1. 2. Inception 6. Use-Case Model: Writing Requirements in Context

2. 2 Introduction Use-Case Model: the set of use cases. A model of the what the system’s does “What” at 1 level is “how” at a higher level. A use case describes the system enabling a user to achieve a user goal. Use cases can be rendered at many levels of detail and formality.

3. 3 Some Terms Actor: an entity that interacts with the system Scenario is to use case as method invocation is to method: One use of the use case. In this course, we focus on the Use-Case Model Skip scenarios.

4. 4 A Use Case Is a Requirement A use-case represents a requirement. typically a functional requirement: The F of FURPS+ A Black-box use case represents what the system does, not how. what vs. how depends on the level of detail In this course, unless otherwise stated, use cases are black-box use cases.

5. 5 Formality Types Brief 1-paragraph summary of success case. Casual Multiple paragraphs, describing several scenarios besides success. Fully dressed All steps & alternatives described in detail. Includes pre- and post-conditions.

6. 6 www.usecases.org The above url contains templates for use cases. You may want to distinguish the system from each actor using different colors or fonts.

7. 7 Pre- & Post-conditions Precondition What must be true on entry to a use-case. Not tested by use-case: assumed true. Post-condition What must be true on exit from to a use-case. Basic flow Describes typical success path through use- case.

8. 8 Other information categories Alternate Flow Describes another flow through use-case Either success or failure. Using “extension” to describe this confuses its use as extending a use-case. Are use-cases system-level “methods” or system level “classes” or something else? Are they “methods” whose primitives are actor & system “methods”?

9. 9 Other information categories … Special requirements A non-functional requirement. E.g. Mandelbrot set images can be stored in a format acceptable to top quality 3 rd party lithographers.

10. 10 Use Case Level of Detail Elementary User Goal: a task that –Is performed by 1 use in 1 place at 1 time –Leaves the system in a consistent state. A source node in the use case reference graph describes an EUG.

11. 11 Reference Graph 123 45 6 7 Source nodes Arcs represent “refers to” relation

12. 12 Find the goal not the means Analyst: What is 1 goal for the POS system? Cashier: To log in quickly; to capture sales. Analyst: Higher than that? Cashier: To identify myself to the system. Analyst: Higher than that? Cashier: To prevent theft & disclosure of private information.

13. 13 Be Persistent Analyst: Higher than that? Cashier: You’re an automaton. However high you think I feel when not talking to you, it is higher than that. Analyst: Higher than that? Cashier: I’m outa here, nerdhole. Analyst: Higher than that?

14. 14 Why? Can every system be viewed as a distributed, OOS, comprising –Actors –System objects? Is requirement analysis & specification different than OOA/D?

15. 15 Primary Actors, Goals, & Use Cases 1.Choose system boundary. Where does system end & actor begin? 2.Identify primary actors. 3.For each actor, identify its goals. 4.Specify use case model satisfying user goals.

16. 16 Mandelbrot Set Visualizer http://cs.ucsb.edu/~cappello/50/projects/ mandelbrotset