requirements engineering southern methodist university, cse 7316 – use cases

RequirementsEngineering

Southern Methodist University, CSE 7316 – Use cases

http://www.oracle.com/technology/products/jdev/collateral/papers/10131/gettingstartedwithusecasemodeling.pdf

Use Cases

A use case describes particular functionality that a system is supposed to perform or exhibit by modeling the dialog that a user, external system, or other entity will have with the system developed.

Actor – entity interacting with the system, e.g., a user, a device, or another system.

[Pfleeger, p.265]

Use cases

Formal definition; a use case describes a sequence of actions a system performs that yields a result of value to a particular actor Describes the interactions between a user and a

system Focus on what the system does for the user

Motivation

Each use case describes a possible scenario of how an external entity interacts with the system. The collection of uses cases paints a picture of the complete functionality of the system.

• Customers can read use cases to see if the system will include all desired functionality

• System designers use use cases to lay out the systems objects and data elements

• Testers employ use cases as a basis for system testing

What is use case modeling?

The core items of use case modeling are use cases and actors.

Whenever we discuss the requirements of a system we recognize one or more people or things that have an interest in the behavior of that system.

These are called the stakeholders of that system.


A use case describes how the system should respond under various conditions to a request from one of the stakeholders to deliver a specific goal

This is primarily done in the form of a scenario that describes a sequence of steps

Each use case captures a “contract” for the behavior of the System under Discussion (SuD) to deliver a single goal

Ultimately, the functional requirements of a system can be captured by describing how the SuD should respond to all possible requests as a series of use cases


In this way you can specify an important part of, but not all requirements

Requirements you cannot capture this way are non-functional requirements, business rules, the user interface and other requirements that are not suitable to be described as a scenario

Use case modeling steps

Find the system boundary Find the actors Find the use cases

Specify the use case Create scenarios

Use case model components

Actors; roles played by people or things that use the system

Use cases; things that the actors do with the system Relationships; meaningful relationships between

actors and use cases System boundary; a box drawn around the use

cases to denote the edge or the boundary of the system being modeled

The system boundary

What is part of the system and what is external to the system

Positioning of boundary has big impact on functional and non-functional requirements

Defined by who or what used the system Drawn as a box

Actors

An actor is anyone or anything with behavior The primary actor is the stakeholder that

interacts with the SuD to achieve a specific goal

The primary actor is often, but not always the one who triggers the use case

It is not, when the use case is actually triggered by an actor who does this on behalf of the real primary actor, or when the use case is triggered by time

Actors

Specifies a role that some external entity adopts when interacting with the system directly

Represents a user role or a role played by another system

Always external to the system Outside our control

Finding actors

Who or what uses the system? Who installs the system? Who starts and shuts down the system? Who maintains the system? Who gets and provides information to the

system?

Time as an actor

For modeling things that happen to your system at a specific point in time but which don’t seem to be triggered by an actor Automatic system backup that runs every morning

Actors

Sometimes an (external) actor needs to provide a service to the SuD Such an actor is called a supporting actor

An actor can be the primary actor for one use case and the supporting actor for another

In general an actor is a role rather than a specific person, job title or thing, although incidentally it can be

The SuD is also an actor Not every stakeholder will directly interact with

the SuD and will show up as an actor

Actors

An example might be the board of directors of the company or the Tax and Customs Administration, which also may require things from the system that must be taken into account

It is important to discover these “hidden” actors at an early stage as it may reveal requirements that may be missed otherwise

Scenarios

The main part of a use case is its scenario A scenario describes a sequence of steps

that are executed in order to fulfill the goal the use case is supposed to deliver

For example, the scenario that describes how to get a parking ticket from a machine could look like this:

Example Scenario

Buy Parking Ticket1. The Car Driver enters a coin in the Ticket Machine2. The Ticket Machine indicates until when the Car

Driver can park3. The Car Driver continues with step 1 and 2 until

satisfied4. The Car Driver presses the button to retrieve the

parking ticket5. The Ticket Machine prints the parking ticket

Scenarios

The scenario must be easy to read Therefore you should avoid scenarios of

more than nine steps and you should always use the active voice, stating exactly who or what is doing what This includes the SuD itself

In the scenario above everything goes as planned, which therefore is called a main success scenario

But in many cases there are exceptions that require a deviation from the planned scenario

Scenarios

In this example exceptions may consist of the Car Driver entering a coin of invalid currency or aborting the transaction

Exceptions are documented as extensions

Extensions

An exception is documented by specifying an alternate route in the scenario, which is called an extension (related to, but not the same as an extension use case, which will be discussed later on)

Extensions can be added to the main success scenario as follows:

Buy Parking Ticket

Main Success Scenario: 1. The Car Driver enters a coin in the Ticket Machine 2. The Ticket Machine validates the coin 3. The Ticket Machine indicates until when the Car Driver can

park 4. … Extensions: 2a Invalid coin: 2a1 The Ticket Machine returns an invalid coin 2a2 Return to step 1 3a Car Driver aborts transaction: 3a1 The Ticket Machine returns the coins that have been

entered 3a2 The scenario ends

Extensions

