Non-functional requirements, also known as quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues. The following diagram, which overviews architectural views and concerns, provides a great source of NFR types (the list of concerns). Good sources for NFRs include your enterprise architects and operations staff, although any stakeholder is a potential source for NFRs.
Why Are NFRs Important?
Stakeholders will describe non-functional requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope. Considering NFRs early in the lifecycle is important because:
- NFRs drive important architecture decisions. When you are identifying your initial technical strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
- NFRs will drive some aspects of your test strategy. Because NFRs tend to be cross-cutting, and because the tend to drive important aspects of your architecture, they tend to drive important aspects of your test strategy. For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.
- NFRs will drive acceptance criteria for functional requirements (such as stories). are typically system-wide thus they apply to many, and sometimes all of your functional requirements. Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfills its overall quality goals, including applicable NFRs. This is particularly true with life-critical and mission-critical solutions.
As you can see in the goal diagram above, there are three basic strategies, which can be combined, for capturing NFRs:
- Technical stories. A technical story is a documentation strategy where the NFR is captured as a separate entity that is meant to be addressed in a single iteration. Technical stories are in effect the NFR equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
- Acceptance criteria for individual functional requirements. Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria. Many of these acceptance criterions will reflect NFRs specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”. So in effect NFRs are implemented because they become part of your “done” criteria.
- Explicit list. Capture NFRs separately from your work item list in a separate artifact. This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements. In the Unified Process this artifact was called a supplementary specification.
Of course a fourth option would be to not capture NFRs at all. In theory I suppose this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders. This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).