The Requirements Operating Model
Four workflows,
one operating model.
The same architecture serves four fundamentally different engineering organizations. Different presenting problems. Same underlying model.
The model
Every organization rests on the same Knowledge Substrate. What differs is which process layer does the sharpest work for their workflow.
The four archetypes further down show where each one gets the most acute value from the framework, and one question further down helps place you among them.
The shared spine
In the workflows we have mapped, the same spine appears whatever the tools and however many steps. What changes between organizations is what fills each box, and how far it splits, since authoring and review are rarely one step each.
This is the box the operating model makes explicit. The rest of this page is about why that matters.
Why separation, and why now
The principle
Generation and evaluation cannot be the same system.
Something writes the requirement. Something else has to judge it. When one engine does both, the judgment inherits the author’s mistakes, and all that’s left to inspect is how confident the output sounds.
The operating model keeps them apart. Generation belongs to the Transformations Layer. Evaluation is a separate step, working from rules that live in the substrate rather than inside the generator, so the standard survives a change of author, a change of tool, and a change of model.
Rules in the substrate can be read, argued with, and versioned. Rules inside a generator can only be inferred from their output.
That evaluation belongs to a deterministic engine. Engineers stay in the loop deciding what the results mean. They stop absorbing the check itself.
“You have the generative aspect to generate requirements, but then you also have the judge to actually measure the quality. Those two should be two different things.”
Systems engineer, medical device manufacturerThe pressure
Requirement volume is rising. Review capacity is not.
Generated text reads as credible whether or not it is correct. Three things recur. Requirements get drafted faster than anyone can defend them, downstream tools inherit whatever they were given, and senior engineers become the bottleneck for volume they did not create.
The constraint has moved from writing to judging. That is what makes separation practical rather than philosophical. A distinct, reproducible evaluation step lets volume rise without review capacity rising with it. Evaluation folded into the generator just means more unexamined text.
“What you really need is more of the rules-based quality check. You don’t want it to be random. You don’t want it to be probabilistic.”
Systems engineering consultancyThe same requirement, checked twice, returns the same result.
A judgment that changes between runs is an opinion, and an opinion cannot be filed as evidence. Reproducibility is what makes a check stand up in a design review, an audit, or a customer’s assessment years later.
In the workflows we have looked at, that is how it gets used. The check is re-run on the approved set so its report can be filed with the design record.
If requirement volume doubled next quarter, what would give first: the writing or the reviewing?
Where do I fit?
One question sorts most organizations: who reads your requirements next, and what do they do with them?
- 01A supplier or contractor you do not employ builds to them. Spec and standards issuers
- 02Your own verification team proves the design against them. Own-product builders
- 03The customer who issued them checks that you met them. Solution suppliers
- 04The client owns them once you hand them back. Engineering consultancies
The four archetypes
Which layers do the sharpest work, and why.
All four are set out the same way. What we see in these workflows in practice, then where the model helps, then one question a team can put to itself.
01
Spec and standards issuers
Sharpest value
- The Outputs Layer treats the spec as an artifact that must be legible to a downstream reader who was never in the authoring room.
- The discipline that makes an engineering record defensible to a certifier is the same discipline that makes a spec buildable by a supplier.
- The Inputs Layer applies Quality of Admission during authoring, so what enters is consistent with everything already there.
- Configuration Authority is what gives a baseline meaning. One version is the spec suppliers build to, and every revision carries forward from it.
Issuers author against their own templates and house rules, not a generic standard, and they revise a standing corpus instead of writing once. In the workflows we have looked at, the checks run requirement by requirement, and coherence across the whole set is rarely checked at all.
If two documents in our library contradict each other on the same interface, who finds out first: us, or the supplier building to both?
02
Own-product builders
Sharpest value
- The Governance Layer establishes Configuration Authority, one source of truth, so design changes propagate without breaking traceability.
- The Transformations Layer covers the arc from user need to concept to design output that design controls demand.
- The Outputs Layer turns the quality record into filed evidence, so the file shows what was checked rather than only who approved it.
Review runs in two tiers: an informal draft review inside the requirements tool, then a formal one exposed to audit. Quality is owned at the point of authoring with no hard gate later, the check is configured differently per requirement level, and it is run a second time on the approved set so the report itself becomes design-file evidence.
When an auditor asks how we knew a requirement was good enough to approve, what do we hand them?
03
Solution suppliers
Sharpest value
- The Inputs Layer applies Quality of Admission to flow-down that arrives at varying quality.
- The Transformations Layer covers decomposition into verifiable lower-level requirements.
- The Outputs Layer supplies the traceability evidence back to the prime, and a reproducible check is what makes that evidence hold under assessment.
- Configuration Authority settles which version of the customer’s requirement set the delivery is being proved against.
Flow-down arrives at whatever quality the prime sent it, so incoming and internally derived requirements are held to different bars, sometimes tiered by mission criticality. Where we have seen customer assessment concentrate is the decomposition to lower-level requirements, which is often the part of the chain with the least written standard behind it.
Can we show what each customer requirement decomposed into, and that every piece of it can be tested?
04
Engineering consultancies
Sharpest value
Substrate is the primary lever here.
- The value here is the Knowledge Substrate, a representation that sits above whatever client system is in play and stays the same when the system changes.
- One standard applies across Word, Excel, Polarion, DOORS, Jama, or a client tool nobody on the team has used before.
- The Inputs Layer handles Quality of Admission when client documents have to be formalized before anything can be done with them.
The requirements platform belongs to the client and changes with the engagement, so a consultancy cannot standardize on one of them. The incoming artifact is usually a document, not a tool export, so what travels between clients is the representation and the evidence.
If the next client works in a tool none of us has used, how much of our method survives the move?