What Is a Requirement?

Not a Wish, Not a Description, Not a Specification

A requirement is a statement of need that constrains the solution space. It tells the design team what the system must do or how well it must perform — without dictating how to achieve it. This distinction is fundamental and routinely violated.

"The system should be user-friendly" is a wish. "The dashboard displays real-time sensor data" is a description. "The pump uses a centrifugal impeller with 316 stainless steel housing" is a specification. None of these are requirements.

A requirement says: the system shall do X, under conditions Y, to performance level Z, and here is how we will verify it. If any of those elements are missing, you don't have a requirement — you have a conversation starter.

The Anatomy of a Requirement

Every well-formed requirement has five attributes. Not some of them. All of them.

Shall statement — The core obligation. Uses "shall" to indicate a binding constraint (not "should," "will," or "may"). "The system shall maintain cabin pressure between 75 kPa and 103 kPa during cruise flight."

Performance threshold — A quantified, measurable bound. Not "fast" but "within 200 milliseconds." Not "reliable" but "mean time between failures of at least 5,000 operating hours." If you cannot attach a number or an objective pass/fail criterion, the requirement is not testable.

Verification method — How you will prove the requirement is met. Inspection, analysis, demonstration, or test (the IADT framework). Define this when you write the requirement, not when you write the test plan. A requirement you cannot verify is a requirement you cannot close.

Rationale — Why this requirement exists. What stakeholder need or higher-level requirement drives it. Without rationale, requirements become orphans — nobody knows why they're there, nobody can assess whether they're still relevant, and nobody has the authority to challenge them.

Allocation — Which element of the system architecture is responsible for satisfying this requirement. An unallocated requirement is nobody's problem, which means it's everybody's problem at integration time.

Requirements as Data vs. Requirements as Prose

This is the fundamental shift in digital engineering, and it applies to requirements as much as to design.

Traditional requirements live in paragraphs inside Word documents or PDF files. They are written in natural language, organized by section number, and managed through document version control. Finding all performance requirements, or all requirements allocated to a specific subsystem, or all requirements without a verification method requires reading every page.

Requirements as data means each requirement is a structured record with typed fields: an identifier, a shall statement, a type classification, a performance threshold, a verification method, a rationale, an allocation, a status, a parent requirement, and a set of relationships to design elements and test cases. These records live in a database or a model, not in a document. They are queryable, filterable, traceable, and auditable without human reading effort.

The difference is not cosmetic. When requirements are data, you can run queries: "Show me all performance requirements allocated to the thermal subsystem that have no verification method defined." When requirements are prose, that query is a person reading 300 pages.

Why "The System Shall Be Reliable" Is Not a Requirement

It fails every test:

• Not testable: What test do you run? What result is pass vs. fail?
• Ambiguous: Reliable to whom? Under what conditions? Over what time period?
• No threshold: How reliable? MTBF of 100 hours? 10,000 hours? 1,000,000 hours?
• No verification method: Inspect it? Analyze it? Test it for how long?
• Not necessary as stated: Every system "shall be reliable" — this adds no information to constrain the design

The corrected version might be: "The system shall achieve a mean time between critical failures of no fewer than 5,000 operating hours, verified by reliability analysis per MIL-HDBK-217F, when operated within the environmental conditions specified in Section 3.2." Now you have something a designer can target and a tester can verify.

The Quality Criteria

A good requirement is:

• Testable — You can write a procedure that yields an objective pass/fail
• Unambiguous — Only one interpretation is possible among competent practitioners
• Necessary — Removing it would degrade the system or violate a constraint
• Achievable — Current technology and budget can meet it
• Verifiable — One of the IADT methods can confirm satisfaction
• Singular — Contains one requirement, not several combined with "and"

When a requirement fails these criteria, it creates cost — not immediately, but at integration, verification, and acceptance. Bad requirements are cheap to write and expensive to satisfy.

Assessment