The requirements chain
From why a project exists to how it is built: how objectives, requirements and constraints connect, and why each link matters to an agent.
Reading the chain
Requirements are not a flat list. They form a chain that runs from why to how. An objective says what the project 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 project.
Project requirements describe what the project 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.
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. The pages on each record type below explain every link in detail.