Requirements quality attributes examined

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.

Why does requirements quality matter?

It is often useful to look at things in reverse. Ask oneself, what is the impact of having poor requirements? This graphic illustrates the point that there is a non-linear increase in rework caused by poor requirements.

The cost of poor quality software requirements in generating rework

A comparison of requirements quality attributes according to different sources:

Our view

We recommend something very close to the IIBA BABOK as follows

Clear: unambiguous functional meaning.
Concise: contains no extraneous and unnecessary content.
User-oriented: focusses on what the user needs to achieve.
Complete: both internally complete (all functional steps within a requirement) and as a set, all CRUD events covered
Consistent: user and object names are consistent throughout a set of requirements
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

IIBA - BABOK

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.

IEEE Std 830

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

“An SRS should be:

Correct;
Unambiguous;
Complete;
Consistent;
Ranked for importance and/or stability;
Verifiable
Modifiable;
Traceable.”

RBT Inc

Characteristics of Testable Requirements In order for the requirements to be considered testable, the requirements ideally should have all of the following characteristics: Requirements Based Testing Overview 8

1. Deterministic: Given an initial system state and a set of inputs, you must be able to predict exactly what the outputs will be.

2. Unambiguous: All project members must get the same meaning from the requirements; otherwise they are ambiguous.

3. Correct: The relationships between causes and effects are described correctly.

4. Complete: All requirements are included. There are no omissions.

5. Non-redundant: Just as the data model provides a non-redundant set of data, the requirements should provide a non-redundant set of functions and events.

6. Lends itself to change control: Requirements, like all other deliverables of a project, should be placed under change control.

7. Traceable: Requirements must be traceable to each other, to the objectives, to the design, to the test cases and to the code.

8. Readable by all project team members: The project stakeholders, including the users, developers and testers, must each arrive at the same understanding of the requirements.

9. Written in a consistent style: Requirements should be written in a consistent style to make them easier to understand.

10. Processing rules reflect consistent standards: Processing rules should be written in a consistent manner to make them easier to understand.

11. Explicit: Requirements must never be implied.

12. Logically consistent: There should be no logic errors in the relationships between causes and effects.

13. Lends itself to reusability: Good requirements can be reused on future projects.

14. Terse: Requirements should be written in a brief manner, with as few words as possible.

15. Annotated for criticality: Not all requirements are critical. Each requirement should note the degree of impact a defect in it would have on production. In this way, the priority of each requirement can be determined, and the proper amount of emphasis placed on developing and testing each requirement. We do not need zero defect in most systems. We need good enough testing.

16. Feasible: If the software design is not capable of delivering the requirements, then the requirements are not feasible.

Extracted from Requirements Based Testing Process Overview

Some Agile Coaches Recommend

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.

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.

In the table shown, the columns mean:

The quality score of the individual requirement (with some consideration for context) test for 350+ words, phrases and linguistic patterns for clarity.
Clear & Functional Contains unambiguous statement(s) of functionality (description of data movements) .
User-oriented A user is identified as the subject within the requirement, performing an action with data.
Concise the ratio of words to functional size, within reasonable boundaries
Measurable & testable If functional intent is detected, then it is measurable and testable, again we are determining if there was clear functional intent.
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.
Complete (buried functionality) functionality detected in the notes/acceptance criteria that should have been in the requirement itself.
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:

Quality score for each individual requirement
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.