From requirement to proof
Every requirement is an object of its own - with level, status, approval and the verification that backs it. No spreadsheets, no searching, no “I think that was covered”.
Why requirements get lost in spreadsheets
Not because nobody maintains them - but because a spreadsheet has no notion of relationships.
Nobody knows what is actually verified
The status column says “done”. Whether a passed test exists for it lives in another document. Or in none.
One change, twenty follow-up questions
A requirement gets rephrased. Which tests, work packages and commitments depend on it? Only whoever read everything knows.
Evidence is assembled at the end
Two weeks before the audit the hunt begins - exactly when the months-old gaps surface.
Two versions of the truth
The business unit's spreadsheet and engineering's test list. Both maintained, both different.
Four steps, permanently traceable
The same flow whether you work to a standard or simply want to keep a specification under control.
Capture
A requirement as a standalone object with a stable id, level, priority and acceptance criteria.
Link
Typed links to verification items, work packages, risks and documents - visible from both ends.
Verify
Walk the verification item step by step, record the result, attach the evidence. A run is an event, not a checkbox.
Freeze
Capture a state: requirements, verifications, links and results together - immutable and comparable.
Requirements
A requirement is an object, not a row
Stable id, its own detail page, a refinement tree from customer requirement down to component. Every content change raises a version - automatically, without discipline.
Gerät einschalten
Selbsttest abwarten
Anzeige prüfen: alle Segmente leuchten
Coverage
“Verified” means passed - not planned
The traffic light is computed, never set: from the linked verification items, their latest runs and the date of the requirement's last content change. Nobody can talk it up.
Traceability
The matrix that shows your gaps
Rows are requirements, you pick the columns: verification level, work packages, risks, change requests. Empty cells aren't a display gap - they are the statement.
| Unit | Integration | Qualifikation | Abnahme | |
|---|---|---|---|---|
| REQ-0101 | — | |||
| REQ-0102 | — | — | ||
| REQ-0103 | — | — | — | — |
| REQ-0104 |
REQ-0103 hat auf keiner Ebene eine Prüfung — die Lücke steht als Zeile da, nicht als Fußnote.
BAS-0003 · Abnahme Release 2
Typ Auslieferung · eingefroren am 18.07.2026 · Aufbewahrung bis 2036
248
Anforderungen
163
Prüffälle
410
Verknüpfungen
214
Verifiziert
Der Stand ist unveränderlich. Was heute anders ist, zeigt der Vergleich mit BAS-0002 — dazugekommen, geändert, entfernt.
Evidence
The state of that day, immutable
A frozen state captures what applied at a point in time - including verification results and the methodology in force. Before freezing you see which gaps you are freezing in.
Go deeper
Without ceremony
Rigour where it proves something - and only there.
You decide how strict
Levels, states, mandatory rules and approval stages are configuration. A generic project works without any constraint, an ASPICE project with the full chain.
Approvals expire instead of blocking
Changing an approved requirement is never blocked: the status moves to “Changed” and the old approval stays on record with the version it applied to.
Derive instead of maintaining twice
Coverage, suspicion, rule violations and approval state are computed. There is no second field anyone has to keep in sync.
Built for regulated projects, just as usable everywhere else
Automotive SPICE and V-Modell XT set the bar - which is why baselines, approvals and assessment evidence exist. If you simply want to keep a specification under control, switch all of it off and keep requirements, verifications and the traffic light.
Frequently asked questions
What prospects ask most before the trial.
No. Presets for both are included, but every project can work generically: requirements, verifications, links and the coverage traffic light work without any state or approval obligation. Rigour is opt-in, not a prerequisite.
No, it is part of the same system. Requirements link to work packages, risks, change requests, wiki pages and tasks - which is exactly why impact analysis answers questions a standalone requirements tool cannot.
Through the interface, the public API, or AI-assisted from a specification PDF. For day-to-day operation every action is also available as an API and as tools for AI assistants.
The version increments, the approval expires (the record remains, naming the version it applied to), and every link attached to it is flagged as suspect. Someone then confirms the link still holds - or re-runs the verification.
Yes. The coverage and consistency report is generated as a PDF from live data; the evidence package is an archive tied to a frozen state - with a spreadsheet, the methodology in force and a cover sheet.
Requirements that prove themselves
Fourteen days, with your real requirements, no credit card.