How Fine Should You Cut It? The Right Level of Granularity for System Requirements
Every systems engineer has faced the same moment: staring at a requirement that feels simultaneously too vague to verify and too broad to allocate. You decompose it. Then you decompose the children. At some point someone in the room says “aren’t we just writing design specs now?” and the meeting goes sideways.
This is not a philosophical problem. It has a concrete answer. The right level of granularity for a system requirement is the level at which the requirement can be unambiguously allocated to a single responsible design element and independently verified without reference to other requirements. When both conditions are true, decomposition stops. When either condition is false, you have more work to do.
That answer is precise enough to be operational. The rest of this article explains how to apply it, the practical heuristics that support it, where the boundaries are, and how modern tooling can surface the gaps you’re missing.
Why Getting This Wrong Is Expensive in Both Directions
Requirements that are too high-level look clean on paper and become expensive during verification. “The system shall provide reliable communication” is untestable. Reliable by what metric? Under what conditions? For what duration? A verification engineer handed this requirement cannot write a test procedure. They will either escalate to systems engineering (slowing the program) or interpret the requirement themselves (introducing undocumented assumptions). Both outcomes are costly.
Requirements that are too granular create a different class of problem: they constrain design choices that should belong to the responsible engineer. “The RF subsystem shall use a QPSK modulation scheme with a symbol rate of 2.4 Msps” might be appropriate in a design specification, but embedded in a system requirement it locks a design decision before the trade study that would justify it. When the implementation team discovers that 16-QAM at 1.2 Msps achieves the same data throughput with better spectral efficiency, they cannot change it without a formal requirements change — which means paperwork, a change control board, and schedule impact. The requirement was written to solve the engineer’s design problem, not to capture the system’s actual need.
Both failure modes are common. Both are avoidable.
The Allocatability Test
A requirement is allocatable when you can point to a specific design element — a subsystem, an assembly, a software module, an interface — and say: that element is solely responsible for satisfying this requirement. If satisfying the requirement requires coordination across multiple design elements, the requirement needs further decomposition. If no single design element can own the requirement, it belongs at a higher level.
The word “unambiguously” matters. If there is a reasonable argument that two different subsystems might own the requirement, the decomposition is incomplete. The goal is that a responsible engineer, handed the requirement, knows without asking that it belongs to their design element.
Practical check: Write the requirement on a card and hand it to the subsystem lead. If their first question is “who else owns this?” — decompose further.
The Independent Verifiability Test
A requirement is independently verifiable when a test engineer can write a complete test procedure for it — stimulus, pass/fail criteria, measurement method — without referencing other requirements or making interpretive assumptions.
This is the operative filter in SMART criteria as applied to requirements. SMART in a systems engineering context means:
- Specific: The requirement addresses one thing. Not “the system shall be safe and reliable” — that is two requirements minimum, possibly a dozen.
- Measurable: There is a numeric threshold, a defined condition, or a binary pass/fail criterion. “The system shall maintain link budget margin of at least 3 dB under worst-case atmospheric conditions defined in Section 4.2.1” is measurable. “The system shall maintain adequate link margin” is not.
- Achievable: The requirement is physically realizable and not in conflict with peer requirements. Achievability is often not checked at the leaf level — it surfaces during integration.
- Relevant: The requirement traces to a stakeholder need or a higher-level requirement. If you cannot trace it up, question why it exists.
- Testable: This is the practical gate. Can someone write the test? If yes, the requirement passes. If no, the requirement is either too vague (needs more specificity) or too broad (needs decomposition).
The T in SMART is not an afterthought. It is the requirement’s exit ticket from the requirements phase.
Design Freedom Preservation
Requirements should describe what a system must do or achieve — outcomes, behaviors, and constraints — not how it must do it. This principle, called design freedom preservation, is frequently stated and frequently violated.
The violation usually happens under pressure. An architect who has already made a design decision will unconsciously write the requirement to match the decision, rather than writing the requirement that the decision satisfies. This produces “requirements” that are actually design specifications without the traceability context of a design specification.
The practical discipline is to challenge every “shall” with the question: Does this constrain method, or does it constrain outcome?
- “The thermal control system shall maintain component junction temperatures below 85°C during steady-state operation at maximum rated power” — constrains outcome. Correct requirement.
- “The thermal control system shall use a vapor-chamber heat spreader with a thermal resistance of less than 0.15°C/W” — constrains method. This is a design specification, not a system requirement, unless vapor-chamber technology is itself a derived requirement from a higher constraint.
The distinction determines whether the design team has freedom to optimize. Requirements that constrain method eliminate trade space before the trade has been done.
Shall-Not vs. Shall Requirements
One underused tool in requirements decomposition is the shall-not requirement. Most requirements express positive obligations: the system shall achieve X. Shall-not requirements express constraints: the system shall not emit radiation above Y in frequency band Z.
Shall-not requirements are often the correct form for safety, electromagnetic compatibility, environmental, and regulatory constraints. They preserve design freedom while clearly bounding the solution space. “The transmitter shall not radiate spurious emissions exceeding -60 dBc in any frequency band outside the allocated channel” tells the RF designer what to avoid without dictating how to achieve it.
Teams that avoid shall-not requirements tend to instead write vague positive requirements that embed the constraint implicitly (“the transmitter shall have adequate spectral purity”) — and then discover during EMC testing that “adequate” was interpreted differently by the designer and the test engineer.
The shall-not form forces clarity about the boundary condition and is independently verifiable by measurement.
When to Stop Decomposing and Start Designing
The boundary between requirements and design specifications is real, and crossing it in the wrong direction is one of the most common errors in systems engineering.
Requirements answer: What must the system do?
Design specifications answer: How will it do it?
Decomposition should stop when:
- The requirement is allocatable to a single design element.
- The requirement is independently verifiable without additional decomposition.
- Further decomposition would require making a design decision that has not yet been validated by a trade study.
That third condition is the one most often ignored. Engineers who are uncomfortable with ambiguity decompose past the correct stopping point. They make implicit design decisions and encode them as requirements, eliminating the trade space that the design phase was supposed to explore.
When you reach a point where the next level of decomposition requires selecting an implementation approach, stop. Write a derived requirement that captures the constraint the design must satisfy, and hand the implementation question to the design specification.
The handoff is explicit. A design specification says: “To satisfy Requirement X, this element will be implemented as Y. The design meets Requirement X because [analysis/test].” The requirement and the design specification are linked by traceability. The distinction matters for change management — changes to design specifications do not require the same change control as changes to requirements, because they do not represent new stakeholder obligations.
How Graph Structure Surfaces Decomposition Gaps
Recognizing the theoretical stopping criteria is one thing. Finding the requirements in your database that have not yet reached them is another. In a large program — hundreds or thousands of requirements — manually inspecting each one for allocatability and testability is not feasible.
This is where the structural properties of graph-based requirements tools become operationally valuable. In a flat document or a spreadsheet-based RTM, a requirement that is incompletely decomposed looks identical to a leaf-level requirement. Both are rows. Neither has a visual indicator that something is missing.
In a graph model, requirements are nodes. Parent-child decomposition creates edges. Allocation to design elements creates another class of edges. The structure is queryable.
Flow Engineering uses this graph architecture in a way that directly supports the decomposition problem. A requirement node that has no children (not decomposed) and no allocation (not assigned to a design element) is structurally distinguishable from a requirement node that has no children and is allocated. The first is a gap. The second is a correct leaf-level requirement.
This is not a minor feature — it is a qualitatively different way of finding problems. Instead of a requirements review where engineers read through documents looking for vague language, a project manager or systems lead can query the graph for unallocated nodes with no children and get a work list. Those are the requirements that are neither decomposed nor assigned. They are stuck in the middle: too broad to allocate, not yet broken down.
Flow Engineering’s model also captures the distinction between a requirement that traces to a parent and one that does not — surfacing requirements that were written without a traceable rationale. Both gaps (no-children-no-allocation and no-parent) represent structural problems that the graph makes visible as first-class objects, not as findings buried in a review comment.
The practical workflow this enables: before a major design review, run a structural query on the requirements model. Any node that is not a verified leaf (allocated and testable) and has no decomposition children becomes a line item for the systems engineering team to resolve before the review. This moves requirements quality from a document review discipline to a model health discipline — which scales.
Practical Starting Points
If you’re working through a requirements set and trying to apply these criteria, here is a working sequence:
- Read each requirement and ask: who owns this? If the answer involves more than one subsystem, decompose.
- Ask: can a test engineer write a test procedure from this requirement alone? If no, either tighten the language (make it measurable) or decompose.
- Check for method constraints. If the requirement tells the designer how to implement rather than what to achieve, rewrite it as a shall-not or move it to a design specification.
- Identify shall-not opportunities. Constraints, safety bounds, and regulatory limits are often better expressed as shall-not requirements.
- Stop when you are about to make a design decision. The next level down is a design specification, not a requirement.
- Use your tool’s structure to find what you missed. Any requirement with no children and no allocation target is a candidate for further work.
The question “have I decomposed enough?” has a structural answer: every requirement in your model should either have children (if it is a parent) or have an allocation target (if it is a leaf). Requirements that have neither are incomplete. Requirements that have both are suspicious — a requirement that has children and is also directly allocated may be skipping a level.
Getting this right does not eliminate ambiguity from systems engineering. It moves the ambiguity from the requirements to the places where it belongs: design decisions, trade studies, and interface negotiations. Those conversations are productive. Ambiguous requirements are not.