Needs
Updated 15 May 2026
A delivery system responds to two distinct domains: needs and requirements. Understanding what they are, how they differ, and how they fit together is what makes the system legible — to the teams doing the work and to the stakeholders expecting outcomes.
Three ideas run through this section:
Needs and requirements are distinct domains. Needs are directional vectors — what stakeholders want the system to deliver. They are consumed when delivered. Requirements are always-active constraints — rules, policies, standards, and obligations that persist. Treating one as the other creates failure modes that the structure here is designed to prevent. Per ADR-003 in meta/DECISIONS.md.
Needs exist at different levels of specificity. A strategic investment hypothesis is a need. So is a concrete capability a product team will build this increment. So is a specific behavior a developer will implement this week. These are not the same thing — they have different owners, different time horizons, and different degrees of specification. The artifact hierarchy makes those distinctions explicit.
Requirements shape the conditions within which needs are delivered. Business rules, non-functional constraints, regulatory obligations, and operational requirements all govern what the system must do — but they are not items on the backlog. A complete picture of the delivery system has both domains visible and managed separately.
Documents
| Document | What it covers |
|---|---|
| Needs Hierarchy | The artifact hierarchy from Initiative to Story — what each level represents and how they relate within the needs domain |
| Needs and Requirements | The two distinct domains — needs (consumed) and requirements (always-active) — with the four categories within the requirements domain |
Related
- Flow — how these artifacts move through the delivery system
- Flow Metrics — initiatives and features as units of measurement
- Glossary — definitions of Initiative, Feature, Story, and Capability