Managing Changing Managing Changing Requirements:Requirements:

Structure the Use Case Model Structure the Use Case ModelPowerPoint Presentation derived from IBM/Rational course

Mastering Requirements Management

Most slides copyright IBM/Rational. Slide 1

Objectives

• Simplify the maintenance of the requirements without sacrificing clarity or comprehension for stakeholders.– Structure the use-case model.– Define and describe the relationships between use

cases.• Include, Extend, Generalization

– Describe concrete and abstract use cases.– Define actor generalizations.– Describe concrete and abstract actors.

Where Are We in the Requirements Discipline?

Manage Change: Activities and Artifacts

Workflow of use case modeling

• Seek Actors: Name and describe• Seek Use Cases:

– For each (active) actor ask “What would you like to use the system for?”

• Name and briefly describe each Use Case• Iterate based on previous findings

Iterate

Seek ActorsDescribe the Use Cases

Seek Use Cases

Analysis Phase

Structure the Use-Case Model

• What is model structuring?– Factoring out parts of use cases to

make new use cases.

• Why structure the use-case model? – Simplify the original use cases.

• Make easier to understand.• Make easier to maintain.

– Reuse requirements.• Share among many use cases.

Relationships Between Use Cases

• Include

• Extend

• Generalization

«include»

«extend»

What Is an Include Relationship?

• A relationship from a base use case to an inclusion use case.

• The behavior defined in the inclusion use case is explicitly included into the base use case.

«include»

Base

Inclusion

Dependency – Include

• A relationship from a base use case to an inclusion use case• Implies that a use case “calls” another use case• Primarily for reuse behavior common to several use cases• The “calling” Use Case references the “called”. All conditions

for the usage are stated in the “calling” Use Case, e.g:– ”… The system then prints the report according to <Print> …”– ”… The system collects the coins according to <InsertCoins>, the system

is now ready to …”

Analysis Phase

OrderCoffee

Include Relationship: RU e-st Example

Identify Customer Use Case1. Log on2. Validate logon3. Enter password4. Verify passwordA1: Not valid logonA2: Wrong passwordA3: ...

Get Quote Use Case1. Include “Identify Customer” to

verify customer’s identity2. Display options. Customer

selects “Get Quote”3. ...

Execute Trade

Get Quote

Identify Customer

Other Use Case «include»

«include»

«include»

Trading Customer

Execution of an Include Relationship

• Fully executed when the inclusion point is reached.

Use-Case Instance

Base Use Case

Included Use Case

Why Use an Include Relationship?

– Factor out behavior common to two or more use cases.

• Avoid describing same behavior multiple times.

• Assure common behavior remains consistent.

– Factor out and encapsulate behavior from a base use case.

• Simplify complex flow of events.• Factor out behavior not part of

primary purpose.

«include»

Base

Inclusion

Why not?

• Do not overuse this concept– generates too many Use Cases– makes the Use Case Model more

difficult to understand and maintain

Analysis Phase

OrderCoffee

What Is an Extend Relationship?• Connects from an extension use case to a base

use case. – Insert extension use case’s behavior into base use

case.– Insert only if the extending condition is true.– Insert into base use case at named extension point.

«extend»

Extension

Base

Dependency - Extend

• From an extension use case to a base use case• Implies behavior in one use case is an extension of the

behavior in an other use case.• Is used to model optional behavior.• Conditions for how and when the extension is done is

stated in the extending Use Case: – ”… if the user pushes the “add sugar” button, sugar is

added according to <AddSugar> …”

Analysis Phase

OrderCoffee

Extend Relationship: RU e-st Example

Get ExpertPredictions

Get News

Get Quote

«extend» «extend»

Trading Customer

Expert QuoteSystem

News System

Extend Relationship: (cont.)Get Quote Use CaseBasic Flow:1. Include “Identify Customer”

to verify customer’s identity.2. Display options. 3. Customer selects “Get

Quote.”4. Customer gets quote.5. Customer gets other quotes.6. Customer logs off.A1. Quote System unavailable…

