What Drives Quality: Requirements

My 2nd book What Drives Quality is available on Amazon, in my webshop, and in all other major bookstores.

This second posting on “What Drives Quality” investigates factors that drive the quality of requirements. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money. 

With requirements I mean activities for specifying the products to be developed and supporting activities such as requirements clarifications, reviews and inspections, and requirements management and tracing. Indepent of which development method (RUP, Agile, etc) is used, you need to create an common understanding and agreement between the order of a product, and the developers.

Some of the factors that drive Requirements Quality are:

 

  1. Requirements Management Capability – Skill and experience level of the professionals who are doing the requirements managing activities.
  2. Requirements Commitment – Agreements between the strategic product manager and the project managers, where the project/team commits to deliver certain functionality.
  3. Requirements Stability – Inverse of the amount of requirement changes over time. (The less changes, the higher stability.)
  4. Requirements Process Maturity – The quality of the defined and baselined requirements management processes, including all supporting material such as training and templates.
  5. Roadmap Quality – Usability of the roadmap with respect to requirements management for projects (e.g., information about when to develop which product versions; quality of the business case for a product version; allocation of scope to a version, decisions about product introduction, end of maintenance, and phase out dates).
  6. Scope Stability – Impact of major changes in projects that are related to changes in the product roadmap, including stability of the products to be developed, development teams involved in projects, and major changes in project funding or delivery dates.
  7. Root Cause Analysis – Capability to learn from defects found during development. (By analyzing defects, determining common causes (related to processes, tools, and development environment, capabilities, management and organization), and defining actions to prevent them from recurring.
  8. Requirements Definition Capability – The skill and experience level of the people doing requirements definition (e.g., product managers).

 

To give a background on this list of requirements quality factors, let discuss some of them. Many organizatation struggle with changing requirements. The scope of their projects is unstable, which can have major impact on the quality of the developed products. Managing scope stability, for instance by using Agile methods to stabilize requirements for an interation is a solution that can increase the quality (and efficiency) of their development projects. Also risk management techniques can be used to identify potential changes, and to take action to prevent the changes, for instance by clarifying requirements or reducing the project scope before starting development.

Another factor, Requirements Definition Capability, has to do with how you communicate requirements. Using a requirement specification document (or any other written format) has shown to often lead to confusion, resulting in developing the wrong product that the customer doesn’t need. Richer communication techniques, like discussing the requirements, requirement clarification workshop, and planning games in agile where requirements are verified with product owners and mapped into engineering tasks have proven to significantly reduce requirements unclearness.

Do you recognize the quality factors mentioned in the list above? Do they play a role in your organization, or are there other factors that influence requirements quality? Feel free to react, and share your experience!

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 3 Comments

  1. Hi Ben,
    I was led a stray by the title. I think it should be: what drives quality of requirements.
    About number 3: I agree, but I think it has nothing to do with the real world, where requirements do change.

    1. Hi Cecile,

      Yes, requirements do change, but the way to you manage changes can have serious impact on the quality of your products. Ignoring change, or putting a difficult process in place to prevent changes from entering the development project is not a solution. Embracing change, for instance by creating stable iterations and introducing changes at specific points in a project usually works much better!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

×
×

Cart