Those Other Requirements: Quality Attributes and Their Inescapable Trade-Offs
I’ll bet you’ve used software systems that did just what they were supposed to do but you hated them. Maybe they were too slow, or they crashed a lot, or the user interface was clumsy. These are examples of products that satisfied their functional requirements but not your quality expectations.
Not surprisingly, nearly all sets of software requirements focus on functionality, the things a product must be able to do or let the user do. Thoughtful analysts and designers also need to explore various types of nonfunctional requirements. The largest set of these fit in the category of quality attribute requirements, also called quality factors or quality of service requirements. Sometimes they’re called the “ilities” because many of them end in “-ility.”
This article provides a brief introduction to quality attributes and points out the trade-off decisions you’ll need to make among the various attributes. It’s not possible to optimize all of the quality factors at once. You need to determine which ones are most important to customer success and maximize those.
Quality Attribute Requirements
Carefully specifying quality attributes lets you build a product that delights its users, instead of merely doing what it’s supposed to. Excellent products reflect an optimum balance of competing quality characteristics. If you don’t explore the customers’ quality expectations during elicitation, you’re just lucky if the product satisfies them. Disappointed users and frustrated developers are the more likely outcome.
You don’t directly implement requirements concerning safety, reliability, portability, security or other characteristics. Instead, these quality attributes serve as the origin of many functional requirements. They also drive architectural and design decisions.
It costs a lot more to patch a completed system to achieve essential quality goals than to design for them at the outset. Just think of the countless security updates we all receive for operating systems and common applications. Wouldn’t it be nicer if developers spent more time designing for security in the first place?
The term “quality attributes” encompasses several dozen product characteristics. I’ve seen lists identifying 50 or more attributes. Most project teams need to consider only a handful of them. If developers know which characteristics are most crucial to success, they can choose appropriate design and construction approaches to achieve the quality goals.
Internal and External Quality Attributes
One way to classify quality attributes distinguishes characteristics that are visible while executing the software (external quality) from those that are not (internal quality). External quality factors are primarily important to users; internal qualities are more significant to developers and maintainers. Internal quality attributes indirectly contribute to customer satisfaction by making the product easier to enhance, correct, test, and migrate to new platforms.
Table 1 briefly defines several internal and external aspects of quality every project should consider. Certain attributes are of particular importance on specific types of projects:
- Internet and corporate applications: availability, integrity, interoperability, performance, scalability, security, usability
- Embedded systems: performance, efficiency, reliability, robustness, safety, security, usability
- Desktop and mobile systems: performance, security, usability
You might need to emphasize different quality attributes for different system components. Performance could be critical for certain components, while usability or security is paramount for others. Also, your products might have other unique quality attributes I didn’t list here. Gaming companies might want to capture emotional requirements for their software, for instance.
Quality Attribute Trade-Offs
Certain attribute combinations present inescapable trade-offs. Customers and developers must decide which attributes are more important than others, and they must respect those priorities when they make design trade-off decisions.
Figure 1 illustrates some typical interrelationships among the quality attributes from Table 1, though there are exceptions. A plus sign in a cell indicates that increasing the attribute in the corresponding row usually has a positive effect on the attribute in the column. For example, design approaches that increase a software component’s portability also make the software easier to connect to other software components (interoperability), easier to reuse (reusability), and easier to test (verifiability).
A minus sign in a cell means that increasing the attribute in that row generally adversely affects the attribute in the column. An empty cell indicates that the attribute in the row has little effect on the attribute in the column.
Performance and efficiency have a negative impact on most other attributes. If you write the tightest, fastest code you can, using coding tricks and relying on execution side effects to save some milliseconds, the code will likely be harder to maintain and enhance. It also could be more difficult to port the application to other platforms if you’ve tuned the code for a specific operating environment.
Systems that optimize ease of use and those that are designed to be reusable and interoperable with other software or hardware components often incur a performance penalty. I once led a project to create a general-purpose mainframe component that multiple other applications could invoke to create graphical X-Y plots. This program worked great and saved considerable development time, but it ran slower than applications that incorporated custom graphics code for plotting. You have to balance the possible performance (or other) reductions against your solution’s anticipated benefits to ensure you’re making sensible trade-off choices.
Note that the matrix in Figure 1 isn’t symmetrical. That is, the effect that increasing attribute A has on attribute B isn’t necessarily the same as the effect that increasing B will have on A. For instance, Figure 1 shows that designing the system to increase performance doesn’t necessarily affect security: the cell with row = Performance and column = Security is empty. However, the cell with row = Security and column = Performance contains a minus sign. Increasing security can degrade performance because the system must go through more layers of user authentications, encryption, and malware scanning.
To reach the optimum balance of product characteristics, you must identify, specify, and prioritize the pertinent quality attributes during requirements elicitation. As you define the important quality attributes for your project, use Figure 1 to avoid committing to conflicting goals. Following are some examples:
- Don’t expect to maximize usability if the software must run on multiple platforms with minimal modification (portability). Different platforms and operating systems impose different constraints and offer variable usability characteristics.
- It’s hard to completely test the integrity requirements of highly secure systems. Reused generic components could compromise security mechanisms.
- Highly robust code could exhibit reduced performance because of the data validations and error checking that it performs.
Be careful to avoid unnecessary constraints and conflicting requirements. Those can make it impossible for developers to fully satisfy the requirements. Nobody wins when that happens.
Neglect Quality Attributes at Your Peril!
Quality attribute requirements aren’t like bits of desired functionality you can jot onto a story card and implement whenever the time is right. You need to elicit and analyze these kinds of nonfunctional requirements up front so your team can design the desired balance of product characteristics from the beginning.
Quality attributes permeate the system; they’re not just an optional add-on, to be prioritized with your other functional stories. A thoughtful approach can save you much expensive grief later on when users might otherwise complain about performance, the user experience, reliability, or other important quality characteristics.
Quality — in all its many dimensions — must be baked into a software system, not smeared on at the end.
This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.