The College Of Applied Studies And Community

Services

Lecture 3 :Use cases II (UC description)Systems Analysis & Design

Instructor: Nouf Aljaffan

CT 1

414

* N

ouf A

ljaffa

n

1

February 2012

Outline• Concept of Use Case Description

• Levels of Use Case Description

• Reading and writing Use Case Descriptions

CT 1

414 *

Nouf

Alja

ffan

2

Use Case Diagram of the Customer Support System

Use Cases grouped into system modules

Note: Same actor interacts with different modules

CT 1

414 *

Nouf

Alja

ffan

3

Use Case Description• Complements Use Case Diagram

• A breakdown of a single use case (e.g., sequence of steps included in the function “Look up item availability”); process logic included

• In contrast to Use Case Diagram, Use Case Description captures variations of a Use Case

• Example: “Create new order” can be done via phone+clerk and via Internet ordering – 2 scenarios (see slide 3)

CT 1

414 *

Nouf

Alja

ffan

4

Level of Use Case Description

• Three levels of detail:• UC* Brief description

• Summary of what system does in response to actor’s actions

• UC Intermediate description• Shows steps in use case, if-then

• UC Full description• Includes Brief description, expands intermediate description, shows

scenarios

CT 1

414 *

Nouf

Alja

ffan

5

* UC=Use Case

Brief Description of Create New Order Use Case

CT 1

414 *

Nouf

Alja

ffan

6• Same description that is usually captured in initial Use Case Diagrams (“bird’s view” of system)

Intermediate Use Case Description

CT 1

414 *

Nouf

Alja

ffan

7

Telephone Order Scenario for Create New Order Use Case

Full Use Case Description

• Superset of intermediate and brief descriptions (contains these)

• Consists of 11 compartments (we will use some)

• Shows steps (“Flow of Events”) broken down to the actor and the system side – useful!

CT 1

414 *

Nouf

Alja

ffan

8

Full Use Case DescriptionTelephone Order Scenario for Create New Order Use Case

CT 1

414 *

Nouf

Alja

ffan

9

Computer System, Computer(steps encoded in software)

CT

141

4 *

Nou

f Alja

ffan

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• …

10

Writing Use Case Descriptions

1. Select a use case

2. Write abbreviated full description (Use case name, Scenario (if any), Business Event, Actors, Flow of steps, Exception conditions)

3. For figuring Flow of steps, - Keep in mind general system model: Input-Processing-Output- Steps should be at nearly the same level of abstraction (each

makes nearly same progress toward use case completion)

4. For figuring exception conditions, focus on if-then logic.

CT 1

414 *

Nouf

Alja

ffan

11

CT

141

4 *

Nou

f Alja

ffan

Method of Modeling

Bottom-up Process

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

Top-down Process

• Starting with an overview of the system, and then splitting Use-cases

12

File actions

Formatting actions

Viewing Actions

print

saveBullets format

loadSave as

preview

Font format

Paragraph format

CT

141

4 *

Nou

f Alja

ffan

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.

13

UC

UCUC

CT

141

4 *

Nou

f Alja

ffan

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.

14

UC

CT

141

4 *

Nou

f Alja

ffan

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

15