MODELING

REQUIREMENTS: USE
CASES

Requirements Modeling: Use Case

A use case is a case (or situation) where
your system is used to fulfill one or more
of your user's requirements; a use case
captures a piece of functionality that the
system provides. Use cases are at the
heart of your model, since they affect and
guide all of the other elements within your
system's design

Requirements Modeling:
Use Case

Logical View

Process View

Use Case
View
Development
Physical View
View

Requirements Modeling:
Use Case

Once priority and risk are assigned to a

use case, it can help manage a project's
workload. Your use cases can be assigned
to teams or individuals to be implemented
and, since a use case represents tangible
user value, you can track the progress of
the project by use cases delivered. If and
when a project gets into schedule trouble,
use cases can be jettisoned or delayed to
deliver the highest value soonest.

Capturing a System
Requirement
Requirement A.1
The content management system shall
allow an administrator to create a new
blog account, provided the personal
details of the new blogger are verified
using the author credentials database.

Actor
Actor is the user of the system, actor could
be:
Person
System
Device
An actor is drawn in UML notation using
either a "stick man" or a stereotyped box
and is labeled with an appropriate name

Actor

Actor
It's actually worth being very careful when
naming your actors. The best approach is
to use a name that can be understood by
both your customer and your system
designers. Wherever possible, use the
original term for the actor as identified
within your customer's requirements

Refining Actors
There are actors that interact with your
system, you will find that some actors are
related to each other. The
Administrator
actor is really a
special
kind
of
system user. To show
that an administrator
can do whatever a
regular user can do
(with
some
extra
additions),
a
generalization arrow

Use Cases

The next step is to find cases where the

system is being used to complete a
specific job for an actor use cases.
Use cases can be identified from your
user's requirements.
A use case, or job, might be as simple as
allowing the user to log in or as complex
as executing a distributed transaction
across multiple global databases.

Use Cases

Don't be deceived; the use case is probably

the single most powerful construct in UML to
make sure your system does what it is
supposed to.

?What Makes a Good Use Case

Experience will help you determine when

you have a good use case, but there is a
rule of thumb that can be used to specify
a use case:
A use case is something that provides
some measurable result to the user or
an external system.
Any piece of system behavior that meets
this simple test is likely to be a good
candidate for a use case.

Communication Lines

At this point, we've identified a use case

and an actor, but how do we show that
the Administrator actor participates in
the Create a new Blog Account use case?
The answer is by using communication
lines.

Communication Lines

This simple example shows a communication

line between only one actor and only one use
case. There is potential to have any number
of actors involved in a use case. There is no
theoretical limit to the number of actors that
can participate in a use case.
To show a collection of actors participating in
a use case, all you have to do is draw a
communication line from each of the
participating actors to the use case oval.

Communication Lines

System Boundaries

To show your system's boundary on a

use case diagram, draw a box around all
of the use cases but keep the actors
outside of the box. It's also good practice
to name your box after the system you
are developing.

System Boundaries

Use Case Descriptions

A diagram showing your use cases and actors

may be a nice starting point, but it does not
provide enough detail for your system designers
to actually understand exactly how the system's
requirements will be met. How can a system
designer understand who the most important
actor is from the use case notation alone? What
steps are involved in the use case? The best way
to express this important information is in the
form of a text-based description, every use case
should be accompanied by one.

Use Case Descriptions

Some types of information that you
can include in your use case
descriptions:
What the detail means and why it is
Use case
useful

description detail

Some indication as to which requirements

this use case partially or completely fulfills.

Related Requirements

The use case's place within the system and

why this use case is important.

Goal In Context

What needs to happen before the use case

can be executed.

Preconditions

What the system's condition should be if

the use case executes successfully.

Successful End
Condition

What the system's condition should be if

the use case fails to execute successfully.

Failed End Condition

Use Case Descriptions

