1. New Perspective Based on how the system is used

2. What Is a Use Case? A case of how the system is used. –A behaviourally related sequence of interactions performed by an actor in a dialogue with the system to provide some measurable value to the actor (Jacobson 1994). A scenario is a unique path through the system. An instance of a use case is a scenario. A class of scenarios is a use case.

4. Components of a Use Case Diagram Actors – stick figures. Use cases - ovals. –High level event-triggered processes. –Way in which the user uses the system. Communication lines – connecting actors to Use Cases. Extension lines –One use case extends another if it is sometimes performed by it. –One use case includes another if it is part of it’s normal processing.

5. To Model Use Cases Determine system scope and purpose. Identify the actors. Identify the use cases. Create a use case diagram. Describe the use cases. Identify user services and business services. Develop user services and business services. Complete the use case descriptions.

6. Business use cases and use cases The business model represents the system as is. When the business is modelled using Use Case modelling, more than just the computer system is modelled. When the computer is modelled, then the boundaries and actors are specific to the system.

7. Business Use Case modelling Reference: Rational Unified Process (online). Three types of activities (or Use Cases): –1. Commercially important activities, often called business processes. –2. Support activities that are needed to make the system work, such as administration, cleaning and security. –3. Management work.

8. Core business use cases Should have a communicates-relationship to or from a business actor. – So that businesses are built around the services their users request. Can be triggered periodically or they can run for a very long time –(e.g. a surveillance function). Have business actors that originally initiated them. May produce results for a business actor, although they are not explicitly initiated by the business actor. – For example, the development of a widely distributed product is seldom initiated by an identifiable customer. Instead, the need for a new product is realized from market studies and the accumulated requests of many users.

9. Non-core business use cases Management and supporting business use cases do not necessarily need to connect to a business actor, although they normally have some kind of external contact. A management business use case, for instance, might have the owners of the business, or the board, as its business actor. Abstract business use cases do not need a business actor, because they are never instantiated ("started") on their own.

10. Business actors An actor is an entity with whom the business interacts. The term actor means the role someone, or something plays while interacting with the business. E.g. –Customers, Suppliers, Partners, Potential customers (the "market place"), Local authorities, Colleagues in parts of the business not modeled. An actor normally corresponds to a human user, but sometimes an information system plays the role of an actor, or ‘time’ can also do so.

11. Actor v user An actor represents a type of business user rather than a real physical user. Several physical users of a business can play the same role. The same user can act as several different actors. A business actor should be given a name that reflects its role towards the business. The name should be applicable to any person—or any information system—playing the role.

12. Potential actors

13. Picking actors What in the system's surroundings will become actors to the system? Start by thinking of individuals who will use the system. How can you categorize them? It is often a good habit to keep a few individuals (two or three) in mind and make sure that the actors you identify cover their needs.

14. Picking actors The following set of questions is useful to have in mind when you are identifying actors: –Who will supply, use, or remove information? –Who will use this functionality? –Who is interested in a certain requirement? –Where in the organization is the system used? –Who will support and maintain the system? –What are the system’s external resources? –What other systems will need to interact with this one?

15. Actors Help define system boundaries –Actors should interact directly with the system. –Business actors may not be actors. –Business workers may not be actors. A business worker may be someone who facilitates or operates a business process, but may not be involved in initiating it or may not receive benefit from it.

16. Actors Are characterised by their external view rather than their internal structure. Participate in interactions involving message exchanges and actions with systems. Are denoted as stereotyped class rectangles or as stick person icons. Have goals to be achieved by interaction with systems. Have instances that are objects playing the role of an actor.

17. Actors Have one role for each use case with which they interact, that is one role per communicates relationship. Must have a name or identifier. May be played by a single object. May have generalisations with other actors – an actor may inherit characteristics of a more general actor.

18. Identifying Actors Who uses the system? Who starts up / shuts down the system? Who maintains the system? What other system(s) use this system? Who gets information from the system? Who provides information to the system? Does anything happen automatically at a preset time? (A time / date can be an actor).

19. Business Actor, Actor, Use Case

20. Use Case perspective The system is described from the perspective of the user. Each user describes the tasks or sets of tasks they do separately. The first task done may cause the user to be involved in doing other tasks. –E.g. (shop) Pick a product, pay for product. –Only things that are done by the same person at the same time in the same place are part of the same thread.