Requirements lose their rationale during a project. That is the real problem.
They emerge in workshops, end up in a list, move into the ticketing system – and eventually nobody remembers which business need they were meant to address. TAOM preserves the connection to the Process Step, Role, and System from which the Requirement originated.
Refinement
A Requirement is not simply written – it is refined
Between “we need a validation” and an implemented field lie eight stages. Project disputes rarely arise from the requirement itself; they arise where ownership of the next refinement stage is unclear.
The value
The question that comes two years later
Eventually, someone asks why a particular field exists, whether a validation is still necessary, or what happens if an Enhancement is removed.
What a Requirement is connected to
Six relationships that remain intact
Process
The process in which it is needed.
Activity
The exact Process Step where it originated.
Role
Who needs it and who is accountable for it.
System
Which Application must fulfill it.
Business Objective
What it contributes to.
Development Context
What is built from it – through to its WRICEF classification.
Where Requirements come from
Most Requirements begin as findings during Process Discovery
What emerges in a workshop
- 01Missing System FunctionalityWhat the System cannot do and therefore has to be worked around.
- 02WorkaroundsThe spreadsheet beside the System without which the process does not work.
- 03Integration GapsData that has to be transferred manually.
- 04Compliance Obligations and EvidenceWhat someone handles alongside the process without it being formally documented.
- 05Data IssuesFields and data that nobody fully trusts.
No break in context
These findings emerge during Process Discovery – and remain connected to the Process Step where they were identified.
Discovery → Finding → Requirement → Delivery therefore becomes one connected flow rather than a handover between separate tools.
What it produces
Traceable all the way through Acceptance
- 01Business RequirementsWhat the business needs, expressed in business language.
- 02Functional RequirementsWhat the System must provide to meet that need.
- 03WRICEF ObjectsWorkflow, Report, Interface, Conversion, Enhancement, Form.
- 04Functional and Technical SpecificationsRequired behavior and technical implementation, both connected to the same origin.
- 05User StoriesFor teams that work this way – while preserving the same source context.
- 06Acceptance CriteriaThe criteria used to determine whether the Requirement has been fulfilled.
Typical use cases
Where this is applied
- 01Transformation InitiativesWhen many Requirements emerge simultaneously and quickly lose their context.
- 02Fit-to-Standard Follow-upTurn every identified Gap into a Requirement with its business rationale preserved.
- 03Legacy System ReplacementDetermine which existing characteristics are genuinely required by the business and which are merely historical.
- 04Audit PreparationDemonstrate why a Control exists and where it applies.
- 05Handover to DeliverySpecifications that carry the business rationale into implementation.
- 06Testing and AcceptanceValidate against the underlying business need, not merely against the specification document.
Getting started
Start with a Requirement that is currently disputed
Take one where nobody can clearly explain anymore why it was written that way. Connect it to the Process Step from which it originated – and see how much clearer the discussion becomes.