A question was posed by a user on another forum to which I replied recently. The question is fundamental, deceptively simple and goes to the heart of requirements methodology. I thought the question important enough that it is worth posing in our forum. Below are the question from the user and my response in its entirety. Whether or not you agree with my response, I am quite sure that you will agree with the importance of the question itself. Enjoy.
What techniques do you use to decide when enough requirements have been elicited?
The question encapsulates beautifully the fundamental dilemma surrounding the gathering of requirements – how do I know when I am done? The reality is that one could write an entire book on the subject :-). While we wait for this book to be written, let me offer up a very, very simplified check list that can be used to help with the problem.
1. Define the Problem that the Business is attempting to solve.
2. Identify the specific Business Strategies that are to be used to solve the Business Problem. All Business Strategies identified need not involve software products or projects. For our purposes, we will just concentrate on the software portions of the Strategy.
3. Define concrete AND measurable Business Objectives that will be achieved as a result of implementing the Strategies identified in the previous step. These Business Objectives should be ideally be quantified in terms of money – for example, costs saved, revenue increased.
4. Define the High Level Features of your software product(s) that will enable you to achieve your Business Strategies and Objectives.
5. Use Models to flesh out the Features. The Models will enable you to do the following:
a. Ensure that you have spoken to the correct stakeholders.
b. Identify the different systems impacted by your solution.
c. Identified the different data elements relevant to your solution.
d. Define the correct processes that will support your solution.
e. Define the interaction between the human being using your application and the solution itself.
6. Define detailed Functional and Non-Functional requirements for your Features using the Models in the step above.
7. Trace every requirement back to a specific Feature and its associated Strategy / Objective.
8. Trace every Feature forward specific requirements to ensure that you have defined requirements for each Feature.
9. Lather, rinse, repeat.
This is an iterative process. While the above appears to define a linear process, real life is never that simple. The dynamics of your project will define how you jump through the different stages above. Regardless of how you walk through the different process steps, you should do all of the above. There will be a lot more churn in the beginning but as you start working the project the different pieces will start falling in place. The closer you are able to stick with the linear process, the less churn you will have. But no matter what, you will iterate since that is the nature of the beast.
When you have done the above, you will know when you have gathered “enough requirements.”
