Need, Requirement, and Design Choice

A need describes what a person or organization must accomplish. A requirement states a capability, quality, or constraint that a solution must satisfy for the need to be met. A design choice is one way of satisfying a requirement. Keeping the three apart stops a preferred product from being written down as if it were unavoidable.

Three sentences about one lookup

“Find the relevant order evidence for an invoice” is a need. “For supported identifiers, return matching permitted records with source identifiers, and mark no-match instead of inventing one” is a requirement. “Use a vector database” is a design choice. An exact-identifier lookup may be served by the database the organization already runs; a semantic search engine addresses a different need, such as finding documents by meaning. Writing the design choice in the requirement’s place would exclude the simpler option before anyone tested it.

NASA’s requirement-writing checklist states the rule directly: requirements should say what is needed, not how to provide it. When an implementation must be named, because of a mandated platform, an existing contract, or a supported operating environment, record that source and its owner so that the sentence is recognized as a constraint rather than a preference.

Trace each requirement to something above it

Every requirement should point to the need or constraint it serves. A requirement with no parent is either a hidden preference or a missing piece of the need statement; either way it deserves a question. GOV.UK’s guidance on defining user needs extends “user” beyond the person at the screen to the people who must deliver, support, and pay for the technology, so their needs produce requirements too.

A workflow outcome is not a component requirement. Preparing an evidence packet in six minutes describes the clerk’s work; displaying a lookup result in two seconds describes one component. Both are written and measured separately, because meeting one does not demonstrate the other.

References: NASA: How to write a good requirement, GOV.UK: Define user needs. Examples here are illustrative.