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…
–2–
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
–4–
CS 121
Last lecture
Good requirements are crucial
Specifying requirements is hard

–5–
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!
–6–
CS 121
Requirements modeling
We build models in requirements analysis to
understand


–7–
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.
–8–
8
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–
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
engineering
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
system’s 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
Description
System
requirements
specification
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
Processes
The processes used for RE/RM vary widely depending
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
Client
Customer of 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
Customer of client
– 17 –
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.
6.
– 25 –
….
Alternative path can be completed or refer to another use
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
Stockroom
call on phone
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, can’t 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
User
Goal
Play game
Priority
1
User
User
User
Play level
Initialize game
View high scores
1
1
3
User
User
User
User
Set level
Pause game
Exit game
Save game
3
2
2
3
User
User
Change Controls
Play saved game
4
3
– 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<MAX
k<0
Win level
– 37 –
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