Nearly every software requirements specification I read consists almost entirely of functional requirements, descriptions of behaviors the product should exhibit under certain conditions. This is a natural emphasis. However, as you explore the requirements for your next system, be sure to also examine nonfunctional software requirements.
The most significant category of nonfunctional requirements also goes by the names software quality attributes, quality factors and quality of service requirements. These requirements don't describe what the system does, but rather how well it does the things it does. They are sometimes called the "ilities" because so many of them end in –ility: usability, portability, reliability, availability and so forth. They don't all end in –ility; others include efficiency, integrity, security, safety, robustness and performance. Some of these attributes (such as usability, availability, safety) describe aspects of external quality that are visible and important to users. Others describe internal quality properties, which are more important to developers and maintainers (testability, maintainability, reusability).
Quality attributes are difficult to specify, yet often they distinguish a product that merely does what it's supposed to from one that delights its users. Deficiencies in any of these quality dimensions have a huge impact on how the customer responds to the product. If you do not explore quality attributes during requirements elicitation, the customers will simply be lucky if they get what they expect.
From a technical perspective, quality attributes drive significant architectural and design decisions. It's far more difficult and expensive to re-architect a completed system to try to achieve essential quality goals than it is to design for them at the outset. The table below indicates typical ways in which specific types of quality requirements translate into categories of technical information.
| Quality Attribute Types | Likely Technical Information Category |
|---|
| Integrity, interoperability, robustness, usability, safety | Functional requirement |
| Availability, efficiency, flexibility, performance, reliability | System architecture |
| Interoperability, usability | Design constraint |
| Flexibility, maintainability, portability, reliability, reusability, testability, usability | Design guideline |
| Portability | Implementation constraint |
I'm afraid I have bad news. Certain attribute combinations have inescapable trade-offs. The most glaring conflict is between efficiency and most other attributes. Nearly any action you take to increase some level of quality is likely to have a negative impact on efficiency. Introducing additional security layers or designing for portability can lead to reduced efficiency. Similarly, optimizing efficiency might have a negative impact on, say, maintainability or portability. So it's essential for users and developers to decide which attributes are most important to the overall success of the product.
As you specify quality requirements, make sure that they are verifiable and are as quantitative as possible. Requirements such as "the system shall be robust" or "the system shall be user-friendly" are meaningless. There's no way to determine exactly what "robust" or "user-friendly" means or how to tell if you've achieved those goals. All requirements should be verifiable. That is, there should always be some way to determine whether a specific requirement has been satisfied. Elements of a well-defined nonfunctional requirement include the following:
- A unique label or identifier, such as Availability.Group1
- A brief statement of the desired system property, such as "To maximize the time during which a set of services is available for use by the members of User Group 1 during a specific time frame."
- A measurement scale that defines exactly what we mean by (in this case) "availability": 100 * (actual hours of service availability during a time period) / (total hours during that time period).
- A statement of exactly how we will perform the measurement to verify whether the requirement has been satisfied: "Start measuring time when a service is not fully functional. Stop measuring when it is again fully functional. 'Hours of availability' equals total hours during that time period minus the hours of downtime."
- One or more target values, of varying degrees of desirability. Perhaps the minimally accepted availability is 95%, the desired objective is 98%, and an ideal outcome is 99.5%. Quality attributes often permit shades of gray like this.
Specifying quality attribute requirements this precisely is certainly more work than a simplistic approach of demanding 24x7 availability. But it's the best way to ensure that all project stakeholders share the same expectations and work toward the same objectives.
-----------------------------------------
About the author: Karl Wiegers is Principal Consultant with Process Impact in Portland, Ore. He is also the author of More About Software Requirements: Thorny Issues and Practical Advice; Software Requirements, 2nd Edition; Peer Reviews in Software: A Practical Guide; and Creating a Software Engineering Culture.