There is no standard for the layout of a scenario, let alone how to add extensions

It is good practice to number the steps of the main scenario and to put the extensions after that instead of in between in order to keep the scenario readable

Number the extensions in such a way that it is clear at what step it exits from the main success scenario and what point it returns

For example, a third extension that also exits at step 2 would be numbered as 2b1, 2b2, etc.

Use Case Properties

Although it is the core the scenario is not the only thing there is to say about a use case

Other aspects (or properties as you may call them) of a use case may consist of the following: Scope: the name of the (part of the) system the use case

belongs to Stakeholder: someone or something that has an interest in

the goal the use case delivers Primary Actor: the stakeholder who or which initiates the

use case to achieve a goal Brief Description: a brief description of the goal the use

case is supposed to deliver

Use Case Properties

Level: at what level the use case has been written Preconditions: what conditions must be met before the

scenario can start Postconditions: what conditions must be met for a valid end

of the scenario, to be divided into minimal guarantee(s) and success guarantee(s)

Trigger: the event or sequence of events that initiate the use case

Use Case Templates

There is also no standard that dictates what properties need to be included in a use case

What you need to write down for use cases depends on the situation, especially on who is writing it and for what purpose

For example, if an on-site team performs the requirements definition and analysis, while the design and implementation is done remotely, you need to be very explicit and you probably specify all these properties and even more

On the other hand, a small team that performs the requirements definition up to the implementation in one and the same room may suffice with specifying only a few properties, perhaps only the Brief Description

Use Case Templates

Before you start your project you should decide upon templates that are going to be used

In practice it suffices to use two templates for each project

You use a simple one with only a few properties for use cases that do not need to be worked out in detail

You use a more extensive one that has all properties that are relevant, for the other use cases The first template is commonly called the Casual

version and the second one the Fully Dressed version. Review and modify the templates to fit the needs of your

project You may want to add properties like Brief Description,

Number, Priority or Status.

www.oracle.com/.../use_case_model_1001.gif

High-Level Example Scenario: ATM banking for the week. 1. Sally Jones places her bank card into the ATM. 2. Sally successfully logs into the ATM using her personal

identification number. 3. Sally deposits her weekly paycheck of $350 into her savings

account. 4. Sally pays her phone bill of $75, her electric bill of $145, her

cable bill of $55, and her water bill of $85 from her savings account

5. Sally attempts to withdraw $100 from her savings account for the weekend but discovers that she has insufficient funds

6. Sally withdraws $40 and gets her card back

Detailed Example Scenario: A successful withdrawal attempt at

an automated teller machine (ATM) 1. John Smith presses the “Withdraw Funds” button 2. The ATM displays the preset withdrawal amounts ($20, $40, …) 3. John chooses the option to specify the amount of the withdrawal 4. The ATM displays an input field for the withdrawal amount 5. John indicates that he wishes to withdraw $50 dollars 6. The ATM displays a list of John’s accounts, a checking and two savings

accounts 7. John chooses his checking account 8. The ATM verifies that the amount may be withdrawn from his account 9. The ATM verifies that there is at least $50 available to be disbursed from the

machine 10. The ATM debits John’s account by $50 11. The ATM disburses $50 in cash 12. The ATM displays the “Do you wish to print a receipt” options 13. John indicates “Yes” 14. The ATM prints the receipt

Scope and level

Use cases can be written for different purposes

They can be written to describe a business process, to describe the functional requirements of a system or to document the design of a system

Use cases can also be written at different levels of detail, from high to low level

Design scope

The design scope of a use case can be the enterprise, a specific system or a subsystem

Use cases that are used to describe the business process are typically of scope “enterprise”

The design scope is not a specific property of a use case (thus not be confused with the “scope” property) but something you should consider carefully to make sure you understand what is inside and what is outside the boundary of the use case

Design scope

Something that is essential for the use case but outside its boundary, must be covered either by another actor (which may be a supporting actor) or another use case

For instance, if some other system delivers data that is essential to the use case, you do not model how that system works but model it as an actor

Business and system use cases Business people write Business uses cases that

have the business as subject and are used to document business processes

Software developers write System use cases that have the system as subject and describe how actors communicate with the system to achieve their goals. “Sell Books” will be a business use case, where “Browse Catalogue” will be a system use case

Business and system use cases Business use cases are created by business

analysts and describe the business, whereas system use cases are created by developers and describe the system

Use cases can be of different level, from high-level Summary uses cases, through mid-level User Goal Use cases, to low-level Subsystem use cases.

Pre-conditions and guarantees

You use Preconditions to specify the conditions that must hold true before the scenario of the use case starts and will not be checked again after that

Often a precondition indicates that some other use case has already run to set up the condition

Write preconditions as a set of assertions, for example “User is logged on”, “Credit Card has been validated” and so on. Consider putting preconditions that hold for multiple use cases, in a separate document

Instead of including the assertion in the use case, you then include a reference to the generic precondition

Pre-conditions and guarantees With Minimal Guarantees you specify what, from the

viewpoint of the stakeholders, at least must hold true in case neither the main success scenario nor any alternate route has successfully finished

The most common Minimal Guarantee is “The System has logged how far it got”

