requirement modeling

Requirements ModelingRequirements Modeling

– 2 –

Modeling Requirements:Modeling Requirements:

from customer views to something translatable to from customer views to something translatable to softwaresoftware

Techniques for developing functional requirements

What the software is supposed to do!

– 3 –

Requirements modelingRequirements modeling

We build models in requirements analysis or/and We build models in requirements analysis or/and specifications to understandspecifications to understand current systems or business processes which we are trying

to automate how users will use a new system

– 4 –

The software requirements documentThe software requirements documentThe software requirements document is the official The software requirements document is the official

statement of what is required of the system statement of what is required of the system developers.developers.

Should include both a definition of user requirements Should include both a definition of user requirements and a specification of the system requirements.and a specification of the system requirements.

It is NOT a design document. As far as possible, it It is NOT a design document. As far as possible, it should set WHAT the system should do rather than should set WHAT the system should do rather than HOW it should do it.HOW it should do it.

4

– 5 –

Agile methods and requirementsAgile methods and requirements

Many agile methods argue that producing a Many agile methods argue that producing a requirements document is a waste of time as requirements document is a waste of time as requirements change so quickly.requirements change so quickly.

The document is therefore always out of date.The document is therefore always out of date.

Methods such as XP use incremental requirements Methods such as XP use incremental requirements engineering and express requirements as engineering and express requirements as ‘‘user user storiesstories’’

This is practical for business systems and games but This is practical for business systems and games but problematic for systems that require a lot of pre-problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems delivery analysis (e.g. critical systems) or systems developed by several teams, e.g., large government developed by several teams, e.g., large government systems.systems.

5

– 6 –

Requirements document variabilityRequirements document variabilityInformation in requirements document depends on the Information in requirements document depends on the

type of system and the approach to development type of system and the approach to development used.used.

Systems developed incrementally will, typically, have Systems developed incrementally will, typically, have less detail in the requirements document.less detail in the requirements document.

Requirements documents standards have been Requirements documents standards have been designed e.g. IEEE standard. These are mostly designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems applicable to the requirements for large systems engineering projects.engineering projects.

6

– 7 –

Requirements and DesignRequirements and Design

In principle, requirements should state what the system In principle, requirements should state what the system should do and the design should describe how it should do and the design should describe how it does this.does this.

In practice, requirements and design are inseparableIn 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 non-

functional requirements may be a domain requirement.

This may be the consequence of a regulatory requirement.

– 8 –

Tools for modeling requirementsTools for modeling requirements

Use Cases Use Cases – in late 70s, my advisor wrote a tech paper on – in late 70s, my advisor wrote a tech paper on how to do thishow to do this

State DiagramsState Diagrams

UI Mockups UI Mockups – standard process in DoD and auto industry – standard process in DoD and auto industry – (Not in my kitchen)– (Not in my kitchen)

StoryboardsStoryboards

PrototypesPrototypes

– 9 –

Functional Reqs:What should it do?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

– 10 –

Client

sell my beautiful jewelry

Customer of client

find a cool ring on sale

User-centric: What, not howDifficult to express

Functional Reqs: What should it do?Functional Reqs: What should it do?

– 11 –

Modeling functional ReqsModeling functional Reqs

Identify user classesIdentify user classes

Example:jewelry store ownerbuyer of jewelry

– 12 –

Modeling functional reqsModeling functional reqs


For each user class identify goalsFor each user class identify goals

Example Buyer:

search for itemplace an orderreturn an item

– 13 –

Modeling functional reqsModeling functional reqs


For each user class identify goalsFor each user class identify goals

For each user class/goalFor each user class/goal Describe how the user will use the system

– 14 –

ExampleExampleName: Order jewelry from a catalogName: Order jewelry from a catalog

Actors: Customer Alice, Sales rep Bob, Stockroom, Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Shipping dept.

Initiator: AliceInitiator: Alice

Scenario:Scenario:

1.1. Alice calls companyAlice calls company

