A requirements brief is not meant to imagine every screen from the outset. It should provide a shared basis for understanding current work, priorities and the conditions in which the solution will be used.
Describe the problem before the solution
Explain the current process, the difficulties encountered and the improvements sought. An observable objective is more useful than a list of technologies or a general request for digitalisation.
- Who performs the task today?
- Where do errors or delays occur?
- Which decision should the solution support?
Identify users and their journeys
Each profile should receive the functions and information it needs without automatically receiving every permission. Describe the main actions, approvals and exceptions.
- Internal and external profiles.
- Frequent actions and exceptional situations.
- Approval owners.
Define data and business rules
List the information created, viewed, changed, imported or exported. Specify its origin, sensitivity, useful lifetime and the rules governing calculations or decisions.
- Data sources and owners.
- Access rights by profile.
- Checks, histories and retention requirements.
Prioritise and identify dependencies
Separate what is essential for a first version from what can follow later. Identify existing systems, accounts, providers, formats and interfaces on which the project may depend.
Prepare validation and operation
Define how a feature will be accepted, who will test it, which test data may be used and which deployment, documentation, support or maintenance conditions need discussion.
Key points
- Start from the problem and users.
- Document data, rules and access.
- Prioritise before selecting technology.