WRITING THE REQUIREMENT
J U S T T H E B A S I C S , P L E A S E
J O H A N N L O H R M A N N
THE REQUIREMENT PROCESS
2
Functional Requirements
Software Requirement Specification
UAT (User Acceptance
Testing)
Change Management
THE BASIC STRUCTURE
Theme
Epic
Story
3
THE BASIC DEFINITIONS
Theme Collection of User Stories
Epic A big user story
User Story Something the end user wants
Use Case The detailed requirement
4
USER STORY VS. USE CASE
A user story is the What
and Why.
a use case is the How.
5
A User Story is part of the
play in front of
the black curtain.
6
A Use case is everything
that happens behind the
black curtain.
7
W O R K I N G W I T H U S E R S T O R I E ST H E B A S I C S
8
FROM THEME TO USER STORIES.
Theme Epic User Stories
Work toward
a goal.
Big user story. Something the
user wants.
Georgia
Lottery
Corporation
provides a
secure system
for end users.
As an end
user, I'd like to
set my
password, so I
can log into
the system.
As a salesperson,
I want to be able
to edit my profile,
so I can set my
password.
9
USER STORY FORMULA
As a(n) ______ (actor) I
want to ______ (do
something) so that I can
_____ (end result).10
USER STORY: RELATED TO THE BUSINESS UNITS
Finance Legal
Operations Technical
11
USER STORY PRACTICE
Finance user storyLegal user storyTechnical user storyOperations user story
12
USER STORY RESULTS
13
As an administrator, I'd like to ensure that all salespeople's passwords meet corporate strength
requirements, so I can harden access to the system.
As an administrator, I'd like to send an email to a new salesperson containing a tokenized access link, so they
can temporarily access the system in order to set their
password.
USER STORY RESULTS
14
As an administrator, I want to send an email to a new
salesperson containing a tokenized access link, so that
the salesperson can temporarily access the system in
order to set their password.
As an administrator, I want to ensure that all
salespeople's passwords meet corporate strength
requirements, so that I can harden access to the system.
W O R K I N G W I T H U S E C A S E ST H E B A S I C S
15
USE CASES: THE MAIN PARTS
Use Case Number
Application
Use Case Name
Use Case Description
Primary Actor
Precondition
Trigger
Basic Flow
Alternate Flow
16
USE CASES: INSIDE THE DOCUMENT
Current Functionality
Limitations
Risks
Assumptions
Requirements
Business Rules
Vendor Tasks and Assumptions
Impact
17
USE CASE TERMS
BasicTerms Definition
Basic flow Most common implementation. Assumes
no errors or alternatives exist.
Alternate Flow Alternative implementations. Describes
error conditions.
Constraint Limitation or state. Example: data range of
values, behavior of the application. Required
state at particular point in time.
18
USE CASE TERMSBasicTerms Definition
Precondition A constraint that must be true when a
use case is invoked.
Postcondition A constraint that must be true when a
use case has ended.
Relationship A semantic connection between
model elements. Examples include
associations, dependencies, and
generalizations, extend, and include.19
USE CASE TERMSBasicTerms Definition
Unified Modeling
Language
Visualize the design of a system.
Use Case
Diagram
A UML diagram that shows actors,
use cases, and their relationships.
Use Case Model A model that describes a systems
functional requirements in terms of
use cases.
20
B A S I C M O D E LS
21
EXAMPLE: UNIFIED MODELING LANGUAGE (UML)
22
EXAMPLE: USE CASE DIAGRAM
23
EXAMPLE: USE CASE MODEL
24
WRITING THE REQUIREMENT
J U S T T H E B A S I C S , P L E A S E
J O H A N N L O H R M A N N