2.2. Bob answers phoneBob answers phone

3.3. Alice says she wants to place an order from the Alice says she wants to place an order from the catalogue.catalogue.

4.4. Bob asks how the order will be paid.Bob asks how the order will be paid.

5.5. …… USE CASE

– 15 –

Forms of Use CasesForms of Use Cases

Casual – Casual – ““user storiesuser stories””

Fully dressed use cases – preconditions, post-Fully dressed use cases – preconditions, post-conditions, actors, stakeholders, etc.conditions, actors, stakeholders, etc.

…

these are cultural issuesbut in agile methods, less is more

– 16 –

Key aspects of Use CaseKey aspects of Use Case

NameName: what we call this use case: what we call this use case

ActorsActors: entities that interact with system (typically : entities that interact with system (typically people but also can be other systems)people but also can be other systems)

InitiatorInitiator: actor who initiates the use case: actor who initiates the use case

ScenarioScenario: sequence of steps users take and how : sequence of steps users take and how system respondssystem responds

– 17 –

Example: Main scenarioExample: Main scenario

Name: Order jewelry from a catalogName: Order jewelry from a catalog

Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.


Scenario:Scenario:



3.3. Alice says she wants to order item X.Alice says she wants to order item X.

4.4. Bob checks stockroom for availability.Bob checks stockroom for availability.

5.5. Stockroom says it is available.Stockroom says it is available.

6.6. ……

– 18 –

Main scenario with branchesMain scenario with branchesName: Order jewelry from a catalogName: Order jewelry from a catalog

Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept.


Scenario:Scenario:



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

4.4. Bob checks stockroom for availability.Bob checks stockroom for availability.

5.5. Stockroom says it is available.Stockroom says it is available.

5a. Stockroom says it is not available. See order out of stock item 5a. Stockroom says it is not available. See order out of stock item use case.use case.

6. ….6. ….Alternative path can be completed or refer to another use

case.

– 19 –

Use case developmentUse case development

Brainstorm to identify Use CasesBrainstorm to identify Use Cases

Validate/prioritize/ensure consistencyValidate/prioritize/ensure consistency

Elaborate high priority/complex use cases Elaborate high priority/complex use cases identify identify new Use Casesnew Use Cases

Repeat until _________________Repeat until _________________

Waterfall: until done – done keeps movingAgile: until good enough for now

– 20 –

Sequence Diagram - AlternativeSequence Diagram - Alternative

Alice: Customer

Bob: Sales rep Stockroom

call on phone

answers phone

wants to order

…

– 21 –

Example: Pac Man Use CasesExample: Pac Man Use Cases

Actor Goal/Title 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

– 22 –

Elaborated Use CaseElaborated Use CasePlay gamePlay game::

1.1. User chooses User chooses ““Play GamePlay Game”” from main menu. from main menu.

2.2. Start level is displayed with player having 3 livesStart level is displayed with player having 3 lives

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

4.4. Pac Man moves to empty space, return to step 3Pac Man moves to empty space, return to step 3

4.a. 4.a. Pac Man hits dot but not end of level, 50 points awarded, return to Pac Man hits dot but not end of level, 50 points awarded, return to step 3step 3

4.b.4.b. Pac Man hits dot and level ends, 50 points awarded and new level Pac Man hits dot and level ends, 50 points awarded and new level starts (see starts (see start new level use casestart new level use case))

4.c. Pac Man hits ghost (see 4.c. Pac Man hits ghost (see hits ghost use casehits ghost use case))

4.d. Pac Man hits a wall, can4.d. Pac Man hits a wall, can’’t move any further in that direction, returns t move any further in that direction, returns to step 3 with new constraintto step 3 with new constraint

etc.etc.

– 23 –

Refined Use CaseRefined Use Case

Play game:Play game:

1.1. User chooses User chooses ““Play GamePlay Game”” from main menu. from main menu.

2.2. Start level Start level displayeddisplayed with 3 lives and 0 score with 3 lives and 0 score

