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)

Want some personalised insights? Click here to get started...
AuthorTrevor Lindars