Technical requirement
A binding technical or architectural decision about how the system is built.
What it is
A technical requirement fixes a "how": the database, an integration, an API style, a hosting region. It is written when the choice is not up for debate in every story.
Why it matters
Some decisions are expensive to reverse and affect everything built after them. Writing them down as requirements keeps every developer and every agent building on the same foundations.
What goes wrong without it
- Each feature picks its own library, pattern or data store.
- Integrations are rebuilt differently each time.
- A choice made in one sprint is silently undone in the next.
What it gives an AI agent
Agents happily introduce a new framework or pattern if it helps the task at hand. Technical requirements tell them which foundations are fixed — for example, "use the clinics' existing calendar, do not keep a second schedule" — so they build on them instead of around them.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| Use a good calendar integration. | Appointments are read from and written to the clinics' existing calendar; the app keeps no separate schedule. |
How it relates to the rest
- Realizes a functional or non-functional requirement: it says how that is achieved.
- Often comes with a decision that records why this choice was made.
- Different from a project requirement, which is about what the project delivers, not how the product is built.
In Corpole
- Type Technical Requirement (TR), in the Requirements group.
- Needs at least one acceptance criterion before Approved or Authority.
- Linked with realizes to the functional or non-functional requirement it serves; the agent reads it in the work context of every story that implements those.