What Is the Right Level of Requirements Granularity?

Every experienced systems engineer has encountered both failure modes. Requirements that read like marketing copy — “the system shall be reliable and easy to use” — tell engineers nothing actionable. Requirements that specify the exact resistance tolerance of every resistor in a signal chain tell engineers far too much, far too early, and make every design change an administrative nightmare.

The question is not which extreme to avoid. Both are obviously wrong. The real question is how to find the practical middle ground — and how to know, for any given requirement at any given moment in a program, whether you are at the right level of detail.

This article offers a concrete framework. It won’t give you a universal answer, because there isn’t one. But it will give you the two tests every requirement should pass, the two dimensions that should drive your granularity decisions, and a way to structure your requirements hierarchy so that different levels can coexist without collapsing into a single unmanageable flat list.

The Two Tests for Correct Granularity

Requirements granularity is correct when a requirement passes both of these tests simultaneously:

Test 1: Independent Verifiability. Can you write a single verification procedure — a test, an analysis, an inspection, a demonstration — that confirms this requirement is met, without simultaneously testing something else? If your verification procedure inherently checks three different behaviors at once, the requirement is too broad. If it requires you to set up a test rig for a ten-millisecond timing margin that nobody will ever claim caused a system failure, you may be too granular.

Test 2: Single Ownership. Can you assign this requirement to exactly one engineer, one team, or one supplier and have a clear conversation about whether it has been satisfied? If a requirement spans two subsystems such that neither team fully owns it, it is probably too coarse and needs to be decomposed. If satisfying a requirement is entirely within one engineer’s half-day of work and generates a verification artifact that costs more time to create than the design work itself, you may have gone too far.

When a requirement passes both tests — independently verifiable, singly owned — it is probably at the right level of granularity. When it fails either one, you have a decision to make.

Granularity by Lifecycle Phase

The right level of granularity is not fixed across a program. It changes as the design matures, and your requirements structure should change with it.

Stakeholder needs and concept-phase requirements should be deliberately coarse. At this stage, you are capturing intent, not specifying solutions. A stakeholder need like “the device shall not require recalibration during normal operating shifts” is appropriate at this phase. You are not yet in a position to specify the allowable drift rate of the sensor stack — you do not know the sensor stack yet. Granular requirements at the concept phase are premature, and they constrain design decisions before any design analysis has been done.

System-level requirements are the first level that should pass both tests above. Here you are specifying what the system must do in terms that can be allocated to subsystems and ultimately verified at the system level. These requirements should be complete enough to drive architecture and to form the basis of supplier statements of work, but not so detailed that they implicitly mandate a specific implementation.

Subsystem and component requirements are where granularity increases substantially, and appropriately. Once the architecture exists, you know what each subsystem is responsible for, and you can specify its behavior in much more concrete terms. Timing budgets, interface signal definitions, environmental tolerances, failure mode behaviors — these belong at this level, not at the system level.

Verification requirements and test specifications sit at the bottom. They are the most granular of all, and they should be, because you are specifying exactly what is measured, under what conditions, against what acceptance criteria. Confusing verification specifications with system requirements is a common source of requirements bloat — teams write test-level detail into requirements that should live at a higher level of abstraction.

The mistake most teams make is not that they have requirements at the wrong level. It is that they have all levels collapsed into a single flat document or database, with no structure distinguishing between them. A mission-level objective, a system performance requirement, and a test tolerance live at completely different levels of abstraction. Treating them as peers creates confusion about what needs to be verified, what needs to be changed when the design evolves, and what actually needs to be reviewed in a requirements review.

Granularity by Safety Criticality

The second dimension that should drive granularity decisions is safety criticality and regulatory exposure.

For functions with a direct path to hazard — control functions in a medical device, braking logic in an autonomous vehicle, fire suppression activation in a data center — granularity should be maximized within the constraint of single ownership. The reason is not pedantry. It is that coarse requirements in safety-critical domains create ambiguity that auditors, certification bodies, and failure investigators will resolve against you. “The system shall respond promptly to sensor anomalies” is unverifiable and indefensible. “The system shall generate a fault-state response within 50 milliseconds of detecting a sensor reading outside the calibrated range, under all operating temperature conditions” is neither.