Minimal Guarantees are written as a set of assertions that must be satisfied at the end of any path of the scenario, for example “All entered information must have been stored”

Pre-conditions and guarantees With Success Guarantees you specify what must

have been achieved at the end of the main success scenario or any alternate route

Success Guarantees are also written as a set of assertions that describe what would satisfy any of the interests of the stakeholders

These assertions add to the Minimal Guarantees Mind that Preconditions and Guarantees may be

related to, but are not the same as business rules.

Use case diagrams

A use case diagram provides an index to use cases

The following gives an overview of the conventions you should apply when drawing use case diagrams

Actors and use case diagrams In a diagram you include actors as people-like

figures and use cases as ellipses and draw lines that indicate the relationships, or communications between them

It is custom to draw the primary actor and other stakeholders that communicate with the use case to the left and secondary actors to the right

Put the primary actor at the top, as in the following example

Actors, use cases and communications

Use case inclusion

A use case inclusion is another way to say that one use case calls the other

Higher-level use cases may call lower-level use cases (that is: require the behavior of lower-level use cases). the higher-level use case includes the lower-level one, hence the

term “inclusion”. A typical example is a Summary use case that includes User

Goal use cases Another typical example is a User Goal use case that includes

some reusable Subfunction use case, like “Log On” If you want to express this in the scenario of the Summary use

case, you underline the name of the lower-level use case, as in the following example:

Use case inclusion

Log Ticket Main Success Scenario: 1. The Helpdesk Employee Finds Customer

using its name or address 2. The Helpdesk Employee enters the details

of the Ticket 3. …

Use case inclusion

An inclusion is drawn as a dashed arrow from the higher-level to the lower-level use case

The lower-level use case should also be drawn lower to emphasize it is at a lower level

Use case inclusion

Use case extensions Recall that earlier on an extension has been defined as alternate

route to the main success scenario In general an extension use case is an extension of a main success

scenario that has been moved out of the originating use case into a use case of its own

The point at which it exists the originating use case is called an extension point like the point at which it returns is called the return point.

When moving out the extension, the exception to the main success scenario becomes the trigger of the extension use case

In the extension use case you refer to the originating use case by underlining its name, but not visa versa.

Suppose you would like to model the fact that a Car Driver can abort buying a parking ticket using an extension use case

The scenario of the originating use case does not change except for the fact that the alternate scenario is cut out of the extension part

The extension use case may look as follows:

Use case extensions

Abort Transaction Trigger: any time in Buy Ticket the Car Driver

can abort the transaction Main Success Scenario 1. The Ticket Machine returns the coins that

have been entered

Use case extensions

An extension is drawn using a dashed arrow from the extension use case to the originating one

The extension use case should be drawn lower than the originating use case, emphasizing that it is at a lower level

Use case extensions

Use case extensions

An extension to the main success scenario can be moved out to an extension use case, to prevent the use case from becoming too complex

Other reasons to create extension uses cases can be to add to fixed requirements or when a different development team implements the extension

Use case extensions

There are a few situations in which you create extension use cases, being: To leave details out of the originating use case that

otherwise would clutter its scenario As a way to add to requirements that are fixed and you are

not allowed to change the originating use case When the extension concerns an isolated piece of

functionality that may be implemented by a different team In this case you may want to be able to estimate both use

cases separately

Generalized Use Cases

You can also generalize use cases When use case A specializes use case B (or B

generalizes A) you express that A is “a kind of” B, implying that whatever applies to B also applies to A

A adds to or may override behavior of B Use case generalizations are drawn by drawing an

open arrow from the specialized use cases to the general one

The specialized use cases are drawn below the general one

Generalized Use Cases

Reading use cases

It is imperative that use cases are easy to read, while specializing some generic scenario is conceptually a difficult thing to understand

In practice you probably are best off by leaving the scenario of the generic use case empty and using generalization only to share common stakeholders, triggers, conditions or other properties between specialized use cases

However, the larger the system, the more advantageous using the mechanism of generalizing use cases may become

Actors can be specialized too, but that may also introduce confusion and should be done scarcely

There are not that many properties to share between actors anyway

Organizing use cases

When there are more than just a few, organizing use cases becomes imperative for several reasons, among them to be able to find them back

As applies to many things giving a use case a proper name is a good start

A good name generally has the form “Do Something” (active verb phrase) and expresses the goal of the primary actor as clear as possible

Another good thing to do is to number the use cases In most situations a generic, hierarchical numbering will suit best For example, when the summary use case has number 1, use

cases that detail this are numbered as 1.1, 1.2 and so on.

Use case organization

There are a couple of alternatives to organize use cases: By primary actor By summary use case By development team and release By subject area Combinations of the above

Use case organization

Give use cases a name that expresses the goal clearly and number them

Use cases can be organized by primary actor, Summary use case, development team and release, or subject area

Writing in iterations

Use cases are written in iterations A good way to start is with identifying all actors and their goals

consider setting it up as an Actor-Goal List that lists all actors with their named goals, a brief description of each goal and the priority it has

Actor-Goals List starts with naming the actors with their goals When you have the feeling the list is pretty complete, you start

