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.

A functional requirement can legitimately name a capability such as exporting audit records, supporting offline work, or enforcing an access rule. That does not automatically select a product or algorithm. The problem is an implementation preference presented as a necessity without a supporting need or constraint. For example, requiring permitted records with source references leaves room to compare retrieval designs; mandating a vector database narrows that choice and therefore needs its own justification. Test required capabilities rather than dismissing all feature requirements as premature design.

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. Where the choice is architectural and the reasoning matters later, the place for it is an architecture decision record, not the requirement.

Record the source or derivation of each requirement

Record the need, constraint, or approved derivation of each requirement, with bidirectional traceability, followed forward to tests and evidence as well. A requirement may also be derived from an approved design or established practice rather than directly decomposed from a parent. NASA recognizes such self-derived requirements and requires appropriate higher-level concurrence. Record that derivation and approval; investigate an unexplained requirement without assuming that every parentless requirement is a preference. 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’s response latency. 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
• NASA, Requirements Management