1. SWENET.org1 Applying Use Case Templates Paul Grabow - Baylor University Stephen Frezza – Gannon University

2. Version 4 SWENET.org 2 Introduction Who is the audience for this presentation? Students who have Read about use cases Discussed use cases in class What is the purpose of this presentation? To learn how to apply a use case template Not to give a comprehensive intro to use cases

3. Version 4 SWENET.org 3 Some References Cockburn, Alistair,“Structuring Use Cases with Goals”, Journal of Object-Oriented Programming, Sep-Oct 1997 & Nov-Dec 1997. Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley, 2001. Fowler, M., UML Distilled (3rd ed.), Addison Wesley, 2004. Jacobson, Ivar, Object-Oriented software engineering: A Use- Driven approach, Addison-Wesley, 1992. Larman, C., Applying UML and Patterns (3rd ed.), Prentice-Hall, 2005.

4. Version 4 SWENET.org 4 Use Case: Purpose To uncover and record functional requirements To serve as vehicle of communication between customer and contractor during requirements definition Not to record non-functional requirements

5. Version 4 SWENET.org 5 Use Case: Vantage Point From “outside” the system As an observer of the system System viewed as “black box”

6. Version 4 SWENET.org 6 Use Case “Pieces” Name Name: Verb phrase that represents the goal Scope Scope: {Enterprise, System, Subsystem} Named Level Level: {Summary/ System, User, Sub function } Pre-condition Pre-condition: Assumed to be true when UC begins Success/Failure End Conditions Success/Failure End Conditions: Must be true (or false) after the UC finishes Primary Actor Primary Actor: Who (or what) initiates the UC Stakeholders & Interests Stakeholders & Interests: Who & why they care

7. Version 4 SWENET.org 7 Use Case “Pieces”, cont. Triggers, Guarantees Triggers, Guarantees: What event starts UC, what system promises to provide/do Main Success Scenario Main Success Scenario: Sequence of goal- achieving actions Extensions/Variations Extensions/Variations: Conditions plus actions/steps to handle branching conditions with respect to any step in main success scenario Related Information Related Information: Performance target, open issues, schedule, super-use cases, sub use cases

8. Version 4 SWENET.org 8 Use Case Template From Alistair Cockburn See http://alistair.cockburn.us/usecases/usecases.html

9. Version 4 SWENET.org 9 Constructing a Use Case 1.Identify Actors & Goals List the actors and the goals that the system will support 2.Identify System Success (and Failure 2.Identify System Success (and Failure) Identify main goal (that adds value for the stakeholders) Success: equivalent to the main goal; failure: inverse of success 3.Define Main Success Scenario Describe ordered series of actions that achieve main goal for typical actor (with no branching)

10. Version 4 SWENET.org 10 Constructing a Use Case, cont. 4.Identify Extensions and Sub-variations To cover branching and I/O alternatives And superordinate and subordinate use cases 5.Identify Related information Performance target Open issues Schedule

11. Version 4 SWENET.org 11 System Success & Failure Success Defined with respect to the stakeholders Often broader than the goal of the primary actor System Directly responsible for success (or failure) Cannot be responsible for what it cannot control Actor(s) Not directly responsible for success (or failure) because not part of system

12. Version 4 SWENET.org 12 Example: Create Bank Account Goal in Context: Existing customer requests new bank account Scope:A single bank Level:Primary Pre-condition:None Success End Condition: If customer ID is valid, then Bank account established Failed End Condition: Bank account not established when customer ID valid or bank account established when ID invalid

13. Version 4 SWENET.org 13 Example, cont. Primary Actor:Teller Stakeholders:Bank employees and customers Trigger Event:Teller asks system for new account

14. Version 4 SWENET.org 14 Example, cont. Main Success Scenario Actor ActionSystem Action 1. Request new account 2. Determine if ID valid 3. Generate new account 4. Return new account number 5. Reads new account number

15. Version 4 SWENET.org 15 Example, cont. Extensions ConditionAction 3a. Invalid IDNotify user: “Invalid ID”

16. Version 4 SWENET.org 16 Example, cont. Sub-variations 1. Teller may enter ID by a. Typing on a keyboard b. Speaking into a microphone c. Scanning a written form 2. Teller may read account number on a. Computer screen b. Paper printed by the system

17. Version 4 SWENET.org 17 Example, cont. Superordinate use case: None Subordinate use case: IsIDValid GenerateNewAccount

18. Version 4 SWENET.org 18 Example, cont. What would be some possible Performance targets? Open issues? Schedule

19. Version 4 SWENET.org 19 Suggestions Iterate Iterate: For each UC Not all information will be known/learned at the same time Okay to leave some things blank Several iterations typical A refinement process More detail added over time

20. Version 4 SWENET.org 20 Suggestions, cont. After first version of scenario, can you … Split some actions for clarity? Partition actions that should be developed together, or written later? Identify a group of actions that should be a separate use case? Still claim that system is a black box?

21. Version 4 SWENET.org 21 Suggestions, cont. Check scope Is scope consistent with scenario? Should scope be expanded? Restricted? After several iterations of defining scenario, identify EXTENSIONS SUB-VARIATIONS Superordinate Use Case: Subordinate Use Cases:

22. Version 4 SWENET.org 22 Suggestions, cont. After completing extensions and sub- variations fill in Performance Target: OPEN ISSUES SCHEDULE

23. Version 4 SWENET.org 23 Summary Use case Purpose: To identify functional requirements To server as vehicle of communication Vantage point: From outside system System as a black box Use case template provides “Check list” Uniform format