adding Brief Descriptions You may find new goals and actors when doing so After the Actor-Goal List is verified and complete, it can be

prioritized Keep in mind that the priority of each goal should have been

determined by the customer

Writing in iterations The next step is to create initial use cases out of the Actor-

Goal List Many of the goals be User Goal level use cases In many cases you can use the goal as name for the use case

and copy the Brief Description After that you write the main success scenario for all use cases Next you identify the exceptions there may be to the main

success scenario of each use case and you write extension to that

It is very important to work out these exceptions, as new actors, classes and business rules may be discovered

MoSCoW stands for Must Have, Should Have, Could Have and Won’t Have and is used to prioritize functionality You can find more about MoSCoW at

http://na.dsdm.org/en/about/moscow.asp.

Use case recipe

The short recipe for creating use cases is as follows: 1. Identify the actors 2. List their goals 3. Add brief descriptions to the goals 4. Create an initial use case for each goal 5. Describe the main success scenario for each use case 6. Identify the exceptions to the main success scenarios and

work them out as extensions 7. Validate the use cases 8. Optimize the use cases

“This is not a use case”


Southern Methodist University

CSE 7316 – Step by step examples

A use case tells a story of reaching a goal,or a set of stories of both getting and failing.

UC 4: “Place an order”“ 1. The clerk identifies the customer, each item and

quantity. 2. System accepts and queues the order.”

Extensions:“1a. Low credit: Clerk takes prepayment”“2a. Low on stock: Customer accepts reduced...”

Alistair Cockburn www.usecases.org

Examining the Goals the system supports makes good functional requirements.

“Place an order.” “Get money from my bank account.”“Get a quote.”“Find the most attractive alternative.”“Set up an advertising program.”

Goals summarize system function in understandable, verifiable terms of use.


The use case pulls goal & scenarios together, Each scenario says how a condition unfolds.

The use case name is the goal statement:“ Order product from catalog”

Scenario (1): Everything works out well ...Scenario (2): Insufficient credit ...Scenario (3): Product out of stock ...

Use case is goal statement plus the scenarios.

(Note the grammar: active verb first)


How to do it:(1). Identify the actors and their goals.

What computers, subsystems and people will drive our system? An “actor” is anything with behavior.

What does each actor need our system to do? Each need shows up as a trigger to our system.

Result: a list of use cases, a sketch of the system. Short, fairly complete list of usable system function.


How to do it: For each use case...(2). Write the simple case: goal delivers.

The main success scenario, the happy day case. Easiest to read and understand. Everything else is a complication on this.

Capture each actor’s intent and responsibility, from trigger to goal delivery. Say what information passes between them. Number each line.

Result: readable description of system’s function.


How to do it:(3). Write failure conditions as extensions.

Usually, each step can fail. Note the failure condition separately, after the

main success scenario. Result: list of alternate scenarios.


How to do it: For each failure condition,(4). Follow the failure till it ends or rejoins.

Recoverable extensions rejoin main course. Non-recoverable extensions fail directly. Each scenario goes from trigger to

completion. “Extensions” are merely a writing shorthand. Can write “if” statements. Can write each scenario from beginning to end.

Result: Complete use case


How to do it:(5). Note the data variations.

Some extensions are too low-level to cover “here”. e.g. “Reimburse customer” Reimburse by cash, check, EFT, or purchase

credit? Deferred variations note cases that must be handled

eventually, by lower-level use cases. Useful for tracking requirements at high level.

Result: Feed-forward information, rolled up into an easy-to-track format.


The value of failure scenarios is detecting unusual situations, completeness

“What if their credit is too low?” “What if they run over the extended credit limit?” “What if we cannot deliver the quantity?” “What if data is corrupt in the database?”

(These are commonly overlooked situations)


Both recoverable and non-recoverable failures are part of requirements.

Ideal situation (s1):Good credit, items in stock -> accept order.

Recoverable situation (s2, s3):Low credit -> valued customer? -> accept.Low stock -> reduce quantity? -> accept.

Unrecoverable situations (s4, s5):Not a valued customer -> decline orderOut of stock -> decline order


Write the recoverable and failure scenarios as “extensions” to the ideal one.

UC 4: “Place an order”

“ 1. Clerk identifies the customer, each item and quantity.

2. System accepts and queues the order.”

Extensions:

“1a. Low credit: Customer is ‘Preferred’...”

“1b. Low credit & not Preferred customer: ...”

“2a. Low on stock: Customer accepts reduced...”


A scenario refers to lower-level goals: subordinate use cases or common functions.

UC 4: “Place an Order”1. Identify customer (UC 41) 2. ...

UC 41: “Identify Customer” 1. Operator enters name. 2. System finds near

matches. Extensions:

2a. No match found: ...


The outer use case only cares if the inner one succeeds, avoiding proliferation.

UC 4: “Place an Order”

1. Identify customer (assumes success)

2. ...

Extensions:

1a. Customer not found: (does not care why

it failed, only if it

is recoverable)


Every sentence at every level is a goal.Use cases are one sentence style repeated.

Goal: “Customer places an order.”

how why

Step: “Customer prepays for the order.”

how why

