Thus far in this journey to determine reasonable quality requirements for our project, we have taken steps to determine which areas of quality are most important for us to focus on. Starting with a thorough landscape for quality, we are now at a point where we can reasonably identify our specific project needs.
Unfortunately, the terms or attributes we have used to this point are not easily framed in a quantifiable fashion. To specify “the system shall be user friendly” brings us no closer to testable requirements, and a reasonable approach to getting to more appropriate terms is missing from many of today’s prominent sources of information on requirements.
This critical step is actually one that has been around for decades, and is more often found in books related to software quality or quality engineering than to books focused on software requirements. What we need to do here is perform a translation, from the landscape of quality that has ensured we are properly covered, to a corresponding set of criteria that will allow us to specify our desired in appropriate, testable terms.
There are many of these testable criteria that we can choose from. They come from a variety of sources, and it is a safe be that you have identified many of them as specific measures for projects in the past. They can range from specified GUI standards and response times that can support usability, Mean Time to Between Failures and Mean Time to Repair that address availability, and many others.
A couple of key points here. Generally, you will need to identify more than one of these criteria to give you coverage of any one aspect of quality (otherwise, we would simply specify our quality requirements in the original terms we had previously identified). Secondly, most of the criteria we can use will at least partially satisfy more than one of these aspects of quality at the same time (specified error handling mechanisms can support robustness, usability, interoperability and safety, for example). Clearly, if a criterion at least partially satisfies two or more of the attributes we deem as important, it is an attractive one to use.
To aid in the identification of appropriate criteria for your project, I have provided a mapping between the attributes we have been discussing over the past few weeks and a set of criteria that has grown as more sources are identified. This is captured in a spreadsheet that maps these relationships, and supports all the other steps identified in this series. It can be found here, and is free to download and use on your projects. This is by no means closure on the list of possible criteria: grow the table based on your experience, and it can be a strong resource for you and the rest of the organization for future projects.
This table has grown from a number of different sources. When reviewing current requirements-based books for quality requirements, we get a few examples of terms that are used for specific quality attributes (such as response times for usability), but nowhere near a list that covers all criteria, and no discussion of the need to perform the orthogonal mapping identified here. Indeed, in one popular text, the author simply laments “the fuzzy notion of usability”. Instead, we need to dive into Quality based references, such as Software Quality Assurance by Daniel Galin or Software Quality Engineering by Michael S. Deutsch and Ronald R. Willis, for a more complete set.
There are some very interesting candidate criteria in this table, many of which help underline the notion that we should consider quality for the system, rather than simply for the software component of that system. Imagine, for example, a system requirement to support maintainability and reusability that specifies key documents that are maintained and readily available in a specified form and location, for a specified time. While not testable by running code, this is a strong requirement for a system that will be fielded and maintained for decades.
All this is a long-winded way of saying that once we have identified the important attributes of quality for our project (as discussed in the previous two weeks), we need to then identify a set of measurable criteria that will give us reasonable coverage of these attributes. These will provide the terms we use to identify our measurable quality requirements, and as with the functional requirements, we need to continue to specify these elements until we have reached a point where we have adequately addressed the quality needs of our system.
Now that we have the appropriate terms that we can use to specify quality, we start to get into more familiar requirements territory. Next week we will bring this all together and show how the characteristics of good requirements statements apply as much to quality requirements as they do to the functional requirements. – JB