1. Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional, block-box view) requirements – Include information for other models such as exceptions, concepts, terminology, constraints, etc. n Simple, easy to show to clients, emphasize client/user’s perspective n Example – Process Sale in POS system Customer arrives at the cash register. Cashier starts new sale…

2. Copyright ©2004 Cezary Z Janikow 2 Use Case Elements n Actor – Entity with behavior, usually external to our system (some are more obviously external others not) Can be live, or other system, but must be physical Primary – has goals fulfilled in the course of use case Supporting – provides supports such as external systems Offstage – has interest in the system’s behavior n Scenario (use-case instance) – A sequence or actions and interactions between actors and the system in the course of particular story, transaction, or use of the system n Use Case – A collection of related scenarios, some successful some exceptional or failures, describing actors interacting with the system to support a specific goal

3. Copyright ©2004 Cezary Z Janikow 3 Use Case Example n Returns in POS – Main scenario: Customer returns an item within 30 days with the original package and cash receipt – pay back the cash – Extensions: Alternatives: Customer paid by a credit card, or does not have the receipt Exceptions: Item not purchased in the store

4. Copyright ©2004 Cezary Z Janikow 4 Use Case Model n Use Cases – Text n System Sequence Diagrams – Actor-system interfaces and message sequencing n Contracts – Descriptions of change of state in the System n Use-case Diagrams – Relationships among uses cases and actors

5. Copyright ©2004 Cezary Z Janikow 5 Use Case model Influence

6. Copyright ©2004 Cezary Z Janikow 6 Use Case Formats n Brief – One paragraph summary – Useful during inception and early analysis in general to identify scope and risks n Casual – More detailed but still in early stages n Fully Dressed – All steps, scenarios, exceptions, special requirements, etc. – Needed in Inception for the important use cases to establish glossary, extract concepts, assess risk – Needed in Elaboration/construction when iterating on

7. Copyright ©2004 Cezary Z Janikow 7 Use Case Example n Fully dressed Process Sale – See the textbook for a template and the actual use case

8. Copyright ©2004 Cezary Z Janikow 8 Use Case Goals and Levels n It is important to identify all stakeholders and assess their goals – The purpose of Use Case is to address these interests – All relevant should be there – Not irrelevant should be there n User-goal level – Elementary Business Process EBP – Fulfillment of primary actor’s goals n Subsystem level – Not complete EBP, such as pay by credit (payment is only a part of sale)

9. Copyright ©2004 Cezary Z Janikow 9 More on Use Cases. n Preconditions and Postconditions n Special requirements: related non-functional n Two-column format – More visual and comprehensible Actors doesSystem does n Templates – www.usecases.org www.usecases.org n Avoid UI details early on – Essential: item is recognized – Concrete: UPC bar code is scanned with optical scanner Avoid early on

10. Copyright ©2004 Cezary Z Janikow 10 How to Identify Use Cases n Choose system boundary – Is the cashier an actor or system? – Is Credit authorization our responsibility?

11. Copyright ©2004 Cezary Z Janikow 11 How to Identify Use Cases n Find all primary actors and their goals – Who does what or needs what? Rather than asking “what you do” ask “what is your role, goal, interest” – Analyze events n Remember stakeholders and their goals – Cashier wants easy processing while management wants efficient and secure processing n Keep track of these findings separately for reference

12. Copyright ©2004 Cezary Z Janikow 12 How to Identify Good Use Cases n Boss test – Can you excuse your time doing THIS? n EBP test – Is it well defined process starting with some external need/event and leaving the state consistent? n Size test – Remember that use case(s) will be processed in your time boxes

13. Copyright ©2004 Cezary Z Janikow 13 Use Case Diagrams

14. Copyright ©2004 Cezary Z Janikow 14 Use Case Diagrams

15. Copyright ©2004 Cezary Z Janikow 15 Use Case Diagrams

16. Copyright ©2004 Cezary Z Janikow 16 Activity Diagrams n In requirements analysis it may be useful to have other views: – Dataflow – Process (control flow) n These are expressed with Activity Diagrams Chapter 28

17. Copyright ©2004 Cezary Z Janikow 17 Activity Diagrams