The Process Model

Once again, the Unified Process model is spotlighted, again with emphasis on the Inception phase (Figure 4-1).

In this chapter, the following Unified Process workflows and activity sets are emphasized:

• Requirements: Analyze the Problem

• Requirements: Define the System

• Requirements: Manage the Scope of the System

• Test: Plan Test

Use-Cases

The project's success depends largely on defining requirements in a manner that is intuitive to both the IT staff and the project sponsors. The requirements documentation not only serves as a key artifact, but also must be a living artifact. Requirements cannot be expected to remain stable throughout the project effort, so they must be in a format that can be easily assimilated by the current project team, as well as by new team members. The key vehicle to capturing requirements is the use-case. Many people I work with ask, “But when do you do functional requirements?” Use-cases are the functional requirements of the application.

The concept of the use-case sprang from Ivar Jacobson's early work on large telecommunications switching systems at Ericsson. This was his primary contribution to UML. As mentioned in earlier chapters, Jacobson's Objectory Process was transformed into Rational Software's popular process model, the Unified Process.

Use-cases are goal-oriented and serve as containers of sorts for the interactions that they satisfy. Jacobson's definition of a use-case will serve as a baseline as we begin our exploration of this key UML artifact:

A behaviorally related sequence of interactions performed by an actor in a dialog with the system to provide some measurable value to the actor.

Let's examine this definition in more detail.

Use-cases are goal-oriented. Remembering this is key to using them effectively. They represent the what of the system, not the how. Use-cases are also technology neutral, so they can apply to any application architecture or process. Even if you were to throw out all that UML offers and use only use-cases, a project's requirements would be defined in a much clearer and more coherent fashion than if use-cases were not used. Figure 4-2 identifies the sequence that we follow to arrive at the use-cases.

The process of identifying use-cases is easier if the event table is grouped by actor, as in Table 4-1. Often a use-case will be associated with only one actor. However, some types of use-cases—for example, those that provide information such as reports—often have more than one actor.

Notice that certain events in the table tend to cluster together, such as those dealing with order entry. Also some events deal with maintaining an order, as well as inquiring about an existing order. We take these natural groupings and write a short descriptive phrase (one or two words) for each, asking these questions:

• What do these events have in common?

• Do these events have the same ultimate goal? If so, what is it?

Table 4-1. Event Table with Events Grouped by Actor

Subject	Verb	Object	Frequency	Arrival Pattern	Response
Customer	Places	Order	1,000/day	Episodic	Order is edited and saved in the system.
Customer	Buys	Warranty	60/day	Episodic	Order is validated as to terms and then recorded.
Customer	Changes	Order	5/day	Episodic	Order is edited to make the change and then recorded.
Customer	Cancels	Order	1/week	Episodic	Order is removed from the system.
Customer	Inquires about	Order	200/day	Episodic	Order information is provided.
Customer	Changes	Address	5/week	Episodic	Address is changed. service clerk
Shipping clerk	Sends	Order	700/day	Episodic	Order is packaged and shipped according to the shipping terms.
Supplier	Sends	Inventory	5–10/day	Episodic	New inventory is checked in.
Time	Produces	Back-order report	3/week	Episodic	Report is produced.
Time	Produces	Accounting interface	1/week	Episodic	Interface is added to the system.
Packaging clerk	Prepares	Order	100/day	Episodic	Package is readied for shipment.
Manager	Inquires about	Orders	5/day	Episodic	Request is honored.
Billing clerk	Inquires about	Past-due invoice	10/day	Episodic	Past-due report is produced.

Next we place each of these descriptive phrases next to an oval (the designation for a use-case), along with the associated actors to produce our first attempt at a use-case diagram, shown in Figure 4-3.

The actors are connected to the use-cases by arrows, which indicate association relationships. Notice the accounting system actor. Because it is an external system and nonhuman, this actor is rendered by the interface stereotype and drawn as a box. Stereotypes are discussed in more detail later in the chapter. For now, think of a stereotype as a categorization or grouping mechanism. Using stereotypes is optional; there is nothing semantically incorrect about representing this actor as a stick figure. I consulted on a project whose management took a dim view of stick figures as part of the deliverables, so we went with the box notation. You can probably guess that this organization had quite a few other hurdles to clear before it became successful at using UML.

Notice also the line with the large triangle arrow connecting the customer service clerk and order clerk actors. This arrow means that a customer service clerk “is an” order clerk, thereby denoting a generalization relationship. That is, the two actors can be substituted for the same thing, and they perform the same logical function but happen to be physically one person (recall from Chapter 3 that we should focus on the role and not on the actor).

One last feature to notice is the dashed line from the order clerk to the customer, which denotes a dependency association relationship—that is, a relationship in which one actor depends on the other. In this case the fact that the arrow points from the order clerk to the customer (rather than vice versa) shows that the order clerk depends on the customer. Many practitioners would say that the actor involved in processing an order is the customer. This is debatable because the user interface will be geared toward the order clerk, not the customer. However, the order clerk is useless without the customer's input.

To check consistency, we determine whether any events identified during the Inception phase have not found a home in a use-case. Any that haven't are out of scope, worded incorrectly, or missing a use-case. It's a good practice to add a new column to the event table for recording which use-case satisfies each event.

This is a good time to talk about scope creep. Every project suffers from it. If you have experience with one that hasn't, then you have had the luxury of wonderful project sponsors, or you aren't telling the truth, in order to protect the guilty. Keep the following bit of wisdom close at all times:

All requirements originate as features in the project vision. These features lead to events that the use-cases then satisfy. If a particular feature isn't defined as an event and satisfied by a use-case, then it is a change request that requires some form of change control action.

This doesn't mean that the project won't accept changes. Rather it says that to keep your schedule true to the increments to be implemented, changes must be tracked and assigned to a later-scheduled increment that will satisfy them. Do you need to update the event table and related use-case documentation? You bet. If the event table and use-cases are not kept up-to-date, you will lose all traceability.

We have now completed the first UML diagram: the use-case diagram (although it is subject to change). From the perspectives of the project sponsors, this is the most important diagram because it represents their domain; that is, it represents the boundaries of the project scope from a high-level perspective, and it is the basis for dividing the project into multiple increments.