Use Cases - Heracleia Human-Centered Computing...

Use CasesUse Cases in Iterative Development

CSE 5324, Summer 2017

Outline

• What and Why?• Major Elements of a Use Case• Guidelines for Writing Use Cases• Use Case Diagrams• Use Case-Driven Development

CSE 5324, Summer 2017, Ali Sharifara UTA 2

Use-Case

• What it is: – Text story

Widely used to discover and record (mostly functional) requirements

• What is it about: – Some actor(s) using a system to meet specific goals – Answering questions:

• Who is using the system, what are their typical scenarios of use, and what are their goals?

• What it is NOT:– Not object-oriented – Not a diagram

• UML use cases diagrams are “secondary-value” artifacts

• Focus: use cases, not use case diagrams

CSE 5324, Summer 2017, Ali Sharifara 3

Example: Point of Sale

1. Customer arrives at a checkout (+goods)2. Cashier uses POS system to record items 3. System presents a running total and line-item details. 4. Customer enters payment information, which the system validates and records.5. System updates inventory. 6. Customer receives receipt from the system and leaves.


Actors, Scenarios, and Use Cases

• Actor: Entity that shows a behavior, – e.g.: a person (role), computer system, or organization

• Scenario: specific sequence of actions and interactions between actors and a system – use case instance

• Use case: collection of related success & failurescenarios that describe an actor using a system to support a goal


Use Case Example with Scenarios (casual format)

• UC Handle Returns • Main success Scenario: A customer arrives at a

checkout with items to return. The cashier uses the POS system to record each returned item ...

• Alternate Scenarios: – If the customer paid by credit ...– If the item identifier is not found in the system ... – If the system detects failure to communicate with

the external accounting system ...


Use-Case Model

• Set of all written use cases • Model of the system’s functionality and environment • Unified Process (UP) defined artifact within the

requirements discipline • May optionally include a UML use case diagram

– Use cases, actors, and their relationships– context diagram


System Context diagram - Example

• A system context diagram (SCD) is a diagram that defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it. This diagram is a high level view of a system.


Three Kinds of Actors

• Primary actor – Has user goals fulfilled through using services of the system

under discussion – drives the use cases

• Supporting actor – Provides a service to the system under discussion

• e.g., payment authorization service • implies: clarification of external interfaces and protocols needed

• Offstage actor – Has an interest in the behavior of the use case, but is not

primary or supporting • e.g., a government tax agency


Use Case Format

Brief • Succinct one-paragraph summary • Usually the main success scenario • Done during early requirements analysis • Should take only a couple of minutes Casual • Informal paragraph format• Multiple paragraphs covering various scenarios Fully Addressed • Details all steps and variations • Includes supporting sections such as preconditions and success

guarantees • mainly done after many use cases are identified and during early

requirements workshop for high-value and high-risk requirements (e.g., core architectural)


A Template for Fully Dressed Style


Coffee Maker Example

Example of a “semi” fully dressed use case Coffee Maker Example

heracleia.uta.edu/~sharifara/5324/CoffeeMakerExample.pdf


Write in an Essential Style (early phase)

• Keep the user interface out • Focus on actor intent • User’s intentions and system’s responsibilities rather

than their concrete actions • Example

– Manage Users :1. Administrator identifies self. 2. System authenticates identity.

• Another is concrete style that embeds user interface decisions– Avoid during early analysis

• Example1. Administrator enters ID and Password in a dialog box


Write Black-Box Use Cases

• Focus on what the system must do, – i.e., the behavior or functional requirements – Not on how it will do (the design)

Examples:• Good: System records the sale • Bad: The system writes the sale to the database.• Worse: System generates SQL INSERT

statement for the sale


Guideline: Write Terse Use Cases

“System authenticates …”, rather than “The System authenticates …”


Take an Actor and Actor-Goal Perspective

Use case definition • A set of use-case instances, where each instance is

a sequence of actions a system performs that yields an observable result of value to a particular actor

• Write requirements focusing – on the users/actors of a system– Asking about their goals and typical situations – and what they consider a valuable result


Actor-Goal List


One Column vs Two Column Format Two column emphasizes interaction


How to Find Use Cases?

• Choose the system boundary– What you are building?– Wo will be using the system?– What else will be used that you are not building?

• Find primary actors and their goals – Brainstorm the primary actors first– Who starts and stops the system?– Who gets notified when there are errors or failures?

• Define use cases that satisfy user goals – Prepare an actor-goal list (and not actor-task list)– In general, one use case for each user goal– Name the use case similar to the user goal


What Tests Can Help Find Useful Use Cases?

Which of these are valid use cases?

• Negotiate a Supplier Contract • Handle Returns• Log in• Move Piece on the Game Board



Which of these are valid use cases?

• Negotiate a Supplier Contract • Handle Returns• Log in• Move Piece on the Game Board

• All of these can be use cases – At different levels, – Depending on the system, boundary, actors, and goals



• Rather than asking – ”What is a valid use case?”

• More practical question: – “What is a useful level of focus to express use

cases for application requirements analysis?”

• Rules of thumb – The Boss Test – The EBP Test – The size test


