What are use cases in Software Engineering & use cases formats?

Table of Contents:

• Use Cases
• Definition
• Diagram
• Motivation
• Are Use Case Functional Requirements?
• Actor Kinds
• Use Case Formats
• Example of Fully Dressed Use Case
• Use Case Sections Detail
• Use Case Process Sale 

Use Cases - Definition

• Text stories to discover and record requirements
• Use case name should start with a verb
• These are inputs to many subsequent artifacts

• Example

– Process Sale: A customer arrives at a checkout with items to purchase. The
cashier uses the POS system to record each purchased item. The system
presents a running total and line-item details. The customer enters
payment information, which the system validates and records. The system
updates inventory. The customer receives a receipt from the system and
then leaves with the items.

• Use cases are not diagrams, they are text.

Actor

• – Something with behavior e.g. Person, Computer System, cashier etc.

Scenario

• – Sequence of actions and interaction between user and the system
• – Also called use case instance

“A use case is a collection of related success and failure scenarios that
describe an actor using a system to support a goal” 

“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 [RUP]”

Use Case Diagram 

Use Cases - Motivation

• Keep the user of the system involved in finalizing its requirements.
• Use cases are based on the user interaction with system and facilitate it very well.
• Use cases are simple. Its story communicate the requirements with less confusion and easy understanding among the stakeholders and development team.
• Emphasize on the user goals and perspective by asking them about the system users, scenarios and goals.
• Provides layers of sophistication e.g. novice use case, use case diagram, use cases relationships and use case packages etc.

Are Use Case Functional
Requirements?

• Use Cases are requirements with primary focus on functional requirements. Emphasize
• on the F in FURPS+
• In UP and other modern method Use Cases are the central mechanism for discovering and definition of requirements
• To reduce old style feature lists

Actor Kinds

• Actors are roles played by person, organization, software, and machines
• There are three kinds of actors in the system under development

• – Primary Actor

• Has user goals fulfilled through using services of the SuD e.g. Cashier
• This type of actor drives a use case

• – Supporting Actor

• Provides a service to the SuD e.g. Automated payment authorization service
• These actors clarify the external interfaces and protocols

• – Offstage Actor

• This actor has interest in the behavior of the use case e.g. Government Tax Agency
• These are identified to ensure that all necessary interests are identified and satisfied.

Use Cases Formats

• Brief

– One paragraph summary and cover mainly success scenario
– These are written during early requirements analysis

• Casual

– Has informal paragraph format
– Multiple paragraphs cover various scenarios
– Written during early requirements analysis

• Fully Dressed

– All steps and variations are written in details
– It has many sub section e.g. pre conditions, post conditions, and
success guarantees
– Expansion of the brief use cases when all are identified

Example of Fully Dressed Use Case

Use Case Sections Detail

• Scope

– Bounds the system under design
– System use case describe use of one software system
– If use case also describe how it is used by its customers and
partners the with broader scope they are called business use
cases.

• Level

– Focus on user goal level
– User goal level is the common kind that describe the scenario to
fulfill a goal of primary actor
– Sub function level describe the sub steps required to support a
user goal

• Primary Actor

– The primary actor that calls the system services to fulfill a goal.

• Stakeholder and Interests List

– Suggest and bound what the system must do
– Enforce the stuff needed inside the use case to satisfy
stakeholder interests

• Preconditions and Success Guarantees (Post conditions)

– Avoid useless noise to the requirements
– Only focus on what must always be true before the use case  starts
– Successful Guarantees focus on what must be true after the use case end

• Main Success Scenarios and Steps (or Basic Flow)

– Happy path scenarios, basic/typical flow of events
– One happy path satisfy the interest of stakeholder
– Captures three kinds of steps

• Interaction between actors
• Validation
• State Change by the system
• Extensions (or Alternative Flows)

– Cover scenarios and branches of happy/unhappy path other than basic flow
– It has two parts
• Condition

• Handling

– Both Basic Flow and Extensions should cover all interests of the stakeholder
related to the use case
– After handling extension of a scenario, by default it merge back to the main
basic flow
– If extension point is very complex then create a separate use case

• Special Requirements

– Record non functional requirements, quality attribute, or
constraints in this section
– E.g. Performance, reliability, usability and designing constraints

• Credit Authorization response within 30 sec
• While touching UI the text should be visible from one meter
• Language internationalization on the displayed text
• Technology and Data Variations List

– Technical constraints imposed by stakeholder about input output technology
– Using UPCs or EANs for item identification encoded in bar code symbology