When developing a new product, system or service there are two primary ways you can end up going down the wrong path:
1 - Inadequate requirement capture means that you are developing something that may not work properly due to:
- critical performance shortfalls
- interoperability issues at key interfaces
- survivability/reliability issues in the real operating environment
- unexpected/unwanted behaviour
- solution will not work at scale
2 - Inadequate requirement validation means that you may be building something that nobody wants because the solution:
- solves the wrong problem
- is more difficult to use than existing or competing options
- doesn’t work properly with other systems key to the user
- cannot realise its potential due to limitations in other systems owned or operated by the user
Both outcomes are unacceptable and it takes a fair bit of thought and engagement to get it right. Now, I am not saying that you can definitively capture all the requirements up front. As you probably know by now, I am an advocate of an evolutionary, learning-based development approach. However, that said, you should be able to get off to a good start by avoiding the following common mistakes associated with requirements definition:
- Not engaging with key stakeholders (validation)
- Trying to specify the “how” (solution) instead of the “what” (need)
- Bundling multiple requirements into a verbose statement that is not simple, concise, clear, unambiguous and easily understood
- Not relating the requirement to a specific objective or outcome
- Not specifying a context or operational environment
- Neglecting critical interface dependencies
- Specifying objectives that cannot be proven (ie success cannot be verified)
- Failing to include tolerances or ranges for numerical requirements
- Including things that are not necessary (and, by implication, irrelevant)
- Including things that are not achievable (within the known constraints)
- Failing to include any kind of supporting rationale
- Failing to clarify the difference between “must-haves” and “desirables”
- Failing to include references to the parent and/or child (derived) requirements (ie lack of traceability to the source and associated key drivers)
- Duplicating requirements (each should be unique)
The key thing is to create a firm foundation by avoiding these mistakes and then iterate, test and adapt. Good luck ;0)