Use Cases, Part I Understanding the Business Dynamics

1. Use Cases, Part I Understanding the Business Dynamics Understand the business workflow Identify system support points the system 'use cases' Basic elements of the Use Case Model

2. From Business Workflow to System Use Case • What is a Use Case? A use case is a sequence of actions performed by a system that yields an observable result of value to a particular actor.

3. Use Cases • 6 things to know about a Use Case model: • How do I discover Use Cases? • What a Use Case is NOT • Where does ‘Use Case’ fit in the development process? • What are the basic elements of a Use Case Model? • How do I draw a Use Case Model as a diagram? • After the basics, how do I refine the Use Case Model?

4. How do I discover Use Cases? • two steps: • Business Workflow, drawn as Swimlanes Diagram • Decide the activities in the Business Workflow that call for system support • These will become our initial “use cases.”

5. Discovering Use Cases -- the Business Workflow

6. Discovering Use Cases -- deciding system support points

7. What a Use Case is NOT A Use Case is ... • not the workflow between the actors. • i.e., it is not the interactions that occur outside the system boundary between “business workers.” • not the interactions between the system components. • i.e., interactions that occur within the system boundary ~ the “white-box” view of the system. • not the total set of requirements. • i.e., to complete the requirements documentation we need another piece: the "non-behavior" requirements. A Use Case is ... • a named description of the users’ (“actors”) interactions with the system. • i.e., it reflects a “black-box” view of the system.

8. Where does the Use Case fit in the development process? • Use Case Diagrams are part of what is used "to model the problem" • before we go on to begin to model the solution. • It is a kind of "contract" between customer and developer • in a language both can understand and speak. • In the UML, it is a core artifact. • the UML calls itself "Use-Case-Driven" • use-cases are developed early-on • use-cases are used throughout the life cycle • In the Unified Process, this is part of the "Requirements Workflow."

9. What are the basic elements of a Use Case Model? A. What are the parts of a Use Case Model called? B. What does each part look like? C. How do the parts "fit together"?

10. The Use Case Model – What are its parts called? • There are four core elements of a Use Case Model: • the system (boundary) • the set of all use-cases specify a system in terms of its intended functions (functionality). This defines a firm boundary around the system, separating it from the outside world. • the actor • someone or something outside the system (boundary) that interacts with the system • the use case • a sequence of actions that a system performs that yields an observable result of value to a particular actor. • the request • a line of communication between actor and use-case – typically an initiating "transaction." It crosses the system boundary.

11. What do the parts look like? And how do they fit together? shown as a Use Case Diagram

12. The Use Case Model • The Use Case diagram is only one part of the Use Case model. Use Case model: a model of the system's intended functions and its environment, consisting of: • Use-Case Diagrams • Use-Case Packages • Actors, each given a: • Actor name • Actor description • Use Cases, each given a: • Use Case name • Use Case summary -- a brief description of: • the nature of what the actor needs (the system) to do • the observable result of value to the actor • More detail will be added later

13. Use-Case Package informal definition: a ‘chunk’ of system functionality. • – i.e., a system or sub-system. example: • the Customer Loyalty Program processing • the new EU-Bid (sub)system UML definition: A use-case package is a collection of use cases, actors, relationships, diagrams, and other packages. It is used to structure the use-case model by dividing it into smaller parts.

14. Use-Case Package ~ systems & subsystems

15. Actor informal definition: An actor describes a role that a user plays with respect to the system. • One individual can play several, different roles. • An actor doesn't need to be human (in spite of stick figure icon). • i.e., this includes other (external) systems. example: • Branch Manager • Mail System • Auctioneer UML definition: A actor is someone or something outside the system that interacts with the system.

16. Actor Discovery Look for ‘users’ that are direct users of the system. • who to include? • all initiating users • significant information providers ? recipients of system outputs (only when useful) Name and describe the actor: • Actor name: • Branch Manager • Actor description: • think: "A Branch Manager is..." a manager who has business accountability for one of EU-Rent's vehicle rental locations.

17. Actor

18. Use Case informal definition: A use case describes one “case” of how a user can use the system. • – i.e., a ‘system service’ that the user can request from the system. example: • Register Club Member • Order Vehicle Model UML definition: A use case is a sequence of actions performed by a system that yields an observable result of value to a particular actor.

19. After the basics, how do I refine the Use Case Model? • .