Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

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

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

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

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

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!!

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?

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

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”