1. 1 Dilbert Scott Adams

2. 2

3. 3

4. 4 Writing Effective Use Cases, Alistair Cockburn Use Cases: Requirements in Context, Daryl Kulak Applying Use Cases: A Practical Guide, Geri Schneider; Jason P. Winters References

5. 5 Representing the System Requirements RECAP Use cases represent the features that are seen by the system’s users. Users are the “actors” and the requirements are the “use cases” specifications.

6. 6 Actors and Use Case Examples Order-Processing Actors: –Customer –Customer Rep –Shipping Company –Clerk –Inventory System –Accounting System Defines system boundary… what is outside the system? The Actors.

7. 7 Use Cases Use Cases that “serve” the Customer: –Place order –Send order –Get status on order –Return product –Cancel order –Register Complaint

8. 8 The Complete Use Case The “Use Case” specs: –What must be done to deliver the “use” to the “user”. –Specify: Basic functionality Alternatives Error conditions Any and all preconditions Postconditions (Refer to Appendix B in the SRS)

9. 9 Example: Place Order Use Case Precondition: valid user logged into system. Basic path: 1.Begin with customer selecting Place Order 2.Enters name and address 3.If zip is entered, system supplies city & state … 10.When payment is confirmed, mark order confirmed, return order ID to customer, and use case ends Postcondition: the order is saved and marked confirmed.

10. 10 Specifying a Use Case The Basic path example is one approach. Everything in one place… Continue refining adding branching or alternative flows… to show: 1.Other alternatives 2.Error handling

11. 11 Alternative Paths Examples: 1.At any time before selecting Submit, Customer can select Cancel. If Cancel is selected, the order is not saved and the Use Case ends. 2.In Step 7, if any information is incorrect, system is to prompt user to correct information

12. 12 Branching - Example Find Order Use Case 1.User enters order ID, customer ID, or name. 2.User selects Find. 3.If user entered order ID a)Display that order 4.If user entered customer name or ID a)Return list of all orders for that customer b)User will select one order from the list c)Display that order

13. 13 Repetition Examples Place Order Use Case: 4. For each product code entered: a) Supply product description and price b)Add price to the total OR 4.While customer enters product codes: a)Supply product description and price b)Add price to the total

14. 14 Expanded, complex Use Cases Think of the “actor” as representing a class… with objects being specific instances of the class. Each instance may interact differently… does your Use Case specify how each instance will be responded to? The Basic path represents the response to the most common instance… and is called the primary scenario.

15. 15 Secondary Scenarios Add alternatives to the Basic case Write separate flows of events to represent an alternate scenario Place Order –scenarios for each case: 1.Order arrives that is complete, with correct payment 2.Order arrives missing payment 3.Order arrives missing shipping address

16. 16 Finding Secondary Scenarios Walkthrough primary scenario and ask: Can more than one action be taken at this step? Can something go wrong at this step? Can something happen at any time? Give each a secondary scenario name.

17. 17 Adding “easy to understand” detail Techniques: –Extends (or Uses) use case X is optionally extended by the functionality of use case Y –Includes use case X always includes use case Y –Interfaces –Inheritance > XY XY

18. 18 Optionally Extends or Uses Place Order > Seasonal Sale Price Frequent Customer Discount Extension Points: Seasonal Sale Price, before Step 5 Frequent Customer Discount, before Step 6 > may never take place!!! … it depends.

19. 19 Always Includes Find Order Cancel Order > Factor out common behavior … can be re-used in other use cases

20. 20 > The “extending use case” defines logic that may be required during a given set of steps in the parent use case. Continues the behavior of the parent use case by conceptually inserting additional action sequences Used when an alternate course of action is complex Note: The parent use case could include this behavior

21. 21 > Represents one use case “invoking” another –Example: use case that encapsulates common logic required by several use cases. Represent dependencies between use cases –Dashed line is used

22. 22 Inheritance NOT between use cases… but between actors!! Customer Customer Rep Here, Customer Rep inherits the same role as the Customer.

23. 23 Interface Describes how to interact with the actor or the use case. The interface specs are a set of operations. Specify for each operation: –What is passed –What is returned Actor or Use Case supporting the interface Actor or Use Case using the interface

24. 24 Example of Interfaces Place Order User interface Place order interface Customer Rep Customer

25. 25 Place Order Interface - example Supported by Place Order use case - and used by the Customer. 1.Get Product Description and Price (Product ID) return Description, Price 2.Add Price to Total (Price) return Total 3.Submit Order ( ) return Order ID, Where Description, Price, Total, and Order ID used by Customer

26. 26 User Interface - example Supported by Customer and used by Place Order use case. 1.Enter Name_and_Address ( ) return Name, Address 2.Enter Product_Code ( ) return Product Code 3.Enter Credit_Card_Info ( ) return Credit Card, Expiration Date Name, Address, Product Code, Credit Card, and Expiration Date used by Place Order.

27. 27 Diagramming Use Cases Activity Diagrams (Flow Charts) –Documents the steps in a Use Case Storyboarding to show the sequence of events from the user interface perspective

28. 28 Storyboarding Designed to show the user interface. Not what it will look like, but the user’s “steps” in supporting the use case. Objectives: 1.Clarify what is happening from the user’s point of view. 2.Get early acceptance from user of interface design. 3.Ensure that all required data attributes are identified and specified.

29. 29 What information is needed? Place Order Place order interface Customer ? ?

30. 30 Collecting your data specs… Reference for transparencies Computer Information Systems Development: Analysis and Design Michael Powers David Adams Harlan Mills

31. 31 Order Status S toryboard - Prototype You are not asking for feedback on the GUI Design!

32. 32 Know How To Uncover Reality “… if I was designing and building an application used to track sales trends for the Sales department in my company, my first instinct, if I decided to research my users, would be to hunt down Molly from Sales and ask her what she would like the application to do… Molly has no idea what your software might be able to do, and she almost certainly doesn’t have the technical chops to explain it.

33. 33 She likely doesn’t realize that your product could make the task of creating a client birthday list for mailing out discount coupons a matter of two clicks, and therefore, she would never mention that this task is particularly gruesome and ask if your software could do it for her. Thus, you need to look a little deeper to find out what Molly needs.

34. 34 If you want to know what Molly wants the software to do, don’t ask her directly. Instead, find out what she does, how she does it, and what she will want to do later. Eventually, you’ll figure out how all that translates into a Web application. For now, don’t think about Web applications. Think about users.

35. 35 Developers tend to want to put up dialog boxes and error messages and all sorts of intrusive widgets that explain what’s going on behind the scenes, but users don’t care. They only want to know the thing is working so they can accomplish their goals.

36. 36 A user’s goals live outside the application. The goals are personal. Very few users have a goal of understanding how PeopleSoft works. That goal is usually encapsulated by a larger goal. Perhaps Molly wants to earn a promotion at work and thinks that understanding PeoplsSoft better will enable her to be more productive. The application itself is not a goal at all – it’s an obstacle between Molly and her goal.

37. 37 Acknowledging that the user’s goals have nothing to do with your Web application allows you to design something that pays more attention to the user’s real goals… Goal-directed design means listening to users, getting to the truth of what they want, and creating applications from a more informed perspective.” Designing the Obvious Robert Hoekman, Jr. Recommended!