October, 2013

1. Unified Modeling Language and Use Case Diagrams Donna Thomas Vice President, PMO October, 2013

2. Agenda • Intro to Unified Modeling Language (UML) • Steps to Establish Use Cases • Use Case Diagram Core Elements and Relationships • Documenting Use Cases • Use Cases in the SDLC

3. Intro to Unified Modeling Language • Object-oriented development approach • some times called OO modeling or OO techniques • Use Case Diagrams most common UML technique Source of illustration: http://www.uml-diagrams.org/use-case-diagrams-examples.html

4. Eliciting Requirements Using Use Case • Use cases came from object-oriented world and apply to general requirements analysis • Provides a method to capture user requirements • Focus on actual, but abstracted, usage scenarios • Ask Users: • “Describe a goal you wish to accomplish with the system.” • NOT: • “What do you want the system to do?” • Explore sequences of ‘actor’ actions and system responses • Derive functional requirements and tests cases

5. Appropriate Use Case Applications • Use cases work well for: • End-user applications • Web sites • Devices with which users must interact • Use cases are NOT valuable for: • Batch processes • Computationally-intensive systems • Event-driven real-time systems

6. Establishing Use Cases

7. 1- Identify Key Stakeholders • Purpose: • Identify internal and external stakeholders impacted by a proposed initiative or who share a common business need • Define stakeholder influence, authority (approve, sign off, veto), and project attitude • Define Meeting Agendas and/or Communication Plan • Determine level of effort to elicit and document requirements • Identify actors needed for User Requirements (i.e., User Stories and Use Cases) • Method: • Conduct Stakeholder Analysis • Adding stakeholders in future phases may impact scope, schedule, resources • Suggested Deliverable(s): • Stakeholder Table (User and Development Community) Most important step for Project and Process to Establish Use Cases!

8. 2- Establish the Solution Scope • Purpose: • Align internal and external stakeholders on project scope / boundaries • Define a solution scope that can feasibly be implemented • Method: • Display how system inter operates at a very high level or how systems operate and interact logically. • Develop a baseline interaction between systems and actors; actors and system or systems and systems. • Suggested Deliverable(s): • Context Diagram or Use Case Diagram

9. Context Diagram or Use Case Diagram - Which one is better? Latinitas Use Case Diagram • Context diagram from a DFD and/or a Use Case Diagram are often used to set the boundaries for a solution Latinitas Context Diagram

10. 3 - Identify the Actors • Purpose • Identify Actors (users or systems with behavior) • Primary- a user who calls on the system to deliver a service • Supporting/Secondary - provide a service to the system under development (e.g., printers, web services, people who gather information for a user) • Actors must be able to make decisions, but need not be human • Identify missing Stakeholder Roles • Method • Actor names are generally role names • Translate Stakeholders Table into Actors • Document the profiles of actors (with respect to the system/solution under development) helps to make use cases consistent • Multiple roles may become a single actor • Suggested Deliverable(s) • Actor Profile Table • Actor Profile Characteristics

11. Questions to Help Identify Actors • Who Uses the system directly? • Who gets information, reports, or messages from the system? • What systems or web services get/provide information or messages from/to the system? • Who starts up or operates the system? • Who maintains the system? • Who shuts down the system? • What other systems use this system? • What other systems interact with this system? • Who (or what) provides information to this system? • Does anything happen automatically at a present time?

12. Actor Profile Table Example Multiple Roles may become a single Actor Single Role may become multiple Actors

13. Actor Profile Characteristics

14. Actor Profile Example

15. 3 - Identify the User Interactions with a System • Purpose: • Identify goals that clearly express why a specified actor performs a particular task • Identify WHO will interface with the system (actors) and WHAT functionality is included in the system (use cases) • Solidify SCOPE of the project with a defined set of Actors and Use Cases • Method: • Establishing User Interactions with a System may require multiple process modeling tools to understand a customer’s business process • Data Flow Diagram • Use Case Diagram • Process Flow Diagram • Suggested Deliverable(s): • Use Case Diagram • Use Case Catalog

