Business Requirements Document Checklist
This article focusses on a checklist that can be applied to check the quality of requirements that have been written. It will help the author of a requirements document to be able to self-assess their work to aid the quality of the deliverable. It could also be used to create a common standard across a whole team.
The aim of a business requirements document is to articulate in writing the business requirements for a change or project. It should reflect the requirements of all the impacted business stakeholders. These should be agreed between them, how important they are and why they are needed.
They should be written clearly and concisely and not ambiguous. The business stakeholders need to be clear on what is requested as well as the stakeholders responsible for delivering the requirements.
It is worth becoming familiar with diagramming techniques as these are a good way to ensure requirements are unambiguous. They can also be quicker and easier to read than lines of text. See this link for a previous article I wrote called The Importance of Diagrams in Business Analysis.
If you want a view of where the business requirements document fits within other types of documentation and within the project lifecycle then see my article, A comprehensive guide to the major Business Analyst deliverables?
For an overview of what a business requirements document contains then see What to include in a Business Requirements Document (BRD)
Checks of the Document Structure
| DS1 | Is there a standard BRD template that must be used or a approach based in the organisation you work for? First check what this is and the guidelines. This will help with standardisation as part of a business analyst team. | |
| DS2 | It is not necessary to write a huge chunky business requirements document that can become difficult for stakeholders to understand and be lengthy to put together.
Have you helped control this by using techniques to reduce the size of a business requirements document such as the following: 1. Use of diagrams 2. Break down the requirements into separate documents or create clear categories and groupings instead 3. Ensure you are not showing off knowledge and are sticking to the requirements 4. Not mixing up different levels of information in your requirements. Have a separate business rules section if there are lots of rules you want to describe. 5. Make use of prototyping or story boards 6. Agile techniques such as use of user stories or use cases to break down the requirements into management chunks that can be used to demonstrate business value. This may lead to a different format or medium to the traditional requirements document. The checklist in the business requirements sub section below will still be applicable. |
|
| DS3 | Clear labelling of documentation, the author, the sponsor and date created. | |
| DS4 | Has version control been applied?
All versions should be recorded along with a short narrative of the difference between each version. |
Introductory sections
| WC1 | Is a glossary required?
Is it necessary to enable your stakeholders to be familiar with terminology used in the document and any abbreviations used? |
|
| WC2 | Have you included an executive summary for those that might not have time to read the whole document and just need to be consulted?
This should include: · Introduction – no more than half a page also setting out the problems to be solved or the opportunities to be realised · Project objectives · Associated documentation · Items in scope · Items out of scope |
|
| WC3 | Have you captured any assumptions, risks, issues and dependencies that are relevant to gathering the requirements? | |
| WC4 | Have you set out the work context?
This could be a context diagram, or a list of all of the stakeholders and system interfaces affected by the scope of the Business requirements document. |
Business Requirements
| BR1 | Does each requirement relate back?
• To the problem or opportunity statement • To a scenario or business process This is to ensure each requirement is needed |
|
| BR2 | Is each requirement tagged with a Unique Identifier reference? | |
| BR3 | Is the requirement implementation-neutral?
• Defines what functionality is required but not how • Allows the architect or system developer to decide what technology/method is best suited to achieve the functionality |
|
| BR4 | Is the requirement stated clearly and concisely?
• Consists of a single requirement • No more than 30-50 words in length • Easily read and understood by non-technical people • Unambiguous and not susceptible to multiple interpretations • Does not contain definitions, descriptions of its use or reasons for its need • Avoids subjective or open-ended terms |
|
| BR5 | Is each requirement stated in precise, verifiable and in measurable terms?
• Stated in such a way that is can be tested by inspection, analysis or demonstration • Make it possible to evaluate whether the solution met the requirement • Is it free of weak words (like the following): o Appropriate o Efficient o Powerful o Fast o Easy o Effective o Reliable o Compatible o Normal o User friendly o Before o After o Quickly o Timely o Strengthen o Enhance o Minimize o Maximize o Rapid o Sufficient o Adequate o Support o But not limited to |
|
| BR6 | Has the requirement been stated in active voice?
• Has passive voice (shall be) been avoided? |
|
| BR7 | Does the requirement state what the system shall do, rather than what it shall not do?
• If “shall not” has been used, is the use of the negative justified (for safety, etc.), and have double negatives been avoided? • If there are requirements that are not currently required but for a possible future phase these must be added to an appendix instead and not be part of the main requirements section |
|
| BR8 | Is each requirement complete?
• Contains all the information that is needed to define the requirement • Leaves no one guessing (For how long?, 50% of what?) • Includes measurement units if necessary |
|
| BR9 | Can an objective test be written for the requirement?
• Are both a test method and a test case evident in the wording of the requirement? • Are all necessary reaction windows or other tolerances stated in the requirement? |
|
| BR10 | Are the requirements consistent?
• Does not conflict with other requirements in the requirement specification • Uses the same terminology throughout the requirement specification • Does not duplicate other requirements |
|
| BR11 | Is each requirement viable?
• For example: • Can be met using existing technology • Can be achieved within budget • Can be met within schedule • Is something the organisation has the necessary skills to utilise • Will be used by end users • Helpful to build the solution |
|
| BR12 | Are the requirement’s preconditions and triggers clearly defined within the requirement? | |
| BR13 | Have exception scenarios been explored in the requirements? | |
| BR14 | Has the rationale for the requirement been clearly stated?
• Are there any associated requirements that might affect interpretation of this requirement and should therefore be referenced in the rationale statement? • If no rationale statement has been included, is the rationale obvious in the requirement statement or from associated directives or references? |
|
| BR15 | Has a Business value, source and rationale populated for each requirement? | |
| BR16 | There is a mixture of requirements priorities with no more than 60% of them being ranked high. |
Final Quality Checks
| FQ1 | Has each requirement been evaluated and vetted by all stakeholders who are impacted by it?
• Which design, and implementation groups are affected? • Which test and integration groups are affected? • Are any third-party equipment organisations affected? • Which maintenance and support organisations are affected? • Do any other specialists or users need to evaluate it? |
|
| FQ2 | Are all the impacted stakeholders on the circulation list for final review of the requirements document?
• Have we provided each of them a list of the requirements they need to review? |
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
