What Is the Right Level of Requirement Granularity?
The granularity problem in requirements engineering does not announce itself. Teams rarely write a requirement and think “that’s too vague.” They think they’ve captured the intent. The failure mode appears later — during verification planning, when an engineer asks “how do we actually test this?” and the answer is either “we can’t” or “we’d need twenty separate tests to cover what this one requirement implies.”
Getting granularity right is not about writing more requirements or fewer. It is about matching the specificity of a requirement to the level of the system hierarchy where it lives, and ensuring that every requirement is verifiable with a defined method at the level where it appears.
This article gives concrete guidance on how to calibrate granularity across hierarchy levels, with examples drawn from aerospace and medical device development — two domains where the cost of getting this wrong is measured in program delays, failed audits, or patient harm.
What Makes a Requirement the Wrong Size?
Before discussing hierarchy, it helps to have a working definition of the failure modes.
Too high-level (under-specified): The requirement states a goal or property but does not include enough quantitative or behavioral constraint to support a verification method. You can write a compliance matrix that references it, but you cannot write a test procedure against it without first decomposing it further. The requirement has deferred the engineering decision to somewhere downstream without creating a documented link.
Too fine-grained (over-specified at the wrong level): The requirement prescribes a specific implementation, material, algorithm, or component at a level where that decision should not be made. It constrains the solution space without capturing the performance outcome the system actually needs to deliver. Alternatively, it describes behavior that belongs to a subsystem or component, not to the level of system where it appears in the document.
The hybrid failure: A single requirement is simultaneously over-specified in one dimension and under-specified in another. This is the most common and hardest-to-catch pattern. Example: “The flight control computer shall use a dual-redundant voting architecture to ensure safety.” This prescribes the architecture (over-specified for a system requirement) while leaving the actual safety outcome — probability of hazardous failure, response time under fault conditions — completely unmeasured (under-specified). It looks like a real requirement. It traces to a safety objective. But it cannot be verified without additional work that is undocumented.
Granularity Across the Hierarchy
The right granularity changes at each level of the system decomposition. The following structure is typical in aerospace and medical device development, though the labels vary by program and standard.
Stakeholder / Mission Level
At this level, requirements describe what the system must do for its users and the context in which it must do it. These are often written in operational terms — what a crew can accomplish, what a patient outcome looks like, what a mission profile demands.
These requirements are deliberately high-level by design. They are not testable against the final hardware directly. They are verified through a combination of analysis, simulation, and acceptance testing at the system level after decomposition is complete. The mistake is not that they are high-level — it’s when teams never decompose them.
Aerospace example (appropriate at this level): “The aircraft shall maintain controlled flight following any single hydraulic system failure during approach and landing.”
This is not yet testable on hardware, but it is well-formed: it identifies the condition (single hydraulic failure), the phase (approach and landing), and the required outcome (controlled flight). It drives decomposition into hydraulic architecture requirements, flight control authority requirements, and crew alerting requirements.
Medical device example (appropriate at this level): “The infusion pump shall prevent under-infusion and over-infusion events that could result in patient harm under normal and single-fault conditions.”
Again, not directly testable, but the condition (normal and single-fault), the harm mode (under/over-infusion), and the subject (infusion pump) are all defined. This drives decomposition into flow accuracy requirements, occlusion detection requirements, and alarm threshold requirements.
System Level
This is where granularity decisions have the highest leverage — and the highest failure rate.
System-level requirements should capture emergent behavior: properties that arise from the interaction of subsystems and cannot be assigned to any single component. They must be specific enough to support a verification method at the system level — test, analysis, inspection, or demonstration — without prescribing how the subsystems achieve the outcome.
Too vague (fails here): “The navigation system shall be accurate.” — No quantified condition, no measurement method, no operating scenario defined.
Too fine-grained (fails here): “The GPS receiver shall use a 12-channel L1/L2 dual-frequency antenna to achieve positioning accuracy.” — This belongs at the component level. At the system level, the requirement should specify the positioning accuracy and the conditions under which it must be achieved. The antenna architecture is a design choice.
Right granularity: “The navigation system shall provide position accuracy of ≤10 meters CEP (Circular Error Probable) under the following conditions: [enumerate conditions]. Accuracy shall be verified by flight test using [defined reference method].”
This requirement names the metric (position accuracy), the quantified threshold (10 m CEP), the conditions, and the verification method. A test engineer can write a test procedure against this without further interpretation.
Medical device example at system level: “The closed-loop insulin delivery system shall reduce time-in-hypoglycemia (glucose <70 mg/dL) to ≤4% of monitored hours during standard use, as verified by [defined clinical protocol].”
This captures emergent system behavior — the interaction between sensor, algorithm, and pump — without prescribing how the algorithm achieves the outcome.
Subsystem and Component Level
At these levels, requirements can and should be more specific. Implementation details that were inappropriate at system level become necessary constraints. However, the requirement still must be verifiable, and it should trace back to a parent requirement that explains why this constraint exists.
A component-level requirement with no parent trace is either orphaned (it was never derived from a system need) or its parent trace was never documented. Both are audit findings in DO-178C, IEC 62304, and ISO 26262 reviews.
The trace test: Every component-level requirement should answer the question “which system-level property does this enable?” If it cannot, it should either be deleted or traced.
Granularity and Verification Planning
The connection between granularity and verification cost is direct and underappreciated until budget is set.
A vague system-level requirement forces verification engineers to make interpretive decisions that should have been engineering decisions. Two test engineers given the requirement “the system shall respond quickly to operator inputs” will write different tests. Neither will be wrong according to the requirement. The requirement has deferred a scope decision into the verification phase, where changing it costs more and is less visible.
A requirement that is too fine-grained for its level creates a different problem: it generates verification events that don’t roll up to system-level coverage. You can have 100% component-level test passage and still have unmeasured system behavior because no requirement captured what the components were supposed to achieve together.
The practical discipline is to build the verification approach before finalizing requirements. For each requirement, ask: what is the verification method (test, analysis, inspection, demonstration), who executes it, at what level of assembly, and what constitutes pass/fail? If you cannot answer all four, the requirement is not ready. This is not bureaucratic overhead — it is the earliest possible failure mode detection in the V-model.
How Modern Tools Handle Granularity
Traditional requirements management tools — IBM DOORS, Jama Connect, Polarion — provide structure for organizing and tracing requirements, but the granularity problem is largely left to the author’s judgment and peer review. A vague requirement is stored and traced just as cleanly as a well-formed one. The tool does not distinguish between them.
This is not a criticism of those tools’ core function. They were designed to manage requirements at scale, and they do that reliably. But they do not actively analyze requirement quality or flag structural problems.
AI-native tools approach this differently. Flow Engineering, built specifically for hardware and systems engineering, implements requirement analysis that can identify the hybrid failure pattern described earlier — requirements that are over-specified in one dimension and under-specified in another. When a requirement contains architectural prescriptions (mentions of specific components, materials, or topologies) alongside absent or unmeasured performance outcomes, the system flags it for review. This is not spell-check for requirements. It is structural analysis against a model of what makes a requirement verifiable at a given hierarchy level.
Flow Engineering’s graph-based model of system structure is relevant here: because requirements are linked to system functions and verification events in a connected model rather than a flat document, the tool can surface cases where a requirement has no verification path — not just no verification method in the requirement text, but no downstream verification event in the program structure. That is a different and more actionable finding than a text-analysis flag.
The limitation to acknowledge is that AI-assisted flagging identifies candidates for review, not final dispositions. A requirement flagged as potentially over-specified still requires an engineer’s judgment about whether the specification is appropriate for that program context. The tool narrows the search space; it does not replace the decision.
Practical Starting Points
If you are auditing an existing requirements set for granularity problems, or setting standards for a new program, the following tests are concrete and fast to apply:
The verification method test. For each requirement, write one sentence describing how you would verify it. If you cannot do this in one sentence, or if the sentence requires multiple test events to be defined before it makes sense, the requirement needs decomposition or quantification.
The level assignment test. Ask: does this requirement describe behavior of the whole system, or behavior of a part? If it describes a part, it belongs at the level of that part — or it needs to be rewritten to capture the system-level outcome the part’s behavior enables.
The implementation detection test. Scan for nouns that name specific components, architectures, or technologies. Each one is a candidate for challenge: is this constraint necessary at this level, or is it a design decision that has been embedded in a requirement?
The condition coverage test. For every performance requirement, check that operating conditions are defined. Accuracy requirements without an environmental envelope, timing requirements without a load condition, and reliability requirements without a mission profile are all incomplete regardless of how specific the threshold looks.
The parent trace test. For any requirement that feels too detailed for its level, find its parent. If the parent requirement does not clearly explain why this constraint is needed, either the trace is missing or the requirement is orphaned.
Summary
Requirement granularity is not a stylistic preference. It is an engineering discipline with direct consequences for verification cost, audit defensibility, and the probability of discovering integration failures late.
At each level of the system hierarchy, the right granularity means: specific enough to support a defined verification method at that level, and constrained enough to bound the design space without prescribing the solution. At higher levels, this means quantified outcomes with defined conditions. At lower levels, this means implementation constraints that trace cleanly to parent performance requirements.
The hybrid failure — a requirement that over-specifies implementation while under-specifying the outcome — is the most common and most expensive form of the problem. It survives review because it looks specific. AI-assisted tools can help surface it systematically, but the judgment call about whether a given specification is appropriate remains with the engineer who understands the program context.
Write the test procedure before you finalize the requirement. If you can’t, the requirement isn’t done.