For functions with lower criticality — user interface preferences, non-binding performance targets, cosmetic specifications — the cost-benefit of high granularity shifts. Spending verification budget on requirements that are aspirational rather than binding is waste. These requirements should be coarser, explicitly marked as non-mandatory where appropriate, and not held to the same verification rigor.

The practical failure mode here is treating all requirements as equally granular regardless of their safety relevance. This produces one of two problems: either everything is written at the safety-critical standard, generating massive overhead for requirements that don’t warrant it, or everything is written at the aspirational standard, leaving safety-critical functions underspecified.

A clean solution is to tag requirements with a criticality level and apply different granularity standards by tag. This is straightforward to implement in any structured requirements tool and has an immediate effect on the quality of both requirements writing and verification planning.

Structure, Not Compression

The underlying principle behind everything above is that granularity is a structural problem, not a compression problem. The goal is not to find the one magic level of detail at which all requirements should be written. It is to build a requirements hierarchy in which each level is internally consistent and each level serves a distinct engineering purpose.

A well-structured hierarchy looks roughly like this:

• Level 1: Stakeholder needs. Intent and constraints, not specifications. Owned by systems engineering and product management.
• Level 2: System requirements. Allocatable, independently verifiable at the system boundary. Owned by systems engineering.
• Level 3: Subsystem requirements. Derived from system requirements via allocation and analysis. Owned by subsystem leads.
• Level 4: Component requirements and interface specifications. Detailed enough to drive detailed design. Owned by design engineers.
• Level 5: Verification requirements. Specific enough to be executable. Owned by test and verification teams.

When you trace a stakeholder need down through this hierarchy, you should be able to show that it has been fully addressed at some combination of lower levels, that each lower-level requirement is owned by someone, and that the verification requirements at the bottom are sufficient to confirm satisfaction. When you cannot do this, you have a gap — either in granularity, in traceability, or in coverage.

How Modern Tools Handle Hierarchical Granularity

The problem with most legacy requirements tools is that they model requirements as lists. IBM DOORS, in its classic form, is organized around modules. Jama Connect organizes requirements into sets within a project. Both can be structured hierarchically through discipline and configuration, but the underlying data model is essentially flat. Teams that want to maintain meaningful level distinctions have to enforce those distinctions manually through naming conventions, attribute tags, and module structure.

This creates friction. When changing a system-level requirement requires manually finding all the derived subsystem requirements and updating their attributes, teams stop doing it. Requirements drift from their parent intent over time.

More recent tools have moved toward graph-based models where parent-child relationships between requirements are first-class data structures, not workarounds. In this model, decomposition is native: a system requirement can be explicitly linked to the two or three subsystem requirements that together satisfy it, and that relationship is maintained as the design evolves.

Flow Engineering is built around this model. Its hierarchical decomposition approach lets teams author requirements at multiple levels and maintain explicit parent-child relationships between them, without collapsing everything into a single flat list. When a system requirement changes, the tool makes the downstream dependencies visible immediately — the subsystem requirements that were derived from it, the verification procedures that test them. This makes the structural integrity of the requirements hierarchy something the tool actively maintains rather than something teams have to manually police.

For teams working on safety-critical systems with multiple levels of certification — where you need to demonstrate to a regulatory body that stakeholder needs are fully covered by system requirements, which are fully allocated to subsystem requirements, which are fully verified by test procedures — this is not a convenience feature. It is table stakes.

Practical Starting Points

If your current requirements structure has a granularity problem, the path forward is not to rewrite everything. It is to introduce structure.

Start by identifying the level distinctions that matter for your program — probably three or four, not five or six — and tagging every existing requirement with a level. This alone will surface most of your problems: requirements written at wildly different abstraction levels that are currently treated as peers.

Then apply the two tests to the requirements at each level. Flag everything that is not independently verifiable at its current level or that cannot be cleanly assigned to a single owner. Do not rewrite these requirements immediately — just flag them. Establishing the pattern of the two tests matters more than fixing everything at once.

Finally, choose a tool that makes the hierarchy explicit. If your tool cannot natively represent that a system requirement has been decomposed into three subsystem requirements and show you those relationships in both directions, you will fight your tooling every time the design changes.

The right level of requirements granularity is not a number and it is not a rule. It is a structural property of a well-organized hierarchy. Get the structure right, and granularity takes care of itself.