5.3 Tools

There are a number of tools (techniques and approaches) that you can employ to ease the tasks involved in the Filled iteration. Let's look at each of them in turn .

5.3.1 The Stakeholder Interview

The stakeholder interview is your primary tool for gathering requirements and for getting additional information about confusing requirements. Refer to Chapter 4 for details on interviewing stakeholders and holding joint requirements planning sessions.

5.3.2 IPA Filter

IPA stands for includes, preconditions, and assumptions (and not India Pale Ale).

There are three parts of a use case that can be easily confused :

• An include association between use cases

• A precondition on a given use case

• An assumption for a use case

When should you use each of these elements? Table 5.1 lists our rules of thumb for the types of information that should populate each of these fields.

Table 5.1. Includes, Preconditions, and Assumptions Compared

Use This	Under These Conditions
Include association	When the reused use case does not provide value to an actor and it is only an intermediate step that is used by use cases within this development effort that really provide the value, it signifies an include relationship.
Precondition	When something inside the system being built, but outside this use case, must be in place before this use case can run, it is an example of a precondition.
Assumption	When something outside the control of this development effort ( especially things that have been ruled beyond the scope of this project) must be in place before this use case can run, you've found an assumption.

5.3.3 White Space Analysis Filter

Think of white space analysis filter as a way to examine a "day in the life" (although it may refer to any period ”say, a month or a year ”in the life). When you walk through the existing or newly modeled business processes, you can discover that there are missing interactions, perhaps significant areas that have not been addressed in the use cases so far. We call these unaddressed areas the white space in your requirements picture. If this system is part of a business process engineering effort, the business process definitions can help structure the discussions. Or, if this system is automating existing procedures, those process definitions can be used. Or, more likely, the information stored in people's heads can guide the process.

Go through a day in the life of each actor, and then move on to end-of-week, end-of-month, end-of-quarter, and end-of-year processes. These walk-throughs should help you identify interactions that may not have been obvious earlier.

5.3.4 Abstraction Filter

When you're gathering requirements and making them understandable to all the stakeholders, an important function is abstraction . Abstraction is a process of generalization that allows you to consider the similarity between requirements and to make decisions consistently across the business domain. Take a reality check on how abstract the use cases are. The primary reason for modeling requirements with use cases is to communicate the requirements to the users, application designers, and testers. If the use cases are too abstract, they will not provide sufficient, meaningful detail. If they are not abstract enough, you will repeat similar information in many different places, resulting in problems with consistency and documentation volume.

Read your use cases and think about the various people who must rely on them. Have you provided sufficient detail, or are the use cases too abstract? Have a sample use case reviewed by a user and by an application designer. Then discuss the use case with them to ensure that they are comfortable with the level of abstraction.

5.3.5 Testing Use Cases with Scenarios

The way to attack use case testing is to use scenarios. Scenarios, discussed earlier in Section 5.2.4, are effective testing tools for use cases because they help users and IT staff walk through what would happen in an everyday interaction with the application.

5.3.6 Review

Peer reviews and user reviews should conclude this iteration to identify existing issues with the documentation.

5.3.7 Additional Use Cases

There are peripheral use cases that are often forgotten in requirements gathering.

• Security ” authentication and authorization of users

• Audit ” logs of online or batch activity

• Backup and Recovery ” creating and maintaining copies of the system data

• Remote users ” interactions of customers or supply chain partners

• Reporting requirements ” queries and reports

The Filled iteration is the time to create these use cases.