Business Requirements Analysis ITEC-630 Fall 2010

1. Business Requirements AnalysisITEC-630 Fall 2010 Use Case Analysis Prof. J. Alberto Espinosa

2. Objectives • Introduction to Context Diagrams • Introduction to Use Case modeling • Transitional Artifacts • Initial, Base and Elaborated Use Cases • Extended Use Cases • Refactoring: Included Use Cases

3. The Big Picture Business Process Analysis Figure out what the application will to do to support these processes (and the system qualities) InformationAnalysis Functional and Non-Functional System Requirements Analysis

4. System Vision & Concept • Vision: what is the purpose of the system? • Business case: what business problem does it solve? “the work” • Development case: what artifacts to use in analysis? • Who is the client? i.e., who’s paying for the system? • Who are the customers? i.e., who will buy the system? • Who are the stakeholders? i.e., who has a vested interest in the system? who will be affected by the system? • Who are the users? i.e., who will operate the system? • Other relevant facts, assumptions and constraints • Project glossary • Rough estimation of costs and risks

5. The Context Diagram

6. The Context Diagram • Not a use case artifact, but very useful for a high level overview of the system • It is a representation of the system boundary and all the actors that interact with the system • It has a long history with various modeling methods for systems analysis • If drawn and formatted nicely, it provides a nice depiction of the system up front • It provides a simple high level view of the system • It helps visualize: • What is inside and what is outside the system boundary • Who are the actors that interact with the system • Which actors are human and which are external systems • What are the basic information flows into and out of the system

7. The Context Diagram: The System It’s Boundary The Actors Information Flows

8. The Meaning of Arrows in Context Diagrams Meaning of the direction of arrows = information flow • Arrows from actor to the system represent actors supplying information to the system • Arrows from system to the actor represent the system returning information to the actor • Double-headed arrows represent both actor and system exchanging information with each other • The arrows should contain text with a brief description of the information flow being exchanged

9. Context Diagram Example Enters account and transaction information &gets transaction confirmation receipts Gets ATM statusinformation ATM Service Customer ATM System Another System Getscustomeractivityinformation Gets customertransactiondata Customer Accounts System Bank Manager

10. Use Cases

11. Use Cases • Introduced in 1986 by Ivar Jacobson (1 of 3 amigos) • As a supplement to object modeling • Central artifact of the UP • An important aspect of the UML • Purpose: to capture, document and communicate requirements • Essence: discover and record functional requirements by writing stories about using the system to fulfill stakeholders’ goals • Use cases describe a system from the actors’ perspective

12. Why/Where AreUse Cases Useful • Help find, record and communicate the system’s behavioral (i.e., functional) requirements (not all) • Use cases describedistinct processes that will be handled by the system, and the events that trigger these processes, so it is a great tool to model how a system will provide a solution consistent with the BPM. • Fosters good communication with stakeholders • Intuitive, text-based tool, easy to understand • And with system designers/developers • Reference for testing and quality reviews • Good for system documentation • Good for end-user training

13. Definition • A Use Case: “a sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the system” – Jacobson, 1995i.e., a collection of scenarios that describe actors using a system to support a goali.e., a behavior of the system that produces a result of value to the actor

14. Key Aspects ofUse Case Modeling • Identify system boundaries • Identify system actors: something (human or non-human) that has behavior and interacts with the system • Identify actors’ goals for the system • Identify business events that fulfill these goals • Model (success/failure) scenarios for these events • Write use cases to document these scenarios

15. Use Case Diagram Illustration SystemBoundary (External)HumanActors (External)SystemActor (Internal)Use Cases Note how some arrows in this diagram have different direction than in the context diagram because arrows have a different meaning in use case diagrams!!

16. Actors

17. Actors • An actor is “anything outside of the system that exchanges information with it, including users and other systems” – Armour et. al. 2001 • An actor is “an entity that interacts with the system for the purpose of completing an event – Jacobson 1992 • Actors play roles (e.g., client, salesperson, etc.) • An actor is not a person, but the role the person plays • A person can have many roles (e.g., user, manager) • And a role can be played by many persons (e.g., clients) • An actor can be a person or any (non-human) external entity (e.g., external system, device, external service organization) that the system will interact with

