November 5th, 2015
How to Elaborate Requirements Through Use Cases and User Stories Mar$n Schedlbauer, Ph.D., CBAP, CSM, PSM Requirements Techniques
Narrative Statements
•  often in the form of “The system/solution shall …”
User Stories
•  high-level description of user needs that are elaborated later
Use Cases
•  narratives for each usage scenario including exceptions
Visual Artifacts
•  UML models, storyboards, context diagrams, mockups
2
The Business Analyst is asked to collect and organize lots of
information, not just “requirements”.
Objectives
Stakeholder
Information
Functional (Detailed)
Requirements
Solution
Non-Functional (QoS)
Assumptions
Transition
Constraints
Rules
Risks
Collaborative Requirements Analysis with Use Cases
3
3
Requirement Type: Objective
Requirement Type: Objective
Definition: Describes the needs and objectives of the organization
and why some project has been initiated. Objectives
describe WHAT the organization is trying to achieve and
WHY it is important.
Discovered Through: Organizational Analysis
Preferred Format: SMART benefit statements specifying metrics that can be
used to gauge success.
Examples: •  Reduce incidents of adverse drug interactions by 30%
within the next twelve months.
•  Lower the average cost of prescriptions by 15% within
6 months by substituting generics or alternative
medicines.
•  Require all hospitals and health centers to use the
prescription management system exclusively for all
prescriptions.
Requirement Type: Stakeholder
Requirement Type: Stakeholder
Definition: Describes the needs of specific stakeholders and WHAT
they need from the solution. These requirements serve as
a bridge between objectives and solution requirements.
Regulatory bodies are recognized stakeholders who are
often represented by proxy.
Discovered Through: Requirements Analysis
Preferred Format: Use Cases or User Stories; Regulatory Rules
Examples: •  (as a use case) Physician writes prescription
•  (as a use case) Physician checks interaction of
prescribed drug with other drugs that have been
prescribed previously.
•  (as a user story) As a physician, I want to check if the
drug I am prescribing has side effects so that I can alert
my patient.
•  (as a regulation) The FDA requires compliance with
standard CFR 21 Part 11.
Requirement Type: Functional Solution
Requirement Type: Functional Solution
Definition: Describes the external behavior of the solution and the
information that it manages.
Discovered Through: Requirements Analysis
Preferred Format: Narrative statements or steps in a use case scenario.
Screen or report mockups.
Examples: •  The system shall list the side effects by order of
probability of occurrence.
•  The system shall allow the patient to select the
pharmacy to which the prescription will be sent.
•  The system shall transmit prescriptions using the
SCRIPT format.
Collaborative Requirements Analysis with Use Cases
6
Requirement Type: Non-Functional
Requirement Type: Non-Functional Solution
Definition: Describes quality of service requirements and
environmental conditions under which the solution must
remain effective. Includes requirements relating to
performance, response time, security, usability,
compatibility, availability, and reliability, among others.
Discovered Through: Requirements Analysis
Preferred Format: Narrative statements.
Examples: •  The system shall be available from 2am through
midnight, 99% of the time.
•  The system shall not display any patient identifying
information, except the patient’s name and insurance
information, on any printed prescription.
•  The system shall list drug side effects and
contraindications within 2 seconds after a drug has
been selected, 90% of the time.
Collaborative Requirements Analysis with Use Cases
7
Requirement Type: Transition
Requirement Type: Transition
Definition: Describes the capabilities that the solution must have to
ease transition from the current state to the future state.
Includes data conversion requirements and ways to bridge
skill gaps.
Discovered Through: Solution Assessment and Validation
Preferred Format: Narrative statements.
Examples: •  Send a memo to all physicians informing them that all
prescriptions must be electronic.
•  Inform patients that they must provide the name and
address of the pharmacy to which they want
prescription to be sent.
•  Input the addresses of all Massachusetts Walgreen’s,
CVS, and RiteAid pharmacies into the database.
Collaborative Requirements Analysis with Use Cases
8
Plus: Assumptions
Artifact: Assumption
Definition: Describes an understanding that is taken as true without
concrete proof.
Discovered Through: Requirements Analysis
Preferred Format: Narrative statements.
Examples: •  Patients have access to a pharmacy that accepts
electronic prescriptions.
•  Pharmacies accept the SCRIPT format.
Collaborative Requirements Analysis with Use Cases
9
Plus: Constraints
Artifact: Constraint
Definition: Describes a limitation or restriction on the solution.
Discovered Through: Requirements Analysis
Preferred Format: Narrative statements.
Examples: •  The solution must be operable by the end of the fiscal
year.
•  The solution must be compliant with the regulations of
the ACA.
Collaborative Requirements Analysis with Use Cases
10
Plus: Rules
Artifact: Rule
Definition: Describes a policy or guidelines by which an
organizational unit operates.
Discovered Through: Requirements Analysis
Preferred Format: Narrative statements; Decision Table.
Examples: •  Patients may not receive samples of medications.
•  The prescribing physician must be licensed in the state
in which the prescription is filled.
Collaborative Requirements Analysis with Use Cases
11
Definition: User Story
DEFINITION: USER STORY
“A small, concise statement of functionality or
quality needed to deliver value to a specific
stakeholder.”
“A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide).
Collaborative Requirements Analysis with Use Cases
12
Initial Use Cases As User Stories
§  User stories define requirements from a user’s perspective
and are deliberately written without much detail
§  Details are added during conversations with the user and
subject matter experts once the user story has been
selected for a iteration.
§  They serve as an initial use case brief and are eventually
elaborated through use case scenarios.
§  Example user story using the canonical form:
–  As a patient,
I want to view my past prescriptions
so that I can request refills and see side effects.
Collaborative Requirements Analysis with Use Cases
13
User Story Qualities
An effective user story conveys the following:
§  The perspective or role of the user requiring the functionality
described by the story
§  The feature defining the action that the user must be able to
perform using the product
§  The purpose of the story describing the user’s intention
Collaborative Requirements Analysis with Use Cases
14
Definition: Use Case
DEFINITION: USE CASE
A use case is “a description of the observable
interaction between an actor and a solution that
occurs when the actor uses the system to accomplish
a specific goal”.
BABOK® Guide, Version 3.0
Collaborative Requirements Analysis with Use Cases
15
Definition: Actor
DEFINITION: ACTOR
An actor is “a human, device, or system that plays
some specific role in interacting with a solution”.
BABOK® Guide, Version 3.0
Collaborative Requirements Analysis with Use Cases
16
Definition: Scenario
DEFINITION: SCENARIO
“An analysis model that describes a series of actions
or tasks that respond to an event. Each scenario is an
instance of a use case”.
BABOK® Guide, Version 2.0
Collaborative Requirements Analysis with Use Cases
17
Applying Use Case Principles to Story Elaboration
During conversations when trying to understand a user story’s
intent, ask the users and SMEs to:
§  Identify possible scenarios
§  Describe the details of each scenario
§  Define post-conditions, i.e., what will be true when the goal
is accomplished
§  Define pre-conditions, i.e., what we assume is true in order
for the feature to work
§  For each scenario step, ask if that can be done differently
§  Ask if every user does it the same way; if not, consider
defining personas to understand the different user roles
Collaborative Requirements Analysis with Use Cases
18
Analysis Process with User Stories and Use Cases
• Find the actors (users)
• Find the goals of each actor
• Define the goals as user stories
• Elaborate the user stories by identify scenarios
• Write detailed use case narratives
• Augment the narratives with diagrams, models, and mockups
• Review use cases with stakeholders
Collaborative Requirements Analysis with Use Cases
19
Use Case Diagrams
§  A use case diagram is a graphical representation of the
actors and their initiated use cases:
write presciption
check interactions with other drugs
Physician
§  The diagram is informal and often only sketched on a
whiteboard during an elicitation session.
§  Only record the use cases formally if they are used by
remote teams or are needed for compliance.
Collaborative Requirements Analysis with Use Cases
20
System Use Case Catalogs
Instead of recording the actors and use cases in a diagram, a
catalog is often preferable because it is easier to manage.
Actor
Use Cases
Physician
•  write prescription
•  check drug interactions
•  view prescription history
Nurse
(same as physician)
Patient
•  request refill
•  view prescription history
Pharmacist
•  fill prescription
Collaborative Requirements Analysis with Use Cases
21
Use Case Narrative
The details of the use case and its associated scenarios are
captured in the use case narrative.
Each use case has an associated narrative.
The use case narrative describes the flow of control through
each normal and alternate scenario.
write presciption
Physician
Use Case: Write Prescription
Actors: Physician, Patient
Trigger: a medication is required
Pre-Conditions: Patient has received medical exam
Post-Conditions: prescription sent to pharmacy
Normal Scenario:
1. This use case starts when a medication is
required.
2. The physician selects the medication.
3. The physician checks if generic alternatives are
available. {V1}
...
Alternate Scenarios:
V1: Generics Are Available
V1.1. …
Collaborative Requirements Analysis with Use Cases
22
Scenarios Define Use Cases
Use cases are defined fully through scenarios:
§  Basic path scenario
–  The typical course of event
§  Alternate scenarios
–  An alternate way in which the basic path can play out but
still result in a successful outcome
§  Exception scenarios
–  When something goes wrong and the use case cannot be
completed successfully
§  Every scenarios represents a path through the use case
from the start triggered by an event to its completion.
Collaborative Requirements Analysis with Use Cases
23
Perspective: Current vs Future State
A use case is created from a specific perspective:
§  Current State: As-Is
§  Future State: To-Be
Collaborative Requirements Analysis with Use Cases
24
Best Practices for Defining Use Cases
Stakeholders often don’t know their processes and needs well.
Asking for the “first step” of a use case or process may confuse
them.
A better approach might be to state a use case as an
interaction and ask:
• What happens during this interaction?
• What is the desired outcome or goal of this interaction?
• What tasks do have to be accomplished to achieve the goal?
• What does the interaction produce as its deliverable?
• Who participates in the interaction?
• Don’t focus on the order of steps, just tell me what happens.
Collaborative Requirements Analysis with Use Cases
25
More Best Practices
Afterwards, for each step ask them:
• What other step must be completed before this one can be
done?
• Who carries out the activity?
• Does it always happen like this?
• When does this step get done differently?
• Now you are ordering the activities and you are starting to elicit
the branches in the flow.
Collaborative Requirements Analysis with Use Cases
26
Pre and Post Conditions
Pre-Conditions:
Define what you assume to be true in order for the use case to
succeed
Post-Conditions
Describe what the use case will have altered or accomplished.
This is essentially a summary of the use case outcome
It’s often much easier to define the pre- and post-conditions
after you have investigated the basic and alternate flows.
Collaborative Requirements Analysis with Use Cases
27
Stakeholder Reviews
Schedule a walkthrough with the appropriate stakeholders,
domain experts, developers, and end users to assure that the
use case has been understood correctly.
ü  Do this before you proceed to implementation.
Collaborative Requirements Analysis with Use Cases
28
Summary: User Stories Versus Use Cases
§  User stories are not the same as use cases, but both serve
a similar purpose: understand what the user needs.
User Story
Use Case
Simple statement of user need
and purpose for need
More complete definition of user
need and how system is expected
to behave
Elaborated through conversation
on agile projects
Elaborated through step-by-step
narrative scenarios
Defines acceptance criteria and
scenarios
Defines pre and post conditions
§  Both are augmented with models to specify expected
behavior, but the models may not be formal work products
or deliverables in an agile environment.
Collaborative Requirements Analysis with Use Cases
29
Summary: Benefits and Challenges
Benefits
Challenges
Instills customer ownership
Not detailed enough when regulatory
restrictions require detailed
documentation
Useful for iterative and incremental
delivery of solutions
May not align with waterfall methods
that are documentation centric
May eliminate the need for more
detailed requirements specifications in
agile environments where
stakeholders and delivery teams are
co-located
Does not document non-functional
requirements well and therefore
require additional techniques to be
used in conjunction with user stories
Clearly defines the value that a
features provides
Story format may not include enough
detail for teams that are distributed
Prioritize with story points for timeboxed iterations
Collaborative Requirements Analysis with Use Cases
30
Interactive Case Study
Consider the design of a virtual shopping assistant for a
clothing store, such as Macy’s.
1.  define at least five user stories
2.  take one of the user stories and refine it into a use case
3.  elaborate the use case by defining the functional
requirements for the normal scenario
4.  identify alternate and exception scenarios
5.  describe pre- and post-conditions
What other artifacts would you need to create to communicate
the requirements fully? How would you decide what’s really
necessary? What about non-functional requirements,
constraints, and business rules?
31