Substep: “Customer gives credit card number.”


Visit http://alistair.cockburn.us/Use+cases to read more on use cases.

1. Use cases hold functional requirements in an easy-to-read, easy-to-track, text format.

2. A use case collects how 1 goal succeeds or fails; a scenario shows one specific condition; scenarios / use cases nest inside each other.

3. Use cases show only the Functional req’ts.

4. They make a framework for non-functional requirements & project details.

5. Design is not done only in use case increments.


Example: Buy Product

The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks authorization on the credit card and confirms the sale both immediately and with a follow-up email.

[ Fowler p.39]

Example Use Case Text

UC 1: Buy a Product [ Fowler p.40]1. Customer browses through the catalog and selects items to buy2. Customer goes to check out3. Customer fills in shipping information (address, next-day or 3-day)4. System presents full pricing information, including shipping5. Customer fills in credit card information6. System authorized purchase7. System confirms sale immediately8. System send confirming emailExtension: Authorization Failure6a. System fails to authorize credit purchase. Allow customer to re-enter credit card

information and retryExtension: Regular Customer3a. System displays current shipping information, pricing information, and last four

digits of credit card information3b. Customer may accept or override these defaults. Return to primary at step 6.

Use Case Diagram

Place phonecall

Retrievevoice mail

Receivephone call

Cellularnetwork

UserCellular telephone

Use Case Diagram

Trackorder

Checkpassword

Validateuser

User

Retinalscan

<<include>>

Top 10 Mistakes to Avoid When Writing Use Cases

10. Write functional requirements instead of usage scenario text. 9. Describe attributes and methods rather than usage. 8. Write use cases too tersely. 7. Divorce yourself completely from the user interface. 6. Avoid explicit names for your boundary objects. 5. Write using a perspective other than the user’s, in a passive

voice. 4. Describe only user interactions; ignore system responses. 3. Omit text for alternative courses of action. 2. Focus on something other than what’s “inside” a user case,

such as how you get there or what happens afterwards. 1. Spends a month deciding whether to use include or extends.

[Rosenburg p. 60]


Southern Methodist University

CSE 7316 – More on Use cases in Software Development

Defining the boundaries of the system Use context diagramming to understand the

system boundaries Describe interactions between the system

and the environment Begin with system, then add users and other

systems Actor can represent one or more users

Identifying use cases

Examine each actor with the purpose of identifying each interaction

For each user, identify a discrete use of the system Examine all incoming and outgoing messages for

each system that interacts with your system Examine periodic and timed events

88Spring 2005Specification and Analysis of Information Systems

Based on Eran Toch

http://www.technion.ac.il/~erant

Specifying Requirementswith Use Case Diagrams

89

Outline

• Introduction

• Use Case Diagrams

• Writing Use Cases

• Guidelines for Effective Use Cases

90

Illustration

Use Cases

• A use case is a contract of an interaction between the system and an actor.

• A full use-case model comprise of:– A diagram, describing relations between use-cases and

actors.– A document describing the use case in details

Register User

Use case in diagram Use Case in script

admin

Introduction | Diagrams | Writing | Guidelines

91

Models: OO - Use Case DefinitionModels: OO - Use Case Definition

• Describes “what” (not “how”) the system will do at a high-level

• Has a user focus for the purpose of scoping the project and giving the application some structure

• Scenarios that identify a particular thread of system usage -- a written narrative

• Shifts the perspective to what users need to accomplish (in contrast to what users want the system to do)

• A discrete, stand-alone activity that an actor can perform to achieve some outcome of value.

92

Models: OO - Use Case Definition, con’tModels: OO - Use Case Definition, con’t

• Use cases capture functional requirements of a system from the perspectives of the different users of the system

• Use cases are textual narratives describing the different kinds of scenarios in which the system will be used

• Use case diagrams help to visualize which actors are involved in which scenarios

• The functional requirements described in use cases will be realized by collaborations of objects in the design

• Non-functional (or qualitative) requirements are not depicted with use cases

93

Models: OO - Use Case Definition, con’tModels: OO - Use Case Definition, con’t

A use case is a scenario that describes how software is to be used in a given situation

A use case is defined from an “actors” perspective

An actor is a role played by a person or device as it interacts with the software

An actor is anything that communicates with the system and that is external to the system itself

By creating use cases, you keep the focus of development on the user and the user’s perception of the system

A non-trivial system will often have many actors, each involved in multiple scenarios

94

Models: OO Use CasesModels: OO Use CasesIdentifying Use CasesIdentifying Use Cases

The first step in identifying use cases is to identify the different people or devices that will interact with the product

Consider what each actor hopes to accomplish by using the product

This can lead to the discovery of new requirements

There can be overlap, in that different actors may expect to use the same system facilities

Be consistent

Look for opportunities to represent two similar scenarios with a more general one

95

Models: OO Use CaseModels: OO Use CaseQuestions Answered by a Use CaseQuestions Answered by a Use Case

What main tasks or functions are performed by the actor?

What system information will the actor acquire, produce, or change?

Will the actor have to inform the system about changes in the external environment?

What information does the actor desire from the system?

Does the actor wish to be informed about unexpected changes?

