Quality Specification

August 26, 2007 by
Filed under: Process 

This is the last of a 4-part series on determining reasonable quality attributes for your projects. In the first three parts, we identified that overall quality can be expressed in a wide range of areas, and it is better to start with this wide range rather than to start with a shorter list that was devised before your project was born.

From there, we looked at different techniques for narrowing the list of attributes and prioritizing the remaining ones, to make our task easier and to ensure that we sufficiently specify the requirements for the areas that are most important to us.

Last week, we took this list and performed a critical translation: from the set of terms that gives us reasonable coverage for quality, to a different set of terms that can be expressed in a quantified form.
Finally, we look at the characteristics of good requirements, provide some tips on how these apply to the approach to quality requirements we are expressing here, and tie the whole process together.

Karl Wiegers suggests 10 characteristics that you should consider when developing your requirements: complete, consistent, correct, feasible, modifiable, necessary, prioritized, traceable, unambiguous, and verifiable. While you will never have a perfect specification, I have found that using this list while reviewing requirements can dramatically improve the results.

To some degree, we deal with several characteristics simply by following the process outlined in this series. Our initial range of quality attributes and disciplined breakdown supports completeness, and the series of steps we take give us a natural traceability that we can retain for future review. If we retain the rationale as part of this process, we have improved the modifiability of the requirements: we will be able to refer back to understand why we made the choices we did, and have better confidence in our modifications as a result.
Prioritization is addressed, but it makes sense to further prioritize your quality requirements in the context of all the requirements to ensure you are focusing on the most important areas of your system. Similarly, the approach supports consistency and necessity by deriving criteria from the attributes, but again these should be considered in the broader context as well.

The final four characteristics (correctness, feasibility, unambiguity, verifiability) all relate to the specific statements we generate from the criteria we have selected. Having translated to measurable criteria helps us for verifiability, but these four characteristics are closely related to one another. There are a number of points to consider when expressing the requirements:

  • Ensure the statements are broken down so that each is uniquely testable.
  • Carefully express the conditions surrounding the requirements, and be sure the statements are written in terms that can be controlled in a test environment.
  • Express valid ranges and boundary conditions where necessary.
  • Specify both expected behavior as well as how the system should behave in exceptional conditions (indeed, this is a key part of expressing quality requirements).
  • Avoid ambiguous terms (such as several, if possible…) or expressing requirements that simply are not feasible (such as instantaneous response).

There are other points to consider beyond these, but you get the idea. Once we have followed the first few steps of this approach, we are left with a set of terms that allow us to express the quality of our system in a manner that is identical to the way we express the functionality.

It is important to follow all of the steps in this series – skip any one and you open yourself up for all kinds of grief:

  • If you fail to start with a broad taxonomy for overall software quality, there is potential for missing an entire area of quality that may be critical. Often, neglected areas of quality are of interest to internal stakeholders: there are no quality requirements to ensure that the system is developed to be testable or maintainable, for example. Left to chance, systems are rarely built to satisfy these critical areas.
  • If you fail to cull the irrelevant attributes and prioritize the remainder, you are making the entire effort of developing quality requirements more difficult than it has to be. Given a finite amount of time to develop requirements, you will be less likely to adequately cover the areas that are most important to you, diminishing the value of the effort overall.
  • If you fail to make the translation from the broad quality attributes to a set of criteria, you will have a tough time expressing the quality of your system in terms that can be objectively verifiable. In addition, failure to make this translation as a conscious part of the overall process will make it more difficult for you to identify criteria that support several of your key attributes at the same time.
  • If you fail to specify these criteria with due consideration to the characteristics of good requirements, you will have gone through this effort and still not developed a solid spec. Indeed, while the first few steps of this process are the equivalent of using reasonable analysis models to derive the functional requirements, this last step of ensuring the statements adhere to these characteristics is common across all requirements.

Much of the effort for identifying quality attributes for a project can be done in a single collaborative session with appropriate stakeholder representatives. Certainly, the narrowing of the broad list and prioritization of those remaining attributes is achievable in an hour’s moderated session. From there, an initial translation may also take place in this group session, or different representatives can be tasked with actions to clarify specific criteria that will support the important quality needs for this project. At this point, simply follow the review and refinement process you use for your traditional functional requirements (you do have one, don’t you?).

Retain all of your decisions along the way. Download and use the spreadsheet provided, follow this process, and expressing software quality will no longer be the difficult process you thought it was. – JB


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    We found the diagnostic very effective in providing a way for our teams to express their views on areas that we need to improve. At the same time, seeing where we were doing relatively well offered some great perspective and encouragement.

    — Michael Nienhuis, VP Operations, Class Software Solutions Ltd.