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