Requirements modeling
Last lecture
• Good requirements are crucial
• Specifying requirements is hard
Today
Techniques for developing functional requirements
What the software is supposed to do!
Requirements modeling
We build models in requirements analysis to
understand
– current systems or business processes
– how users will use a new system
Tools for modeling requirements
•
•
•
•
•
Use Cases
State Diagrams
UI Mockups
Storyboards
Prototypes
Functional reqs: What should it do?
connect
mysql
database to
asp .net
web …
Developer
sell my
beautiful
jewelry
find a
cool ring
on sale
Customer of client
Client
Functional reqs: What should it do?
sell my
beautiful
jewelry
User-centric: What not how
find a
cool ring
on sale
Customer of client
Client
Modeling functional requirements
• Identify user classes
Example:
jewelry store owner
buyer of jewelry
Modeling functional requirements
• Identify user classes
• For each user class identify goals
Example
Buyer:
search for item
place an order
return an item
Modeling functional requirements
• Identify user classes
• For each user class identify goals
• For each user class/goal
– Describe how the user will use the system
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 want to place an order from the
catalogue.
4. Bob asks how the order will be paid.
5. …
USE CASE
Forms of use cases
• Casual – “user stories”
…
these are cultural issues
but in agile methods, less is more
• Fully dressed use cases – preconditions,
post-conditions, actors, stakeholders, etc.
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
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 want to order item X.
4.
Bob checks stockroom for availability.
5.
Stockroom says it is available.
6.
…
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. ….
Alternative path can be completed or refer to another use case.
Sequence diagram
Alice: Customer
Bob: Sales rep
call on phone
answers phone
…
wants to order
Stockroom
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
Agile: until good enough for now
Example: Pac Man Use Cases
Actor
User
User
User
User
User
User
User
User
User
Goal
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
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
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.
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
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
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
Set level
Pause game
Exit game
3
2
2
User
User
User
Save game
Change Controls
Play saved game
3
4
3
Agile method: goal stack
highest priority, best modeled
use case
prioritized
use cases
lowest priority, least modeled use case
Uses of use case
• Requirements:
– Define functional requirements
– Expose business rules (constraints on
behavior)
• Planning: Suggest an iterative strategy
• Design: Validate design models
• Testing: Provide scenarios for validation
Requirement Quality
•
•
•
•
•
•
•
•
Specify what not how
Unambiguous
How can use cases contribute to quality in
Testable
functional requirements?
Feasible
Consistent
Prioritized
Traceable
Agreed upon by customer
Tools for modeling (functional)
requirements
•
•
•
•
•
Use Cases
State Diagrams
UI Mockups
Storyboards
Prototypes
good for describing “flow”
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
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
Tools for modeling (functional)
requirements
•
•
•
•
•
Use Cases
State Diagrams
UI Mockups
Storyboards
Prototypes
good for describing “flow”
better for state machines
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.
Storyboards
Good for communicating “look and feel” in
addition to “flow” (again addressing non-functional
requirements)
Tools for modeling (functional)
requirements
•
•
•
•
•
Use Cases
State Diagrams
UI Mockups
Storyboards
Prototypes
these are special cases of prototypes
Prototypes
Use fast prototyping tools to clarify functionality, look and feel, etc.
Sample level with simplified art, minimal features
Which model should you use?
All that are appropriate!
Invent new ones as needed!
Requirements for games
Management
Marketing
…
Game Designer
Users
Software engineers
Top down game specification
•
•
•
•
•
•
•
•
•
•
High concept
Competitive analysis
Main character
Game Mechanics
Underlying models
Major features
Look and feel
Scoring
UI
etc.
Traditional
Game Design Document
“Game Bible”
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
Agile method: goal stack
prioritized
use cases,
proofs of concept
display
sprite
move
sprite
level 0
proof of concept to
understand feasibility
use case
Next Time
• Design practice
• Reading/watching
– McConnell
– UML tutorial (several pages, do it all)
– Youtube: Will Wright 13:00-30:00
Next Assignment
Game Design Document
• Review the assignment and come prepared next
time to ask questions!
• This is not a 3-hours-the-night-before-it-is-dueassignment.
• Use the remainder of class to begin to PLAN
who is doing what and issuing tickets.
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?