4.3 Tools

4.3.1 The Use Case Diagram

In the Facade iteration, create a use case diagram for each Facade use case. Whether you put multiple use cases on one diagram in your diagramming tool is up to you ”it doesn't matter. At this point, you will only be able to show the initiating actor as a stick figure and the use case bubble with its name . It may seem trivial, but it is worthwhile to begin now so there is a basis once the details start arriving from the next iteration.

Figure 4.2 shows an example of a use case diagram in the Facade iteration.

Figure 4.2. Use Case Diagram Sample

4.3.2 The Hierarchy Killer

Hierarchies of requirements must die. With use cases, we have the chance to abandon this aged technique in favor of a better approach. Remember that functional decomposition has a host of issues that complicate requirements specification (see Chapter 2). Yet, with use cases, we all have a strong tendency to put use cases into neat hierarchies that look shockingly like functional decomposition. Some approaches even color -code the levels in the hierarchy, adding to the confusion.

Dr. Suh's Minimal Good System Axiom (Suh 1990) says that the requirements of a system must be independent of each other. This means that if one requirement is a subset of another requirement, they are not independent of each other. This causes problems when things change, as changes ripple down the hierarchy. It causes problems in stakeholders' understanding because businesspeople do not think of requirements in terms of hierarchies. It requires extensive connections and communication between teams creating requirements specifications within the hierarchy. It requires additional layers of management, as people need to be responsible for the various layers of requirements.

In reality, sometimes use cases need "groupings" in projects. There are two ways to accomplishing grouping without the ills of hierarchies.

To group use cases for project organization reasons , use UML packages instead of hierarchies. Here are some examples of project organization grouping:

• Use cases assigned to business analysis teams

• Use cases relating to separate product releases

• Use cases at different points in their completeness (facade, filled, focused) or maturity (demonstrable, stable)

For project organization grouping needs, use the UML package. The package is a dumb container of use cases (or any other UML artifact). The package never needs to be modified if the use cases within it are modified, moved, merged, or deleted. Avoid the urge to embed intelligence in the packages by making them "high level" use cases.

You may also need to group use cases to show that multiple use cases are needed to fulfill a certain business process . In this case, the use cases themselves should not be linked, because that would violate Suh's axiom and would also cause a lot of rework when the business process changed (which is very likely during the next downsizing, rightsizing, reorganization, or whatever). Instead, create a scenario (see Section 2.3.4). You may remember that a scenario is a real-life instance of a use case. In this situation, we are creating a multiuse case scenario, a scenario that links several use cases together to illustrate a full lifecycle business process (that is, the entire procurement/usage/disposal lifecycle). The scenario will be very useful to the testers, who can use it as an example for the tests they create for the business processes and computer application. Plus, it is an effective way to tell if there is a match between the system use cases and the business process definitions. The scenario is not a hierarchy of use cases. It is not a use case itself, just a temporary linkage of use cases to test assumptions.

Keep a close watch on your requirements for hierarchies. Once they appear, stamp them out. This applies to use cases, nonfunctional requirements and business rules.

NOTE:

In the first edition of this book, we advocated a tool called system context level use case . This represented a very weak version of use case hierarchy, but a hierarchy nevertheless. Since we've seen the system context level use case cause so many problems in so many projects, we formally disavow this technique in this new edition.

NOTE:

One hierarchy you will notice us using is the actor hierarchy. Actors themselves are not requirements, so putting them into a hierarchy is useful and doesn't have dire consequences.

4.3.3 Use Case Name Filters

When you're considering use case names, it's a good idea to run them through the following filters. Use case names

• Should conform to verb-noun construction: mail checks, determine eligibility, trace shipment, print letter

• Can contain adjectives or adverbs

• Should not contain any situation-specific data

• Should not be tied to an organization structure, paper forms, computer implementation, or manual process: enter form 104-B, complete approval window, get approval from immediate supervisor in Accounting Department

• Should not use "weak verbs" (discussed later) that do not describe the action: process, complete, do, track

4.3.4 Actor Filter

A single person can play multiple roles, and actors can include external systems or devices. Therefore, the names of actors that involve human actions should reflect the roles that people play and not the names of actual people. Actors get value, provide value to the system, or both. Generalizing several layers of actors is best left until the Filled iteration (discussed in Chapter 5).

Be careful not to link a use case actor to your current organization chart. Although the actor's name must be recognizable to the users, there may be a more generic or abstract name that would still make sense to the users and would not tie your use cases into the current organizational chart (see Table 4.5).

