Iterative and Incremental Processes

One common misconception in the requirements world is that you have to gather all the requirements before moving on to the next step of design and construction. In some circumstances this is necessary, but not always. On the one hand, if you are outsourcing or if the requirements document forms the basis of a contract, then clearly you need to have a complete requirements specification. On the other hand, providing the overall architecture is known, construction can often begin before all the requirements are gathered. We suggest that you consider this point when working on your own requirements projects.

Let's go back to the IceBreaker project. The developers are ready to start building the product, so right after the blastoff meeting the key stakeholders select a few (let's say three or four) of the highest-priority business use cases. The requirements analysts gather the requirements for only those business use cases, ignoring the remainder for the meantime. It is feasible to ignore them because there is always a minimal functional connection between the business use cases, so the analysts do not interfere with one another's work. Then, when the first tranche of requirements have successfully passed the Quality Gateway, the developers can start their work. The intention is to implement a small number of use cases as early as possible to get the reaction of the stakeholders. If there are to be nasty surprises, then the IceBreaker team members want to get them as early as possible. While the first use cases are being developed and delivered, the analysts are working on the requirements for the next-highest-priority ones. Soon they have established a rhythm for delivery, with new use cases being delivered every few weeks.