What the detail means and why it is Use
case
useful
description detail
The main actors that participate in the use Primary Actors
case. Often includes the actors that trigger
or directly receive information from a use
case's execution.
Actors that participate but are not the main Secondary Actors
players in a use case's execution.
The event triggered by an actor that causes Trigger
the use case to execute.
The place to describe each of the important Main Flow
steps in a use case's normal execution.
A description of any alternative steps from Extensions
the ones described in the Main Flow.

Use Case Descriptions

A complete use case description for
the "Create a new Blog Account" use
case.
Create a new Blog Account
Use case name

Requirement A.1

Related
Requirements

A new or existing author requests a new blog account Goal In Context

from the Administrator.
The system is limited to recognized authors and so Preconditions
the author needs to have appropriate proof of
identity.
A new blog account is created for the author.

Successful
Condition

End

The application for a new blog account is rejected.

Failed
Condition

End

Use Case Descriptions

Administrator.

Primary Actors

Author Credentials Database.

Secondary Actors

The Administrator asks the CMS to create a new blog Trigger

account.
Action

Ste
p

The Administrator asks the system to create a

new blog account.

The Administrator selects an account type.

The Administrator enters the author's details.

The author's details are verified using the

Author Credentials Database.

The new blog account is created.

A summary of the new blog account's details

are emailed to the author.

Main Flow

Use Case Descriptions

Branching Action

Ste
p

The Author Credentials Database does not

verify the author's details.

4.1

The author's new blog account application is

rejected.

4.2

Extensions

Use Case Descriptions

The use case description has identified a

new actor, the Author Credentials
Database. By creating a complete
description of the Create a new Blog
Account use case, it becomes clear that
this actor is missing.
If you can, it's worth reviewing your use
case model with its users as much as
possible to ensure that you have
captured all of the key uses of your
system and that nothing has been

Use Case Descriptions

How Many Use Cases Should Your

?Model Have

There is no set rule for the number of

use cases that your use case model
should contain for a given system. The
number of use cases depends on the
jobs that your system has to do
according to the requirements. This
means that for a particular system, you
might only need two use cases or you
might need hundreds.

Use Case Relationships

The purpose of use case relationships is

to provide your system's designers with
some architectural guidance so they can
efficiently break down the system's
concerns into manageable pieces within
the detailed system design.

Adding Another
Requirement
Requirement A.2
The content management system shall
allow an administrator to create a new
personal Wiki, provided the personal
details of the applying author are
verified using the Author Credentials
Database

Adding Another Requirement

To capture Requirement A.2 a new use

case needs to be added to the Content
Management System.

New Use Case

Descriptions
The detailed description for the
"Create a new Personal Wiki" use
case.
Create a new Personal Wiki
Use case name

Requirement A.2.

Related
Requirements

A new or existing author requests a new personal Goal In Context

Wiki from the Administrator.
The author has appropriate proof of identity.

Preconditions

A new personal Wiki is created for the author.

Successful
Condition

End

The application for a new personal Wiki is rejected.

Failed
Condition

End

New Use Case

Descriptions
Administrator.

Primary Actors

Author Credentials Database.

Secondary Actors

The Administrator asks the CMS to create a new

personal Wiki.

Trigger

Action

Ste
p

The Administrator asks the system to create a

new personal Wiki.

The Administrator enters the author's details.

The author's details are verified using the

Author Credentials Database.

The new personal Wiki is created.

A summary of the new personal Wiki's details

are emailed to the author.

Main Flow

New Use Case

Descriptions
Branching Action

Ste
p

The Author Credentials Database does not

verify the author's details.

3.1

The author's new personal Wiki application is

rejected.

3.2

Extensions

Redundancy between the two use

case descriptions

The first thing to notice is that we have some

redundancy between the two use case
descriptions. Both Create a new Blog Account
and Create a new Personal Wiki need to
check the applicant's credentials.
This repetitive behavior shared between two
use cases is best separated and captured
within a totally new use case. This new use
case can then be reused by the Create a new
Blog Account and Create a new Personal Wiki
use cases using the <<include>>
relationship.