3.3. Play level (see separate use case)Play level (see separate use case)

4.4. Repeat 3 on successive levels until game overRepeat 3 on successive levels until game over

– 24 –

Refined Use Case (no UI spec)Refined Use Case (no UI spec)

Play game:Play game:

1.1. User chooses to play gameUser chooses to play game

2.2. First level starts with 3 lives and 0 scoreFirst level starts with 3 lives and 0 score

2.2. Play level (see separate use case)Play level (see separate use case)

3.3. Repeat 3 on successive levels until game overRepeat 3 on successive levels until game over

How do you refine a Use Case??Talk to user!!

– 25 –

Pac Man Use CasesPac Man Use CasesActor 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

– 26 –

Agile method: goal stackAgile method: goal stack

highest priority, best modeled use case, e.g, Play UC

lowest priority, least modeled use case, e.g., store game history

prioritizeduse cases

– 27 –

Uses of use caseUses of use case

RequirementsRequirements: : Define functional requirements Expose business rules (constraints on behavior)

PlanningPlanning: Suggest an iterative strategy: Suggest an iterative strategy

DesignDesign: Validate design models, i.e., does design : Validate design models, i.e., does design provide for Use Caseprovide for Use Case

TestingTesting: Provide scenarios for validation testing: Provide scenarios for validation testing

– 28 –

Requirement QualityRequirement Quality

Specify what not howSpecify what not how

UnambiguousUnambiguous

TestableTestable

FeasibleFeasible

ConsistentConsistent

PrioritizedPrioritized

Traceable – Agile: back to requestorTraceable – Agile: back to requestor

Interative: back to a specification #Interative: back to a specification #

Agreed upon by customerAgreed upon by customer

How can Use Cases contribute to quality in functional requirements?

– 29 –

Tools for modeling (functional) requirementsTools for modeling (functional) requirementsUse CasesUse Cases


UI MockupsUI Mockups



good for describing “flow”

– 30 –

State diagramsState 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

– 31 –

Tools for modeling (functional) requirementsTools for modeling (functional) requirementsUse CasesUse Cases





good for describing “flow”

Better for state machines

– 32 –

UI Mock UPUI 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

– 33 –


Good for communicating “look and feel” in addition to Good for communicating “look and feel” in addition to “flow”“flow” (again addressing non-functional requirements) (Indian Jones vs Casablanca movies) Missing in my GPS experience

– 34 –

Tools for modeling (functional) requirementsTools for modeling (functional) requirements

Use CasesUse Cases





these are special cases of prototypes

– 35 –


Sample level with simplified art, minimal features

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

– 36 –

Which model should you use?Which model should you use?

All that are appropriate!

Invent new ones as needed!

– 37 –

Requirements for gamesRequirements for games

Game Designer

Management

Marketing

Users

…

Software engineers

– 38 –

Top down game specificationTop down game specification

High conceptHigh concept

Competitive analysisCompetitive analysis

Main characterMain character

Game MechanicsGame Mechanics

Underlying modelsUnderlying models

Major featuresMajor features

Look and feelLook and feel

ScoringScoring

UIUI

etc.etc.

Traditional Game Design Document

“Game Bible”

– 39 –

Bottom up game specificationBottom up game specification

Use casesUse cases

State diagramsState diagrams

UI mock upsUI mock ups



Make your vision “concrete”

Discover technical requirements:• Display sprite• Move sprite• Detect collision• etc.

Address feasibility

Suggest iterative design/developmentstrategy

– 40 –

Agile method: goal stackAgile method: goal stack

initial top goals – risks, proof of conceptinitial top goals – risks, proof of concept

movesprite

display sprite

level 0

prioritizeduse cases,

proofs of concept

proof of concept tounderstand feasibility

use case

requirement modeling

Education

system requirements

design requirements

requirements modeling

modeling requirements

nonfunctional requirements

requirements analysis

design document

business systems