requirement modeling
Post on 20-Jan-2015
178 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
Identify user classesIdentify user classes
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
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 –
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.
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 –
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.
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 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
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
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
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
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 –
StoryboardsStoryboards
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
State DiagramsState Diagrams
UI MockupsUI Mockups
StoryboardsStoryboards
PrototypesPrototypes
these are special cases of prototypes
– 35 –
PrototypesPrototypes
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
StoryboardsStoryboards
PrototypesPrototypes
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
top related