96

Use Case Diagram Objective

1. Create a semi-formal model of the functional requirements

2. Analyze and define:– Scope– External interfaces– Scenarios and reactions


97

What Makes Good Use-Case Specification?

• Lack of ambiguity– Each requirement must be interpreted in a single manner.

• Completeness– They should cater for all current demands of the system.

• Consistency– Requirements should not conflict with each other. If there

are, tradeoffs must be detected and discussed.

• Avoid design– Requirements should raise a need, not answer it. (Why?)


98

Outline

• Introduction




99

Example

A Simple Example

Handle Message

Cellular Phone

Customer

Bill Management

Handle CallExternal Phone

Company

ActorsUse CaseSystem

boundary


Association

100

Models: OO Use Case - ComponentsModels: OO Use Case - Components

• Actor– Outside the system model; but interacts

– Person, machine, information system . . .

• Use Case– Narrative text describing the sequence of events of an actor, using a

system

– “stories”

– Static model of functionality

• Use Case Diagram– What happens when an actor interacts with a system

– Represents a function that makes sense t an actor

– Actor initiates interactions with the system; and vice-versa

– No temporal sequencing

101

Models: OO - Syntax for Use CasesModels: OO - Syntax for Use Cases

Library Customer

An actor is represented by a stick figurewith a label. The label describes the role of that actor

An actor is represented by a stick figurewith a label. The label describes the role of that actor

Borrow Book

A use case is represented by an oval. The name of the use case is provided inside the oval

A use case is represented by an oval. The name of the use case is provided inside the oval

102

Use Case: Steps in CreatingUse Case: Steps in Creating

1. Identify who will use the system directly1. Identify who will use the system directly

2. Pick one of those actors2. Pick one of those actors

3. Define what the Actor wants to do with the system -- this becomes a Use Case

3. Define what the Actor wants to do with the system -- this becomes a Use Case

4. For each Use Case, determine what happens4. For each Use Case, determine what happens

5. Describe the “basic course”5. Describe the “basic course”

6. Consider alternatives6. Consider alternatives

7. Review for commonality7. Review for commonality

8. Repeat Steps 2 - 7 for each Actor8. Repeat Steps 2 - 7 for each Actor

103

Models: Use Case - ActorsModels: Use Case - Actors

The ActorsWhat types of actors do you have in the factory control system?• You have two types of actorsThe failure monitors that inform the system of machine failures areactorsThe operators that oversee individual machines are actors• Note that factory machines are not (yet) actorsThe initial version of this application will not interact directly withfactory machines(Future versions will interact directly with machines)

The ActorsWhat types of actors do you have in the factory control system?• You have two types of actorsThe failure monitors that inform the system of machine failures areactorsThe operators that oversee individual machines are actors• Note that factory machines are not (yet) actorsThe initial version of this application will not interact directly withfactory machines(Future versions will interact directly with machines)

104

Finding Actors

• External objects that produce/consume data:– Must serve as sources and destinations for data– Must be external to the system

Humans MachinesExternal systems Sensors

Database PrinterOrganizational Units


105

Example

Actors can be generalized

The child actor inherits all use-cases associations


Should be used if (and only if), the specific actor has more responsibility than the generalized one (i.e., associated with more use-cases)

Register Client

Sales Person

Institutional Sales Person

Perform Sale

Perform Business Sale

Sales Manager

Cancel Sale

106

Models: Use CasesModels: Use Cases

What use cases do you have in the factory control system?

• A failure monitor initiates one interaction with the system?It informs the system that a machine failure has occurred(The system in turn informs the operator that the machine’s state isnow unscheduled maintenance)

• The system initiates no interactions with a failure monitorThe system need not reset or otherwise interact with a failure Monitor

• An operator initiates one interaction with the systemAn operator asks the system to change a machine’s state(Changing a machine’s state to scheduled maintenance alsorequires recording today as the date of last maintenance)

• The system initiates four interactions with an operatorIt informs the operator that a machine has failed (noted above)It informs the operator that a running machine is now waitingIt informs the operator that a waiting machine is now runningIt informs the operator that scheduled maintenance on a machine is due

What use cases do you have in the factory control system?

• A failure monitor initiates one interaction with the system?It informs the system that a machine failure has occurred(The system in turn informs the operator that the machine’s state isnow unscheduled maintenance)

• The system initiates no interactions with a failure monitorThe system need not reset or otherwise interact with a failure Monitor

• An operator initiates one interaction with the systemAn operator asks the system to change a machine’s state(Changing a machine’s state to scheduled maintenance alsorequires recording today as the date of last maintenance)

• The system initiates four interactions with an operatorIt informs the operator that a machine has failed (noted above)It informs the operator that a running machine is now waitingIt informs the operator that a waiting machine is now runningIt informs the operator that scheduled maintenance on a machine is due

107

Models: Use Cases - Models: Use Cases - Example Factory Control SystemExample Factory Control System

108

Models: Use Case ScenarioModels: Use Case ScenarioA scenario is a use case instance

• It contains the same steps as does the use caseA scenario typically describes just one execution path (one outcome) through the use case

• It describes a sequence of actions and interactions of objects

