Requirements Specification with Use Cases

* These notes are a combination of materials from Rational Software Corp., Alistair Cockburn, Dr. Harry Koehnemann, and my annotations

What is a Use Case?

System behavior is how a system acts and reacts The outwardly visible & testable activity of a system

System behavior is captured in use cases. Use cases describe the system, its environment,

and the relationship between the system and its environment.

The Use Case Model A model that describes a system’s functional reqs

in terms of use cases A model of the system’s intended functionality (use

cases) and its environment (actors) Each use case is a container for one or more

related scenarios describing system usage.

DEFINITION (p. 149):

“A use case describes sequences of eventsbetween an actor and a system that yield a result of value to the actor”

Student

View Report Card

Register for Courses

Login

A Scenario Is a Use-Case Instance

Scenario 1Log on to system.Approve log on.Enter subject in search.Get course list.Display course list.Select courses.Confirm availability.Display final schedule.

Scenario 2Log on to system.Approve log on.Enter subject in search.Invalid subject.Re-enter subject.Get course list.Display course list.Select courses.Confirm availability.Display final schedule.

StudentCourse Catalog

System

Register for Courses

Use Case Scenarios and Specifications

Specification: A structured natural language narrative that identifies: Objective: Every use case must have a goal the Primary Actor is trying to

achieve Primary Actor: one who performs the trigger event Trigger Event: an event that causes the system to respond Secondary Actor(s): participate in interactions in the use case; often a system Business Rules / Constraints: as they apply; often promoted to the

Supplementary Specification Pre/Post Conditions: predicates that must exist before/after the Happy Day case One or more scenarios…

4

A scenario is an instance of a use caseThe normal basic flow called the “Happy Day” caseA use case may have several alternative flows

Regular variants Exceptional flowshandling error situations

Copyright © 2000 Rational Software, all rights reserved

Use Case Model +

SupplementarySpecification

Glossary

Use-Case Specifications

...

Use-Case Model

Actors

Use Cases

Object Oriented Analysis and Design Using the UML v2000Copyright © 2000 Rational Software, all rights reserved

SupplementarySpecification

Glossary and Supplementary Specification

(FURPS model) Functionality* Usability Reliability Performance Supportability

Design constraints…etc.

Glossary

Course Registration System Glossary

1.        Introduction

This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.

2.         Definitions

The glossary contains the working definitions for the key concepts in the Course Registration System.

2.1       Course: A class offered by the university.

2.2       Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered.

2.3      Course Catalog: The unabridged catalog of all courses offered by the university.

Since the focus is on the what (functionality), you can use use cases even if you are not doing OO

The Use Case Model

A Use Case Model Consists of:1. Use Case Diagram: Actors, Use Cases, Use Case Relationships

2. Use Case Specification: A textual description of the use cases

A use case diagram: A use case diagram uses use cases, actors and use case

relationships to define a system's behavior

Defines what a system (subsystem, class, or interface) does.

Defines system communication with its environment, as represented by actors.

Does NOT define how a system operates or imply sequence.

Use Case Notation: Actor

<<Actor>>Another Actor

AnActor

“An actor defines a coherent set of roles that users of an entity can play when interacting with the entity” – UML Representing something outside the system that interacts with it

Represented as a “stick man” figure By definition, an actor is a stereotyped class where the stick man

icon is used for graphical representation

Notation: Use Case

ReceiveCallManagePhonebook

“A coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system (subsystem, class) and one or [actors] together with actions performed by the system (subsystem, class)” -- UML

Represented as an ellipse containing the use case name Optional:

• Extension points

• [As a classifier] Compartments for attributes and operations

Notation: Communicates-Association

A channel of communication between an actor and a use case.

A line is used to represent a communicates-association.

An arrowhead indicates who initiates each interaction.

No arrowhead indicates either end can initiate each interaction.

Actor 1

Actor 2 Actor 3

Use Case

