The return on investment for good requirements gathering is virtually always higher than the cost. In almost all cases if you spend the time develop the requirements you can develop a far superior product with much less hassle and frustration. At the same time not doing the right amount of requirements gathering can create a chaotic environment in which stakeholders are upset with the managers, managers are upset with the developers, developers are upset with managers and in the end what really suffers is the product. Some of the benefits from good requirements gathering can be:
- Fewer defects in the delivered product
- Less development rework
- Faster delivery of the finished product
- Less unused features
- Lower cost of development
- Less miss-communicated requirements
- Reduced project chaos
- Higher levels of satisfaction from stakeholders
- Higher levels of satisfaction from developers
- Higher levels of satisfaction from consumers and users
- Products that work well and have a useful feature set
How can you accomplish this? It’s a question easier asked than answered. There are many theories, best practices, books, articles and classes you can try but in the end what it really takes is communication, cooperation and time. Stakeholders should be involved throughout the project but stakeholders cannot do the job by themselves. Customer input can help bridge the gap between what is expected and what’s delivered. Developer input can help reduce development time and project cost by adding valuable insight about technical aspects of the requirements reducing the amount of rework which the project will need. When everyone works together to develop high quality requirements document you end up with a much better result.
So how do you know when you have a good requirements document? A good place to start is making sure that everyone involved is in agreement on the requirements baseline.
- Customers should agree that the requirements document will produce a product which meets their needs
- Developers should agree that the requirements are understandable and achievable
- Quality Assurance team should agree that the requirements are testable
- Stakeholders should agree that the requirements will fulfill the business objectives
A few good resources for high quality requirements gathering:
Software Requirements by Karl Wiegers & Joy Beatty
Visual Models for Software Requirements by Anthony Chen & Joy Beatty