The objects in the scenario are from the classes in the use caseE.g., a particular set of objects acting to cancel a catalog order

• The notation for a scenario is an interaction diagramIt may be either a sequence diagram or a collaboration diagramWe will discuss only sequence diagrams in this session

A scenario is a use case instance

• It contains the same steps as does the use caseA scenario typically describes just one execution path (one outcome) through the use case

• It describes a sequence of actions and interactions of objects

The objects in the scenario are from the classes in the use caseE.g., a particular set of objects acting to cancel a catalog order

• The notation for a scenario is an interaction diagramIt may be either a sequence diagram or a collaboration diagramWe will discuss only sequence diagrams in this session

109

Models: Use Case-Models: Use Case-Railway ExampleRailway Example

ARRSSystem Administrator Use Cases

System Administrator

Sign InSign Out

Create User Accounts

Modify User Accounts

Activate/DeactiveUser Accounts

Create Roles

Delete User Accounts

Delete RolesManage Security

110

ARRSTrain Conductor Use Cases

Train Conductor

Sign In

Sign Out

Passenger ListReport

Print StandingTickets

Inout TicketStub Info

Models: Use Case-Models: Use Case-Railway ExampleRailway Example

111

Models: Use Case - Models: Use Case - Elevator ExampleElevator Example

1. Passenger pressed floor button

2. Elevator system detects floor button pressed

3. Elevator moves to the floor

4. Elevator doors open5. Passenger gets in and

presses elevator button6. Elevator doors closes7. Elevator moves to

required floor8. Elevator doors open9. Passenger gets out10.Elevator doors closes

112

Models: Use Case ExampleModels: Use Case Example

Trading Manager

Trader

Salesperson

Accounting System

Set Limits

Analyze Risk

Price Deal

Capture Deal

Valuation

Update Accounts

Limits Exceeded

ĒincludeČ

ĒincludeČ

UML Distilled, Fowler, Martin and Kendall Scott, Second Edition, Addison-Wesley, 2000page 42.

UML Distilled, Fowler, Martin and Kendall Scott, Second Edition, Addison-Wesley, 2000page 42.

113

Linking Use-Cases

• Linking enables flexibility in requirements specification– Isolating functionality– Enabling functionality sharing – Breaking functionality into manageable chunks

• Three mechanism are used:– Include– Extend– Inheritance


114

Use-Case Levels

User goals

Perform Sale

Choose Products

Fill-in billing info

Sub-functionality


Base Use Case: Used directly by the user

Alistair Cockburn “Writing Effective Use Cases”

115

The “Include” Construct

• Include is used when:– Decomposing complicated behavior– Centralizing common behavior

• The base use case explicitly incorporates the behavior of another use case at a location specified in the base.


Perform Sale

Fill-in billing info

<<include>>

Example

116

Extend – Graphical Representation

• The base use case can incorporate another use case at certain points, called extension points.

• Note the direction of the arrow– The base use-case does not know which use-case

extends it


Perform SaleAfter checkout

Gift wrap Products

<<extend>>Product is a gift

Example

117

Example: Amazon

Product Page

Review Writing

Shopping Cart


118

Example – cont’d


Search Product

Navigate Deals

Checkout

Handle Order Status

Login Register

View Product Details Write

Review

Rank Supplier«include»

«include»

«include»

«include»

«extend»user is not a member

«extend»

«extend»

After page generation

Add to cart

«extend»

Customer

119

Generalization between Use-Cases

• The child use case inherits the behavior parent use case:– The interaction (described in the textual description)– Use case links (associations, include, extend, generalization)

• Child use-case can substitute parent Use case

• Overriding occurs through the textual description


Example

Handle Sale Call

Customer Representative

Tech Assistant Representative

Handle Call

Handle Technical Assistance Call

1. Transfer call to available representative2. Mark representative as busy3. Start record call4. Stop record call 5. Log call details6. Mark representative as free

120

Generalization Hazards

• Combining generalizations of actors and use-cases can be dangerous

Undergrad Student

Graduate Student

Submit Exam

Submit Thesis

Undergrad Student

Graduate Student

Submit and Get Grade

Submit Thesis

Submit Exam

Bad: Undergrad can submit thesis

Good: Only graduate student can submit thesis


121

Example: Phone Company Operational System

The Cellular Phone

Who are the actors?

External Phone companies

Orange’s objective: Build a system that handles SMS messages, handles calls (for 2 and 3 generation phones), including conference calls and multiple calls from a single phone. The system must support users on the move.


122

Example: Cell Company System


3G Phone

Handle SMS Message

Cellular Phone

while talking

Handle Call

External PhoneCompany

Handle Video Call

Handle Cell Migration

<<include>> <<include>>

Handle Multiple Calls

Handle Conference Call

<<extend>>{incoming call}

<<extend>>{phone initiate call}

Handle Voice Call

123

Outline

• Introduction




124

Structure of a Use Case Specification

Name

Actors

Preconditions

Post conditions

Success Scenario

Alternatives flows



Trigger

125

Triggers

• What starts the use-case?

• Examples:– Customer reports a claim– Customer inserts card– System clock is 10:00


