02 · Product
Requirements
Requirements as live data, not frozen text.
Requirements in synapse™ are written against the system architecture, checked against it live, and verified through it. The hierarchy follows rules you configure, so the process is enforced by the tool rather than by a document nobody reads. The whole team works on the same set at the same time, in an interface built to be used every day.
One hierarchy across levels, from customer requirements down to the statements a subsystem owner is accountable for.
- Built for teamsEveryone works on the same requirements at the same time, with comments and mentions on the requirement itself. No master spreadsheet, no merging two versions on a Friday.
- The process is enforced, not followedRequirement definitions are configurable: which kinds exist, what they carry, which parent each can sit under. The hierarchy you designed is the only one the tool allows.
- Parametrised against the architectureA requirement references the parts and attributes of the system model directly. The values it states are the model's values, live, not numbers copied in.
- Checked liveA requirement carries its own compliance rule and grades itself against the current design. When a value moves past its limit, the requirement fails on its own.
- Verification flows upVerification status comes from the actions and children below, never from a dropdown. A parent is verified when what is under it is verified.
- An interface engineers want to openFast, clean and keyboard-driven. Table, tree, filters and saved views, designed for daily use rather than for the demo.
Written against the system, checked against the system
A requirement mentions the parts and attributes it constrains and reads their live values from the architecture. A compliance rule on the requirement grades that value against the limit, so a mass budget that goes over is a failing requirement today, not a finding at the next review.
A hierarchy imposed by the tool, not maintained by hand
Mission, capability, function and base are the defaults. Define your own kinds, the fields they carry and the parents they accept, and a requirement can only be created or moved where those rules allow. The decomposition stays the one your process designed.
Verification flows up
Each requirement's verification status is derived from its linked verification actions and from its children. Complete the actions at the bottom and the status rolls up on its own, respecting whether the parent is verified partially or entirely through its children.
Every change, by everyone, on record
The whole team edits the same requirements, and every edit is logged with who made it, the value before and after, and whether it is still a draft or already merged into the baseline.