The Boss test

– “What have you been doing all day?” • Your reply “logging in!” • Is your boss happy? No value? No good use

case!


The Size Test

• A use case is very seldom a single action or step

• Instead, a use case typically has many steps, and in the full dressed format will often require 3-10 pages of text.


The EBP Test

• An Elementary Business Process is a term from the business engineering field– A task performed by one person in one place at

one time, in response to a business event, which adds measurable value and leaves the data in a consistent state.

• Focus on use cases that reflect EBPs.– Not a single small step, e.g., “delete a line item” or

“print a document”– Not a big task taking days, e.g., “negotiate a

supplier contract”


Applying Tests

• Negotiate a supplier contract– Much broader than EBP, rather a business use case

• Handle returns– OK with the Boss. EBP. Size is good.

• Log in– Boss is not happy is this is all you do all day!

• Move piece on game board – Single step – fails the size test.


Use case diagrams

• Use case diagrams describe what a system does from the standpoint of an external observer. – The emphasis is on what a system does rather

than how.• Use case diagrams are closely connected to

scenarios. – A scenario is an example of what happens when

someone interacts with the system. – A scenario is a specific sequence of actions and

interactions between actors and the system.


A scenario

• Here is a scenario for a medical clinic.

• A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "

• We want to write a use case for this scenario

• Remember: a use case is a summary of scenarios for a single task or goal.


Use cases

• Step 1: Identify the actors• As we read the scenario, define those people or

systems that are going to interact with the scenario.



Questions for Identifying People Actors

• Who is interested in the scenario/system?• Where in the organization is the scenario /system be

used?• Who will benefit from the use of the scenario/system?• Who will supply the scenario/system with this

information, use this information, and remove this information?

• Does one person play several different roles?• Do several people play the same role?


Use cases

• So as we read our scenario, what or who is the actor?


• The actor is a Patient.


Use cases

• The picture below is a Make Appointment use case for the medical clinic.

• The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).

• Actors are stick figures.

• Use cases are ovals.

• Communications are lines that link actors to use cases.


Use Case Components

• The use case has three components.

• The use case task referred to as the use case that represents a feature needed in a software system.

• The actor(s) who trigger the use case to activate.

• The communication line to show how the actors communicate with the use case.


Use case

• Each use case in a use case diagram describes one and only one function in which users interact with the system

– May contain several “paths” that a user can take while interacting with the system

– Each path is referred to as a scenario


Use case

• Labelled using a descriptive verb-noun phrase• Represented by an oval


Make Appointment

Remember that identifying use cases is a discovery rather than a creation

Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system

Use case - Actor

• Labelled using a descriptive noun or phrase• Represented by a stick character


Actors: An actor depicts any entity (or entities) that performs certain roles in a given system.

Use-Case Diagram-Relationships

• Boundary– A boundary rectangle is placed around the

perimeter of the system to show how the actors communicate with the system.


Make Appointment

Note that the actors in the system are outside the system boundary.

Use-Case Diagram - Example


A use case diagram is a collection of actors, use cases, and their communications.

Use Cases


• Types of Relationships for Use Cases

– Generalization– Include– Extend

Generalization Relationship

– Represented by a line and a empty arrow• From child to parent


Child use case Parent use case

Include Relationship

– Arrow Represents the inclusion of the functionality of one use case within another

– is drawn from the base use case to the used use case

– Write << include >> above arrowhead line


Notice that ONLY between use cases (not between actors)

Extend relationship

– Represents the extension of the use case to include optional functionality

– Arrow is drawn from the extension use case to the base use case

– Write << extend >> above arrowhead line


This is often used when much of the same code may be in both only one extends the functionality somewhat.

Example of Relationships

• A use case is a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor


Use Case (Context) Diagrams :Suggested Notation


Use Case Diagrams


Alternative Actor Notation


Use Case form Basis for Others


Use Cases in Iterative Development

• Functional requirements are primarily captured in use cases

• Use cases drive the iteration planning and work

• Easy for users to understand • Influence user manual/documentation • Functional or system testing corresponds to

the scenarios of use cases • Independent of implementing technology


Use-Case Driven Development

• Functional requirements are primarily recorded in use cases.

• Use cases are an important part of iterativeplanning.

• Use-case realization drive the design.• Use cases often influence the organization of

user manuals.• Functional or system testing corresponds to the

scenarios of use case.• UI wizards or shortcuts may be created for most

common scenarios.CSE 5324, Fall 2016, Jeff Lei 49

Writing Use Cases in UP

• Inception: Holds a first 2-day requirement workshop– Identify most use cases by name– Pick 10% to 20% of the use cases to analyze and write in

detail

• Elaboration: Build risky, high-value, or architecturally important parts and clarify the majority of the requirements– Holds a two-day requirements workshop in each iteration– For example, if there are 4 iterations, then complete 30%,

50%, 70%, and 80-90% use cases in 1st, 2nd, 3rd, and 4th

iteration, respectively.

• Construction: Some minor use case writing

CSE 5324, Fall 2016, Jeff Lei 50

Date post:	17-Mar-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Use Cases - Heracleia Human-Centered Computing...

Documents