18. Importance of Actors • Systems need to provide value to actors– i.e., identifying actors help find use cases • Actors help analysts focus on how the system will be used, not how it will be implemented • Actors are external to the system, so they help define the boundary of the system

19. Actor Types • Primary Actor: one who receives value from the system • You need to identify all primary actors upfront because the goal of your system is to deliver value to these actors • Secondary Actor: one who provides service to the system in one or more use cases • i.e., helps create value for primary actors • i.e., would not exist without primary actors or system • You can discover these later because your system doesn’t need to fulfill their goals

20. Actor Personalities • Initiator: an actor who initiates events that trigger a use case (e.g., customer places an order) • External Server: an actor who provides a service to the system in the use case (e.g., query to a credit bureau to process a loan) • Receiver: an actor that receives information from the use case (e.g. IRS receives corporate tax return) • Facilitator: an actor that supports another actor’s interaction with the system (e.g., data entry clerks)

21. Actor Specification Card

22. Finding Use Cases • List all goals for all primary actors(e.g., obtain a loan, obtain banking services) • Identify business events that will accomplish these goals (e.g., apply for a loan, withdraw cash) • Each business event or goal that yields observable value to a primary actor maps to a use case • Actor specification cards are useful for this • As we will see next week, goals are not always fulfilled by the system (e.g. ATM has no cash), so Use Cases need to model “sunny day” (i.e., optimistic) and “rainy day” (i.e., pessimistic) scenarios.

23. A Use Case Model • Is a complete set of artifacts of the use cases describing how actors interact with a system • Artifacts are any diagrams, models, cards, tables, documents and other descriptions that define and describe the system requirements • We will focus on two artifacts initially: diagrams and textual descriptions • The use case model should fully describe the entire “functional scope” of the application • Each use case within a use case model has its own smaller functional scope, which encompasses the functional responsibility of the use case • Collectively, all use cases combined should encompass the entire functional scope of the system (i.e., the whole is equal to the sum of the parts).

24. Main Use Case Model Artifacts • Context Diagram:not really! part of a formal Use Case Model, but it is often included because it provides a great high level representation of the system • Use Case Diagram: shows the system boundary, actors and all use cases involved • Activity Diagrams: use case descriptions (below) are some times diagrammed using this type of UML artifact • Use Cases: text descriptions that describe all possible scenarios of how actors interact with the system to deliver the required system functionality (i.e., functional scope).

25. Use CaseDiagrams

26. Actor Actor Actor UseCase UseCase UseCase Use Case Diagram Symbols System Triggered Event Actor initiatesinteractionwith thesystem System Boundary

27. Actor initiatesthe use case UseCase UseCase Meaning of the Direction of Arrows • Arrows have a DIFFERENT meaning in Use Case Diagrams than in context diagrams • Direction of arrows DO NOT represent information flow • Instead, they indicate WHO INITIATES the use case The system initiatesthe use case

28. User initiatesuse case UseCase UseCase UseCase UseCase Direction of Arrows Human Actors External System Actors H S External system initiates use case: rarely happens  external system must have this capability H S Internal system initiatesuse case Internal system initiates use case:happens often  the use case needsdescribe how it interacts with the external system

29. Actor Actor Actor UseCase UseCase UseCase Use Case Diagram Symbols System Triggered Event Actor InitiatedEvents System Boundary

30. An Example:A Loan Application System

31. TransitionalArtifacts

32. Transitional Artifacts • Help associate two different artifacts – it can be difficult to figure out how components of two artifact relate to each other • You can build a transitional artifact for any pair of artifacts, e.g.: • Business Process Model / Use Case Model • Use Case Model / Data Model • This can help keep track of things and ensure that no artifact component is superfluous. • It also helps make your artifacts more cohesive with each other • There are different types of artifacts, but one of the most popular is a transition matrix or table containing: • One row for each component of one artifact • One column for each component of the other artifacts • Some notation or explanation in each cell about how particular components from one artifact relate to the components of the other

33. BPM/Use Case Transitional Matrix No process steps associated with this UC • It has one row (or column) for every BPM process step and decision • And one column (or row) for every use case in your solution • Mark or make annotations in each cell in which a given BPM process step or decision is associated with a particular use case • All empty rows should be manual steps No use cases associated with this process step

34. Example: BPM – Car Rental Process

35. Example: Use Case ModelCar Rental Application

