Documenting requirements is an essential task for business analysis professionals. Producing high quality requirements is crucial to producing a quality end product. Without quality requirements, the project is open to ambiguity, scope changes and missing features which may result in increased cost and an unusable end product.
A well written, high quality requirement is:[]
1. Clear: The requirement should be written in simple, unambiguous and easily understandable language. Any abbreviations or jargon should be defined to ensure everyone understands the requirement.
2. Complete: The requirement should cover all of the needs of the business/user and contain all information necessary to produce the desired end result.
3. Consistent: The requirement should not conflict with any other requirements, assumptions or constraints.
4. Correct: The requirement should accurately describe the functionality or goal to be delivered. In addition, the requirement should be grammatically correct with proper spelling.
5. Feasible: The requirement should be achievable given time, cost, resource and technical constraints.
6. Measurable and Testable: The requirement should document the business need in a way that can be measured and tested. How do you know if the requirement has been met if you cannot test or measure it?
7. Prioritized: The requirement should include an indication of how vital it is in relation to the completion of the project. A critical requirement indicates that the project is not complete until the requirement is satisfied whereas a desired requirement is not necessary for project completion. Prioritizing requirements will help the team to understand where changes can be made if the project budget or time constraints change.
Tips for writing requirements[]
The requirements document should be understandable by anyone who reads it. To ensure quality, run a spell check and re-read your document to check for errors, omissions and ambiguity.
Write your requirements in the present tense using “shall”. Example: "The system shall display the current market value on line 23 of the asset screen." Instead of: "We would like the market value to be displayed on line 23 of the asset screen."
Avoid vague words that cannot be measured such as better, easy, fast, etc. Example: "The system shall retrieve the requested information in less than .23 seconds." Instead of: "The system shall retrieve the requested information quickly."
Define any jargon, acronyms and abbreviations. Example: "A test environment shall be available during the user acceptance phase (UAT)." Instead of: "A test environment shall be available during the UAT."
Describe the “what”, not the “how”. Business and user requirements should define the need (the what) and not necessarily how (technically) this will be accomplished. By describing how the need will be met, you may be limiting the options for a technical solution.
By following the guidelines of quality requirements and holding walkthroughs of requirements documents with stakeholders and technical team members, you can help ensure the delivery of a quality product.