16. Multiple Process Modeling Tools to Define User Interactions • Process Flow Diagram (PFD) • Schematic representation of a process • Breaks a process down to a finite number of steps that get executed one at a time • Explains when a decision is required in the system, and what next process steps must be executed based on a decision • Does NOT focus on inputs and outputs and why each process step is performed • Data Flow Diagram (DFD) • Provides a functional view from a system perspective • Shows HOW a system's environmental entities, processes, and data are interconnected • Shows flow of data through a system and models processes to define scope boundaries • Does NOT show the strict order of execution steps (unlike Process Flows) • Use Case Diagram (UCD) • Provides a functional view from an Actor’s perspective • Shows the use cases and actors in a system, and the relationships between them • Shows WHAT the system is and HOW actors interact with the system • Does NOT explain how business requirements can be accomplished–hence, Use Cases

17. Problem Definition Process Flow Diagram that identifies User Interactions with System

18. Mixing Data Flow Diagram (DFD) Techniques with Use Case Diagrams (UCD) • A Context diagram is functionally decomposed into DFD processes, entities, and data • A DFD drills down to define how a system is interconnected and defines system processes • A UCD shows what the system is and how actors interact with the system • System processes are not same as Use Cases, and difficult to draft a UCD without DFD Processes highlighted in Yellow are for the Volunteer

19. Use Case Diagram (UCD) - Core Elements and Relationships

20. High Level Use Case Diagram Example • Event (use case) names are verb-object like DFD processes and represent user goals not system functions • No data stores • Focus is on WHAT interactions an Actor (system users) requires with the system • No arrow heads for lines connecting actor and use case, since considered two-way • Each Use Case can include another Use Case's functionality or extend another Use Case with its own behavior. Figure 3 in UML-Use Case reading today

21. Use Case Examples • Use cases do NOT describe: • User interface designs • Technology solutions • Application architecture • algorithm or mathematical requirements • Use cases describe: • User goals • User’s view of the system • A set of task-related activities Good Examples of Use Case Names • Intuit QuickBooks “activities”: • Write a Check - Create an Invoice • Enter Credit Card - Charge Receive Payment • Amazon.com options for an accepted order: • Check Order Status - Change Shipping Options • Cancel Unshipped Items - Track Package • Buy a product online: • Search Catalog • Place Item in Shopping Cart • Pay for Items in Shopping Cart

22. Use Case Catalog Example These Columns assist with Estimating, Planning, and Tracking

23. 4 - Document each Significant Use Case Basic Structure and Components • Use Case Name • Revision History / Owner • Brief Description (Actor’s Goals) • Primary & Secondary Actors • Assumptions • Pre-Conditions • Post-Conditions • Triggers • Main Course of Events (basic flow) • Alternate Paths • Exception Paths (or error handling) Additional Components • Special Requirements • Business Rules • Dependencies • Open Issues • Response Time • Frequency of Use • Data Sources * * Suggest keeping data sources in the use case until they are signed off by the user. After approval, create a data dictionary

24. Key Components of a Use Case – Documenting the “Flows” Use Case name: Login to the system Basic flow of events: Successful login • 1. User launches the login screen. • 2. User enters a combination of username and password. • 3. System validates the combination and logins the user successfully. Alternate flow A: Incorrect username/password combination • A.3. System validation of the username/password combination fails due to incorrect entry. • A.4. Systems asks the user to re-enter the username/password combination. • A.5. Go back to basic flow 2. Exception flow B: User record does not exist in the database • B.3. System validation finds that the user record does not exist in the database. • B.4. Systems alerts the user that their record does not exist. • B.5. Use case ends.

25. Use Cases in SDLC Use Case Diagramsaid in analysis and documentation of high level businessrequirements for scope & stakeholders Use Cases aid in defining functional requirements and evaluating Change Requests Use Cases aid in designing wire frames, process flows, etc. Use Cases aid in user acceptance testing (UAT) Use Cases aid in creating test cases and user manuals

26. Visio Software and Database Category

27. Q&A

28. Use Case Exercise Using your Stakeholders Table and any other resources available-- • Create a high level Use Case Diagram for your project. (See example in the reading for today—UML-Use Cases; Figure 3 is an example of a High Level Use Case.) • Create a drill down Use Case Diagram of one of the use cases in your #2 High Level Use Case Diagram. (See example in the reading for today—UML-Use Cases; Figure 4 is an example of a Drill Down Use Case.)