The name 'Quality of Service Requirement' was suggested as alternative to 'nonfunctional requirement' or 'quality attribute' in MSF for Agile Software Development by Sam Guckenheimer. In retrospect, I believe that it was a good idea. 'Nonfunctional requirements' always sounded to me like the way that nasty tasting cough syrup tastes. If you implement a nonfunctional requirement, does your system become nonfunctional? For all who like that name, I am just kidding....

Quality attributes have been studied extensively by the Software Engineering Institute. I first heard about the relationship between quality attributes and scenarios at SD East in Boston this year. As MSF for Agile Software Development utilizes scenarios to achieve a finer level of granularity than use cases, I am always eager to see what others are doing to improve them. I discovered the SEI work after we had adopted an internal Microsoft approach called LAAM which may or may not have been based on it. LAAM and quality attributes are surprisingly similiar.

Nonfunctional requirements, quality attributes, and quality of service requirements are names for the constraints on functional requirements such as performance, security, and platform. There are certainly many more types of quality of service requirements than these but these three are the most common. The important aspect of a quality of service requirement is that it does not describe functionality but instead constrains other functionality, the presentation of that functionality, the implementation of that functionality, or its environment. Since there are many different types of qualities of service, the format varies. For example, we can just list the platforms that we must support (the most important being Microsoft Windows, of course) if all of our functionality is available on each of the platforms.

Life gets tricky when you start getting specific. For example, we can't ask for our system to be 'fast'. 'Fast' is poorly defined and probably in the eye of the beholder. I remember a requirement in one of the requirements documents that I received as a developer asking for the system to be 25% faster. This may have been achievable but it would have been a complete waste of time. For most systems, 20% of the functionality is used 80% of the time. Therefore, optimizing the other 80% of the functionality may yield diminishing returns. In describing quality of service requirements such as performance, we should target specific areas.

For those quality of service requirements that need to target an area, we use the following format: context, stimulus, response. For example, consider the quality of service requirement,

"During a catalog search, return the search results in under 3 seconds.”

"During a catalog search" is the context, "return the search results" is the stimulus, and "in under 3 seconds" is the response. For any targeted quality of service requirement, you can use this format. The context and stimulus should appear in a scenario for any externally visible quality of service requirement.

Quality of service requirements have the greatest impact on the architecture. A good architecture will facilitate easier delivery of quality of service requirements. But then a good architecture is important for so many reasons.