Chapter 7: Deriving Use Cases from Requirements

Avoid showing the following:

-- Many use cases in one diagram -- Many use case diagrams each containing only one use case -- Many relationships between use cases -- Overly complex use case diagrams

A use case diagram is a UML behavioral diagram that depicts the following:

-- Use cases of a system or subsystem -- Actors that use the use cases -- The system or subsystem boundary -- Inheritance relationships between actors -- Relationships between use cases

Bidirectional traceability offers three advantages:

1. It ensures that each requirement will be delivered by some use cases (e.g., there are no blank rows) 2. it ensures that all the use cases are required (e.g., there are no blank columns). 3. It ensures that high-priority use cases are developed and deployed as early as possible.

Identifying use cases involves four activities:

1. Look for domain-specific verb-noun phrases in the requirements. 2. Look for noun phrases that are actors, and noun phrases representing subsystems that contain the use cases. 3. Rearrange the use cases among the subsystems to improve subsystem cohesion. 4. Produce a requirement-use case trace-ability matrix to show which use cases realize which requirements.

Use case scopes are specified in two declarative sentences:

1. The first sentence is formulated as "this use case begins with (TUCBW)" followed by the actor performing the actor action and where the actor action takes place. Always use third-person, simple present tense. 2. The second sentence is formulated as "this use case ends with (TUCEW)" followed by the actor explicitly or implicitly acknowledging that the use case accomplishes the intended business task (for the actor).

The generation of the schedule takes into account a number of factors, in descending order of importance:

1. The priorities of the use cases. (High-priority use cases should be developed and deployed as early as possible to satisfy the customer's business needs and priorities. 2. The dependencies among the use cases. (If use case B depends on use case A, then B must not be deployed before A because the users won't be able to use B without A) 3. The team's ability to develop and deploy the user cases. (The effort required by the use cases allocated to an iteration must not exceed the ability of the team to develop and deploy them.

The inheritance between actors can be utilized to rearrange to use cases among subsystems:

1. To reduce the number of use cases of a subsystem, use cases of an actor subclass can be separated from use cases of the actor super class to form a subsystem of their own. 2. Use cases of an actor subclass can be merged with use cases of an actor super class to reduce the number of subsystems if desired.

For each use case, three decisions are made:

