Prioritizing Software Quality Requirements

You can’t have the maximum value for all quality characteristics. Here’s how to decide which are most critical.

Image by creativeart on Freepik

In an ideal universe, every software product would exhibit the maximum value for all quality attributes. The system would always be available, never fail, instantly supply results that are always correct, block all unauthorized accesses, and never confuse a user. Wouldn’t that be great?

In reality, though, trade-offs and conflicts between certain attributes make it impossible to optimize all of them simultaneously. You have to determine which attributes are most important to your project’s success, and then state specific objectives for them so designers can make appropriate choices. This article describes an approach for identifying and specifying the most important quality attributes for your project, adapted from consultant Jim Brosseau’s method.

Step 1: Start with a broad taxonomy

Begin with a rich set of quality attributes to consider, such as those listed in Table 1. There are many others, but these are the attributes that apply most commonly to software-containing products This broad starting point reduces the likelihood of overlooking an important quality dimension.

Table 1. Some common software quality attributes

Step 2: Reduce the list

Engage a cross-section of stakeholders to assess which of the attributes are likely to be important to the product. For instance, an airport check-in kiosk for travelers must emphasize usability (because most users will encounter it infrequently) and security (because it has to handle payments). Attributes that don’t have much impact on your project’s success need not be considered further.

Step 3: Prioritize the attributes

Prioritizing the pertinent attributes sets the focus for future elicitation discussions. Pairwise ranking comparisons can work efficiently with a small list of items like this. Figure 1 illustrates how to use Jim Brosseau’s spreadsheet to assess the quality attributes for an airport check-in kiosk.

Figure 1. Sample quality attribute prioritization for an airport check-in kiosk.

For each cell at the intersection of two attributes, ask yourself, “If I could have only one of these attributes, which would I take?” Entering a less-than sign (<) in the cell indicates that the attribute in the row is more important; a caret symbol (^) points to the attribute at the top of the column as being more important.

For instance, comparing availability and integrity, I conclude that integrity is more important. The passenger can check in with the desk agent if the kiosk isn’t available, but passengers will be very unhappy if the kiosk doesn’t show the correct information. I put a caret in the cell at the intersection of availability and integrity, pointing up to integrity as being the more important.

The spreadsheet calculates a relative score for each attribute, shown in the second column. In this illustration, security is most important with a score of 7, closely followed by integrity at 6 and usability with a score of 5. Though the other factors do indeed contribute to success—it’s not good if the kiosk crashes halfway through check-in, so reliability matters—the fact is that not all quality attributes can have top priority.

Prioritization helps you focus elicitation efforts on the key attributes and helps you know how to respond when you encounter conflicting requirements. In this example, elicitation would reveal a desire to achieve specific performance goals, as well as some specific security goals. These two attributes can clash because adding security layers can slow down transactions. Because the prioritization revealed that security is more important (with a score of 7) than performance (with a score of 4), you should bias the resolution of any such conflicts in favor of security.

Step 4: Elicit specific expectations for each attribute

Users won’t know how to answer questions such as “What are your interoperability requirements?” or “How reliable does the software have to be?” The business analyst must ask questions that explore the users’ expectations and lead to specific quality requirements that help developers create a delightful product.

For instance, following are a few questions a BA might ask to understand user expectations about the performance of an information system that manages patent applications that inventors have submitted:

1. What would be a reasonable response time for retrieval of a typical patent application in response to a query?
2. What would users consider an unacceptable response time for a typical query?
3. How many simultaneous users do you expect on average?
4. What’s the maximum number of simultaneous users that you would anticipate?
5. What times of the day, week, month, or year have much heavier usage than usual?

Consider asking users what would constitute unacceptable performance, security, or reliability. That is, specify system properties that would violate the user’s quality expectations, such as allowing an unauthorized user to modify a file. Defining unacceptable characteristics lets you devise tests that try to force the system to demonstrate those characteristics. If you can’t force them, you’ve probably achieved your quality goals.

Step 5: Specify well-structured quality requirements

Simplistic quality requirements such as “The system shall be user-friendly” or “The system shall be fully available 24×7” aren’t useful. The former is far too subjective and vague; the latter is rarely realistic or necessary. Neither is measurable. Therefore, the final step in this process is to craft specific and verifiable requirements from the information that was elicited regarding each quality attribute.

When writing quality requirements, keep in mind the SMART mnemonic—make them Specific, Measurable, Attainable, Relevant, and Time-sensitive. If a quality requirement isn’t measurable, you’ll never be able to determine if you’ve achieved it. The notation called Planguage is an excellent tool to facilitate precise specification of quality attribute requirements.

Satisfying the user’s quality expectations is a powerful contributor to software project success. Wise business analysts will explore quality attributes as diligently as they elicit the system’s functional requirements.

Authors: Karl Wiegers and Joy Beatty

This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. Karl is the author of numerous other books, including Software Requirements Essentials (with Candase Hokanson), Software Development Pearls, The Thoughtless Design of Everyday Things, and Successful Business Analysis Consulting. Karl thanks Jim Brosseau for sharing his tools for prioritizing quality attributes.