SOFTWARE REQUIREMENTS

UNDERSTANDING USER REQUIREMENTS

2 / 24
 Use cases and user stories
Sample use cases from various applications

3 / 24
 Use cases and user stories
As used on agile development projects, a user story is a “short, simple
description of a feature told from the perspective of the person who
desires the new capability, usually a user or customer of the system”
User stories often are written according to the following template,
although other styles also are used:
As a <type of user>, I want <some goal> so that <some reason>.

4 / 24
 Use cases and user stories
Both are focused on understanding what different
types of users need to accomplish through interactions
with a software system
However, the two processes move in different
directions from these similar starting points

5 / 24
 Use cases and user stories
User stories provide a concise statement of a user’s
needs.
Use cases dive further into describing how the user
imagines interacting with the system to accomplish his
objective.
The use case should not get into design specifics, just
into the user’s mental image about the interaction

6 / 24
 The use case approach
• Identify actors:
– Who (or what) is notified when something occurs within
the system?
– Who (or what) provides information or services to the
system?
– Who (or what) helps the system respond to and complete
a task?

7 / 24
 The use case approach
• Use case diagrams provide a high-level visual
representation of the user requirements

8 / 24
 The use case approach
• Arrows from each actor (stick figure) connect to the use
cases (ovals) with which the actor interacts. An arrow
from an actor to a use case indicates that he is the
primary actor for the use case.
• The primary actor initiates the use case and derives the
main value from it.
• An arrow goes from a use case to a secondary actor,
who participates some how in the successful execution of
the use case.
•

9 / 24
 The use case approach
• Questions to consider
– What will the actor use the system for?
– Will the actor create, store, change, remove, or read
data in the system?
– Will the actor need to inform the system about
external events or changes?
– Will the actor need to be informed about certain
occurrences in the system?
• Provide a brief description that elaborates the
intent of the use case
Program Vacation Setting
Actor(s): Homeowner/programmer
Description: Homeowner/programmer sets lighting and
alarm options for an extended stay away from home
10 / 24
 The use case approach
The system actors
• An actor is a person (or sometimes another software
system or a hardware device) that interacts with the system
to perform a use case
– Who (or what) is notified when something occurs within the
system?
– Who (or what) provides information or services to the system?
– Who (or what) helps the system respond to and complete a
task?
• Users
– Students are actors on EduNext system
– Authors are actors on a word processing system
• Other systems or applications
– The EduNext system is the actor of the FAP system.
• A device
– Camera
– Printer
11 / 24
 The use case approach
The use case diagrams
The diagrams provide a high-level visual representation
of the user requirements
• The primary actor
initiates the use case
and derives the main
value from it
• An arrow goes from a
use case to a
secondary actor, who
participates some how
in the successful
execution of the use
case.

12 / 24
 The use case approach
The use case specification

13 / 24
 The use case approach
The use case specification
• Mandatory elements
– Name – Unique and descriptive
– Brief description – Paragraph describing purpose
– Actors – List all actors that interact with this use case
– Flow of events – Basic flow and Alternate flows
• Optional elements
– Pre-conditions – conditions that must be present in
order for a use case to start
– Post-condition – state of the system after a use case
has run its course
– System or subsystem – level of use case. System
causes multiple subsystems to interact
– Other stakeholder – non users
– Special requirements – performance or throughput
14 / 24
 The use case approach
The use case specification
• Preconditions define prerequisites that must be met before
the system can begin executing the use case. For example: or
a use case to withdraw cash from an automated teller
machine, the ATM must contain money
• Postconditions describe the state of the system after the use
case executed successfully. Postconditions can describe:
- Something observable to the user (the system displayed an
account balance).
- Physical outcomes (the ATM has dispensed money and
printed a receipt).
- Internal system state changes (the account has been debited
by the amount of a cash withdrawal, plus any transaction
fees).

15 / 24
 The use case approach
Outline the use cases
• Outline all the basic flows first
– Basic flow is the most common path
– What event starts the use case?
– How does the use case end?
– How does the use case repeat some behavior?
• Outline alternate flows
– Are there optional situations?
– What odd cases might happen?
– What variants might happen?
– What may go wrong?
– What may not happen?
– What kind of resources can be blocked?
16 / 24
 Use case scenario
• A scenario is a description of a single instance of usage of
the system. A use case is therefore a collection of related
usage scenarios, and a scenario is a specific instance of a
use case. When exploring user requirements, you can
begin with a general use case statement and develop
more specific usage scenarios, or you can generalize from
a specific scenario example to the broader use case.

17 / 24
 Comprehensive use case template
• The essential elements of a use case are the following:
- A unique identifier and a succinct name that states the user
goal
- A brief textual description that describes the purpose of the
use case
- A trigger condition that initiates execution of the use case
- Zero or more preconditions that must be satisfied before the
use case can begin
- One or more postconditions that describe the state of the
system after the use case is successfully completed
- A numbered list of steps that shows the sequence of
interactions between the actor and the system—a dialog—
that leads from the preconditions to the postconditions

18 / 24
 Normal flows, alternative flows, and
exceptions:
• One scenario is identified as the normal flow of events
for the use case. It’s also called the main flow, basic flow,
normal course, primary scenario, main success scenario,
sunny-day scenario, and happy path. The normal flow for
the “Request a Chemical” use case is to request a
chemical that’s available in the chemical stockroom.

19 / 24
 Use case Presentation
• Although many use cases can be described in simple prose, a
flowchart or a UML activity diagram is a useful way to visually
represent the logic flow in a complex use case, as illustrated in
Figure 8-4.
• Flowcharts and activity diagrams show the decision points and
conditions that cause a branch from the normal flow into an
alternative flow

20 / 24
 Use case Presentation
•

21 / 24
 The use case approach
• Association relationships
In UML models, an association is a relationship between two classifiers,
such as classes or use cases, that describes the reasons for the
relationship and the rules that govern the relationship.
• Generalization relationships
In UML modeling, a generalization relationship is a relationship in which
one model element (the child) is based on another model element (the
parent). Generalization relationships are used in class, component,
deployment, and use-case diagrams to indicate that the child receives all
of the attributes, operations, and relationships that are defined in the
parent.
• Include relationships
In UML modeling, an include relationship is a relationship in which one
use case (the base use case) includes the functionality of another use case
(the inclusion use case). The include relationship supports the reuse of
functionality in a use-case model.
• Extend relationships
In UML modeling, you can use an extend relationship to specify that one
use case (extension) extends the behavior of another use case (base). This
type of relationship reveals details about a system or application that are
typically hidden in a use case.
22 / 24