Strategies for Capturing Quality Requirements

 

Quality requirements, also known as non-functional requirements (NFRs), 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 quality requirement types (the list of concerns).  Good sources for quality requirements include your enterprise architects and operations staff, although any stakeholder is a potential source for them.

Figure 1. Architectural views and concerns.

Why Are Quality Requirements Important?

Stakeholders will describe quality 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 quality requirements early in the lifecycle is important because:

1. Quality requirements drive important architecture decisions. When you are identifying your architecture strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
2. Quality requirements will drive some aspects of your test strategy. Because they tend to be cross-cutting, and because they 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.
3. Quality requirements will drive acceptance criteria for functional requirements (such as stories).  Quality requirements 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 quality requirements.  This is particularly true with life-critical and mission-critical solutions.

Capturing Quality Requirements

Figure 2 depicts the goal diagram for Explore Scope.  As you can see, there are several strategies for exploring and potentially capturing quality requirements.

Figure 2. The goal diagram for Explore Scope (click to enlarge).

Let’s explore the three strategies, which can be combined, for capturing quality requirements:

1. Technical stories.  A technical story is a documentation strategy where the quality requirement  is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the quality requirement 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.
2. 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 quality requirements 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 quality requirements are implemented because they become part of your “done” criteria.
3. Explicit list.  Capture quality requirements 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 quality requirements at all.  In theory 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).

Related Resources

• Strategies for Implementing Quality Requirements
• Strategies for Verifying Quality Requirements
• Develop Test Strategy
• Identify Architecture Strategy