1. When does the use case begin. (What is the actor action that causes a stimulus or a system event to be generated and delivered to the software system being developed). 2. Where does the actor action take place? 3. When does the use case end? (This involves the specification of explicit or implicit actor action to acknowledge the completion of the use case.

A use case must begin with an actor or be initiated by an actor.

An ATM customer must insert an ATM card to begin the ATM business processes.

Since the term "user" has been used to refer to human users, a neutral term with a broader scope is needed to refer to both human users and nonhuman users.

An actor is a (business) role played by and on behalf of a set of (business) entities or stakeholders that are external to the system and interact with the system.

Use cases refine requirements and specify a design of system behavior.

As such, use cases should be derived from requirements and satisfy the requirements.

A use case diagram should show the subsystem boundary. Doing so has many advantages.

By examining what the use cases accomplish, the cohesion of the subsystem is assessed -- that is, the use cases should exhibit a core functionality rather than unrelated functionalities. One can identify mission-critical subsystems, which should be developed and deployed as early as possible so these subsystems can be scratch or reuse as a commercial off-the-shelf (COTS) components.

A use case is a business process.This is the most essential property of a use case.

Consider an ATM application that allows a customer to deposit money, check balance, withdraw money, and transfer money between bank accounts. These suggest that there are four business processes: Deposit Money, Withdraw Money, Check Balance, and Transfer Money.

Steps to derive use cases and subsystems from the requirements and allocating them to the iterations.

Step One: Identifying Use Cases Step Two: Specifying Use Case Scopes Step Three: Visualizing use case contexts Step Four: Reviewing the user cases and diagrams Step Five: Allocating the user cases to iterations

The use case priorities are useful for planning the iterations.

That is, use cases with the highest priority are developed and deployed first.

For example, a librarian checks out a book and handles the checkout transaction.

The person plays two roles: a librarian role as well as a patron role.

In the web-based SAMS, a student may want to Display Program Detail for one of the programs listed by the Search for Programs use case.

The student may decide to Submit Online Application after viewing the details of an overseas exchange program. The actor may optionally choose to extend the business process of a use case with the business process of another use case.

"Enter password" only accomplishes a step of the login process.

Therefore, they are not use cases.

To edit a class diagram, the user may add, update, or delete classes or relationships.

These must not be identified as use cases, because they are not business processes; rather, they are operations of the Edit Class Diagram use case.

The next step is to produce a schedule to develop and deploy the use cases.

This is called planning the iterations with use cases. It involves a few steps: 1. The effort required to develop and deploy each use case is estimated. 2. An iteration schedule is produced using the planning and scheduling techniques.

Inheritance is

a binary relation between two concepts such that one concept is a generalization (for specialization) of the other.

A high-level use case is

a refinement, or a more detailed description of a use case.

An operation is

a set of series of actions or instructions to accomplish a step of a business process.

A verb-noun phrase so identified is

a use case if the answers to all the following questions are yes. 1. Is it a (complete) business process? If it is only an operation or an action then the answer is no. 2. Does it begin with an actor? 3. Does it end with the actor? 4. Does it accomplish a business task for the actor?

An operation does not

accomplish a business task. It only accomplishes a step of a business process.

Actor-use case relationships are

always association relationships.

To distinguish the use cases that are referred to by the verb-noun phrase is called

an abstract use case. This is because the verb-noun phrase abstractly specifies the functionality, or business process, of the use case.

An action is

an indivisible, act, movement, or instruction that is performed during the performance of an operation.

A business process may include

another business process.

The execution of one business process may continue with

another business process.

High-level use cases should not specify

background processing activities.

A use case is a

business process. It begins with an actor, ends with the actor, and accomplished a business task for the actor.

Use cases are

business processes.

Requirements are

capabilities that the system must deliver.

Requirement statements are

declarative sentences that state what capabilities the system must deliver, not how the system will deliver them.

Do not attempt to

derive an optional set of use cases. Good enough is enough.

Focus on frequent delivery of small increments,

each of which deploys only a couple of use cases.

No subsystem contains a large number of use cases so that

each subsystem is easy to design, implement, test, and maintain.

The fact that a use case is derived from a given requirement is

entered into a Requirement Use Case Traceability Matrix (RUTM).

The inheritance relationship is also called IS-A relationship because

every instance of the specialized concept is an instance of the generalized concept.

A use case should accomplish

exactly one business task for the actor (functional cohesion).

Carefully select the verb-noun phrases to communicate

exactly what the use cases will accomplish for the actors.

Agile development tends to use a

fixed timescale for the iterations. This makes it easier for the team members to work with the iteration.

The process to derive and specify use cases is not

for the sake of documentation.

Use cases should be derived from and satisfy

functional requirements.

Carefully partition the use cases into

groups of use cases that are closely related.

The team members should work together to

identify use cases, actors, and subsystems, and specify the use case scope.

The system receives requests and

input from users and delivers results to the user.

Software systems process information for

intended applications.

"Accomplishing a complete business task (with a specific business purpose" is essential because

it distinguishes a business process from an operation or action.

To identify the system or subsystems that contain use cases,

look for or infer noun phrases that represent systems, subsystems, or aspects of the business to which the use cases belong.

To identify the actors,

look for or infer nouns and noun phrases that represent business roles played by external entities that initiate the use case, or for which the business task of performed.

Many real-world applications involve

many actors, use cases, and subsystems.

Use case may also be derived from

nonfunctional requirements (e.g. security requirements)

Software development for large complex systems require a way to

organize and visualizing this information.

Show only use cases and actors that are

relevant to a subsystem or aspect.

A business process is a

series of information processing steps that are necessary and sufficient for accomplishing a complete business task (with a specific business purpose).

Textual description of use cases, actors, and subsystems works well only for

small applications that involve only a few use cases, actors, and subsystems.

An actor is a role played by

some entities, not the entities themselves.

Provide a meaningful name for each

subsystem based on the subsystem's functionality.

Due to lack of business insight and knowledge --

the best software solution from the developer's point of view may not meet the users' expectations.

Require statements give the developer

the freedom to design and implement the best software solution.

Use actor inheritance to reduce

the number of actor-use case links in a use diagram.

The UC Priority row shows

the priorities of use cases. It is the high priority of the associated requirements.

When a system is developed from scratch,

the requirements often refer to the system as a whole and mention no other subsystems.

The specification of use case scopes in effect defines

the stopping rule.

Users interact with

the system to perform a certain business task.

To identify use cases, actors, and subsystems,

the team members work together, read through requirements one at a time, look for or infer verb-noun phrases that indicate do something, something must be done, or perform a certain task in the application domain, or for some actor of the application.

Requirements evolve but

the timescale is fixed.

To accomplish these goals,

the use cases are rearranged among the subsystems, a subsystem is decomposed to reduce complexity and some of the subsystems are merged if necessary.

Through the process, the team members understand and communicate

their understanding about the business process.

The goal is

to form subsystems that exhibit high functional cohesion, that is, the use cases of each subsystem should exhibit a cor functionality.

Work closely with the customer and the users to

understand their business processes and priorities and help them identify their real needs.

High-level use case specifications should end with

what the actor wants to accomplish.

A high-level use case specifies

when and where a use case begins and when it ends. In other words, it specifies the use case scope.

Only use the cases and their relationships can be shown

within the system boundary.

There is no optimal set of use cases because the criteria cannot be defined.

Requirements change all the time.

Use cases for the ATM application:

Deposit Money, Withdraw Money, Check Balance, and Transfer Money.

A use case must end with the actor so that the actor knows that the business process has completed successfully.

For example, the Deposit Money business process ends with the ATM customer receiving the deposit slip. The Check Balance business process ends with the ATM customer pressing the OK button to confirm to seeing the expected balance.

Tools for drawing and managing use case diagrams include

IBM Rational Modeler Microsoft Visio, ArgoUML, NetBeans, UML Plugin, and many others.

The priorities may have been obtained during the requirements phase.

If a use case is derived from a requirement, then the corresponding requirement-use case entry is checked.

Step Four: Reviewing the use cases and diagram

In this step, a review of the use case specifications and the use case diagrams is performed.

Review Use Case Specifications

In this step, the abstract use cases, high-level use cases, and use case diagrams are reviewed using the following check list: Abstract Use cases Requirement-Use case traceability matrix High-level use cases Use case Diagram (p.191)

Step Two: Specifying Use Case Scopes

In this step, the high-level use cases are specified. High-level use cases let the teams and team members know when and where each use case begins and when it ends.

Step Five: Allocating the use cases to iterations

In this step, the iteration duration is defined and the use cases are assigned to the iterations.

Step Three: Visualizing use case contexts

In this step, the use cases, actors, subsystems and their relationships are visualized using UML use case diagram.

Step One: Identifying Use Cases

In this step, verb-noun phrases representing business processes are identified from the requirements. Also derived are actors that use the user cases and subsystems that contain the use cases.

In OO programming, inheritance relationships exist between object classes.

Inheritance relationships also exist between use cases. It can be used to show alternate business processes to accomplish a business task.

The RUTM has a number of merits.

It can be used to identify use cases that realize a given requirement. It can also be used to identify requirements that are realized by a given use case.

This increases the visibility.

It is easy to decide how much can be done in two weeks then how much can be done in six months.

Notion and notation are closely related concepts.

Notations are symbols proposed for a language to represent modeling concepts or notions. Notions are the underlying concepts or meaning of the modeling constructs or notations.

Allocating the Use Cases to Iterations

Now the use cases are identified and visualized. Their priorities are derived from the priorities of the requirement.

Systems development is a wicked problem.

One property of a wicked problem is that there is no stopping rule -- you can always do it better.