Every public sector RFP has a requirements table. Hundreds of rows, usually. “Ability to do this, ability to do that,” graded Essential or Desirable, assembled under deadline from workshops, old documents, and whatever the last vendor demo left behind.
Then the questions start. A vendor asks what “ability to manage asset data” actually means. An evaluator asks why row 47 outranks row 48. A year into implementation, someone asks whether the thing being built still serves the process it was bought for, and nobody can answer, because the path from why to what was never written down.
Traceability is that path. It decides whether your procurement is defensible or just an argument.
The chain, end to end
The chain starts earlier than most requirements tables do, and it runs later than most of them are ever used.
Start with what exists. Before anyone writes a requirement, document the processes as they run today, then hold them against a policy and compliance review: the legislation, standards, and internal policy the organization is accountable to. The comparison produces the gap list, and the gaps sort themselves into three kinds: people (a role or skill nobody holds), process (a step nobody performs or performs inconsistently), and technology (a capability no system provides). Most requirements tables begin at the technology gaps and quietly skip the other two. That is how organizations buy software for a process problem.
Every gap becomes user stories. A story names a role, a need, and the reason, and it carries the ID of the step and the policy clause it came from. Stories are the hub of the whole chain. Everything upstream explains why a story exists; everything downstream is a reuse of it.
Stories roll up two ways at once. For procurement, related stories group into RFP requirements, deduplicated, with each requirement listing the story IDs it serves. That count is your weighting: a requirement backed by eleven stories across four processes has earned its Essential rating, and one backed by nothing is a brochure line that snuck in. For the business case, the same stories are scored for compliance exposure and service value, which turns prioritization from a room full of opinions into a sortable column. The RFP and the business case then agree with each other, because they came from the same rows.
The chain keeps paying after award. Each story becomes an acceptance test during validation. The passed tests become onboarding scenarios, because they already describe a role doing a real task. The scenarios become training material. Nothing is written twice, and every artifact still points back to the policy clause that justified it.
When a vendor disputes scope, you point at the chain instead of arguing adjectives. When a new executive asks why the system costs what it costs, the chain is the answer. When the auditor comes, the chain is the file.
You don’t need a requirements platform
The usual excuse for skipping this is tooling. It’s a bad excuse. Traceability is a habit of identifiers and links, and a workbook can hold it:
- Give everything a stable ID. Processes get numbers (1.1.1), steps get step IDs (1.1.1-3), gaps get gap IDs (GAP-014), stories get story IDs (US-023), requirements get requirement IDs (REQ-001). An ID that never changes is worth more than any software license.
- One row, one claim. A requirement that bundles three abilities can’t be priced, evaluated, or tested as one thing. Split it.
- Record links in both directions. The requirement lists its stories; the story names its gap, its source step, and its policy clause. Slightly redundant, and worth it, because questions enter the chain from both ends.
- Count the links. A requirement backed by five stories across three processes has earned its Essential rating. A requirement backed by nothing is a brochure line that snuck in, and you want to catch it before pricing does.
On a recent asset management engagement, this took the form of one workbook: dozens of numbered processes, over a hundred user stories, about fifty requirements, every one carrying the IDs of what it came from. No platform. Just discipline.
The payoff compounds
The first payoff is the RFP itself. Requirements carry their pedigree, evaluators weight what’s demonstrably needed, vendors bid against specifics.
The second payoff shows up later. Requirements kept as structured, linked rows are data. You can count them, query them, report on them, and render them into documentation that stays current because it is the source rather than a copy of it.
That second half is where our recent work has gone. The data extensions we build under Pliris Studios connect exactly this kind of structured workbook to Power BI, so the same rows that hold your processes and requirements render as designed pages and process maps, live. At that point the traceability discipline stops being insurance and becomes the feed for everything downstream. And it started with nothing fancier than IDs in cells.