CS 121

Ordering Chaos

Requirements Modeling
Mike
Michael A. Erlinger
Today:

How Can we specify Requirements in a

meaningful way

reqsModeling.f12.ppt

Administrivia
Teams chosen, GLECS assigned, mail lists made
Tracs created
svns created
Elicitation done

CS 121

Admin
Tracs are up with grader access
Trac Template available
Link to past project for examples of deliverables
email lists for all teams
without graders

without teachers

all teams should have contact info for teachers

2 conference rooms to reserve. check with DruAnn Thomas

<DruAnn_Thomas@hmc.edu>

Blogs
Piazza
work space on 2nd floor
3

CS 121

Panic: Due within 7 Days

Management Update
Customer Elicitation Report
Game Treatment
Use Cases
Technology Assessment
Forcing pyGame version to run on both Mac and Pc

CS 121

Last lecture
Good requirements are crucial
Specifying requirements is hard

lots of examples of poor requirements

CS 121

Today
Modeling Requirements:
from customer views to something translatable to
software

Techniques for developing functional requirements

What the software is supposed to do!

CS 121

Requirements modeling
We build models in requirements analysis to
understand

current systems or business processes which we are trying

to automate

how users will use a new system

CS 121

The software requirements

document

The software requirements document is the official

statement of what is required of the system
developers.
Should include both a definition of user requirements
and a specification of the system requirements.
It is NOT a design document. As far as possible, it
should set WHAT the system should do rather than
HOW it should do it.

CS 121

Agile methods and requirements

Many agile methods argue that producing a
requirements document is a waste of time as
requirements change so quickly.
The document is therefore always out of date.
Methods such as XP use incremental requirements
engineering and express requirements as user
stories
This is practical for business systems and games but
problematic for systems that require a lot of predelivery analysis (e.g. critical systems) or systems
developed by several teams, e.g., large government
systems.
9

CS 121

Requirements document
variability

Information in requirements document depends on the

type of system and the approach to development
used.
Systems developed incrementally will, typically, have
less detail in the requirements document.
Requirements documents standards have been
designed e.g. IEEE standard. These are mostly
applicable to the requirements for large systems
engineering projects.

10

Chapter 4 Requirements

10 CS 121

The structure of a requirements

document
Chapter

Description

Preface

This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version
and a summary of the changes made in each version.

Introduction

This should describe the need for the system. It should briefly describe the
systems functions and explain how it will work with other systems. It
should also describe how the system fits into the overall business or
strategic objectives of the organization commissioning the software.

Glossary

This should define the technical terms used in the document. You should
not make assumptions about the experience or expertise of the reader.

User
requirements Here, you describe the services provided for the user. The nonfunctional
definition
system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that
are understandable to customers. Product and process standards that
must be followed should be specified.
System architecture

11

This chapter should present a high-level overview of the anticipated

system architecture, showing the distribution of functions across system
modules. Architectural components that are reused should be highlighted.

11 CS 121

The structure of a requirements

document
Chapter
System
requirements
specification

Description
This should describe the functional and nonfunctional requirements in more
detail. If necessary, further detail may also be added to the nonfunctional
requirements. Interfaces to other systems may be defined.

System models

This might include graphical system models showing the relationships between
the system components and the system and its environment. Examples of
possible models are object models, data-flow models, or semantic data models.

System evolution

This should describe the fundamental assumptions on which the system is

based, and any anticipated changes due to hardware evolution, changing user
needs, and so on. This section is useful for system designers as it may help them
avoid design decisions that would constrain likely future changes to the system.

Appendices

These should provide detailed, specific information that is related to the

application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships between data.

Index

Several indexes to the document may be included. As well as a normal

alphabetic index, there may be an index of diagrams, an index of functions, and
so on.

12

12 CS 121

Requirements and Design

In principle, requirements should state what the system
should do and the design should describe how it
does this.
In practice, requirements and design are inseparable
A system architecture may be designed to
structure the requirements;
The system may inter-operate with other systems
that generate design requirements;
The use of a specific architecture to satisfy nonfunctional requirements may be a domain
requirement.
This may be the consequence of a regulatory
requirement.
13

CS 121

Requirements
Engineering/Requirements Modeling
The processes used for RE/RM vary widely depending
Processes
on the application domain, the people involved and
the organisation developing the requirements.

