Requirements modeling. Last lecture Good requirements are crucial Specifying requirements is hard.

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?