The requirements chain

Reading the chain

Requirements are not a flat list. They form a chain that runs from why to how. An objective says what the solution must achieve. Business requirements say what the organisation needs to reach it. Stakeholder requirements say what each group of people needs. Functional and non-functional requirements say what the system must do and how well. Technical requirements say how it is achieved.

Each link refines the one above it. When a functional requirement can be traced up to an objective, everyone — and every agent — can see why it exists, and what would be lost if it changed.

Two things beside the chain

Constraints do not describe what to build; they limit how it may be built. A product constraint limits the product itself, a business constraint comes from the organisation or the law, a project constraint limits time, budget, team or tools. A constraint can apply to specific requirements or to the whole solution.

Project requirements describe what the solution must deliver besides the product: training, documentation, a test suite, a go-live date as a deliverable. They are not about the software's behaviour, which is why they sit beside the chain rather than in it.

Below the chain: proof and work

Every requirement carries acceptance criteria: the conditions that prove it is met. Tests check the criteria. Work items — epics, stories, tasks — bring the requirements to life and cover their criteria. None of these replaces a requirement; they point back to it.

Where the chain lives: the change and the solution

A requirement says what should change. It belongs to the initiative that carries out that change, which in turn answers a demand. When the initiative closes, its requirements become history: they stay, with their reasons, as the record of why it was built that way, but they no longer bind agents. What the system does is described by the solution's design records.

What the system is today is described by the solution's design records: business rules, functional behaviour, qualities, the technical design of each component, and architecture decisions. Stories and epics carry the design changes that update them, and a change is applied only when the work is Done. So the agent always reads two things: the solution's current design, which it must respect, and the initiative's requirements, which say what to change.

Why the chain matters to an agent

• It tells the agent why, so it can make sensible choices where the requirement is silent.
• It tells the agent what else is affected, so a change in one place does not quietly break another.
• It tells the agent which limits apply, so it does not build something that cannot ship.
• It lets people see, before code is written, where the chain is missing a link.

In CorPole

CorPole models the chain with typed relations: a requirement refines the one above it, a technical requirement realizes a functional or non-functional one, a constraint constrains requirements, and a new record replaces an old one. An agent reads the chain upwards before it implements anything. Requirements belong to an initiative; what has been delivered lives in the solution's design records. The pages on each record type below explain every link in detail.