The objective of this article is to help business analysts deal with the task of eliciting and documenting non-functional requirements (NFRs) - also known as Quality Requirements. It describes NFR fundamentals in terms of who, what, when, where, and why. It’s considered one easy lesson because my series on functional requirements needed nine articles, and my series on data fundamentals needed 10 (see Series).
This article assumes that the NFRs are wanted in relation to a software-based solution to a business problem or opportunity. Also assumed is that there are or will be functional requirements for the solution.
NOTE: The term discussion is used in this article to generically represent the use of any elicitation technique preferred or most suitable to a given situation.
Why
The old saying “You get what you pay for” is very applicable to software-based solutions. From a functional perspective, the more you pay, the more functionality you get. From an NFR perspective, the more you pay, the more quality you get (or don’t get, for lack of specifying/paying).
Some NFRs address quality aspects of the solution’s development such as Maintainability. Others address the functionality once the solution is in operation (e.g. Availability). Category-level NFRs (see Who section below) can be useful during package selection – asking vendors to identify their software’s support for things like Security or Localization.
What
Each NFR is intended to describe a level of quality of a particular type – commonly referred to as an NFR Category. The following are commonly identified as categories potentially relevant to software-based solutions:
- Availability
- Compatibility
- Localization
- Maintainability
- Performance
- Portability
- Reliability
- Scalability
- Security
- Usability
IIBA BABOK V3 includes the above along with five others. Wikipedia, on the subject of NFRs, also includes these along with dozens more.
Ideally a reusable set of NFR categories is maintained within the organization (e.g. by its BA Practice, or included within a Requirements Document template). If not, part of the task of eliciting NFRs includes establishing a candidate set.
The objective for the BA is to use this list to determine which of the possible categories are considered to be applicable within the context of the solution. This is done in conjunction with appropriate stakeholders (see next section).
Who
The term Stakeholder is commonly used to identify types of people that could potentially have a role in requirements for a software-based solution. This can include decision makers, internal and/or external users of the system, and individuals in various roles related to design, development, testing, and eventual operation of the system.
However, stakeholders initially needed for NFRs should be individuals able to confirm which categories should be discussed in relation to a given solution. These can include:
- Funding approvers – (e.g. Project Sponsor, Product Owner)
- Managers of solution-impacting business areas (e.g. Finance, HR, Information Systems)
- Persons in the organization having specialist responsibilities (e.g. Legal, Security)
Those individuals, or delegates, should be informed about the chosen solution and its defined scope. Given this functional context, the set of potentially-applicable NFR categories should be gone through. The objective is to identify the specific categories believed to warrant subsequent discussion regarding quality. Each of these should be documented as a category-level NFR.
For example:
“The Customer Self-Service Web Portal [solution] shall provide Localization.”
Stakeholders subsequently invited to participate in a discussion of a category-level NFR should be subject matter experts (SMEs) who have either solution-related business knowledge or information systems technical knowledge. Justification for each’s involvement is based on their relation to one of the stakeholders that indicated interest in the NFR category. Depending on the category, SMEs may all come from the business, all be technical, or a combination.
Examples:
Localization – The need for a solution to accommodate different languages, currencies, etc. is a business decision. The details come from business SMEs. These details include the specific types of localizations needed, and at some point, the specific instances (e.g. specific languages, currencies, etc.). From a requirement perspective there should not be any technical details that need to be identified.
Maintainability – Maintainability, while desirable from a business perspective, requires technical expertise to specify and/or evaluate. Details of what constitutes maintainability should come from technical SMEs. During bespoke design/development those SMEs should monitor the deliverables for the specified level of quality.
Availability – Typically, Availability is a technical responsibility. The solution is expected to be ‘running’ when needed. The running of software involves hardware and, in most cases, some form of network capability. If either or both is outsourced, IT maintains and monitors service level agreements. But the specific needs for availability come from business users. Therefore, both business and technical SME stakeholders should participate in detailed discussions.
When
There are two fundamental aspects of when NFRs should be addressed. The first involves when the identification of specific NFR categories applicable within the context of a chosen solution should be done. The second involves when the subsequent detailed discussion for a given category should happen.
Identifying stakeholder interest in specific NFR categories for a solution should not take place before a possible solution to a business problem or opportunity has been chosen for implementation. Where the solution involves an information system, some form of description of the system’s context in relation to other systems and/or users should be available as an input to this activity. See Scope = High-Level Requirements.
When NFR details for a given category-level NFR should be discussed varies based on two factors – when input details specific to the category become available and when its output details are needed.
Examples:
Maintainability – Maintainability quality comes from industry standard design principles being followed as part of solution development. A SME in such principles would be needed be able to identify applicable ones (i.e. inputs to the detailed discussion). Details of those principles should be available as inputs to bespoke development design (i.e. outputs from of the detailed discussion).
Availability – If SME stakeholders indicate that every functional capability of the solution needs to be available 24/7 then that is the only input detail needed (often expressed as a percent value of “99.99…”). That detail needs to be confirmed (i.e. becomes an output) in time for support for that level of availability to be implemented.
If the solution includes online capabilities not required 24/7, or scheduled capabilities such as periodic reports, those availabilities should be discussed as part of detailed functional requirements for each of capability. In cases of non 24/7 or scheduled capability availability, those details are typically not needed until after detailed requirements signoff has occurred.
Where
Where NFRs should be stored is the same place that the solution’s functional requirements are stored. The objective is that any solution stakeholder can locate and access:
- NFRs that they have a stake in
- NFRs of a specific category
- Related Requirements (Functional or Non-Functional)
- NFR Details (See next section)
A Requirements Management (RM) or Application Lifecycle Management (ALM) Tool would be expected to support all of the above, either out of the box or utilizing available extension capabilities. The ability to selectively report in business-friendly document form provides the best of both worlds.
Where an RM/ALM tool is not available, a template-based Spreadsheet, with its filtering capabilities, provides quick and easy access to user-specific details.
NOTE: See Tool Support for a discussion of template-based spreadsheets and RM/ALM options.
Many organizations still utilize template-based documents (e.g. a BRD) for managing requirements. Users are left to navigate through these based on hierarchical section structure or “Find” searches. Navigation links are possible but need to be maintained manually by the document authors.
NFR Details
A category-level NFR in “Shall” format is very high-level – similar to an Epic or Feature-level user story. It’s expected to be a single sentence containing just enough information to be the “… start of a conversation…” at a later point in time. As part of the planning for the follow-on discussions of a given category-level NFR, identifying its lower-level topics should be considered.
Examples:
Useability – E.g. “Look and Feel”, “User Training”, “FAQs”
Security – E.g. “Authentication” and “Access”
Localization – E.g. “Language”, “Currency”
Each lower-level NFR should be associated with its parent category, and the NFR itself be stated as a single sentence.
For example – the category-level NFR “The Customer Self-Service Web Portal [solution] shall provide Localization.” associated with two specific sub-categories:
“The Customer Self-Service Web Portal shall support specific languages.”
And
“The Customer Self-Service Web Portal shall support specific currencies.”
NOTE: An NFR could be expressed in user story format. But when a story-level NFR is “refined’ should be as described in the when section above. Not as it approaches the top of a story backlog based on its stated value.
As with functional requirements, the BA is responsible for bridging the gap between business users and solution providers. With NFRs, the details involved differ from category to category. The Who section above described types of users that should be involved. Solution SMEs should be able to identify the types of details needed for a given category. Business SMEs should then be able to fill in those details.
Take-away Points
A business analyst tasked with eliciting and documenting NFRs should have an appreciation of the following fundamentals:
Why – Quality has a cost, as does lack of quality.
What – Ultimately a solution’s scope includes specific NFR Categories to be addressed.
Who – Decision makers identify quality categories; SMEs provided the details.
When – NFR detail needs to be available in time for that quality to be actioned.
Where – Requirement management applies equally to functional and non-functional.
Detail – Category-specific, SME-driven requirement details.
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].