requirements modeling. last lecture good requirements are crucial specifying requirements is hard
TRANSCRIPT
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?
Developer
connect mysql
database to asp .net web …
Client
sell my beautiful jewelry
Customer of client
find a cool ring on sale
Functional reqs: What should it do?
Client
sell my beautiful jewelry
Customer of client
find a cool ring on sale
User-centric: What not how
Modeling functional requirements
• Identify user classes
Example:jewelry store ownerbuyer of jewelry
Modeling functional requirements
• Identify user classes
• For each user class identify goals
Example Buyer:
search for itemplace an orderreturn 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 catalogActors: Customer Alice, Sales rep Bob, Stockroom,
Shipping dept. Initiator: AliceScenario:1. Alice calls company2. Bob answers phone3. 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”
• Fully dressed use cases – preconditions, post-conditions, actors, stakeholders, etc.
…
these are cultural issuesbut in agile methods, less is more
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 catalogActors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: AliceScenario:1. Alice calls company2. Bob answers phone3. Alice says she want to order item X.4. Bob checks stockroom for availability.5. Stockroom says it is available.6. …
Main scenario with branchesName: Order jewelry from a catalogActors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: AliceScenario:1. Alice calls company2. Bob answers phone3. 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 Stockroom
call on phone
answers phone
wants to order
…
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 doneAgile: until good enough for now
Example: Pac Man Use Cases
Actor Goal Priority
User Play game 1
User Initialize game 1
User View high scores 3
User Set level 3
User Pause game 2
User Exit game 2
User Save game 3
User Change Controls 4
User Play saved game 3
Elaborated use casePlay game:1. User chooses “Play Game” from main menu.2. Start level is displayed with player having 3 lives3. User moves Pac Man left, right, up, down4. Pac Man moves to empty space, return to step 34.a. Pac Man hits dot but not end of level, 50 points awarded, return to
step 34.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 Goal Priority
User Play game 1
User Play level 1
User Initialize game 1
User View high scores 3
User Set level 3
User Pause game 2
User Exit game 2
User Save game 3
User Change Controls 4
User Play saved game 3
Agile method: goal stack
highest priority, best modeled use case
lowest priority, least modeled use case
prioritizeduse cases
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• Testable• Feasible• Consistent• Prioritized• Traceable• Agreed upon by customer
How can use cases contribute to quality in functional requirements?
Tools for modeling (functional) requirements
• Use Cases
• State Diagrams
• UI Mockups
• Storyboards
• Prototypes
good for describing “flow”
State diagrams
Moves to empty spot
Pac Man has n lives, score k
moves left, right, up,down
Hits ghost:Sound effect
n reduced by 1Lose level
n=0
n>0
Hits dot:Sound effect
k increased by 50k<MAX
Win level
Play level: initialize n=3 (#lives), k=0 (level score)
k<0
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
Sample level with simplified art, minimal features
Use fast prototyping tools to clarify functionality, look and feel, etc.
Which model should you use?
All that are appropriate!
Invent new ones as needed!
Requirements for games
Game Designer
Management
Marketing
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/developmentstrategy
Agile method: goal stack
movesprite
display sprite
level 0
prioritizeduse cases,
proofs of concept
proof of concept tounderstand 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-due-assignment.
• 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?