1. Requirements
Modeling

2. – 2 –
Modeling Requirements:Modeling Requirements:
from customer views to something translatablefrom customer views to something translatable
to softwareto software
echniques for developing functional requirements
What the software is supposed to do!

3. – 3 –
Requirements modeling
We build models in requirements analysis or/andWe 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. – 4 –
The software requirements
document
The software requirements document is the officialThe software requirements document is the official
statement of what is required of the systemstatement of what is required of the system
developers.developers.
Should include both a definition of userShould include both a definition of user
requirements and a specification of the systemrequirements and a specification of the system
requirements.requirements.
It is NOT a design document. As far as possible, itIt is NOT a design document. As far as possible, it
should set WHAT the system should do rathershould set WHAT the system should do rather
than HOW it should do it.than HOW it should do it.
4

5. – 5 –
Agile methods and
requirements
Many agile methods argue that producing aMany agile methods argue that producing a
requirements document is a waste of time asrequirements 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 requirementsMethods such as XP use incremental requirements
engineering and express requirements asengineering and express requirements as ‘user‘user
stories’stories’
This is practical for business systems and gamesThis is practical for business systems and games
but problematic for systems that require a lot ofbut problematic for systems that require a lot of
pre-delivery analysis (e.g. critical systems) orpre-delivery analysis (e.g. critical systems) or
systems developed by several teams, e.g.,systems developed by several teams, e.g.,
large government systems.large government systems.
5

6. – 6 –
Requirements document
variability
Information in requirements document depends onInformation in requirements document depends on
the type of system and the approach tothe type of system and the approach to
development used.development used.
Systems developed incrementally will, typically,Systems developed incrementally will, typically,
have less detail in the requirements document.have less detail in the requirements document.
Requirements documents standards have beenRequirements documents standards have been
designed e.g. IEEE standard. These are mostlydesigned e.g. IEEE standard. These are mostly
applicable to the requirements for large systemsapplicable to the requirements for large systems
engineering projects.engineering projects.
6

7. – 7 –
Requirements and Design
In principle, requirements should state what theIn principle, requirements should state what the
system should do and the design shouldsystem should do and the design should
describe how it does this.describe how it does this.
In practice, requirements and design areIn practice, requirements and design are
inseparableinseparable
 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. – 8 –
Tools for modeling
requirements
Use CasesUse Cases – in late 70s, my advisor wrote a tech– in late 70s, my advisor wrote a tech
paper on how to do thispaper on how to do this
State DiagramsState Diagrams
UI MockupsUI Mockups – standard process in DoD and auto– standard process in DoD and auto
industry – (Not in my kitchen)industry – (Not in my kitchen)
StoryboardsStoryboards
PrototypesPrototypes

9. – 9 –
Functional Reqs:
What should it do?
Functional Reqs:
What should it do?
Developer
connect mysql
database to
asp .net web
…
Client
sell my
beautifu
l jewelry
Customer of client
find a
cool
ring on
sale

10. – 10 –
Client
sell my
beautifu
l jewelry
Customer of client
find a
cool
ring on
sale
User-centric: What, not how
Difficult to express
Functional Reqs:
What should it do?

11. – 11 –
Modeling functional Reqs
Identify user classesIdentify user classes
Example:
jewelry store owner
buyer of jewelry

12. – 12 –
Modeling functional reqs
Identify user classesIdentify user classes
For each user class identify goalsFor each user class identify goals
Example
Buyer:
search for item
place an order
return an item

13. – 13 –
Modeling functional reqs
Identify user classesIdentify user classes
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. – 14 –
Example
Name: Order jewelry from a catalogName: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob,Actors: Customer Alice, Sales rep Bob,
Stockroom, Shipping dept.Stockroom, 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 fromAlice says she wants to place an order from
the catalogue.the catalogue.
4.4. Bob asks how the order will be paid.Bob asks how the order will be paid.
5.5. …… USE CASE

15. – 15 –
Forms of Use Cases
Casual –Casual – “user stories”“user stories”
Fully dressed use cases – preconditions, post-Fully dressed use cases – preconditions, post-
conditions, actors, stakeholders, etc.conditions, actors, stakeholders, etc.
…
these are cultural issues
but in agile methods, less is more

