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
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
of quality requirements translate into categories of technical information.
[TABLE]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:
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.