126

Preconditions

• What the system needs to be true before running the use-case.

• Examples– User account exists– User has enough money in her account– There is enough disk space


127

Post-Conditions

• A post-condition is the outcome of the use-case.• Examples

– Money was transferred to the user account– User is logged in– The file is saved to the hard-disk

• Minimal guarantee– The minimal things a system can promise, holding even when

the use case execution ended in failure– Examples: Money is not transferred unless authorization is

granted by the user

• Success guarantee– What happens after a successful conclusion of the use-case.– Examples: The file is saved; Money is transferred


128

Success Scenario

• The success scenario is the main story-line of the use-case

• It is written under the assumption that everything is okay, no errors or problems occur, and it leads directly to the desired outcome of the use-case

• It is composed of a sequence of action steps • Example:

1. Administrator enters course name, code and description

2. System validates course code

3. System adds the course to the db and shows a confirmation message

Interaction step

Validation Step

Internal Change Step

(plus) Interaction Step


129

Guidelines for Effective Writing

• Use simple grammar

• Only one side (system or actor) is doing something in a single step

• Write from an “objective” point of view– Bad: “Get the amount from the user

and give him the money”

• Any step should lead to some progress– Bad: “User click the enter key”

System Actor

Actor asks for money

System asks for amount

Actor gives the amount

System produce the money


130

Steps – cont’d

• Branches:– If the user has more than 10000$ in her account, the system

presents a list of commercials– Otherwise…

• Repeats:1. User enters the name of the item he wishes to buy

2. System presents the items

3. User selects items to buy

4. Systems adds the item to the shopping cart

5. User repeats steps 1-4 until indicating he is done


131

Use-Cases – Common Mistakes

• Complex diagram

• No system

• No actor

• Too many user interface details– “User types ID and password, clicks OK or hits Enter”

• Very low goal details– User provides name– User provides address– User provides telephone number– …


132

Alternative Flows

Success Scenario

ShortcutsExceptions

Endpoints

• Used to describe exceptional functionality

• Examples:– Errors– Unusual or rare

cases– Failures– Starting points– Endpoints– Shortcuts

Starting points


133

Alternative Flows - Example

• Errors:– “Case did not eject properly”– “Any network error occurred during steps 4-7”– “Any type of error occurred”

• Unusual or rare cases– “Credit card is defined as stolen”– “User selects to add a new word to the dictionary”

• Endpoints– “The system detects no more open issues”

• Shortcuts:– “The user can leave the use-case by clicking on the “esc” key


134

Writing Include

• If a base use-case include another use-case, we will add a reference as a step:1. System presents homepage

2. User performs login to the systemOR

<include: login to the system>


135

Writing Extend

• Scenarios do not include direct references

• Instead, they include extension points, such as:User enters search string

System presents search results

Extension point: results presentations

OR

<extension point: results presentations>

• The extension use-case includes conditions in which the extension is being committed– Example: if the user belongs to the “rich clients” group– If more than two commercials were found


136

Outline

• Introduction




137

How to Model?

print

saveBullets format

loadSave

as

preview

File action

s

Formatting actions

Viewing Actions

Font forma

t

Paragraph format

Bottom-up Process Top-down Process

Starting with throwing all scenarios on the page, and then combining them:

Starting with an overview ofthe system, and then splittingUse-cases

138

How to Model – cont’d

• Most of the analysis process are actually

Combined

139

Combining Processes

• Number Limit:– The diagram should have between 3 to 10 base use-case. No

more than 15 use cases (base + included + extending).

• Abstraction:– All use-cases should be in similar abstraction levels.

• Size:– Use cases should be described in half a page or more.

• Interaction: – Use-cases which are carried out as part of the same interaction.

UCUC UC


140

Dividing Processes

• Size:– If a use-cases takes more than a page, consider

include/extend

• Weak dependency:– If the dependency between two parts of a use-case is weak,

they should be divided.

UC


141

More Guidelines

• Factor out common usages that are required by multiple use cases– If the usage is required use <<include>>– If the base use case is complete and the usage may be

optional, consider use <<extend>>

• A use case diagram should:– contain only use cases at the same level of abstraction– include only actors who are required


142

Scope

• A good way to decide on the scope is by in/out lists:


Topic In Out

Any non-software parts of the system Statistical analysis of logs Interfacing with credit card systems Database cleaning processes Backup of logs …


143

When Are we Done?

• When every actor is specified.

• When every functional requirement has a use-case which satisfies it.

• A tractability matrix can help us determine it:

Use Cases

Requirements


144

Moving on

• Data entering and exiting the system is represented by data entities in structural diagrams.

• Behavior induced by use cases can be captured in behavioral diagrams.

Class AClass C

Class B

Class D

Use Case 1

Use Case 2Use Case 3


145

Summary

Introduction to the Unified Modeling Language (UML)

To Use Case Diagram

Use Case DiagramsDual presentation of use-cases

Include, Extend, Inheritance

Writing Use CasesPreconditions & Post-conditions

Main scenario vs. Alternative Flow

Guidelines for Effective Use Cases

requirements engineering southern methodist university, cse 7316 – use cases

Documents