Requirements Quality Attributes

ScopeMaster® takes requirements quality seriously with automated testing.

Automated Quality Scoring by ScopeMaster

ScopeMaster® automatically tests each requirement, it performs 350+ static tests covering 9 out of 10 attributes for good practice writing of requirements.  It’s rather like having the experts (Linda Westfall, Karl Wiegers and Robin Goldsmith) check your work as you go.  It assigns a quality score out of 100 and offers an explanation for how to fix each problem found.  It then runs further tests as it cross-references all the requirements details to determine quality attributes relating to the set of requirements

Requirement Quality Score

The ScopeMaster qscore is a value out of 100 for each requirement, calculated on the results of static tests and contextual information. Each of the 350+ static tests has a weight associated with it.

Individual requirements quality testing, recommendations and quality score (qscore)

Requirements Set Quality Score

ScopeMaster® automatically tests the set of requirements giving an overall quality score out of 100.

ScopeMaster assigns a score for a set of requirements quality

Defect Potential

Every software artefact has a predictable quantity of defects when it is created. When you think about it, this makes sense. For every hour a knowledge work spends on something (code, design, requirements etc) they are likely to make a mistake or two each hour. Defect potentials in requirements are the defects that are likely to be in them when they are created. Rather than look at defect potential per requirement, we look at a normalised metric of defect potential per COSMIC Function Point. For example, studies by Capers Jones shows that the average defect potential in requirements vary between 1 – 2 defects per FP in requirements. Knowing this is an important starting point for finding and fixing these defects – if we now know how many requirement defects we need to find we are part of the way to fixing them.

Defect Density

The defect density is an indication of the concentration of defects within the requirements. Whilst you could use an indicator such as defects found per requirement or defects per use case, we recommend defects per CFP as this is a standardised and consistent metric.

Test Scenario - autogenerated by ScopeMaster, illustrated alternative flows

Defects Found

Comprehensive examination and testing of the requirements reveals:

  • potential defects within an requirement, and
  • potential defects across a set of requirements

Techniques for Finding Requirements Defects

First we need to ensure that we know the actual requirements and then we need to be sure to articulate them well, below are lists of techniques for addressing both of these concerns:

Discovering the Real Requirements?
  • Workshops
  • Prototypes
  • Three amigos
  • Backlog refinement
  • Requirements Inspections
  • Simulations and walkthroughs
Articulating the Requirements Well
  • Textual analysis
  • Use case modelling
  • Data modelling
  • User flow modelling
  • CRUD analysis

Requirements Quality Attributes

Requirements Quality Attributes

Many Agile software teams are familiar with the INVEST pneumonic. We think that falls short of good engineering standards for software quality. Instead we work to a more comprehensive set of attributes:

Clear, Concise, User-oriented, Testable, Measurable, Valuable , Design-free Consistent, Complete, Unique, and . The first 6 apply within the context of an individual requirement and the last three look at the quality of this requirement in the context of a set of requirements. No requirement (or user story) should be examined in isolation.

Requirements Quality Concerns

Requirements quality is a big subject, it is also subject to considerable debate and subjective opinion.  Nevertheless, it must not be ignored.  Most software endeavours do not track requirements quality, but they should.  On average 15% – 35% of all production defects are caused by poor or missing requirements.

All Features