Requirements form a chain
A useful way to structure requirements is to move from the business need toward the detail needed to design, build, test and transition the solution.
Four useful levels
| Question | Practical answer | |
|---|---|---|
| Business | Why the organization needs change | Increase repeat purchase rate |
| Stakeholder | What a stakeholder needs to achieve | Customer can pause a subscription |
| Solution | What the solution must provide | Subscription can be paused without cancelling |
| Transition | What is needed to move from current to future state | Existing customers receive migration instructions |
Functional and non-functional requirements
Functional requirements describe behavior. Non-functional requirements describe qualities or constraints such as performance, security, accessibility, availability, maintainability or compatibility.
A system that “works” but takes ten seconds to load may satisfy the functional requirement and still fail the business expectation.
Quality test
Do not over-specify too early
Requirements should provide enough detail to support the next decision. In a high-uncertainty environment, forcing every detail into a large document before learning anything can create false certainty.
Example
Weak: “Add a better subscription page.”
Stronger: “A returning customer must be able to review, pause, resume and cancel an active subscription from their account without contacting support.”