Software Requirements Engineering

Requirements Specification and Use Cases

 What is a Use Case?
 Narrative descriptions of domain processes in a structured prose format
 They are stories or scenarios of how people use the system
 use cases are a widely used mechanism to discover and record requirements
(especially functional)
 Writing use cases is an excellent technique to understand and describe
requirements.
 Use Case Modeling
◼ Use cases are a way capturing and documenting software requirements

◼ Typical steps
▪ Find a candidate system boundary
▪ Find actors and goals
▪ Find Use cases
▪ Specify the Use cases
▪ Identify Key alternative flows
▪ Iterate until use cases, actors, and system boundary are stable
System Boundary
◼ The System boundary defines the border between the solution and
the real world that surround the solution
◼ Our system
◼ Things that interact with our system
◼ What is inside and what is outside?

System
boundary

I/O
Our Solution
Other
I/O Systems
An Actor
◼ Is not part of the system
◼ Is a role a user of the system can play
◼ Can represent a human, a machine, or another system
◼ Can actively interchange information with the system
◼ Can be a giver of information

Actor
 Actors - stakeholders
Three kind of Actors - Stakeholders
 Primary actor
 a user whose goals has to be fulfilled by the system by using services of the
System under description e.g a cashier
 importance: define user goals
 Primary Actors Initiate the Use Case.
 Supporting actor
 provides a service (e.g information) to system under description
 Secondary actors do not initiate the Use Case.
Actors - stakeholders
 Offstage actor
 It has an interest in the behavior of the use case, but is not primary or supporting
(e.g., a government tax agency).
 importance: ensure all interests (even subtle) are identified
and satisfied
Example of Actors - stakeholders

Q what are the primary secondary and offstage actors in a criminal record system
made for police
Example of Actors - stakeholders
E.G For a criminal record system made for police
Primary actors: The Employees who use the system
Secondary or supporting actor: The nadra system which may give input
offstage actor: The government of Pakistan and higher officials of police and other
defence departments as well as the citizens of Pakistan are the offstage actor
Who Is the Actor?
Who is pressing the keys (interacting with the system)?

Passenge Travel Airline Booking

r Agent system
The passenger never touches this system; the travel agent operates it. Or
perhaps you are building an Internet application ...

Internet Booking system

Passenge (airline www page)
r
 Useful Questions in Identifying Actors

◼Who will supply, use, or remove information?

◼Who will use this functionality?
◼Who is interested in a certain requirement?
◼Who will support and maintain the system?
◼What are the system’s external resources?
◼What other systems will need to interact with this one?
 Use Case Goals and levels
 Goal: Action that actor wants to accomplish
 Level: Type or scope of goal
 Summary level:
The 50,000 feet level perspective which shows life cycle sequencing of related goals

 User-goal level:
the sea level perspective i.e. goal of primary actor in doing something

 Sub functions
underwater perspective i.e. those required to carry out user goals.
 Use Case Goals and levels

hy? summary goal

W

hat? user goal

W

w ?
Ho Sub function
Example of user goals and levels
 Actor has the goal of achieving the service
 We name the use case for this goal

Actor Goal Level Use Case summary

Customer Manage Sales Order Summary Includes all the use cases
required to manage sales
order
Customer Create Sales Order User Customer create a sales order
and saves it in the system
Customer Modify Sales Order User Customer modifies the Sales
Order as needed, saves
changes
 Use Case, Actor, and Scenario
Use case then is a collection of success and failure scenarios
E.G: Successful and un successful scenarios of withdraw cash
Success scenarios

Alternate scenarios
UML use case diagrams

◼use cases can be drawn as diagrams, with:

◼ actors as stick-men, with their names below
◼ use cases as ellipses with their names below or inside
◼ association indicated by lines, connecting an actor to a use case in
which that actor participates
◼ use cases can be connected to other cases that they use / rely on

open account

customer
Use cases vs. internal features

◼consider software to run a cell phone:

Use Cases Internal Functions

■ call someone ■ transmit / receive data
■ receive a call ■ energy (battery)
■ send a message ■ user I/O (display, keys, ...)
■ memorize a number ■ phone-book mgmt.

Point of view: user Point of view: developer / designer

18
Use case diagram (using UML)

System boundary
 Case Study – The NextGen POS System

 Computerized application used to record sales and handle payments and is Used
in retail store
 It includes hardware and software
 It also interfaces to other applications, such as a third-party tax calculator and
inventory control and system should work even if access to external services is
down (i.e. at least allow checkout with cash if credit card processing software goes
down)
 Needs to support Multiple clients-side interfaces i.e. web browser , touch screen