Redundancy between the two use

case descriptions

Redundancy between the two use

case descriptions

The <<include>> relationship declares

that the use case at the head of the
dotted arrow completely reuses all of the
steps from the use case being included.
In the previous figure, the Create a new
Blog Account and Create a new Personal
Wiki completely reuse all of the steps
declared in the Check Identity use case.

Redundancy between the two use

case descriptions

We can see from the previous figure that

the Check Identity use case connected
directly to the Author Credentials
Database actor, but connected through
the Create a new Blog Account and
Create a new Personal Wiki use cases to
the Administrator actor.

Redundancy between the two use

case descriptions

To show the <<include>> relationship in

your use case descriptions, you need to
remove the redundant steps from the
Create a new Blog Account and Create
new Personal Wiki use case descriptions
and instead use the Included Cases field
and include::<use case name> syntax to
indicate the use case where the reused
steps reside, as shown in the next
tables:

Removing Redundancy between the

two use case descriptions

Create a new Blog Account

Use case name

Requirement A.1

Related
Requirements

A new or existing author requests a new blog account Goal In Context

from the Administrator.
The system is limited to recognized authors and so Preconditions
the author needs to have appropriate proof of
identity.
A new blog account is created for the author.

Successful
Condition

End

The application for a new blog account is rejected.

Failed
Condition

End

Removing Redundancy between the

two use case descriptions
Administrator.

Primary Actors

None

Secondary Actors

The Administrator asks the CMS to create a new blog Trigger

account.
Check Identity

Included Cases

Action

Step

The Administrator asks the system

to create a new blog account.

The
Administrator
account type.

selects

an

The
Administrator
author's details.

enters

the

The author's details are checked.

4
include::Chec
k Identity

The new blog account is created.

Main Flow

Removing Redundancy between the

two use case descriptions

Create a new Personal Wiki

Use case name

Requirement A.2.

Related
Requirements

A new or existing author requests a new personal Goal In Context

Wiki from the Administrator.
The author has appropriate proof of identity.

Preconditions

A new personal Wiki is created for the author.

Successful
Condition

End

The application for a new personal Wiki is rejected.

Failed
Condition

End

Removing Redundancy between the

two use case descriptions
Administrator.

Primary Actors

None

Secondary Actors

The Administrator asks the CMS to create a new

personal Wiki.

Trigger

Check Identity

Included Cases

Action

Step

The Administrator asks the system to

create a new personal Wiki.

The Administrator enters the author's

details.

The author's details are checked.

3
include::Che
ck Identity

The new personal Wiki is created.

A summary of the new personal

Main Flow

Check Identity use case description

Now you can create a use case
description for the reusable steps within
the Check Identity use case. Use case name
Check Identity

Requirement A.1, Requirement A.2.

Related
Requirements

An author's details need to be checked and verified Goal In Context

as accurate.
The author being checked has appropriate proof of Preconditions
identity.
The details are verified.

Successful
Condition

End

The details are not verified.

Failed
Condition

End

Check Identity use case description

Author Credentials Database.

Primary Actors

None

Secondary Actors

An author's credentials are provided to the system

for verification.

Trigger

Action

Step

The details are provided to the

system.

The Author Credentials Database

verifies the details.

The details are returned as verified

by
the
Author
Credentials
Database.

Branching Action

Main Flow

Step

The Author Credentials Database

does not verify the details.

2.1

The details are returned as

2.2

Extensions

Benefits from removing redundancy

Reuse using <<include>> removes the

need for tedious cut-and-paste
operations between use case
descriptions, since updates are made in
only one place instead of every use case.
The <<include>> relationship gives you
a good indication at system design time
that the implementation of Check
Identity will need to be a reusable part of
your system.

Special Cases

Sometimes you'll come across a use case

