How Do You Decide What Level of Detail Is Enough in a Requirements Document?

Teams writing requirements tend to make one of two mistakes. The first is vagueness: The system shall perform well under adverse conditions. The second is over-prescription: The system shall use a 32-bit ARM Cortex-M4 processor running at 168 MHz with 192 KB of SRAM to filter sensor data using a fifth-order Butterworth low-pass filter with a 10 Hz cutoff. Both statements fail, just in different ways. The first leaves interpretation to whoever reads it. The second has locked in an implementation before any design trade-off analysis has occurred, and it has created a verification obligation tied to a specific mechanism rather than an outcome.

Finding the right level of detail is an engineering judgment call, not a formatting exercise. There are no universal word counts, no magic number of attributes per requirement. But there are practical heuristics that hold across program types, and there are specific conditions — program phase, criticality level, organizational boundary — that should shift where you draw the line.

Three Heuristics That Actually Work

1. Each requirement must be independently verifiable

This is the most reliable test for whether you have the right level of detail. If you cannot write a specific test, inspection, demonstration, or analysis procedure for a single requirement without also depending on a different requirement to define the scope, something is wrong. Either the requirement is too vague to test, or it is too compound to test cleanly.

The navigation subsystem shall acquire GPS lock within 90 seconds of power-on under open-sky conditions with a minimum of four satellites in view. This is verifiable. You can write the test procedure right now without referencing another requirement.

The navigation subsystem shall be responsive. This is not verifiable. Responsive means nothing without a defined stimulus, a defined response, and a threshold.

The navigation subsystem shall acquire GPS lock, maintain lock through signal dropout events not exceeding 10 seconds, and output position data at 10 Hz with no more than 1-meter CEP. This is three requirements collapsed into one. You can test it, but the failure analysis becomes complex. If GPS lock acquisition passes but position accuracy fails, is the requirement satisfied? Keep them separate.

2. Multiple readers should reach the same interpretation independently

Take a requirement and give it to three engineers on your team who were not involved in writing it. Ask each one, separately, what they would build to satisfy it. If you get significantly different answers, the requirement does not have enough detail — or has used ambiguous language.

Terms like sufficient, adequate, user-friendly, robust, high performance, appropriate, and as needed are interpretation wildcards. They survive reviews because they sound reasonable, and they cause scope disputes during verification because no one agreed on what they meant. Every qualifier in a requirement should be bound to a measurable threshold or a defined standard reference.

The converse failure: a requirement that is so specifically worded that it describes only one possible implementation. At that point, it is not expressing what the system must accomplish — it is expressing what the engineer who wrote it assumed the engineer who reads it would build. That assumption may not survive hardware obsolescence, supplier changes, or design iterations.

3. State the outcome, not the mechanism

A requirement defines what the system must accomplish for its stakeholders. The design defines how it accomplishes that. When requirements leak into design decisions, you constrain solution space prematurely, and you guarantee a verification failure the moment the design evolves.

The pump shall deliver 5 L/min of coolant at 2 bar pressure differential under continuous operation. This is an outcome requirement. Any pump design that achieves it satisfies the requirement.

The pump shall use a brushless DC motor with a rated speed of 3000 RPM driven by a PWM controller at 50 kHz to deliver coolant flow. This is a design specification masquerading as a requirement. If the motor vendor changes, you now have a requirements deviation instead of an approved design change.

The distinction matters most in two contexts: when you are flowing requirements to a supplier, and when you are early in the design process and do not yet know which implementation you will choose.

How Program Phase Changes the Answer

Requirement detail level should not be static across a program’s life cycle. Requirements at the concept phase are necessarily coarser because design decisions have not been made. Requirements at critical design review should be precise and testable because the design is fixed and verification planning is underway.

Concept / Pre-Phase A: At this stage, operational concept documents and system-level need statements describe capabilities, not behaviors. The vehicle shall be capable of unassisted autonomous docking with a tumbling target object. This is appropriate at concept stage. It will not survive as a detailed requirement without significantly more decomposition.

System Requirements Review (SRR): System-level requirements should be verifiable at the system level. They do not need to describe subsystem behaviors in detail, but each one should have a clear verification method identified. Vague language should already be eliminated by this gate.

Preliminary Design Review (PDR): Subsystem and component requirements should be allocated and levied. Supplier-facing requirements should be at their final detail level — not draft. If you cannot write an acceptance test by PDR, the requirement is not ready to flow.

Critical Design Review (CDR): All requirements should be frozen and fully traceable to their parent requirements and downstream verification cases. Any requirement that cannot be verified independently is a risk item that should be flagged, not closed.

The mistake teams make is writing requirements at the level that feels comfortable for their current knowledge, rather than the level appropriate for the program phase. PDR-phase requirements with SRR-level vagueness are a schedule risk you will pay for during I&T.

