Software Requirements Quality

Requirements quality is a matter of some discussion amongst software requirements professionals.  Here are four considered views on software requirements quality, that is what makes for a good requirement or a good set of requirements.

We recommend something very close to the IIBA BABOK as follows

  • Clear: unambiguous functional meaning.
  • User-centric: focusses on what the user needs to achieve.
  • Complete: all functional steps within each requirement and all CRUD events across a set of requirements
  • Consistent: user and object names are consistent throughout.
  • Concise: contains no extraneous and unnecessary content.
  • Measurable: can be sized in COSMIC function points
  • Testable: If it is measurable, it is usually testable too.
  • Valuable :  is necessary for delivering essential user capabilities.
  • Design-free: excludes “how” it should be implemented.
  • Unique: no duplicated functionality across the set of requirements
And the IIBA overview on requirements quality says the following:

While quality is ultimately determined by the needs of the stakeholders who will use the requirements or the designs, acceptable quality requirements exhibit many of the following characteristics”

  • Atomic: self-contained and capable of being understood independently of other requirements or designs.
  • Complete: enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
  • Consistent: aligned with the identified needs of the stakeholders and not conflicting with other requirements.
  • Concise: contains no extraneous and unnecessary content.
  • Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
  • Unambiguous: the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
  • Testable: able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.
  • Prioritized: ranked, grouped, or negotiated in terms of importance and value against all other requirements.
  • Understandable: represented using common terminology of the audience.

Section 4.3 of IEEE Std 830 provides a list of desired quality attributes of a software specification, which are:

“An SRS should be:

  1.  Correct;
  2. Unambiguous;
  3. Complete;
  4. Consistent;
  5. Ranked for importance and/or stability;
  6. Verifiable
  7.  Modifiable;
  8. Traceable.”

The acronym “INVEST” can remind you that good stories are:

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

There is no single standard for what makes up a good quality software requirement.  Furthermore, what may be considered a good requirement for application software will likely differ from a good systems software requirement.

Requirements quality attributes

Automated Requirements Quality Assurance

ScopeMaster tests requirements.  Like SonarQube for requirements, ScopeMaster examines each requirement (or user story) to detect the functional intent and assesses each requirement against the quality criteria listed above.  It cannot detect all the faults,  but it can find about 50% of them.  Once it has analysed the requirements individually, it then examines the requirements in the context of the set of requirements.  This is provides insight that is just not possible with tools like Jira and Azure DevOps, ScopeMaster interprets and analyses requirements, it doesn’t just store them.  This frees up your time to consider other important aspects of your requirements.  It makes your job of improving the requirements quality faster and easier.  It does the hard work for you.

Requirements Quality at a glance

In the table shown, the columns mean:

  1. The quality score of the individual requirement (with some consideration for context) test for 350+ words, phrases and linguistic patterns for clarity.
  2. Clear & Functional Contains unambiguous statement(s) of functionality (description of data movements) .
  3. User-oriented A user is identified as the subject within the requirement,  performing an action with data.
  4. Concise the ratio of words to functional size, within reasonable boundaries
  5. Measurable & testable If functional intent is detected, then it is measurable and testable, again we are determining if there was clear functional intent.
  6. Complete (within the set) means object types that are identified within this requirement found to have complementary CRUD actions to ensure a complete set of maintenance activities across the set of requirements.
  7. Complete (buried functionality) functionality detected in the notes/acceptance criteria that should have been in the requirement itself.
  8. Benefits Has there been an effort to describe the benefits or value of this requirement.

Quality Scoring

ScopeMaster recognises that requirements do not exist on their own.  It understands the context of a set of a requirements and so it determines quality scores at two levels:

  1. Quality score for each individual requirement
  2. Quality score for a set of requirements

ScopeMaster performs hundreds of static and potentially thousands of dynamic tests on each requirement and gives the author immediate feedback.  So you learn to write better requirements as you go.

Requirements Quality Scoring