36. Example: BPM/Use Case Transitional Matrix M=Manual; S=System; C=Current; N=New

37. The Use CaseModeling Process

38. The Use CaseModeling Process Prepare for Use Case Modeling Initial Use Case Modeling Expand Use Case Model Test Use Cases & Doc Organize the Use Cases Ongoing Use Case Management

39. The Use Case Modeling Process  Identify the Major Actors Develop Base Use Case Descriptions   Develop Context Diagram Elaborate Base Use Case Descriptions   Initial Use Case Descriptions Model Extend, Include & Generaliz   Use CaseDiagrams Map Use Cases to Object Models Define/Refine Conceptual Business Objects DevelopInstanceScenarios = Required in the project Prepare for Use Case Modeling Initial Use Case Modeling Expand Use Case Model Test Use Cases & Doc Organize the Use Cases Ongoing Use Case Management

40. The Use Case Modeling Process Identify the Major Actors Develop Base Use Case Descriptions Done Develop Context Diagram Elaborate Base Use Case Descriptions Done Initial Use Case Diagrams Model Extend, Include & Generaliz Done Map Use Cases to Object Models Initial Use Case Descriptions Next Define/Refine Conceptual Business Objects DevelopInstanceScenarios Prepare for Use Case Modeling Initial Use Case Modeling Expand Use Case Model Test Use Cases & Doc Organize the Use Cases Ongoing Use Case Management

41. Initial Use Cases

42. “Initial” Use Cases • More on base and elaborated use cases later • Prepare a list of all use cases based on the actor goals identified in all Primary Actor Specification cards • Per the UP, not all use cases need to be identified at this stage; more use cases will probably be discovered during the elaboration phase • For each Use Case, fill in a Use Case form to record all the information you have about the responsibilities of that use case • Focus on generaldescriptions initially (i.e., Initial Use Cases) • Per the UP, you will add details later as you further elaborate the use cases • But warning! a description is NOT the same as a glorified name (e.g., Cash Withdrawal Use Case: allows customers to withdraw cash), but an actual description of what the system needs to do to accomplish the actors’ goals

43. Use Case Form (“initial” use case or short form)

44. The Use Case Modeling Process Identify the Major Actors Develop Base Use Case Descriptions Done Next Develop Context Diagram Elaborate Base Use Case Descriptions Done Initial Use Case Diagrams Model Extend, Include & Generaliz Done Map Use Cases to Object Models Initial Use Case Descriptions Done Define/Refine Conceptual Business Objects DevelopInstanceScenarios Prepare for Use Case Modeling Initial Use Case Modeling Expand Use Case Model Test Use Cases & Doc Organize the Use Cases Ongoing Use Case Management

45. Base Use Cases

46. Event Course: Expanding the Use Cases:Adding Flow of Events Base Use Cases Initial Use Cases Name: Actors: Name: Description: Actors: Pre-condition: Description: Flow of Events: Post-condition: Assumptions: Etc.

47. Base Use Cases • The base use cases describe the specific behaviors and interactions that take place between actors and the system, within the scope of the use case. • An base use case provides a complete description of the normal set of primary interactions between the actors and the system, within a use casei.e., “sunny day”, “success” or “optimistic” scenarios only, i.e., the scenarios that fulfill actors’ goalsNo need to model “rainy day”, “failure” or “pessimistic” scenarios yet – this comes later

48. Purpose of Base Use Cases • Understand the primary interactions between the system and user as well as system behaviors in the use case • Provide detailed description of “sunny day” scenarios • Begin to identify/document exceptions or alternative scenarios, but don’t model these yet • Begin to identify non-functional requirements and assumptions associated with the use case • Document the priority of each use case in the development effort

49. Base Use Case Contents Same as with initial Use Cases: • Use case number and name • Names of the actor or actors who interact with the system • Description of the use case (the description can be shortened if needed at this point to avoid redundancy with the flows of events) Plus: • “Optimistic”flow of events of the use casei.e., “sunny day” scenarios • Pre-Conditions and Post-Conditions of the use case • Priority of the use case • Known non-functional requirements (e.g., performance, security) specifically associated with the use case • Any other assumptions concerning this use case • A list of exceptions or alternatives found during the definition of activities in the flow of events

50. Use Case Template