Table 4.5. Evaluating Actor Names

Good Actor Names	Poor Actor Names
Pension clerk	Clerk
Sales supervisor	Third-Level Supervisor
Production accountant	Data Entry Clerk #165
Customer service representative	Eddie "The Dawg" Taylor

4.3.5 Verb Filter

Concrete ("strong") verbs are more meaningful in use case names than are general ("weak") verbs (see Table 4.6 for examples). If you find yourself using weak verbs in use case names, it may be that you are unsure of exactly what this use case is accomplishing. You may be recording a use case that provides no value to the actor, or you may be bowing to time pressure, reducing the quality of your work.

Table 4.6. Strong and Weak Use Case Verbs

Concrete (Strong) Verbs in Use Case Names	General (Weak) Verbs in Use Case Names
Create	Make
Remove	Report
Merge	Use
Defer	Copy
Switch	Organize
Calculate	Record
Pay	Repeat
Credit	Find
Register	Process
Deactivate	Maintain
Review	Display
View	List
Enter	Retrieve
Change	Integrate
Combine	Input
Release
Search
Migrate
Receive
Debit
Activate
Archive
Browse

NOTE:

In some situations, verbs we've designated as "weak" are quite acceptable, such as an industry-specific verb. For example, when a banker talks about "processing a loan," the word process is quite specific and therefore a good use case verb. There are always exceptions to the rules.

4.3.6 Noun Filters

Strong (concrete) nouns, like strong verbs, show that use case authors know what they are talking about and aren't hedging. Table 4.7 shows examples.

Table 4.7. Strong and Weak Use Case Nouns

Strong	Weak
Property	Data
Loan	Paper
Agent	Report
Supplies	System
Price	Form
Costs	Template
Offer
Account
Trend
Date
Sales

4.3.7 Packages as Placeholders for Functionality

Packages can be a convenient tool for creating placeholders for large areas of functionality that are not addressed during the Facade iteration. Interactions between the unknown functional area (indicated by the package) and the rest of the system (defined in the Facade use cases) can ensure that the only thing that remains undocumented is the functionality inside the package itself.

NOTE:

The principle of the Facade iteration is to write use cases to create placeholders for each functional area. Your focus must be on the functionality that is the hardest to define or the most nebulous. Therefore, it's a good idea to take a close look at those functional areas that you wish to put inside packages during this iteration. It may be important to break those packages down into Facade use cases instead of leaving them as amorphous packages. Packages are more useful when they hold a place for functionality that cannot be defined at this time or that is known to be simple and is not worth documenting now.

4.3.8 Facade Filter

At what level should Facade use cases exist? Your definition of Facade use cases must start with the major transactions of the system. Activities such as security, audit, backup, and recovery merely support the major business interactions. Leave them until late in the iteration. But there must be at least one Facade use case representing every interaction between an initiating actor (human or computer) and the application in scope.

Facade use cases should be relatively abstract. Abstract use cases can cover a variety of actual proposed interactions with just one abstract interaction. Constantine and Lockwood (1999) talk about "essential use cases," which are abstract enough to define truly how the system interacts with the user without any regard for implementation details.

Omit from this iteration all use case diagram adornments, such as extend or include . Also, there is no need to spend time on the Basic Course of Events section in the use case template. Just fill in a brief summary for each use case as a placeholder.

4.3.9 Peer Review

Think of use case peer reviews as code walk-throughs for use cases, except that peer reviews are much more brief. It is easy to review five use cases in one sitting. Have a technical architect present who can begin to estimate how much architecture is required by these interactions. Also, include an SME who understands the business domain. That person watches for major "gotchas" that you want to catch before you make a fool of yourself in front of the user.

Have peer reviews often and informally. Don't hesitate to pass your Facade use cases by your coworkers during this phase, or perhaps use an outside quality assurance authority. The more involvement there is by these various parties at this time, the easier the later iterations will be, and certainly the easier design and development will become.

The input is the Facade use cases, perhaps partially completed. The process is a review of the use cases for problems in nomenclature , standards, and so on. The output is improved use cases and a list of changes for the author to make. If this is the final review before user review, the output includes a deadline for making the changes.

4.3.10 User Review

User review of your Facade use cases is critical. Plan one or several face-to-face meetings (if possible) with your users to walk through the use cases. You are already iterating through your use case development (Facade, Filled, Focused), so you do not need to have multiple sessions with the same users, but you may need to schedule multiple sessions to include each user who requires involvement. Every hour you spend in user review is an investment in problem avoidance that repays you tenfold later.