How Criticality Level Changes the Answer

For systems developed under DO-178C, DO-254, ARP4754A, ISO 26262, or similar safety standards, criticality level directly sets the standard for requirement quality.

DAL A / ASIL D: At these levels, every requirement must be unambiguous without exception. Interpretive latitude is not acceptable because the cost of a misinterpretation during verification — or during an accident — is catastrophic. Requirements at these levels are also subject to formal analysis (fault tree analysis, FMEA, HAZOP) where ambiguous language produces unreliable analysis results. The verification burden is already high; vague requirements multiply it.

DAL C / ASIL B: The standard for unambiguity is the same, but the verification methods may be less exhaustive. Requirements must still be independently testable, but the evidence you collect for each test is scoped to the criticality level.

DAL D / ASIL A and below: More judgment is permitted in how explicitly requirements are stated, but independently verifiable and single-interpretation still apply. Relaxed criticality does not mean requirements can be vague — it means the verification effort per requirement is proportionally sized.

One practical note: mixed-criticality systems, where a platform hosts functions at multiple DAL or ASIL levels, require particular discipline. Requirements must be tagged to their partition, and detail level must match the highest applicable criticality for that function.

Supplier-Facing Requirements Demand More Explicit Detail

When a requirement stays inside your organization, informal context fills in gaps. Engineers on the same program share design history, attend the same reviews, and can resolve ambiguity through conversation. That context evaporates the moment a requirement crosses an organizational boundary.

Supplier-facing requirements need:

  • Explicit acceptance criteria. Not just what the system must do, but how acceptance will be demonstrated, under what conditions, and who provides what evidence.
  • Environmental and interface constraints. The supplier is not designing in your context. Every assumption your team holds about operating environment, input range, interface protocol, and load condition must be stated explicitly.
  • Derating and margin requirements. If your internal practice is to operate components at 75% of rated capacity, that practice must be expressed as a requirement in the supplier’s SOW, not as tribal knowledge.
  • Verification responsibility allocation. Which requirements does the supplier verify, and which does your integration team verify? This must be stated, not assumed.

Internal requirements can carry more implied context without creating risk. But even internal requirements should be written with the assumption that the engineer who reads them two years from now was not in the room when they were written.

How Modern Tools Help Calibrate Detail Level

Getting detail level right at scale — across hundreds or thousands of requirements on a complex program — is not achievable through manual review alone. Reviewers habituate to the document’s language patterns and stop catching the things they have read twenty times. AI-assisted analysis catches things humans miss.

Flow Engineering addresses this directly through its AI-assisted quality checking layer. As requirements are drafted, the tool analyzes language against configurable quality attributes: testability, unambiguity, single-subject decomposition, and completeness relative to defined attributes like rationale, verification method, and acceptance criteria. Engineers receive inline feedback before the requirement goes to peer review — not after a review cycle has already consumed schedule.

The workflow matters as much as the analysis. Flow Engineering’s peer review workflow keeps the detail-level question visible across the team: a reviewer can flag a requirement as under-specified or over-constrained, and that flag creates a tracked resolution item rather than a comment that gets resolved by silence. For programs flowing requirements to suppliers, the ability to define different attribute completeness thresholds for different requirement sets — stricter for supplier-facing, more flexible for internal working requirements — allows teams to apply appropriate rigor where it matters most without creating uniform overhead everywhere.

This is not a substitute for engineering judgment. No tool can decide whether a 90-second GPS acquisition requirement is the right threshold for your mission profile. But tooling that catches The system shall respond quickly before it survives review is removing a category of error that costs real time and money downstream.

Practical Starting Points

If your team is calibrating detail level on an active program, these are the questions to work through:

  1. For every requirement: can you write the test procedure right now? If not, identify what is missing — a threshold, an environmental condition, a reference standard — and add it.

  2. Give ten representative requirements to an engineer unfamiliar with the program. Ask them to describe what they would build. Compare answers. Where interpretations diverge, revise.

  3. Mark every qualifier. For each word like sufficient, adequate, reliable, or robust, either replace it with a measurable threshold or a reference to a defined standard, or delete it.

  4. Check each requirement for implementation language. If the requirement specifies a component, a technology, or an algorithm, ask whether that specificity is genuinely a stakeholder need or a design assumption that crept in. Push design decisions into the architecture or design description.

  5. Apply different standards to different requirement sets. Supplier-facing requirements should be reviewed against a higher completeness standard than internal working requirements. Criticality-appropriate thresholds should be explicit, not implicit.

The goal is not the thinnest possible requirements document or the most comprehensive one. The goal is a set of requirements where each one can be verified, each one means the same thing to every reader, and none of them have made design decisions that belong to the engineer, not the requirement author.

That is a standard your team can define, communicate, and hold to — with or without a tool. With the right tooling, you can hold to it at scale.