However, there are a number of generic activities

common to all processes
Requirements elicitation;
Requirements analysis;
Requirements validation;
Requirements management.
In practice, RE/RM is an iterative activity in which these
processes are interleaved.
14

14 CS 121

Tools for modeling requirements

Use Cases in late 70s, my advisor wrote a tech paper on
how to do this
State Diagrams
UI Mockups standard process in DoD and auto industry
(Not in my kitchen)
Storyboards
Prototypes
Example: TLB Meetings and Arch/Design Specifications
Today building is set down to light switches, some
things floating white board vs black board
15

CS 121

Functional Reqs:
What should it do?
connect mysql
database to asp
.net web

Developer

16

sell my
beautiful
jewelry

find a
cool ring
on sale

Customer of client

Client

CS 121

Functional Reqs:
What should it do?
sell my
beautiful
jewelry

User-centric: What, not how

Difficult to express
find a
cool ring
on sale
Client

17

Customer of client

CS 121

Modeling functional Reqs

Identify user classes

Example:
jewelry store owner
buyer of jewelry

18

CS 121

Modeling functional reqs

Identify user classes
For each user class identify goals

Example
Buyer:
search for item
place an order
return an item

19

CS 121

Modeling functional reqs

Identify user classes
For each user class identify goals
For each user class/goal

20

Describe how the user will use the system

CS 121

Example
Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom,
Shipping dept.
Initiator: Alice
Scenario:
1.

Alice calls company

2.

Bob answers phone

3.

Alice says she wants to place an order from the

catalogue.

4.

Bob asks how the order will be paid.

5.

21

USE CASE
CS 121

Forms of Use Cases

Casual user stories

these are cultural issues

but in agile methods, less is more

Fully dressed use cases preconditions, postconditions, actors, stakeholders, etc.

22

CS 121

Key aspects of Use Case

Name: what we call this use case
Actors: entities that interact with system (typically
people but also can be other systems)
Initiator: actor who initiates the use case
Scenario: sequence of steps users take and how
system responds

23

CS 121

Example: Main scenario

Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.
Initiator: Alice
Scenario:
1.

Alice calls company

2.

Bob answers phone

3.

Alice says she wants to order item X.

4.

Bob checks stockroom for availability.

5.

Stockroom says it is available.

6.

24

CS 121

Main scenario with branches

Name: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.
Initiator: Alice
Scenario:
1.

Alice calls company

2.

Bob answers phone

3.

Alice says she want to order item D23 from page 5 the
catalogue.

4.

Bob checks stockroom for availability.

5.

Stockroom says it is available.

5a. Stockroom says it is not available. See order out of stock item
use case.
Alternative path can be completed or refer to another use
6.

25

case.

CS 121

Use case development

Brainstorm to identify Use Cases
Validate/prioritize/ensure consistency
Elaborate high priority/complex use cases identify
new Use Cases
Repeat until _________________

Waterfall: until done done keeps moving

Agile: until good enough for now

26

CS 121

Sequence Diagram - Alternative

Bob: Sales rep
call on phone

Stockroom
Alice: Customer

answers phone

wants to order

27

CS 121

Example: Pac Man Use Cases

Actor
User
User
User
User
User
User
User
User
User
28

Goal/Title
Play game
Initialize game
View high scores
Set level
Pause game
Exit game
Save game
Change Controls
Play saved game

Priority
1
1
3
3
2
2
3
4
3
CS 121

Elaborated Use Case

Play game:
1.

User chooses Play Game from main menu.

2.

Start level is displayed with player having 3 lives

3.

User moves Pac Man left, right, up, down (point to other UC)

4.

Pac Man moves to empty space, return to step 3

4.a. Pac Man hits dot but not end of level, 50 points awarded, return to step 3
4.b. Pac Man hits dot and level ends, 50 points awarded and new level starts
(see start new level use case)
4.c. Pac Man hits ghost (see hits ghost use case)
4.d. Pac Man hits a wall, cant move any further in that direction, returns to
step 3 with new constraint
etc.

29

CS 121

Refined Use Case

Play game:
1.

User chooses Play Game from main menu.

2.

Start level displayed with 3 lives and 0 score

3.

Play level (see separate use case)

4.

Repeat 3 on successive levels until game over

30

CS 121

