Skip to content

Software Quality

Requirements quality checking

Requirements quality checking is a review of a draft specification against a set of quality rules before any code is written. It reduces uncertainty about the spec itself: that it is implementable, internally consistent, and means something definite.

It runs before the other verification methods because a working spec is their input. Tests check whether code matches the spec; types check whether the code's shape matches the declared shape; contracts check whether runtime behavior matches the declared contract.

What it catches

  • Ambiguity. A requirement reads more than one way when a word has several meanings, a sentence has more than one parse, or a pronoun's antecedent is unclear (Berry et al. 2003)1.
  • Unverifiability. No test can prove the requirement true or false once the system is built (Mavin et al. 2009)2. The system shall be secure is one. Open-ended terms ("low latency") and superlatives are the wording that produces it (Femmer et al. 2017)3.
  • Compound requirements. One requirement packs several interrelated statements (Mavin et al. 2009)2. None of them can then be traced, tested or changed on its own.
  • Inconsistency. The set breaks a relationship that should hold between its requirements (Nuseibeh et al. 2000)4. The strong form is a contradiction no system satisfies; the weak form is a divergence, two requirements that conflict only under some boundary condition (Lamsweerde et al. 1998)5. Quality-attribute requirements diverge this way, because an architecture strategy that serves one attribute can cost another (Boehm and In 1996)6.
  • Incompleteness. Information is left "to be determined", entities go undefined, or a need is never written down, and the last cannot be measured absolutely, since the only complete specification is the system itself (Zowghi and Gervasi 2003)7. Requirements for unwanted behavior, such as a network failure mid-transaction, are the usual omission (Mavin et al. 2009)2.
  • Terminology drift. A term's meaning shifts during the project, so one word carries several related meanings even where a glossary defines it (Berry et al. 2003)1.
  • Untraceable requirements. A requirement whose origin is unclear, or which cannot be referenced from the design and tests that realize it, cannot be followed through its life (Gotel and Finkelstein 1994)8.

What it does not catch: whether the spec describes the right thing for the business or the user. That's product management, not verification.

Why pre-implementation verification matters

A spec ambiguity that ships becomes a misimplemented feature, a failed acceptance test, a production bug, or a customer-reported defect.

Standards, notation, and tooling

The method checks a draft against an explicit rule set:

  • INCOSE Guide for Writing Requirements — INCOSE's rules for what a "good requirement" is.
  • EARS notation (Easy Approach to Requirements Syntax) — five sentence templates that give each requirement a fixed clause order and a small set of keywords, to cut ambiguity, vagueness and incompleteness.
  • ISO/IEC/IEEE 29148 (ISO/IEC/IEEE 2018)9 — the international standard for requirements engineering; defines the quality characteristics, among them necessary, unambiguous, complete, consistent and verifiable.

QuARS (ISTI-CNR) analyzes a natural-language requirements document automatically (Gnesi et al. 2005)10, with lexical and syntactic rules that flag optionality, subjectivity, vagueness, weakness, implicity, multiplicity, and under-specification.

When to use, when not

Use when:

  • Regulated industry (aerospace, automotive, medtech). The standards mandate it.
  • Large teams with multiple authors of the spec.
  • Long-lived specs that will be the source of truth for years.
  • Multi-stakeholder projects where ambiguity between product, engineering, and legal will cost weeks of rework.

Don't use when:

  • One PM, one engineer, throwaway project: the overhead outweighs the benefit.
  • The spec is executable (a TLA+ model, a Quint spec, a decision table). A mechanical check replaces the review there: a decision table surfaces contradictory rows as duplicates, and a model can be model-checked against separately stated properties (executable specifications).
  • The product is being discovered through user research rather than specified up front. A formal spec quality check on a one-page hypothesis is wasted effort.

Evidence

Fagan puts rework early in the process at 10 to 100 times cheaper than rework in the last half of it (Fagan 1976)11; the paper asserts that ratio rather than measuring it, and what it does measure is how many defects an inspection finds. The claim is about an adjacent method, design and code inspections, extrapolated one stage earlier to requirements, so the support for requirements quality checking is an extrapolation rather than a measurement of it.

Classification

  • Quality dimensions: Functionality (the what side: the spec must describe what we mean before any verification can check whether the code matches it).
  • Area: Requirements engineering, specification authoring, pre-implementation verification. Most evidence comes from regulated industries (aerospace, automotive, medtech) where formal requirement management is mandated.

Referenced by

References

  1. Berry, Daniel M., Erik Kamsties, and Michael M. Krieger. 2003. From Contract Drafting to Software Specification: Linguistic Sources of Ambiguity — A Handbook. Version 1.0, University of Waterloo. https://cs.uwaterloo.ca/~dberry/handbook/ambiguityHandbook.pdf. ↩↩

  2. Mavin, Alistair, Philip Wilkinson, Adrian Harwood, and Mark Novak. 2009. "Easy Approach to Requirements Syntax (EARS)." Proceedings of the 17th IEEE International Requirements Engineering Conference (RE '09). https://doi.org/10.1109/RE.2009.9. ↩↩↩

  3. Femmer, Henning, Daniel Méndez Fernández, Stefan Wagner, and Sebastian Eder. 2017. "Rapid Quality Assurance with Requirements Smells." Journal of Systems and Software 123. https://doi.org/10.1016/j.jss.2016.02.047. ↩

  4. Nuseibeh, Bashar, Steve Easterbrook, and Alessandra Russo. 2000. "Leveraging Inconsistency in Software Development." Computer 33 (4). https://doi.org/10.1109/2.839317. ↩

  5. Lamsweerde, Axel van, Robert Darimont, and Emmanuel Letier. 1998. "Managing Conflicts in Goal-Driven Requirements Engineering." IEEE Transactions on Software Engineering 24 (11). https://doi.org/10.1109/32.730542. ↩

  6. Boehm, Barry, and Hoh Peter In. 1996. "Identifying Quality-Requirement Conflicts." IEEE Software 13 (2). https://doi.org/10.1109/52.506460. ↩

  7. Zowghi, Didar, and Vincenzo Gervasi. 2003. "On the Interplay Between Consistency, Completeness, and Correctness in Requirements Evolution." Information and Software Technology 45 (14). https://doi.org/10.1016/S0950-5849(03)00100-9. ↩

  8. Gotel, Orlena C. Z., and Anthony C. W. Finkelstein. 1994. "An Analysis of the Requirements Traceability Problem." Proceedings of the IEEE International Conference on Requirements Engineering (ICRE '94). https://doi.org/10.1109/ICRE.1994.292398. ↩

  9. ISO/IEC/IEEE. 2018. ISO/IEC/IEEE 29148:2018 — Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. ISO. https://www.iso.org/standard/72089.html. ↩

  10. Gnesi, Stefania, Giuseppe Lami, Gianluca Trentanni, Fabrizio Fabbrini, and Mario Fusani. 2005. "An Automatic Tool for the Analysis of Natural Language Requirements." Computer Systems: Science & Engineering 20 (1). https://iris.cnr.it/handle/20.500.14243/152162. ↩

  11. Fagan, Michael E. 1976. "Design and Code Inspections to Reduce Errors in Program Development." IBM Systems Journal 15 (3): 182–211. https://doi.org/10.1147/sj.153.0182. ↩