Iteration

Analysis and design activities usually get started with a nearly complete use case model and set of requirements. In an incremental development process, the entire use case model or set of requirements artifacts do not need to be completed before activities in subsequent phases of the development process can take place. This is not to imply that you can code while you're still gathering requirements and analyzing the problem. It simply means that, given a fair understanding of the requirements, and completion of certain packages of the use case model, it is possible to begin analysis and design on them. It is important to understand that the more comprehensive the use cases and requirements are, the less likely that the analysis and design will have to be reworked.

Another important aspect of iterative development is the opportunity to address risk early. Risk is that unknown void where the team knows it has to tread but is unsure of the terrain. Risk is usually identified through the experience or lack of experience of the senior members of the team. Often, the unknowns are related to nonfunctional requirements, such as performance, security, and external system interfaces. For organizations venturing into new domains, however, the risk might be in the business processes themselves. Often, it is the architect and the project manager who identify the risky areas; however, any member of the team should be able to point out areas of uncertainty.

For example, the architect of an e-commerce system may recognize a new integration to the billing system and the use of an external merchant account system as an obvious area of risk. Perhaps the architect has never used this particular online merchant account system or has had troubles with it before. In an iterative development process, this area would be one for which the requirements and uses cases would be completed first and for which the analysis and design activities could begin before some other parts of the system had even completed their use case specifications.

When working in an iterative and incremental development process, it is important to have a solid change control process in place. When working in risky areas of the problem space, team members often make important discoveries that affect certain assumptions made in previous phases. When this happens during analysis, the use cases or requirements need to be questioned. For example, the requirements might state that new customers are automatically assigned new IDs that are a composite of their last names and phone numbers. The requirements might also state that every customer must have an ID. Yet elsewhere, the requirements might state that getting a new customer's phone number is optional. In practice, this simple scenario would most likely have been caught during requirements gathering, but if not, the analysis activities certainly would have caught it, and this would be reason to call for clarification of the requirements. "Does the ID have to use the phone number, or could any unique number do?" or "Is it unreasonable to require each customer to provide a phone number?" are questions that should be answered by the requirements team. No member of the development team should be shy about asking questions that could simplify the system.