Requirements under control - without a standard
You're not building an ECU and you're not preparing an ASPICE assessment. Still, there is a specification, there are commitments to the customer, and in the end one question: did we deliver everything we promised - and can we show it?
From specification to acceptance
Every commitment becomes an object with an id - straight from the PDF, no retyping.
The problem has nothing to do with standards
It appears wherever one person promises something and another builds it.
The specification lives in Word
Version 7, attached to an email. Whoever missed last week's change builds against version 6.
Commitments without proof
The quote lists 40 points. Which of them are accepted, nobody knows without asking around.
Changes without a price tag
The customer wants something different. Whether that's trivial or half a sprint only shows once you build it.
Acceptance turns into a debate
In the end two lists sit side by side: theirs and yours. And neither is the truth.
One specification, five stations - from quote to acceptance
How WORKSPACE.PM accompanies a fixed-price project: 60 positions from a special machinery specification, a change request mid-build, an acceptance with a protocol - without ceremony and without a second tool.
40 pages become 60 traceable commitments
The specification arrives as a PDF. The AI assistant proposes requirements including acceptance criteria - you review and accept what fits; nothing lands in the list unasked. Every commitment gets a stable id that still means the same position in three years, plus a priority (must, should, could) and an owner. No more structure is needed at the start: levels, states and approval stages stay switched off until you want them.
Every commitment knows who builds it and who verifies it
The requirement is connected to the work package that implements it and to the verification item that backs it. An acceptance criterion turns into a pre-filled verification item in one click - you don't write the test twice. Both directions are visible: the work package shows which commitments depend on it, the requirement shows which verification covers it.
visible from both sides
The change request gets a price tag - before you commit
Six weeks before acceptance the customer wants position 23 differently. The impact analysis shows in seconds what depends on it: two work packages, one verification item, one dependent commitment. Change the text and the version increments while every link is flagged as suspect - someone has to confirm the verification still fits. That turns “we'll do it quickly” into a defensible statement about effort and consequences.
Impact of REQ-0023
3 links become suspect
Verification runs step by step - the evidence emerges with it
Verify mode walks you through the item: preconditions and expected result stay visible, every step is ticked off. The overall result is derived from them, a failed step immediately offers a field for the actual result and, on request, creates a task on the board. The run is never overwritten: the history shows when what passed - and what it was verified against.
Acceptance takes an hour, not three days
Before the meeting you freeze the state - requirements, verifications, links and results together, immutable. Beforehand you see which gaps you would be freezing in. To the meeting you bring two documents: the coverage report as a PDF and, if the customer wants it, the evidence package as an archive. When release 2 comes, comparing two baselines shows what was added, changed and removed.
coverage-report.pdf
None of this is mandatory. Levels, states, approval stages and mandatory rules are opt-in - a project can work with a single level called “requirement” and still have the full chain of evidence.
None of this is mandatory. Levels, states, approval stages and mandatory rules are opt-in - a project can work with a single level called “requirement” and still have the full chain of evidence.
One flow, six modules - one data base
In WORKSPACE.PM requirements management is not a second tool next to the project but part of the same system. That is exactly why impact analysis can take work packages, risks and dates into account.
Requirements & verification
Project management
Governance
AI & automation
One commitment, one source
Requirement, work package, verification and date live in the same project. There is nothing to synchronise - and no second list anyone can forget.
Three objections we hear often
And what they turn into in practice.
“With 60 positions it isn't worth it.”
Capturing takes as long as typing in Word - everything else is computed: coverage, suspicion on change, evidence. The effort barely scales with the count; the payoff shows at the first change request.
“We don't want standards bureaucracy.”
You won't get any. Levels, states, approval stages and mandatory rules stay off until you switch them on. What remains is a list with an id, an owner, a verification and a traffic light.
“We might need ASPICE later after all.”
Then you switch on the preset. Levels, the approval chain and mandatory rules come with it, the data stays where it is - no migration and no export into another tool.
Same data, more rigour
V-Modell XT and Automotive SPICE ship as presets: levels, states, approval stages and mandatory rules are switched on, not rebuilt. Starting pragmatically today means migrating nothing later.
Related use cases
When your project needs to stay under control in other ways too.
Frequently asked questions
What prospects from non-regulated projects ask most.
Yes, because the effort barely scales with the count: capturing takes as long as typing in Word, everything else - coverage, suspicion on change, evidence - is computed. The payoff shows at the first change request.
No. Levels can be renamed or switched off. A project can work with a single level, which is then simply called “requirement”.
By hand, through the API, or AI-assisted from a PDF: the assistant proposes requirements including criteria, you accept what fits. Proposals are never automatically binding.
Yes. The coverage report as a PDF and the evidence package for a frozen baseline are made for exactly that - both are generated on demand from the data you already have.
The impact analysis shows up front which work packages, verifications and further commitments are affected. Change the text and the version increments while the affected links are flagged as suspect - the follow-up work becomes a work list instead of living in somebody's memory.
Turn commitments into evidence
Fourteen days - bring your current specification along.