Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements modeling. Last lecture Good requirements are crucial Specifying requirements is hard.

Similar presentations


Presentation on theme: "Requirements modeling. Last lecture Good requirements are crucial Specifying requirements is hard."— Presentation transcript:

1 Requirements modeling

2 Last lecture Good requirements are crucial Specifying requirements is hard

3 Today Techniques for developing functional requirements What the software is supposed to do!

4 Requirements modeling We build models in requirements analysis to understand –current systems or business processes –how users will use a new system

5 Tools for modeling requirements Use Cases State Diagrams UI Mockups Storyboards Prototypes

6 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

7 Functional reqs: What should it do? Client sell my beautiful jewelry Customer of client find a cool ring on sale User-centric: What not how

8 Modeling functional requirements Identify user classes Example: jewelry store owner buyer of jewelry

9 Modeling functional requirements Identify user classes For each user class identify goals Example Buyer: search for item place an order return an item

10 Modeling functional requirements Identify user classes For each user class identify goals For each user class/goal –Describe how the user will use the system

11 Example Name: Order jewelry from a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: 1.Alice calls company 2.Bob answers phone 3.Alice says she want to place an order from the catalogue. 4.Bob asks how the order will be paid. 5.… USE CASE

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

13 Key aspects of use case Name: what we call this use case Actors: entities that interact with system (typically people but also can be other systems) Initiator: actor who initiates the use case Scenario: sequence of steps users take and how system responds

14 Main scenario Name: Order jewelry from a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: 1.Alice calls company 2.Bob answers phone 3.Alice says she want to order item X. 4.Bob checks stockroom for availability. 5.Stockroom says it is available. 6.…

15 Main scenario with branches Name: Order jewelry from a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: 1.Alice calls company 2.Bob answers phone 3.Alice says she want to order item D23 from page 5 the catalogue. 4.Bob checks stockroom for availability. 5.Stockroom says it is available. 5a. Stockroom says it is not available. See order out of stock item use case. 6. …. Alternative path can be completed or refer to another use case.

16 Sequence diagram Alice: CustomerBob: Sales repStockroom call on phone answers phone wants to order …

17 Use case development Brainstorm to identify use cases Validate/prioritize/ensure consistency Elaborate high priority/complex use cases  identify new use cases Repeat until _________________ Waterfall: until done Agile: until good enough for now

18 Example: Pac Man Use Cases ActorGoalPriority UserPlay game1 UserInitialize game1 UserView high scores3 UserSet level3 UserPause game2 UserExit game2 UserSave game3 UserChange Controls4 UserPlay saved game3

19 Elaborated use case Play game: 1.User chooses “Play Game” from main menu. 2.Start level is displayed with player having 3 lives 3.User moves Pac Man left, right, up, down 4.Pac Man moves to empty space, return to step 3 4.a. Pac Man hits dot but not end of level, 50 points awarded, return to step 3 4.b.Pac Man hits dot and level ends, 50 points awarded and new level starts (see start new level use case) 4.c. Pac Man hits ghost (see hits ghost use case) 4.d. Pac Man hits a wall, can’t move any further in that direction, returns to step 3 with new constraint etc.

20 Refined use case Play game: 1.User chooses “Play Game” from main menu. 2.Start level displayed with 3 lives and 0 score 3.Play level (see separate use case) 4.Repeat 3 on successive levels until game over

21 Refined use case (no UI spec) Play game: 1.User chooses to play game 2.First level starts with 3 lives and 0 score 2.Play level (see separate use case) 3.Repeat 3 on successive levels until game over

22 Pac Man Use Cases ActorGoalPriority UserPlay game1 UserPlay level1 UserInitialize game1 UserView high scores3 UserSet level3 UserPause game2 UserExit game2 UserSave game3 UserChange Controls4 UserPlay saved game3

23 Agile method: goal stack highest priority, best modeled use case lowest priority, least modeled use case prioritized use cases

24 Uses of use case Requirements: –Define functional requirements –Expose business rules (constraints on behavior) Planning: Suggest an iterative strategy Design: Validate design models Testing: Provide scenarios for validation

25 Requirement Quality Specify what not how Unambiguous Testable Feasible Consistent Prioritized Traceable Agreed upon by customer How can use cases contribute to quality in functional requirements?

26 Tools for modeling (functional) requirements Use Cases State Diagrams UI Mockups Storyboards Prototypes good for describing “flow”

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

28 Tools for modeling (functional) requirements Use Cases State Diagrams UI Mockups Storyboards Prototypes good for describing “flow” better for state machines

29 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.

30 Storyboards Good for communicating “look and feel” in addition to “flow” (again addressing non-functional requirements)

31 Tools for modeling (functional) requirements Use Cases State Diagrams UI Mockups Storyboards Prototypes these are special cases of prototypes

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

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

34 Requirements for games Game Designer Management Marketing Users … Software engineers

35 Top down game specification High concept Competitive analysis Main character Game Mechanics Underlying models Major features Look and feel Scoring UI etc. Traditional Game Design Document “Game Bible”

36 Bottom up game specification Use cases State diagrams UI mock ups Storyboards Prototypes Make your vision “concrete” Discover technical requirements: Display sprite Move sprite Detect collision etc. Address feasibility Suggest iterative design/development strategy

37 Agile method: goal stack move sprite display sprite level 0 prioritized use cases, proofs of concept proof of concept to understand feasibility use case

38 Next Time Design practice Reading/watching –McConnell –UML tutorial (several pages, do it all) –Youtube: Will Wright 13:00-30:00

39 Next Assignment Game Design Document Review the assignment and come prepared next time to ask questions! This is not a 3-hours-the-night-before-it-is-due- assignment. Use the remainder of class to begin to PLAN who is doing what and issuing tickets.

40 Sample questions Why do we want to classify users? What are use cases? What are their benefits? Shortcomings? What are key components to a use case? How can use cases be employed throughout the project? What is a sequence diagram and when is it useful? How does UI design fit into the requirements process? Why do we use prototypes in the requirements process?


Download ppt "Requirements modeling. Last lecture Good requirements are crucial Specifying requirements is hard."

Similar presentations


Ads by Google