Requirement modeling
Download as PPT, PDF6 likes3,659 views
Modeling requirements involves developing functional requirements from customer views into something translatable to software. Techniques like use cases, state diagrams, UI mockups, storyboards and prototypes are used to understand current systems, business processes, and how users will interact with new systems. The software requirements document specifies what is required of the system and should focus on what the system should do rather than how. Requirements modeling is iterative and requirements change in agile methods.
Requirement 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