Refined Use Case (no UI spec)

Play game:
1.

User chooses to play game

2.

First level starts with 3 lives and 0 score

2.

Play level (see separate use case)

3.

Repeat 3 on successive levels until game over

How do you refine a Use Case??

Talk to user!!

31

CS 121

Pac Man Use Cases

Actor

Goal

Priority

User

Play game

User

Play level

User

Initialize game

User

View high scores

User

Set level

User

Pause game

User

Exit game

User

Save game

User

Change Controls

User

Play saved game

32

CS 121

Agile method: goal stack

highest priority, best modeled

use case, e.g, Play UC
prioritized
use cases

lowest priority, least modeled

use case, e.g., store game history
33

CS 121

Uses of use case

Requirements:

Define functional requirements

Expose business rules (constraints on behavior)

Planning: Suggest an iterative strategy

Design: Validate design models, i.e., does design
provide for Use Case
Testing: Provide scenarios for validation testing

34

CS 121

Requirement Quality
Specify what not how
Unambiguous
Testable
Feasible

How can Use Cases contribute to quality in

functional requirements?

Consistent
Prioritized
Traceable Agile: back to requestor
Interative: back to a specification #
Agreed upon by customer
35

CS 121

Tools for modeling (functional)

requirements
Use Cases

good for describing flow

State Diagrams
UI Mockups
Storyboards
Prototypes

36

CS 121

State diagrams
Play level: initialize n=3 (#lives), k=0 (level score)

Hits dot:
Sound effect
k increased by 50

k<0

Win level

37

k<MAX

Pac Man has n lives,

score k
moves left, right, up,
down

Moves to
empty spot

n>0

Hits ghost:
Sound effect
n reduced by 1

n=0

Lose level

CS 121

Tools for modeling (functional)

requirements
Use Cases

State Diagrams

good for describing flow

Better for state machines

UI Mockups
Storyboards
Prototypes

38

CS 121

UI Mock UP
UI Mock Up (or even full design) is often
considered part of the requirements process
because it summarizes the ways a user can interact
with the system.
UI design can also address non functional
requirements, e.g., look and feel

39

CS 121

Storyboards
Good for communicating look and feel in addition to
flow

40

(again addressing non-functional requirements)

(Indian Jones vs Casablanca movies)

Missing in my GPS experience

CS 121

Tools for modeling (functional)

requirements
Use Cases
State Diagrams
UI Mockups
Storyboards

these are special cases of prototypes

Prototypes

41

CS 121

Prototypes
Use fast prototyping tools to clarify functionality, look and feel, etc.

Sample level with simplified art, minimal features

42

CS 121

Which model should you use?

All that are appropriate!

Invent new ones as needed!

43

CS 121

Requirements for games

Management

Marketing

Game Designer

Users

Software engineers
44

CS 121

Top down game specification

High concept
Competitive analysis
Main character
Game Mechanics
Underlying models
Major features

Traditional
Game Design Document
Game Bible

Look and feel

Scoring
UI
etc.

45

CS 121

Bottom up game specification

Use cases
State diagrams
UI mock ups
Storyboards
Prototypes

Make your vision concrete

Discover technical requirements:
Display sprite
Move sprite
Detect collision
etc.
Address feasibility
Suggest iterative design/development
strategy

46

CS 121

Agile method: goal stack

initial top goals risks, proof of concept
display
sprite
prioritized
use cases,
proofs of concept

move
sprite

level 0

47

proof of concept to
understand feasibility

use case

CS 121

Next Time
Design practice
Reading/watching

48

McConnell

UML tutorial (several pages, do it all)

CS 121

Comments on Phase 1 Startup

High level concept
should be specified more as a brain storming of
ideas. high level concept conveys formality before
requirements elicitation
Teacher contact
Need name, school description, classroom
description, etc. earlier. Hard to think about game
concept or questions with no knowledge of
environment

49

CS 121

Keep Responding to Schedule

Phase 1...

50

CS 121

Sample questions
Why do we want to classify users?
What are use cases? What are their benefits?
Shortcomings?
What are key components to a use case?
How can use cases be employed throughout the
project?
What is a sequence diagram and when is it useful?
How does UI design fit into the requirements process?
Why do we use prototypes in the requirements
process?
51

CS 121

The End

52

CS 121