How Specific Should Requirements Be?
Every experienced systems engineer has a folder somewhere — mental or literal — full of requirements that caused problems. Not requirements that were wrong in content, but requirements that were wrong in form. Written at the wrong altitude. Too tight. Too loose. Technically accurate but operationally useless.
Getting the level of detail right is the craft question of requirements engineering. It is the skill that separates engineers who have shipped systems from engineers who have only written documents. Junior practitioners default to one of two failure modes: they either write requirements that read like design specifications, or they write requirements so abstract they could describe almost any system. Both paths lead to integration failures, rework, and the specific frustration of knowing the problem was visible and preventable.
This article covers what a well-formed requirement actually looks like, names the failure modes at both ends of the specificity spectrum, explains how to apply modal language consistently, and describes how modern AI-assisted tools can help teams calibrate requirement quality before it becomes expensive.
What Makes a Requirement Well-Formed
The most durable framework for requirement quality comes down to four properties. A requirement should be:
Testable. If you cannot write a pass/fail test for the requirement as stated, the requirement is not done. This is not a bureaucratic rule — it is the functional definition of a requirement. “The system shall withstand vibration” cannot be verified. “The system shall withstand sinusoidal vibration of 5 g peak from 20 Hz to 2000 Hz per MIL-STD-810H Method 514.8” can be. The difference is not pedantry; it is the difference between a requirement and a wish.
Unambiguous. One requirement, one interpretation. Every reader on the program — systems engineer, hardware designer, test engineer, subcontractor — should reach the same understanding from the same text. Words like “fast,” “robust,” “user-friendly,” and “adequate” are ambiguous by construction. Quantify them or cut them.
Necessary. The requirement must exist because a stakeholder need, a constraint, or a higher-level requirement demands it. If you cannot trace a requirement back to something real, it is overhead at best and a design constraint at worst. Every unnecessary requirement is a cost someone will eventually pay.
Free from embedded design decisions. A requirement states what the system must accomplish and under what conditions. It does not state how the system should accomplish it unless the how is itself a genuine constraint imposed by an external authority. This last property is where specificity becomes a precision instrument rather than a blunt one.
The SMART Adaptation for Requirements
The SMART mnemonic is overused in project management contexts, but its original form maps cleanly onto requirements engineering when applied carefully:
- Specific — precise enough to eliminate interpretive ambiguity
- Measurable — quantified with units, tolerances, and conditions
- Achievable — realistically satisfiable given known constraints
- Required — traceable to an actual stakeholder need or governing constraint
- Testable — verifiable through inspection, analysis, demonstration, or test
The tension in this list is between Specific and Achievable. Tighter numbers are more testable but may be unachievable or may arbitrarily constrain vendors and designers. The calibration exercise is finding the tightest specification that genuinely reflects the stakeholder’s need without importing false precision.
Failure Mode 1: Over-Specification
Over-specified requirements are the more technically sophisticated failure mode. They appear in programs where engineers with deep domain knowledge are writing requirements — which is appropriate — but where those engineers are also solving the design problem in the requirements database rather than in the design space.
An over-specified requirement looks like this:
The thermal management subsystem shall use a vapor-chamber heat spreader with a copper base plate of minimum 3 mm thickness, bonded to the processor package using indium-based thermal interface material, achieving a junction-to-ambient thermal resistance of less than 0.8°C/W at 85W TDP.
The thermal resistance target (0.8°C/W at 85W) is a legitimate requirement. Everything before it is a design solution. Specifying the vapor chamber, the copper thickness, and the TIM material in the requirement eliminates design alternatives before the design team has evaluated them. It may preclude a better, cheaper, or more manufacturable solution. It may create a requirement that only one vendor can satisfy. And when the thermal interface material becomes unavailable, you have a requirements change to manage rather than a design decision to make.
The corrected form:
The thermal management subsystem shall achieve a junction-to-ambient thermal resistance of less than 0.8°C/W when operating at a processor TDP of 85W in an ambient temperature of 55°C.
This states the need. It leaves the design space open. It is still specific — quantified, measurable, testable — but it does not constrain how the system solves the problem.
Over-specification at scale creates programs where design teams feel managed from the requirements database rather than guided by it. They work around requirements. They write non-conformances. They ask for waivers. The requirements document stops being a contract and starts being an obstacle.
Failure Mode 2: Under-Specification
Under-specified requirements are the more common failure mode in early-stage programs and in organizations where requirements are treated as administrative deliverables rather than engineering tools.
An under-specified requirement looks like this:
The communication subsystem shall provide reliable data transfer between system components.
“Reliable” is undefined. “Data transfer” has no rate, latency, or protocol boundary. “Between system components” does not identify which components. This requirement could be satisfied by a CAN bus running at 125 kbps or by a 100 Gbps optical backplane. When two subsystem teams interpret this requirement differently — as they inevitably will — the integration event is where you discover the discrepancy.
Integration failures that trace back to vague requirements have a characteristic signature: both teams did exactly what they thought was required, and neither team was wrong given the text they were handed. The failure is in the requirements, not in the execution. And by the time integration testing surfaces the problem, redesign is expensive.
The corrected form:
The communication subsystem shall transfer telemetry data from the sensor processing unit to the mission computer at a minimum sustained rate of 1 Gbps with end-to-end latency not exceeding 2 ms under full payload conditions.
Concrete. Quantified. Testable. The integration team now has a target instead of a vibe.
Shall, Should, Will — and Why Consistency Matters
Modal verb conventions exist to communicate binding obligation. When applied consistently, they let readers understand immediately whether a requirement is mandatory, preferred, or informational. The standard mapping:
- Shall — mandatory requirement. Failure to comply is a nonconformance. Use this for every actual requirement.
- Should — recommended practice or goal. Non-compliance is acceptable with documented rationale. Use this for design guidance that does not rise to a contractual obligation.
- Will — statement of fact or declaration of intent by the customer or program. Not a requirement on the supplier. Use this for context and for documenting customer-provided conditions.
These distinctions collapse when teams use the words interchangeably. A document that says “the system should withstand 50g shock” alongside “the system shall withstand 50g shock” in different sections has created ambiguity about what is actually mandatory. Verification teams will disagree. Subcontractors will negotiate. Change boards will spend time resolving questions that the convention was designed to eliminate.
The practical rule: pick the convention, document it in your requirements management plan, and enforce it consistently across every requirement author on the program. One paragraph in a style guide applied uniformly is worth more than perfect modal usage in a document that no one else follows.
Finding the Right Altitude: A Practical Framework
Requirements live in a hierarchy. System-level requirements describe what the system must accomplish in its operational environment. Subsystem requirements allocate those capabilities to defined functions. Component requirements specify what each component must deliver to satisfy the subsystem. The level of detail appropriate for each tier is different.
A useful calibration question at each tier: Can the team responsible for satisfying this requirement make meaningful design decisions, or have I already made those decisions for them?
If the answer is that you have made the design decisions, you have specified at too low an altitude for the current tier. Push the detail down one level or move it to the design documentation where it belongs.
A second calibration: Can the team responsible for testing this requirement write a test case from the text as written, without requiring an interpretation conversation?
If the answer is no, the requirement is under-specified for the tier. You need more precision — more units, more conditions, more boundary definitions.
Between those two calibration questions, most requirements problems are visible before they propagate.
How AI-Assisted Tools Are Changing the Calibration Exercise
Manual requirement review has a known failure mode: the author is too close to the material to see the vagueness. The engineer who wrote “reliable data transfer” understood what reliable meant. They had a number in their head. They simply did not write it down, or assumed it was obvious from context. Peer review catches some of this, but peer reviewers share domain assumptions with authors, and shared assumptions produce shared blind spots.
AI-assisted requirements tools address this by applying pattern detection that does not share the author’s contextual knowledge. Tools like Flow Engineering analyze requirement text for linguistic signatures associated with poor specificity: unquantified adjectives (“fast,” “robust,” “minimal”), passive constructions that obscure the subject of the obligation, embedded design solutions flagged against system-level context, and requirements that lack measurable acceptance criteria.
Flow Engineering’s requirements analysis layer can surface these issues at authoring time — before design begins, before the requirement has propagated into allocations, interface control documents, and test plans. The cost of fixing a vague quantifier in the requirements database is approximately an engineer-hour. The cost of discovering through integration test that two teams interpreted “minimal latency” differently is measured in weeks and program risk.
What AI tooling does well in this context is what experienced reviewers do in their heads: pattern-match against known failure modes at scale, across hundreds or thousands of requirements, without fatigue or familiarity bias. Flow Engineering’s graph-based model also surfaces traceability gaps — requirements that exist without a clear parent need or without a downstream verification method — which catches the necessary property failures that human reviewers frequently miss in large documents.
The limitation worth naming: AI flagging is pattern detection, not judgment. A tool can identify that “robust” is an unquantified adjective and flag it for review. It cannot determine whether the stakeholder’s actual need is 99.9% availability or 99.999% availability. That judgment still requires a systems engineer who understands the operational context. The tool accelerates the identification; the engineer still makes the call.
Practical Starting Points
If you are calibrating requirement quality on a program in progress, three interventions have high leverage:
Run a modal verb audit. Extract every requirement containing “should” and determine whether it represents a mandatory obligation or a genuine recommendation. Most programs discover that “should” is being used as a politeness modifier for mandatory requirements. Reclassify or explicitly document the rationale for non-mandatory status.
Apply the test case question to every “shall.” For each mandatory requirement, ask whether a test engineer unfamiliar with the design could write a test case. If not, identify what is missing: a quantitative threshold, a defined condition, a stated boundary, a reference standard.
Flag solution language. Review requirements for verbs and nouns that specify mechanisms rather than behaviors: “use,” “implement,” “incorporate,” specific component names, named protocols where the protocol is not itself a constraint. For each one, ask whether the solution specification is a genuine stakeholder constraint or an inherited design assumption from a previous program.
These three passes will surface the large majority of calibration problems before they become expensive.
The Underlying Principle
The right level of specificity is the level that fully defines the stakeholder need without constraining the design solution. It is a moving target across the lifecycle — what is appropriate at concept definition is under-specified at PDR, and what is appropriate at CDR would be over-prescriptive at concept definition.
The craft is understanding where you are in the lifecycle, what decisions the requirement must enable and what decisions it must protect, and writing with enough precision to eliminate ambiguity without importing false certainty about solutions that have not yet been evaluated. That judgment develops over programs, not over chapters. But the failure modes are learnable, the calibration questions are portable, and the tools for catching errors earlier than integration are better than they have ever been.