and wireless phone etc
 Commercial POS
 4. Define Use cases for user goals
system boundary NextGen POS communication

Process Sale alternate

notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier

«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System

Manage Security

System Manage Users

Administrator use case
. . .
 Use Case Formats (verbal description)
1. Brief
 Terse one-paragraph summary, usually the main success scenario.

e.g
(Process my Email): A student can login, see the headers of Email messages and
then read, delete, reply to, and forward a message.
 Use Case Formats (verbal description)
2. Casual
 Informal, multiple paragraphs that cover various scenarios.
Name short name

(Main Success Scenario): one paragraph.

(Alternative scenario 1): if .... one paragraph

(Alternative scenario 2): if .... one paragraph
 Use Case Formats (verbal description)
2. Casual example
Name Student registers on system or login

(Main Success A student can register with the system by giving certain details, supplying a system id
Scenario): user name and a password(twice). The system responds by reflecting the information
back to the student (but not the password). The student confirms the data and is allowed
access to it via the usual login.

(Alternative  If the user name is already in use the student is asked to change their user name .
scenario 1):

(Alternative If the two passwords are not equal the student must re-input them.
scenario 2):
 Fully dressed use case example
System Online shopping system
Use case name UC12:Validate credit card
Brief description In the online shopping system the customer provides a credit card and it is
validated
Scope This system has a great future scope .It provides security with the use of login id
and password so that any un-authorized users cannot use your account to do
shopping. The authorized will only have access to do online shopping

actors Primary: customer Secondary: credit card company

Pre conditions Customer has selected one item and proceeded to the checkout area
Post conditions Credit card has been validated so customer can continue with the order
Main success scenario 1. Customer enters credit card number and expiration date
2. system verifies card with credit card company
3. System sends authorization message to the customer
 Fully dressed use case example

Alternative In step 2 if credit card company rejects card, system sends rejection message to user
scenario 2a
Alternative In step 2 if the credit card company does not respond within 10 seconds
scenario 2b 1. Tell the user of delay
2. repeat verifying the card

Alternative *a In any step, if the client does not respond after 30 seconds, cancel the transaction
Alternative *b In any step, if there is a power failure, turn off the system
Assumptions User has a credit card
Special Security – no way for customer data to be sniffed
requirements
Detail a use case
Specify use cases you have identified:
Example “Create Sales Order”
Name: Create Sales Order
Summary: Customer creates and saves a Sales Order
System: SMS
Actor: Customer
Pre Condition: Customer is logged in to SMS
Post Condition: Sales order completed and saved. Sales Item is accurate,
including quantities in stock and proposed delivery dates. Pricing is accurate
and complete.
 Generalization:
◼ Actor generalization factors out behavior common to two or more actors into a
parent actor.
 Generalization (cont..):
◼ Use case generalization factors out behavior common to one or more use
cases into a parent use case.
 Use case: Find Book
ID: 7
Parent ID: 6
Brief Description: The customer searches for a book
Primary actors: Customer
Secondary actors: None
Preconditions: None
Main flow:
Overridden 1. (o1.) The Customer selects “find book”.
Overridden 2. (o2.) The system asks the Customer for book search criteria comprising author, title,
ISBN, or topic
Inherited w/o 3. (3.) The Customer enters the requested criteria
change :
:
6.2 (6.1) The system tells the Customer that no matching products could be found

Post condition: None

Alternative flows: None.
<<Include>>
◼ Writing use cases can be repetitive
at times
◼ Factors out steps common to
several use cases into a separate
use case that is then included
◼ The base use case executes until
the point of inclusion in reached,
then execution passes over to the
inclusion use case.
◼ When the inclusion uses case
finishes, control returns to the
base case
UC specification - Include
Use case: Change Employee Details Use case: Find Employee Details
ID: 1 ID: 4
Brief Description: The Manager changes the Brief Description: The Manager finds the employee
employee details details
Primary actors: Manager Primary actors: Manager
Secondary actors: None Secondary actors: None
Preconditions: The Manager is logged on to the Preconditions: 1. The Manager is logged onto the
system system
Main flow: Main flow:
1. include (Find Employee Details) 1. The Manager enters the employee’s ID
2. The System displays the employee details 2. The system finds the employee details.
…
Postconditions: The employee details have been Postconditions: 1. The system has found the
changed employee details.
Alternative flow: None Alternative flow: None
<<extend>>
◼ It is a way of inserting new behavior into an
existing use case
◼ The base case provides a set of extension
points that are hooks where new behavior
may be added, and
◼ The extension use case provides a set of
insertion segments that can be inserted into
the base use case at these hooks
Q&A