Use Case Template Example

11

USE CASE <<Enter Use Case Number>>: <<Use Case Title>>Objective:<<Enter the goal of the use case>>

Primary Actor:<<Enter ID and Name of Actor causing the Trigger event>>

Trigger: <<Action performed by the Primary Actors>>

Secondary Actors:<<actors affected by the outcome or secondary participants (not causing the Trigger)>>

Preconditions:<<The state of the environment required in order to activate this use case.>>

Post Condition(s):<<Enter the expected resulting state from the Main Success Scenario.>>

MAIN SUCCESS SCENARIO<<Enter a numbered list of interactions needed to achieve the objective of the use case>>

Extension Points:<<Often identified inline; alternatively may be catalogued in its own subsection>>

VariationsVariation ID:<<Enter variation ID, should be UC-ID plus a VAR-XX suffix>>

<<Enter numbered list of variations to the steps in the main process above. Indicate whether the variation is an addition, replacement, or removal of interactions from main flow>><<If the variation requires different preconditions or affects changes in the postconditions, be sure to note the changes here. Typically neither is required for a non-failure variation, though sometimes there are additional pre/postconditions.>>

Failure VariationsVariation ID:<<Enter variation ID, should be UC-ID plus a VAR-XX-F suffix>>

<<Enter bulleted list of possible variations to the steps in the main process above>><<Indicate the postconditions associated with this negative outcome, and whether the use case is reentrant (you can repeat subflows or main success scenario or some alternate action as recovery)>>

Business rules<<Enter Business Rules. If they are applied across more than 1 use case then they are moved to the catalog area.>>

Notes:<<free form text here. Note this must not have requirements, but is usually more explanatory>>

Avoid Functional Decomposition

Symptoms Very small use cases Too many use cases Uses cases with no result of value Names with low-level operations

• “Operation” + “object” • “Function” + “data” • Example: “Insert Card”

Difficulty understanding the overall model

Corrective Actions Search for larger context

“Why are you building this system?”

Put yourself in user’s role

“What does the user want to achieve?”

“Whose goal does this use case satisfy?”

“What value does this use case add?”

“What is the story behind this use case?”

Functional Decomposition: Breaking down a problem into small, isolated parts. The parts work together to provide the functionality of the system.

• Often do not make sense in isolation.

Use cases are NOT functional decomposition.• Keep functionality together to describe a complete use of the system.• Provide context.• FOCUS ON THE USER’S GOAL

Functional Decomposition Example

Enter PIN

Insert Card

Select “From” Account

Enter Amount

Select Withdraw Cash

Customer

Select Account Balance

Select Transfer Funds

Select “To” Account

Bank Consortium

Process Transaction

Functional Decomposition Example

Withdraw Cash

Transfer Funds

Deposit Funds

CustomerBankConsort

ium

A Corrected Example

How to do it:

Step 1. Identify and Describe the ActorsIdentify actors and their needs What computers, subsystems and people will drive our system?

• An “actor” is anything that interacts with the system. Result: a list of actors

Step 2. Identify the Use Cases and write a brief description What does each actor need our system to do?

• Each need shows up as a result in our system. • You are still breadth-oriented for now

Important to have a name and a description of each use case, but nothing more (yet)

At this point you can have high-level “bubble diagram” RESULT: Catalog of current use cases

Combined from Leffingwell & Widrig 2nd ed. And Humans and Technology, Alistair Cockburn

How to do it:

Step 3. Identify Actor to Use Case relationships Use cases may involve multiple actors Use cases may affect multiple actors (indirectly) RESULT: Catalog with full scope identified

Step 4. Outline the Individual Use Cases

For each use case, 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 & responsibility, from trigger to completion

• Say what information passes between them.

• Number each line.

Result: readable description of system’s functions.Combined from Leffingwell & Widrig 2nd ed. And Humans and Technology, Alistair Cockburn

How to do it:

