6.3 Steps

To create the Focused iteration artifacts, follow these steps:

1. Merge duplicate processes.

2. Bring focus to each use case.

3. Manage scope changes during this iteration.

4. Manage risks and assumptions.

5. Review.

6.3.1 Merge Duplicate Processes

Examine the contents of each use case in relation to the remaining use cases. If you can share a process with other use cases, you reduce the scope of the project. To reduce the number of use cases, you merge duplicates, generalizing similar use cases. To reduce the size of individual use cases, you merge duplicate processes and generalize processes.

The Payback of Merging Duplicate Processes

The detection and merger of duplicate processes enhances your ability to perform a number of tasks , including the following:

• Choosing better candidate use cases.

• Simplifying the application documentation.

• Prioritizing use cases.

• Creating accurate estimates. If a use case can be used elsewhere, you can estimate the work effort more accurately.

• Improving your development process. For example, if a core set of use cases is employed diversely throughout the system, it might be economical to develop an automated system to test and regression-test these use cases.

• Planning project iterations.

Many processes in a business are essentially the same. Early discovery of these similar processes in the development lifecycle will prevent you from designing, building, and testing duplicate code.

To find and remove duplicates, follow these steps:

1. Identify duplicates.

2. Split the duplicated piece into its own use case.

3. Update the use case diagram.

Merger of duplicates is crucial in this iteration. Duplicate functionality in use cases is a serious problem when you begin to implement the requirements in code. It also complicates maintenance because a single change means that you may have to update several processes.

6.3.2 Bring Focus to Each Use Case

Analysts, designers, architects , project managers, testers, technical writers, and programmers rely on use cases. In addition to extracting scope information from them, these individuals need sufficient data to be able to build and test the system. Each use case must be complete, accurate, and concise . In the Focused iteration, you edit each use case to make sure that your descriptions are complete and provide sufficient information without being wasteful or vague. You must ensure that you define the terms used for the business domain and that you have accurately defined the actors.

For this task, look into the following:

• Interfaces to other systems (ports, APIs, telephony, Internet, and so on) Have you neglected any of these?

• The relationships between the interfaces and the use cases For example, can the telephony interface provide the necessary services to each of the use cases that depend on it?

• Improving the processes Walk through each of the processes from the point of view of the user . What does this tell you about the process? Have you inadvertently retained the manual process? If you have, is it efficient enough for the future system?

• Prioritizing the use cases Have you numbered them in order of importance and urgency to the users? This helps you to identify which use cases should be in the early design and development increments and stages of delivery.

• Defining the inputs and outputs Examine these with the processes to ensure that you have not missed something.

6.3.3 Manage Scope Changes During This Iteration

Requirements change. This moving target, often called scope creep , is invariably viewed as negative. Change renders your carefully crafted requirements obsolete, and that is frustrating. But businesses and government agencies are judged on their ability to adapt to their chaotic marketplaces , so their software must be able to change with them, even while it is being created. Given that you have no totalitarian solution to abolish changes, you must accept change during requirements analysis as well as during the rest of application development. You can develop strategies that allow you to cope with such changes.

When change occurs, you must evaluate its consequences objectively and implement them sensibly. Change may increase or decrease scope. Dealing with a scope decreasea change that reduces the level of automation in a systemmight seem easier. However, it is important that you apply the same mechanisms to analyze both types of changes. Your goal is to identify how a change may alter the system. Dependencies between use cases are relevant to the task of understanding change.

Strategies for Change

Your objective is to handle scope and requirement changes flexibly and accurately. The key is to understand how the overall system must adapt to accommodate the change.

Introducing a new use case typically causes less change than does altering existing use cases. Discovering how the change influences existing functionality accounts for the majority of the effort.

The user community must be involved in defining the additional functionality. We have found it beneficial to walk through the full requirements lifecycle with the additional functionality. Start by defining the Facade iteration of the additional use case. If you are in the position of suggesting change control, you should use the Facade version of the additional use case as the vehicle with which to propose the change. The format is suitable because all the stakeholders are familiar with it. It is also quick to put together, and it is reasonable for inclusion into the matrix. During this process, you should be receptive to the possibility that a new use case may not be required. If possible, it's best to generalize existing functionality to meet the additional requirements.

6.3.4 Manage Risks and Assumptions

While working on this iteration, you'll discover facets of the system that may not be appropriate content for a use case. Even though these observations are irrelevant to requirements gathering, it is important to record and communicate them to team members and users.

Carefully document the assumptions that underlie your requirements. The system and its scope may change significantly if these assumptions fail. For this reason, you should present the assumptions to the users with your use cases.

The following are some of the risks of the Focused iteration:

• Neglect of a major requirement

• Overengineering of use cases

• A user group that is not comfortable with the use cases

You can control these risks by being aware of them during this iteration. Make sure that your reviewers are aware of the risks so that they can screen the requirements for these problems. If the users are not comfortable with their understanding of use cases, it is worth the effort to educate a representative user and involve him or her actively in the requirements-gathering process.

We recommend an active approach to risk management. For example, to mitigate and manage project risk we use the strategy proposed in Rapid Development: Taming Wild Software Schedules (McConnell 1996).

6.3.5 Review

It is essential that somebody review your work for this iteration. Ideal candidates for reviewers are the SMEs because they have the best understanding of the business and the emerging application.

Reviewers look at use cases individually and as a part of the completed system. Each use case must be reviewed for accuracy and completeness. The reviewer must ascertain that the collection of use cases describes an adequate system.

If you are reviewing the Focused iteration, what do you look for?

6.3.5.1 Identify Opportunities Not Taken

In reviewing the work done in the Focused iteration, you may be able to identify areas where further possibilities remain . Ask yourself the following questions:

• Is there duplicate functionality in the system?

• Do the use cases include unnecessary functionality?

• Are any of the processes overly complex?

• Can the team make improvements?

• Is the level of detail and refinement consistent across use cases developed by different teams and team members? (It is important to consider some of the challenges imposed by teamwork on this process.)

6.3.5.2 System Damage

Watch for the following types of faults. You may be reviewing your own or the team's use cases, or you may be a client reviewing the work of an outsourcer.

• Have we inadvertently removed essential parts of the system?

• Will shared functionality work correctly for both processes?

• Does the set of use cases describe a system that meets the business criteria that have prompted this project?

• Does the set of use cases describe a system that meets known technical requirements?

• Have any references to a specific technology crept in?

• Has there been any attempt to design the system at this point?

In addition to looking for mistakes and omissions in the use cases, you should examine the risk and assumptions documentation and be alert for unidentified risks. You should make detailed comments on all flaws to the requirements analyst. The analyst needs to incorporate the observations and correct any defects found.

Reacting to the Review

If you're the requirements analyst and some of your changes do not make it through the review, how will it affect you? If the review returns previously rejected functionality to the system, have the reviewer prioritize its importance. During project planning, it is helpful to know which requirements are essential to the system and which are cosmetic.