Requirements Definition
Objective¶
To document the requirements needed to ensure the problem is addressed in a valuable way.
Defining and Refining Requirements¶
During discovery activities, requirements will be elicited or proposed by stakeholders. Following this, the practice of requirements must be defined and further refined in order to:
- collate requirements that have surfaced through various discovery activities
- refine requirements, so that they are articulated in a way the Delivery Team can relate to
- state explicitly any missing or implicit requirements
- sort them, e.g. using a MoSCoW framework
- state explicitly any dependencies or considerations that may impact iterative delivery
Types of Requirements¶
The requirements specification should include:
- Functional requirements – how the system or feature should behave to address the stated problem.
- User Interface requirements – how the system or feature should appear. For example, it may be helpful to note where users will need additional information, where there are specific accessibility or mobile considerations, or which style rules need to be applied.
- Non-functional requirements (NFRs) – system or feature attributes that cannot be described as functional behaviours. These may include, but will not be limited to security, performance, scalability, data privacy and testability.
In all cases, the Delivery Team may find it helpful to have requirements linked to real world use cases, to highlight the value of the requirements and generate meaningful discussions.
Responsibilities¶
| Owner | Responsibility |
|---|---|
| Problem Owner | The person accountable for ensuring the requirements specification aligns with the problem definition and hypothesis |
| Product Lead | The person responsible for gathering, sorting and refining requirements, and consolidating them into a specification |
| UX Lead | The person responsible for surfacing any UI/UX requirements to the Product Lead |
| Engineering Owner | The person responsible for surfacing any technical requirements to the Product Lead |
| Delivery Team | The group responsible for reviewing the requirements and making sure they understand them |
Triggers¶
Requirements can and should be captured throughout the discovery process, however not every piece of information collected during discovery will become a requirement.
Requirements should be refined once the problem definition has been completed and with enough time to inform solution design before delivery is planned to start.
As a rough guide, you could aim to have requirements ready three months ahead of delivery, although you should continue to review the assumptions and expectations set in your specification.
Toolkit¶
Toolkit