Extension Points:The “Optional Services”extension point occurs at Step 3 in the Basic Flow and Step A1.7 in Quote System Unavailable alternative flow.

Get News Use CaseThis use case extends the Get Quote

Use Case, at extension point “Optional Services.”

Basic Flow:

1. If Customer selects “Get News,” the system asks customer for time period and number of news items.

2. Customer enters time period and number of items. The system sends stock trading symbol to News System, receives reply, and displays the news to the customer.

3. The Get Quote Use Case continues.

A1: News System UnavailableA2: No News About This Stock …

Execution of an Extend• Executed when the extension point is reached

and the extending condition is true.

Use-Case Instance

Base Use Case

Extension Use Case

Extension Point

Why Use an Extend Relationship?

• Factor out optional or exceptional behavior.– Executed only under certain

conditions.– Factoring out simplifies flow of

events in base use case.– Example: Triggering an alarm.

• Add extending behavior.– Behavior developed separately,

possibly in later version.

«extend»

Extension

Base

Why not?

• Do not overuse this concept– generates to many Use Cases– makes the Use Case Model

hard to understand and maintain– should still add value to the Actor

Analysis Phase

OrderCoffee

Concrete Versus Abstract Use CasesAbstract use cases (A & D):

• Do not have to be complete.• Exist only for other use cases.• Are never instantiated on their

own.

A use case is either concrete or abstract.

«extend»

«include»

Concrete use cases (B & C):• Have to be complete and

meaningful.• Can be instantiated on their

own.

A

D

CBHint:Cover up all abstract use cases and you should still be able to understand the main purpose of the system.

Why Wouldn’t You Structure The Model? The solution is harder to see

when the use case gets fragmented.

• Functionally decompose the requirements.

• Decrease understandability.

• Increase complexity.

• Increases effort for reviewers, implementers and testers.

• Not all stakeholders are comfortable with the format.

The use-case model looks like a design.

«include»

Base

Inclusion

«extend»

Extension

Child

• Actors may have common characteristics. • Multiple actors may have common roles or purposes

interacting with a use case.

What Is Actor Generalization?

Child 1 Child 2

Parent

• Parent: Medical Worker– Medical Worker can read

charts

• Children: Doctor, Nurse, Aide– Doctor, Nurse, and Aide can

read charts

Actor Generalization: Hospital Example

Read Chart Nurse

Aide

Medical Worker

Doctor

Schedule Operation

Why Use Actor Generalization?

• Simplify associations between many actors and a use case.

• Show that an instance of a child can perform all behavior described for the parent.

• Represent different security levels.

Child 1 Child 2

Parent

Abstract Versus Concrete Actors

• An abstract actor contains the common part of the roles. – It cannot be instantiated itself.– Example:

• No person is hired to be a Medical Worker.

• A concrete actor can be instantiated.– Example:

• Lauren is a Doctor. • Daniel is a nurse.

Doctor Nurse

MedicalWorker

Use-Case-Modeling Guidelines

• Notations to use and not use.– For example, whether to use generalization

relationships.

• Rules, recommendations, style issues, and how to describe each use case.

• Recommendations for when to start structuring the use cases (not too early).

Discussion: Structuring the Use-Case Model

• How should we structure the use-case model for our class project?– Include relationships?– Extend relationships?– Actor generalizations?

Review: Relationships in the Use-Case Model

fromto

generalization

«include»«extend»

generalization

communicates

communicates

fromto

Checkpoints for Use Cases

• For an included use case: does it make assumptions about the use cases that include it? Such assumptions should be avoided so that the included use case is not affected by changes to the including use cases.

• Are there some optional requirements that are not part of the standard product requirements? If so, you model this with an extend-relationship to the other use case.

Review: Structure the Use-Case Model1. Why might you decide to structure your use-case

model?2. When is an extend-relationship used? 3. When is an include-relationship used? 4. What is an abstract actor?

A concrete actor? An abstract use case? A concrete use case?