Requirements modeling

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. sell my beautiful jewelry find a cool ring on sale Client Customer of client Functional reqs: What should it do? connect mysql database to asp .net web … Developer

7. sell my beautiful jewelry find a cool ring on sale Client Customer of client Functional reqs: What should it do? 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: • Alice calls company • Bob answers phone • Alice says she want to place an order from the catalogue. • Bob asks how the order will be paid. • … 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: • Alice calls company • Bob answers phone • Alice says she want to order item X. • Bob checks stockroom for availability. • Stockroom says it is available. • …

15. Main scenario with branches Name: Order jewelry from a catalog Actors: Customer Alice, Sales rep Bob, Stockroom, Shipping dept. Initiator: Alice Scenario: • Alice calls company • Bob answers phone • Alice says she want to order item D23 from page 5 the catalogue. • Bob checks stockroom for availability. • 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: Customer Bob: Sales rep Stockroom 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

19. Elaborated use case Play game: • User chooses “Play Game” from main menu. • Start level is displayed with player having 3 lives • User moves Pac Man left, right, up, down • 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: • User chooses “Play Game” from main menu. • Start level displayed with 3 lives and 0 score • Play level (see separate use case) • Repeat 3 on successive levels until game over

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

22. Pac Man Use Cases

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

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 Play level: initialize n=3 (#lives), k=0 (level score) Moves to empty spot Hits dot: Sound effect k increased by 50 Pac Man has n lives, score k moves left, right, up, down k<MAX n>0 k<0 Win level Hits ghost: Sound effect n reduced by 1 Lose level n=0

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 Use fast prototyping tools to clarify functionality, look and feel, etc. Sample level with simplified art, minimal features

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

34. Requirements for games Management Marketing Game Designer … 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 display sprite proof of concept to understand feasibility move sprite prioritized use cases, proofs of concept level 0 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?