REQUIREMENTS SPECIFICATION AND USE CASES

REQUIREMENTS IN PROBLEM-SOLUTION SPACE

I need … Problem
Problem
Space
Needs

Tra
Solution

cea
Features Space

bil
The

y it
Product
Software To Be
Requirements Built

Test
Procedures Design User
Docs
USE-CASE MODEL
Use-Cases drive
the work from
analysis through Use-Case Model
test
User Manual

Verified by
Realized by Implemented by

User Interface
Definition

Design Model Implementation Model Test Model

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
 Actor is class and users are an instances

 Can represent a human, a machine, or another system

 Can actively interchange information with the system
 Can be a giver of information
Actor
 Can be a passive recipient of information
WHO IS THE ACTOR?
Who is pressing the keys (interacting with the system)?

Passenger Travel Agent Airline Booking system

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

Internet Booking system

Passenger (airline www page)
USEFUL QUESTIONS IN IDENTIFYING ACTORS

 Who will supply, use, or remove information?

 Who will use this functionality?
 Who is interested in a certain requirement?
 Where in the organization is the system used?
Actor  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

 level: type / scope of a goal

 summary goals ("above sea level"): multi-sitting
 user goals ("sea-level"): one sitting
 subfunctions ("below sea level"): partial

y?
Wh summary goal

ha t? user goal
W

ow? subfunction
H
GOALS AND LEVELS, EXAMPLES

 Withdraw money from an ATM

 level? user goal

 Purchase a book from the online store, and have it shipped to the user; can be cancelled while in transit
 level? summary goal

 Purchase shares of stock online using a "stock trap."

 level?
summary goal
 Update user's balance after a deposit.
 level?
subfunction
 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
WHAT ARE USE CASES?

 It is a case of use
 Describes a conversation between an actor and a system to accomplish a goal
 Use cases are always started by an actor
 Use cases are always written from the point of view of the actors
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 ARE NOT DIAGRAMS

 Use Cases may have a diagram associated with them, and a use case
diagram is an easy way for an analyst to discuss a process with a subject
matter expert (SME).
 But use cases are primarily text.

 The text is important. The diagram is optional.

USE CASES VS. INTERNAL FUNCTIONS
 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
IDENTIFYING USE CASES
 How does each actor use the system?
 What does the system do for each actor?

 You begin with just a name for a use case and fill in the details later.
 Details consist of an initial short description that is refined into a complete
specification
 Use case
 Use case summary
 Use case specification
USE CASE DIAGRAM (USING UML)

System name
Communication
relationship

Use case
Actor

System boundary
DETAIL 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.
PRECONDITIONS

 Anything that must always be true before beginning a scenario is a precondition.

 Preconditions are assumed to be true, not tested within the Use Case itself.
 Ignore obvious preconditions such as the power being turned on. Only document items necessary to
understand the Use Case.
SUCCESS GUARANTEES

 Success Guarantees (or Post conditions) state what must be true if the Use Case is completed
successfully. This may include the main success scenario and some alternative paths. For example, if
the happy path is a cash sale, a credit sale might also be regarded a success.
 Stakeholders should agree on the guarantee.
MAIN SUCCESS SCENARIO

 a.k.a. Main flow

 How do they get it?
 Describes “perfect world” steps in a use case (everything goes as expected)

 Use case start when the customer selects “place order”

The customer enters his or her name and address into the form
 The Success Scenario (or basic course) gives the best understanding of the use case
 Each step contains the activities and inputs of the actor and the system response
 If there are three or more items, create a list
 Label steps for configuration management and requirements traceability
 Use present tense and active voice
 Remember that User Interface designers will use this specification
FINDING EXTENSIONS (ALTERNATIVE FLOWS)
 Each use case has a main flow and many have many alternative flows
 These flows capture errors, branches, and interrupts to the main flow

 For each step in the main flow look for

 Possible alternative to the main flow (how else?)
 Errors that might be raised in the main flow
 Interrupts that might occur at a particular point in the main flow
 Interrupts that might occur at any point in the main flow

 Only document most important alternative flows

FORMAL USE CASE ELEMENTS

(goal of primary actor) (level of goal [summary, user, subfunction])

(primary actor)
"Place an order" (User goal / Clerk)
(action steps:
Main scenario: full sentences showing
who takes the action!
1. Clerk identifies customer, item and quantity. 3 - 9 steps long.)
2. System accepts and queues the order.

(condition causing different actions)

Extensions:
(action step(s)
1a. Low credit & Customer is 'Preferred': handling those conditions)
1a1. System gives them credit anyway.

1b. Low credit & not 'Preferred' customer:

1b1. Clerk performs Sign Up Preferred Customer scenario and accepts only prepayment.
(calling another use case)
2a. Low on stock: Customer accepts rain-check:
2a1. Clerk reduces order to available stock level.
REGISTER FOR COURSES
 1. Display a blank schedule.
 2. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The