Step 5. Refine the Use Cases Identify alternate scenarios

• Alternate success scenarios– Scenarios that may not be common but are not unexpected

• Failure scenarios– Usually, each step can fail.– Also need to consider what happens if a precondition does not hold

• Result: list of alternate scenarios per use case.

Step 6. Verify & Validate the Use Cases (not in text) Did you get all of the use case? Are they (especially the highest priority ones) all correct? RESULT: A complete set of Use Cases with customer, user, all

stakeholder buy-in.

Combined from Leffingwell & Widrig 2nd ed. And Humans and Technology, Alistair Cockburn

Use Case Guidelines

Use Case Development is an iterative process Steps 1-3 in particular focus on the breadth of the catalog Steps 4-5 focus on depth of prioritized use cases in the catalog Note: Other parallel activities can and should be going on:

• UI prototyping

• Architecture document drafts and initial interface code

• Resource planning, scheduling, etc.

A well-structured use case diagram: Communicates a single aspect of a system's use case view. Contains only use cases and actors essential to understanding that

aspect of the systems behaviour that the diagram is modelling. Is consistent in its level of abstraction. Is not so minimalistic as to misinform the reader

• this is NOT just for developers)

Dr. Gary’s Use Case Tips

Use Case No-No’s Use cases are not “flowcharts”! Do not use in isolation!

Do your Use Cases in “phases” The 6 steps from before – “lather, rinse, repeat” After identifying a full catalog of refined use cases, you can start to

“factor” your use cases

Factoring use cases Use cases so far are independent

• Document use case as a statement of user need

• Have not yet discussed how they relate to each other

Use case “analysis”• Considers how use cases relate to each other

• Begins to partition the problem space

I suggest 2 use case models, one after elicitation (SRS), then another at the start of analysis (Architecture doc)

20

Use Case Process: Moving to Analysis

Use cases so far are independent Document use case as a statement of user need Have not yet discussed how they relate to each other Use caseanalysis:considers how use cases relate to each other

• Begins to partition the problem space

I suggest 2 use case models, one after elicitation, then another at the start of analysis

So where are we going? UCs have so far been developed independently We need to start identifying how these UCs overlap

UC1: Preview ExamActor: Professor1. Login2. Go to gradebook3. Select exam4. Review scores5. View questions6. Blah blah…

UC2: Take ExamActor: Student1. Login2. Answer questions3. Submit4. Review score5. View questions6. Blah blah…

UC3: Take PretestActor: Student1. Login2. Answer questions3. Submit4. Review score5. View questions6. Receive remediation7. Blah blah…

UC1

UC2

UC3

Login

Reviewscores

<<i>>

<<e>>

Use Case Relationships

You may find: Some use cases share common subsets of behavior Some use cases have several modes or special cases Some use cases have multiple flows (extensions or variants) you

would like to show in the use case diagram Some actors are specializations of other actors

What do you do? Identify and factor these behaviors into use cases that are related to

one another Create actor specializations/generalizations

“The purpose of use case relationships is to provide your system’sdesigners with some architectural guidance so they can efficiently breakdown the system’s concerns into manageable pieces” - Learning UML 2.0

Notation: Use Case Relationships

Use Case relationships Dependency

• plus stereotypes <<includes>> and <<extends>>

Generalization

Dependency General UML notation A change in the specification of one model element may imply a

change in another model element

Notation: Use Case Relationships

<<include>>

A stereotype of a dependency

the behavior of B is included into A

the included use case is necessary to ensure the functionality of the base use case.

typically there are multiple use cases that include B

B does not require a Primary Actor, but it does require a triggering event.

Ex: “Authentication processes must include fingerprint verification”

<<extend>>

A stereotype of a dependency

behavior of B may be incorporated into A

• the extending use case is used to add specialized behavior to the base use case.

• The base use case defines where it can be extended through an extension point

Is often confused with use case generalization

