I have gathered and documented thousands of requirements for hundreds of applications over
the years. Good requirements are easily understood by the IT team and are testable.
I recently found a great post by David Shaffer called “It’s the Requirements fault! A Recipe for Requirement Clarity “. He really provides a clear concise method for developing solid requirements. Below are a list of questions from his article that I highly recommend any analyst consider when gathering and documenting requirements.
For each requirement you ask the following questions:
- Is the requirement written in S-V-O format? (Subject-Verb-Object)
- Is the requirement written in active voice using a strong auxiliary verb?
- Does the requirement focus on the business need rather than a technical solution?
- Is the requirement easy to understand by all audiences?
- Is the requirement simple, short, and unambiguous?
- Will an example improve the understanding of the requirement?
- Will a visual figure or wireframe improve the understanding of the requirement?
- Can the requirement be tested?
- Does the requirement contradict any other requirement?
- Does the requirement describe how it must be implemented (Ex: display in alphabetic order, ascending/descending order, required/optional field, alphanumeric, numeric, etc.)
What are some questions you normally use when gathering requirements?