Crisis 1 · Year 0-1
Spreadsheet-managed requirements collapse. The coverage matrix breaks above ~800 entries.
Typical bolt-on
Adopt a dedicated requirements management tool.
Compounding cost
€3-10k / engineer / year. Solves the requirements crisis.
Glossary · Comparison
Engineering OS vs Requirements Management Software
Requirements management tools cover one slice of engineering well, the requirement-to-verification chain. An Engineering Operating System covers that slice and the five others a hardware team hits before certification. This page is the structural reference: where the categories diverge, why most teams outgrow a requirements-only setup, and how to federate from an existing RM seat without ripping anything out.
Two categories, not two products
Comparing an Engineering Operating System to a requirements management tool is not a feature-for-feature contest, it's a scope contest. The requirements management category was designed around one entity type. The Engineering OS category is the operating layer that carries every engineering artifact on one typed graph — the layer that turns engineering into operational excellence and the infrastructure itself into an industrial advantage. Both can coexist; the seam is structural.
Category, Requirements Management
Scope: the requirement-to-verification slice
- ·Authoring requirements with explicit attributes (rationale, source, priority)
- ·Bidirectional requirements ↔ verification traceability matrix
- ·Coverage analytics on the requirement tree
- ·Review workflows scoped to requirement state transitions
- ·Export of the requirement set for an audit pack
Category, Engineering Operating System
Scope: the entire engineering graph
- ·Requirements as one typed entity among many
- ·BOM (parts, assemblies, suppliers) with computed mass/cost rollups
- ·Tests, test plans, V&V records linked to the requirements AND to the components they exercise
- ·Cryptographic baselines spanning requirements + BOM + tests + documents
- ·Risk items in the same graph (ISO 14971 / EN 12100)
- ·MCP-native AI agents acting on the whole graph with scoped permissions
- ·Audit-ready exports across the full product history, not just the requirements slice
A requirements management tool keeps doing its job inside an Engineering OS, federated as the authoring surface for that one slice. The Engineering OS owns the structure that binds requirements to everything else the program needs to ship and certify.
The crisis-progression model
Most hardware teams hit the limits of requirements management not in one event, but in a predictable sequence. Each crisis bolts on a new tool. By the fifth, the engineering org is paying for six systems that don't share a graph.
Crisis 2 · Year 1-2
BOM in a spreadsheet still doesn't talk to the requirements tool. Mass / cost rollups drift.
Typical bolt-on
Adopt a PDM / PLM for BOM. Add a sync script with the RM tool.
Compounding cost
€8-18k / engineer / year additional. Two systems of record.
Crisis 3 · Year 2-3
Baselines disagree. The RM tool, the PLM and the shared drive each report a different state at the same revision tag.
Typical bolt-on
Add a config management discipline + custom scripts to synchronize baselines.
Compounding cost
1-2 FTE configuration engineers. Audits start to expose drift.
Crisis 4 · Year 3-4
Pre-audit reconstruction takes 3-6 weeks per program.
Typical bolt-on
Add an audit-evidence tool + document repository structure.
Compounding cost
6+ FTE-weeks per audit × 2/year. Engineering velocity drops.
Crisis 5 · Year 4-5
AI agents can't act usefully because data is fragmented across 5 systems.
Typical bolt-on
Build a custom data lake / data warehouse + retrieval layer for AI.
Compounding cost
€300k-1M build, €200k+/year maintain. Adds a 6th source of truth.
Crisis ∞
6 systems · 3 reconciliation jobs · 8 FTE on tool maintenance · audit anxiety.
Typical bolt-on
Adopt an Engineering OS as substrate. Federate, don't replace.
Compounding cost
Migration paid for itself by Y2. License + admin envelope drops 5-10×.
Federation playbook: starting from an existing the RM tool seat
Teams don't rip out their requirements tool on day one. They federate it as one input to a broader graph.
A.
Import the requirements graph
Connect to the the RM tool API (OSLC where available, native otherwise). Pull requirements, their verification status, and the bidirectional links between them. The graph in Koddex now mirrors the RM tool - read-only for now.
B.
Add what the RM tool doesn't carry
BOM, tests, baselines, risk items, supplier qualification, typed entities the RM tool doesn't model. Each one links to the requirements it touches. The engineering graph now extends past the requirements slice.
C.
Flip authorship direction
Once engineers are working with the broader graph in Koddex daily, they start editing requirements there. The RM tool becomes downstream, receiving updates, not authoring them. Existing licenses keep the historical view, but new work flows through the engineering graph.
D.
Sunset the RM seat at contract renewal
Typically 12-18 months in, the RM tool's authoring role has migrated. License renewal becomes optional. The historical the RM tool archive remains accessible (often through a single read-only seat) but the engineering graph is the operational system of record.