What makes for a good set of requirements?
It’s no secret that I love a good set of requirements. Working from a solid set of requirements makes my life so much easier. They give clarity over what is needed, formally setting the scope of the work, and provide a focal point for conversation.
I am always wary of projects with ambiguous open-ended requirements. They are often an indicator that the project lacks a clear focus or adequate planning.
Starting from a poor set of requirements should raise alarm bells. I view poor requirements as an early indicator that a project is going to be a bit of a slog.
So what makes for a good set of requirements?
Formality – Requirements need an element of formality, a stamp that says to the world that this is an official part of the project. Projects should have clear processes for creating, reviewing, modifying and completing requirements.
What, not how – A requirement is an expression of the desired outcome and not a statement of how something is to be done.
Need, not want – Requirements should focus on what is needed to satisfy the projects goals. They are not a wish list of desired features requested by stakeholders.
Detail – The level of details within a requirement can change from project to project, team to team. The levels of detail held in the requirement should be agreed by the team at the start of each project.
Accessible – All the requirements and the status of each requirement must be held in one central location that is accessible to all.
Concise – Each requirement should focus on just one element. Complex requirements should be broken down into smaller subsets of requirements.
Consistent – All requirements must be recorded in the same format and should not conflict with other requirements. Capturing requirements is a skill that needs to be cultivated like any other skill. Having a number of trained, experienced staff to do this job will help maintain a level of consistency.
Reference – Each requirement must have a unique reference number.
Current – Requirements are a process of discovery and should evolve throughout the project. If the scope of work changes or the team’s understanding changes, then the requirements should also be changed.
Complete – A requirement must contain all the relevant information at the agreed-upon level of detail. The full set of requirements must cover the full scope of the work. This should include requirements from each stakeholder cohort.
Correct – All requirements should support the project in achieving its goals. As the project evolves, some requirements go bad and are no longer needed. Any requirement that is no longer needed should be closed off.
Feasible – It should always be possible to deliver a requirement.
Unambiguous – A requirement should provide context so that it can only have one possible interpretation.
Verifiable – The status of each requirement should be tracked throughout the project. It must be clear how each requirement will be tested. This may include details of the desired level of quality or quantity.
Prioritised – Requirements should be ordered so that the must-have features are completed first, with priority given to requirements with the highest number of dependences.