lower window displays the times the highlighted course is available. The third window shows all the courses currently in the
schedule.
 3. Do
 4. Student clicks on a course.
 5. Update the lower window to show the times the course is available.
 6. Student clicks on a course time and then clicks on the “Add Course” button.
 7. Check if the Student has the necessary prerequisites and that the course offering is open.
 8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated
schedule showing the new course. If no, put up a message, “You are missing the prerequisites. Choose another course.”
 9. Mark the course offering as “enrolled” in the schedule.
 10. End do when the Student clicks on “Save Schedule.”
 11. Save the schedule and return to the main selection screen.
REGISTER FOR COURSES

 System: Course Enrollment System

 Level: User Goal
 1. Student requests to construct a schedule.
 2. The system prepares a blank schedule form.
 3. The system gets available courses from the Course Catalog System.
 4. Student selects up to 4 primary course offerings and 2 alternate course offerings from the available offerings.
 5. For each course, the system verifies that the Student has the necessary prerequisites, adds the Student to the course, marking Student as
“enrolled” for that course in the schedule.
 6. When the Student indicates the schedule is complete, the system saves the schedule.
 Extensions:
 1a. Student already has a schedule: System brings up the current version of the Student’s schedule for editing instead of creating a new one.
 1b. Current semester is closed and next semester is not yet open: System lets Student look at existing schedules, but not create new ones.
 3a. Course Catalog System does not respond: The system notifies the Student and terminates the use case.
 5a. Course full or Student has not fulfilled all prerequisites: System disables selection of that course and notifies the Student.
USE CASE TABLES
 formal use cases can also be written as a table:
USE CASE NAME Submit Promotion Order
ACTOR Club Member
DESCRIPTION Describes the process when a club member submits a club promotion order to either
indicate the products they are interested in ordering or declining to order during this
promotion
Normal Course 1. This use is initiated when the club member submits the promotion order to be
proceeded
2. The club member's personal information such as address is validated against what is
currently recorded in member services
3. The promotion order is verified to see if product is being ordered
4. The club member's credit status is checked with Accounts Receivable to make sure no
payments are outstanding
5. For each product being ordered, validate the product number
6. For each product being ordered, check the availability in inventory and record the
ordered information which includes "quantity being ordered" and give each ordered
product a status of "open"
7. Create a Picking Ticket for the promotion order containing all ordered products which
have a status "open"
8. Route the picking ticket to the warehouse
PRECONDITION Use case send club promotion has been processed
POST CONDITION Promotion order has been recorded and the picking ticket has been routed to the
warehouse
ASSUMPTIONS
GENERALIZATION
 Actor generalization factors out behavior common to two or more actors into a parent actor.
 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 change 3. (3.) The Customer enters the requested criteria
:
:
Renumbered 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 employee Brief Description: The Manager finds the employee
details details
Primary actors: Manager Primary actors: Manager
Secondary actors: None Secondary actors: None
Preconditions: The Manager is logged on to the system Preconditions: 1. The Manager is logged onto the 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 changed Postconditions: 1. The system has found the employee
Alternative flow: None details.
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
CONDITIONAL EXTENSIONS
GUIDELINE

 1. Name the system scope and boundaries.  7. Capture stakeholders and interests, preconditions and
 Track changes to this initial context diagram with the in/out list. guarantees.
 2. Brainstorm and list the primary actors.  The system will ensure the preconditions and guarantee the interests.
 Find every human and non-human primary actor, over the life of the  8. Write the main success scenario (MSS).
system.
 Use 3 to 9 steps to meet all interests and guarantees.
 3. Brainstorm and exhaustively list user goals for the system.
 9. Brainstorm and exhaustively list the extension conditions.
 The initial Actor-Goal List is now available.
 Include all that the system can detect and must handle.
 4. Capture the outermost summary use cases to see who really
cares.
 10. Write the extension-handling steps.
 Each will ends back in the MSS, at a separate success exit, or in failure.
 Check for an outermost use case for each primary actor.
 5. Reconsider and revise the summary use cases.
 11. Extract complex flows to sub use cases; merge trivial sub use
cases.
 Add, subtract, or merge goals. Double-check for time-based triggers and
other events at the system boundary.
 Extracting a sub use case is easy, but it adds cost to the project.

 6. Select one use case to expand.  12. Readjust the set: add, subtract, merge, as needed.
 Consider writing a narrative to learn the material.
 Check for readability, completeness, and meeting stakeholders ’interests.
REQUIREMENTS WORKFLOW

Develop Vision Elicit Stakeholder

Need
System Analyst Find Actors Structure the Requirements
and use cases Use Case Model Reviewer
Manage Capture a
Decencies Common
Vocabulary

Use-Case Specifier Detail a Use case

Review
Requirements

User-Interface Designer User-Interface User-Interface

Modeling Prototyping

Architect
Prioritize Use Cases
Q&A