Chapter 6:Chapter 6:Structuring Requirements: Structuring Requirements:

Use Case Use Case Description and DiagramsDescription and DiagramsObject-Oriented Systems Analysis and

DesignJoey F. George, Dinesh Batra,

Joseph S. Valacich, Jeffrey A. Hoffer

Chapter ObjectivesChapter ObjectivesAfter studying this chapter you should

be able to:– Understand how to structure requirements with

use case diagrams.– Explain the basics of use case construction

using UML standards.– Construct use case diagrams.– Write text-based use cases.

What Is Requirements Structuring?What Is Requirements Structuring?The process of analyzing, organizing, and

modeling the requirements obtained via interviews, questionnaires, observation, and document analysis

Relevant UML models include:– Use Cases – Class Diagrams – Interaction Diagrams, and – Activity or Statechart Diagrams

Use Case DeliverablesUse Case Deliverables

Use case diagrams

Use case descriptions (narratives)

What Is a Use Case?What Is a Use Case? A depiction of a system’s functionality or behavior

as a response to a user request

It is a description of the actions that a system performs that yields an observable result to a particular user.

A use case consists of a set of interactions between a user and a system relating to a single function (e.g. enter an order, determine price, withdraw cash)

A use case may produce many outcomes. These are called scenarios (or sequences)

What Is a Scenario?What Is a Scenario? A scenario (or a sequence) is a single outcome from the

system as part of performing a larger use case.

A scenario produces only one outcome.

The customer browses the catalog and adds desired items to the shopping cart. When ready to check out, customer enters credit card information, and confirms the order. The system checks authorization, and confirms the sale.

If instead, the customer decides to save the shopping cart for later use, or if the credit card information is invalid, those are two different scenarios

Both of the above bullet points are the same use case, but the are 3 different scenarios

A Use Case DiagramA Use Case Diagram

UML Use Case UML Use Case Diagram SymbolsDiagram Symbols

Use Case Actor Boundary Connection Include relationship Extend relationship Generalization

<<include>>

<<extend>>

What Is an Actor?What Is an Actor?

• An external entity that interacts with the system

• Most actors represent user roles, but actors can also be external systems.

• An actor is a role, not a specific user. As such, many users can play the same role. Alternatively, one user can play many roles.

What Is a Boundary?What Is a Boundary?

The dividing line between the system and its environment

- Use cases are within the boundary.

- Actors are outside of the boundary.

What Is a Connection?What Is a Connection?

An association between an actor and a use case

Depicts a usage relationship

Connection does not indicate data flow

What Is an <<include>> What Is an <<include>> Relationship?Relationship?

A connection between two use cases

Indicates a use case that is used (invoked) by another use case

Calls to general purpose functions

UML uses a dashed arrow (pointing to the invoked use case) and the word <<include>>

An <<include>> RelationshipAn <<include>> Relationship

Another example of anAnother example of an<<include>> Relationship<<include>> Relationship

Both buying a house and selling a house require house valuation

- You can make a single house valuation use case, and have both other use cases use (invoke) this use case using an <<include>> relationship

What Is an <<extend>> What Is an <<extend>> Relationship?Relationship?

A connection between two use cases

Extends a use case by adding new behavior or actions (a sub-class)

A specialized use case extends a general use case

UML uses a dashed arrow (pointing to the extended use case) and the word <<extend>>

Examples ofExamples of<<extend>> Relationship<<extend>> Relationship

Buying a product as a registered customer extends buying a product.

- Buying a product as a registered customer adds functionality to buying a product

Registering for a special class extends registering for a class use case.

- Registering for special classes requires instructor permission plus all steps required for registering for a regular class

Example of <<include>> & <<extend> Example of <<include>> & <<extend> RelationshipsRelationships

A Use Case DiagramWith both

<<include>> relationships,

and <<extend>> relationship

Use Case Diagram in MS VisioUse Case Diagram in MS Visio

Include vs. ExtendInclude vs. Extend

Use <<include>> if you want to factor a common behavior that two or more use cases can use

Use <<extend>> if you want to model an extension to a complete “more general” use case that exists in its own right, but you are looking to extend/improve the behavior

GeneralizationGeneralization

The act of grouping or categorizing objects into a more general or generic classes or types of objects

UML uses a solid arrow pointing to the

more general class

Actors may be grouped in generalized categories.

Here as “Customer”

GeneralizationGeneralization

Generalized and Abstract Generalized and Abstract Use CasesUse Cases

A generalized use case is a use case that is part of an <<include>> or <<extend>> relationship. It is the use case that is on the arrow head side

An abstract use case is a use case that does not have any actors. It is only used by other use cases. Example: track sales and inventory data. This use case is only used by other use cases.

Use Case Descriptions Use Case Descriptions (Use Case Narratives)(Use Case Narratives)

A written narrative and description of a use case

Document containing detailed specifications for a use case

Document can be written with no specific format, or using a use case template format

Sample Format for Sample Format for Use Case NarrativesUse Case Narratives

Title – name of use case, should match name in use case diagram

Primary actor – the primary user role

Other actors – other user roles

Level – the level of the descriptive detail. summary, intermediate or detail level

Sample Format for Sample Format for Use Case narratives Use Case narratives (Cont.)(Cont.)

Stakeholders – any group or individual with an interest in the function of the use case

Precondition – conditions that must be satisfied (must exist) before executing the use case

Minimal guarantee – the least amount of processing that is promised by the use caseExample: use case fails, roll back transaction.

Success guarantee – outputs that is expected if the use case succeeds

Sample Format for Sample Format for Use Case narratives Use Case narratives (Cont.)(Cont.)

Trigger – an event that initiates the use case. Example: a deposited check, an executed sales order, a call from another use case

Main success scenario – the step-by-step description of the sequence of interactions between the actor and the use case to bring the main scenario to success

Extensions – detailed description of the else scenarios. Description of abnormal “what if” conditions.e.g. description of interaction if credit card is invalid

Use case description at summary level.

High level bulleted items.

Use case description at intermediate level.

More detail descriptive use case interactions

Use Case AdvantagesUse Case Advantages Every use case is a potential high level requirement A use case captures the detail of the interactions

with the system that must be implemented A use case is a good starting point for the

elaboration phase A use case represents the actor’s point of view A use case should only describe the external visible

behavior of the interaction with the actor A use case should not focus on implementation

RecapRecapAfter studying this chapter we learned

to:– Understand how to structure requirements

with use case diagrams.– Explain the basics of use case

construction using UML standards.– Construct use case diagrams.– Write use cases descriptions/narratives.