16. – 16 –
Key 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. – 17 –
Example: Main scenario
Name: Order jewelry from a catalogName: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, ShippingActors: Customer Alice, Sales rep Bob, Stockroom, Shipping
dept.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 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. – 18 –
Main scenario with branchesMain scenario with branches
Name: Order jewelry from a catalogName: Order jewelry from a catalog
Actors: Customer Alice, Sales rep Bob, Stockroom, ShippingActors: Customer Alice, Sales rep Bob, Stockroom, Shipping
dept.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 want to order item D23 from page 5 theAlice 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 of5a. Stockroom says it is not available. See order out of
stock item use case.stock item use case.
6. ….6. ….
Alternative path can be completed or refer to another
use case.

19. – 19 –
Use case development
Brainstorm to identify Use CasesBrainstorm to identify Use Cases
Validate/prioritize/ensure consistencyValidate/prioritize/ensure consistency
Elaborate high priority/complex use casesElaborate high priority/complex use cases →→
identify new Use Casesidentify new Use Cases
Repeat until _________________Repeat until _________________
Waterfall: until done – done keeps moving
Agile: until good enough for now

20. – 20 –
Sequence Diagram -
Alternative
Sequence Diagram -
Alternative
Alice: Customer
Bob: Sales rep Stockroom
call on phone
answers phone
wants to order
…

21. – 21 –
Example: 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. – 22 –
Elaborated Use Case
Play gamePlay game::
1.1. User choosesUser chooses “Play Game” from main menu.“Play Game” 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(point to
other UC)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 pointsPac Man hits dot but not end of level, 50 points
awarded, return to step 3awarded, return to step 3
4.b.4.b. Pac Man hits dot and level ends, 50 points awarded andPac Man hits dot and level ends, 50 points awarded and
new level starts (seenew level starts (see start new level use casestart new level use case))
4.c. Pac Man hits ghost (see4.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’t move any further in that
direction, returns to step 3 with new constraintdirection, returns to step 3 with new constraint
etc.etc.

23. – 23 –
Refined Use Case
Play game:Play game:
1.1. User choosesUser chooses “Play Game” from main menu.“Play Game” from main menu.
2.2. Start levelStart level displayeddisplayed with 3 lives and 0 scorewith 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. – 24 –
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. – 25 –
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

26. – 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
prioritized
use cases

27. – 27 –
Uses 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. – 28 –
Requirement 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 aInterative: back to a
specification #specification #
Agreed upon by customerAgreed upon by customer
How can Use Cases contribute to quality in
functional requirements?

29. – 29 –
Tools for modeling (functional)
requirements
Tools for modeling (functional)
requirements
Use CasesUse Cases
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
good for describing
“flow”

30. – 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 1
Lose level
n=0
n>0
Hits dot:
Sound effect
k increased by 50
k<MAX
Win level
Play level: initialize n=3 (#lives), k=0 (level score)
k<0

31. – 31 –
Tools for modeling (functional)
requirements
Tools for modeling (functional)
requirements
Use CasesUse Cases
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
good for describing “flow”
Better for state machines

32. – 32 –
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

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

34. – 34 –
Tools for modeling (functional)
requirements
Use CasesUse Cases
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
these are special cases of prototypes

35. – 35 –
Prototypes
Sample level with simplified art, minimal features
Use fast prototyping tools to clarify functionality, look and feel, etc.

36. – 36 –
Which model should you use?
All that are appropriate!
Invent new ones as needed!

37. – 37 –
Requirements for games
Game Designer
Management
Marketing
Users
…
Software engineers

38. – 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. – 39 –
Bottom up game specificationBottom up game specification
Use casesUse cases
State diagramsState diagrams
UI mock upsUI mock ups
StoryboardsStoryboards
PrototypesPrototypes
Make your vision “concrete”
Discover technical requirements:
• Display sprite
• Move sprite
• Detect collision
• etc.
Address feasibility
Suggest iterative design/development
strategy

40. – 40 –
Agile method: goal stack
initial top goals – risks, proof of conceptinitial top goals – risks, proof of concept
move
sprite
display
sprite
level 0
prioritized
use cases,
proofs of concept
proof of concept to
understand feasibility
use case