The pyramid above is a reminder of the top down approach. The goals need to be defined first, followed by an understanding of the business processes, the business requirements and then the system requirements. It can be very tempting for the business stakeholders to feel like they already know the solution and jump straight to the system requirements.
However there a number of dangers with this.
If the scope isn’t defined then it can be difficult to understand if scope creep occurs or if the goals are actually being met. Tracing back to see whether the project has been successful may also be difficult.
If the business processes aren’t understood then it may be difficult to trace the requirements back to the business processes to ensure that all business events and scenarios have been taken into account.
If the system requirements are documented and not the business requirements then the how has been defined and not the what. The how is more likely to change as there are often more than one way to meet a business requirement.
If a business requirements document is written and the contents are actually system requirements then this can lead to the document having to be re-written later on and a perception of the business requirements constantly changing when in reality it is the solution instead.
A top down approach enables traceability, success criteria and other stakeholders who may have a wider expertise and knowledge on the solutions available to make a better recommendation if they understand the business requirements first.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
Great article! Makes a lot of sense and very helpful! Thanks for sharing!