• <<extend>> indicates an optional extension to a use case

• So, it is a bit of a cross between <<include>> and generalization

– Reusable specialization of a use case

Ex: “An authentication process after 5pm may be logged in the security logbook”

Notation: Use Case Relationships

Generalization

B inherits the behavior of A and is allowed to override and extend it.

B inherits the communication relationships of A.

Actors may apply Generalization as well

Ex: “A level 2 authentication process conforms to all constraints of a level 1 process yet also requires a retinal scan”

Notation: Use Case Relationships

Student

GraduateStudent

How would you read this diagram?

Course Catalog

View Report Card

Register for Courses

Submit Grades

Select Courses to Teach

Student

Professor

Billing System

Maintain Student Information

Maintain Professor Information

Login

Close Registration

Registrar

View Grades

<<extends>>

Maintain PersonInformation

Dr. Gary’s Tips

When do you use Includes, Extends, Generalization?• Actors

A generalization is typically used to specialize a particular subtype (e.g. Graduate Student is-a Student)

Remember actors are stereotypes classes, so it is possible to use Associations of any type• For example, a member of a group

• Use Case relationships <<include>> and <<extend>> are relationships between 2 distinct

use cases (instance-level, not type-level) Be careful of their direction - it is not flow! Generalization means one use case, which specializes a given use

case’s behavior (type-level, not instance-level)

Use Case Scoping Constructs

Use Case Scope We have relationships between use cases but no means by which

to collect related use cases into partitioned modules UML provides two constructs: the Use Case Package and the Use

Case Overview (or Context) Diagram

Use Case Packages “A packageis a grouping of model elements” – UML

• May contain all kinds of modeling elements, including nested packages Package owns the modeling elements they contain

• Package elements may reference elements in other packages • Modeling elements belong to a single package

Represented with a folder icon

Packages and Use Cases

Use Case Packages All package-allowed

UML modeling constructs apply Useful when you want to organize a lot of use cases into usable/reusable sets

Packages define a naming context for elements Modeling elements with same name can exist in the

model (use at own risk)

Use Case Overview Diagrams

Show the scope and role (context) of system components in realizing behavior Ironically these have actors but not use case “bubbles” Allows the architect to start capturing where system components

might sit (interface) w.r.t. Actors• Recall the “systems affected” template item I did not like? These

diagrams give a separate place to start introducing where systems sit and how they interact.

Online Registration

SystemCourse

Management System

SIS

Student

Registrar

Registers with

Gains access to

Administers Writes info to

Use Case Modeling Process

Step 7: Identify Common Shared Behaviors Perform a comprehensive review of your use case catalog, looking for

common subsets of behavior If “useful”, factor these into new use cases related to other use cases

(typically through <<include>>)

Step 8: Promote Visibility of Important Extensions Behaviors that are complex or important in use case specification extensions

should be made visible in the use case diagram (through <<extends>>)

Step 9: Consider Special Case Are these specializations of identified use cases? Are they done by a

specialized actor?

Step 10: Partition the Behaviors into Packages Form natural clusters of behaviors that go together

• One way is by Actor• What common functionality will need to be implemented to satisfy behaviors?

Step 11:Start thinking about Architecture Name high-level components that can provide functionality Keep this high-level! It is only a “jumping in” point for doing Analysis

Pros & Cons of Use-Case Modeling

Pros: Used to communicate with the end users & domain experts

• Provides buy-in at an early stage of system development

• Insures a mutual understanding of the requirements

Used to identify who interacts with the system and what the system should do

Used to verify all requirements have been captured and the development team understands the requirements

Used as the basis for the rest of the process lifecycle• For example, used as the foundation for writing test scripts

Cons: Captures only the functional requirements Must complement with other techniques to get Customer,

subcontractor, etc. – other requirements perspectives Organizing and identifying common functionality a “leap of faith” Use case connections to the rest of RUP are kludgy