Skip to content

Software Quality

Requirements quality checking

Requirements quality checking reviews 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

Davis and ISO/IEC/IEEE 29148 both catalog what can be wrong with a requirement (Davis 1993; ISO/IEC/IEEE 2018)1 2:

  • Ambiguity. Vague modal verbs ("the system should be fast"), undefined terms ("the user-friendly interface"), comparators without referents ("low latency", "high throughput"), pronouns without clear antecedents.
  • Inconsistency between requirements. Requirement X says "respond in 100 ms"; requirement Y says "accept uploads up to 5 GB."
  • Incompleteness. Missing error cases, missing non-functional requirements, missing edge cases. "The system processes payments" without specifying what happens on a network failure mid-transaction.
  • Terminology drift. "Customer" in one paragraph, "user" in another, "client" in the API spec — all referring to the same concept, or three different ones.
  • Unmeasurable requirements. "The system shall be secure." No oracle exists; no test can pass or fail against it. INCOSE / EARS notation exists specifically to force measurable phrasing.
  • Conflicting non-functional requirements. Latency vs throughput, security vs usability, cost vs reliability — the standard trade-off matrix, often left implicit and discovered late.
  • Dependency loops. Requirement A depends on B which depends on C which depends on A.

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 force measurable, testable phrasing.
  • ISO/IEC/IEEE 29148 (ISO/IEC/IEEE 2018)2 — the international standard for requirements engineering; defines the quality characteristics (necessary, unambiguous, complete, consistent, verifiable, traceable, modifiable).

QuARS (ISTI-CNR) analyzes a natural-language requirements document automatically (Gnesi et al. 2005)3: 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 bother 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). Those formalisms catch their own inconsistency by construction; see executable specifications and decision tables.
  • 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

On the cost-of-defects direction, Fagan puts rework early in the process at 10 to 100 times cheaper than rework in the last half of it (Fagan 1976)4; 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 the adjacent method, code inspections, extrapolated one stage earlier to requirements, and nothing here measures requirements quality checking itself.

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. Davis, Alan M. 1993. Software Requirements: Objects, Functions, and States. Prentice Hall. https://archive.org/details/softwarerequirem0000davi. ↩

  2. 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. ↩↩

  3. 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. ↩

  4. 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. ↩