whose behavior, when you start to analyze it
more carefully, can be applied to several
different cases, but with small changes.
Unlike the <<include>> relationship, which
allows you to reuse a small subset of
behavior, this is applying a use case with
small changes for a collection of specific
situations. In object-oriented terms, you
potentially have a number of specialized
cases of a generalized use case.

Special Cases

Let's take a look at an example. Currently, the

Content Management System contains a single
Create a new Blog Account use case that
describes the steps required to create an
account. But what if the CMS supports several
different types of blog accounts, and the steps
required to create each of these accounts
differs ever so slightly from the original use
case? You want to describe the general
behavior for creating a blog account captured
in the Create a new Blog Account use case and
then define specialized use cases in which the
account being created is a specific type.

Special Cases

Special Cases
Create a new Editorial Blog Account

Use case name

Requirement A.1

Related
Requirements

A new or existing author requests a new editorial Goal In Context

blog account from the Administrator .
The author has appropriate proof of identity.

Preconditions

A new editorial blog account is created for the Successful

author.
Condition

End

The application for a new editorial blog account is Failed

rejected.
Condition

End

Special Cases
Administrator.

Primary Actors

None

Secondary Actors

The Administrator asks the CMS to create a new

editorial account that will allow an author to edit
entries in a set of blogs.

Trigger

Create a new Blog Account

Base Use Cases

Special Cases
Action

Step

The Administrator asks the system to

create a new blog account.

The
Administrator
selects
editorial account type.

the

The Administrator enters the author's

details.

The Administrator selects the blogs

that the account is to have editorial
rights over.

The author's details are checked.

The new editorial account is created.

Main Flow
5
include::Ch
eck
Identity
6

Special Cases
Branching Action

Ste
p

The author is not allowed to edit the

indicated blogs.

5.1

The editorial blog account application is

rejected.

5.2

The application rejection is recorded as 5.3

part of the author's history.

Extensions

The <<extend>>
Relationship

The designers of UML 2.0 took a very

different view as to the meaning of
<<extend>> between use cases. They
wanted a means for you to show that a
use case might completely reuse
another use case's behavior, similar to
the <<include>> relationship, but that
this reuse was optional and dependent
either on a runtime or system
implementation decision.

The <<extend>>
Relationship

From the CMS example, the Create a

new Blog Account use case might want
to record that a new author applied for
an account and was rejected, adding this
information to the author's application
history. Extra steps can be added to the
Create a new Blog Account use case's
description to show this optional
behavior

The <<extend>> Relationship

Create a new Blog Account

Use case name

Requirement A.1

Related
Requirements

A new or existing author requests a new blog account Goal In Context

from the Administrator.
The system is limited to recognized authors and so Preconditions
the author needs to have appropriate proof of
identity.
A new blog account is created for the author.

Successful
Condition

End

The application for a new blog account is rejected.

Failed
Condition

End

The <<extend>> Relationship

Administrator.

Primary Actors

None

Secondary Actors

The Administrator asks the CMS to create a new blog Trigger

account.
Check Identity

Included Cases

Action

Step

The Administrator asks the system

to create a new blog account.

The
Administrator
account type.

selects

an

The
Administrator
author's details.

enters

the

The author's details are checked.

4
include::Chec
k Identity

The new blog account is created.

Main Flow

The <<extend>>
Relationship
Branching Action

Ste
p

The author is not allowed to create a new blog.

4.1

The blog account application is rejected.

4.2

The application rejection is recorded as part of

the author's history.

4.3

Extensions

The <<extend>>
Relationship

The same behavior captured in Step 4.3

would also be useful if the customer was
refused an account for some reason
during the Create a new Personal Wiki
use case's execution. According to the
requirements, this reusable behavior is
optional in both cases; you don't want to
record a rejection if the application for a
blog account or a personal Wiki was
accepted. The <<extend>> relationship
is ideal in this sort of reuse situation.

The <<extend>>
Relationship