A similar idea for the Business Analyst is: “To write good requirements, you need to have walked a mile in the user’s moccasins to understand how they will use a product.”
Here are three simple steps to follow:
- Make no assumptions about how users will use the product.
- Identify the user community for the requirements you are writing.
- Identify how the user community will use this capability/functionality.
- Ensure you make no assumptions regarding their understanding of the functionality.
- Break down the requirements into simple steps that are easy to understand by anyone.
- Address the 5 Ws – Who, What, Where, When and Why.
- This highlights the benefits to the user.
- State what benefits this capability provides.
- Identify who will benefit most by using this functionality.
- Provide reasons why this capability/functionality provides the best benefits to the user.
- Identify when this capability/functionality can/will be used.
- Define where this capability/functionality is best used.
- Break down the requirements into simple parts – do not complicate it.
- List any assumptions you are making to use this capability/functionality.
- List any dependencies that exist to implement this capability/functionality.
- Identify potential risks that may exist with this capability.
- From a scope perspective, list what’s in and what’s excluded.
- List the requirements in simple language. Start with the most obvious. List one capability at a time. List what will and will not work with this capability, keeping in mind the 5 Ws. Reference examples or diagrams to make your point.