1. ZEIT2301 Design of Information Systems Functional Design: Use Cases School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick

2. Topic 04: Functional Design Objectives Appreciate the role of Use Cases in Systems Development Be aware of the rules & style guidelines for Use Case diagrams. Be able to create functional models using Use Case diagrams. Design Use Case Descriptions Reference: Dennis Ch 5

3. Use Cases Model the systems interaction with the environment Provide a high level view of the system from the user’s perspective. Use cases are a non-technical record of what the customer (or user) expects the system to do. Based on functional requirements.

4. Use Cases and Requirements Use Cases assist the analyst to organize and model the functional requirements identified for the system. Requirements obtained via interviews, questionnaires, observation, document analysis, JAD sessions or prototyping. Use cases are not effective in capturing non-functional requirements They describe what a system accomplishes, not how Non-functional requirements (e.g. reliability, etc) are often documented outside the use case.

5. A Use Case Informally, a use case is a story of using a system to fulfill a (business) goal. A Use Case represents a behaviour, so name should start with a verb eg RentDVDs, Make Appointment, CheckPrice, ApproveLoan

6. Types of Use Cases Early analysis stage concentrates on Use Cases: Overview and Essential

7. Guidelines for Good Use Cases Identify major system functions Choose a good name (start with a verb) Illustrate a complete behaviour Limit each use case to one behaviour Represent the actor’s point of view

8. An Actor An actor is an external entity that interacts with one or more Use Cases of the system An actor is outside the system boundary An actor is a role, not a specific user One actor may represent many users; a particular user may perform more than one role.

9. An Actor Most actors represent user roles e.g. StoreClerk, Customer, BankTeller but occasionally actors can also be external systems. eg CreditAuthorizationSystem An actor is connected to a Use Case Depicts a usage relationship Connection does not indicate data flow NB. There are no arrow heads on the connection line

10. Use Case Diagrams A Use Case Diagram provides a high-level graphical view of all the Use Cases for the part of the system being modelled. Illustrates, in a very simple way, the main functions of the system (or sub-system) and the users that will interact with it. Can be used as a tool to communicate with users in the early phases of system development.

11. Use Case Diagram Syntax Actor person or system that derives benefit from and is external to the subject Use Case Represents a major piece of system functionality Association Relationship (between an actor and a use case) Include Relationship Extend Relationship Generalization Relationship >

12. store clerk system manager financial system A simple Use Case Diagram Note the high level view of the system from the user’s perspective. Diagram does not show the backend processes and databases that would connect these views. rent DVDs add new DVDsincrease price

13. store clerk system manager financial system A simple Use Case Diagram Actors: store clerk (perhaps there are several clerks), system manager, financial system. rent DVDs add new DVDsincrease price

14. An > Relationship Two Use Cases may be connected by an > relationship Indicates a Use Case that is used (invoked) by another Use Case Useful if the Use Case includes common functions also used by other Use cases. The included Use Case is always performed as part of the original Use Case But can also stand on its own

15. A Sales System with > relationships > arrow points from the base use case to the included use case.

16. An > Relationship Two Use Cases may be connected by an > relationship Extends a Use Case by adding new behaviour or actions that are not always part of the Use Case An extend use case cannot stand on its own

17. A Retail Sales System with > and > relationships > arrow points from the extending use case to the extended use case.

18. Include vs. Extend Use > if you want to model an extension to, or a variation of, a use case. Use > if you want to factor the common behaviour among two or more use cases into a single generalized use case

19. Generalization Relationships Optionally, it may be useful to portray a generalization (of an actor or of a Use case). New patient is a type of patient.

20. Use Case Diagram with Extend, Include and Generalization Make appointment is a generalization of Make old patient appt and Make new patient appt.

21. store clerk system manager financial system Use Case Diagrams In a Use case Diagram, the only connection between two Use Cases is via >, > or generalization rent DVDs add new DVDsincrease priceprint updated catalogue X

22. Levels of Use Cases A common challenge is identifying use cases at a useful goal level. For example, how do we know which of these is at a useful level? Negotiate a Supplier Contract Rent DVDs Log In Start Up System Material sourced from Craig Larman and Alistair Cockburn

23. Levels of Use Cases One answer is that they are all use cases. Not helpful… We can end up with too many fine-grained use cases management and complexity problems. Or “fat” use cases which span an entire organization.

24. Guidelines for Use Case Levels Cockburn supports the Elementary Business Process (EBP) guideline. Focus on use cases at the level of EBPs. “A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.”

25. EBP for Use Case Levels Naively, you can apply the “boss test” for an Elementary Business Process Boss: “What do you do all day?” Me: “I logged in!” Is Boss happy?

26. Guidelines: Size for Use Case Levels An EBP-level use case usually is composed of several steps, not just one or two. Think in terms of user-level goals. Stakeholders usually relate to requirements presented in the form of goals.

27. Use Case Levels: Applying the Guidelines Applying the EBP and size guidelines, which would you choose as a use case? Negotiate a Supplier Contract Rent DVDs Log In Start Up System

28. Use Case Levels: Applying the Guidelines Applying the EBP and size guidelines: Negotiate a Supplier Contract Rent DVDs Log In Start Up System The others can also be modelled as Use Cases. But, prefer a focus on the user-goal level.

29. Definition: Essential & Concrete (Real) Use Cases “Keep the User Interface out” Essential use cases defer the details of the UI, and focus on the intentions of the actors. Essential: Clerk enters Customer ID Good Concrete: Clerk takes Customer ID card and reads the bar code with laser scanner. Not recommended at this stage. Anticipates physical design decisions about how the process will be done

30. Use Case Descriptions Individual Use Cases are described in words: Use Case Description. Use Cases are text, not diagrams Despite the emphasis often given to the diagrams. A Use Case Diagram just helps in identifying Use Cases by name and creating a context for the Use Case

31. Use-Case Descriptions Describe basic functions of the Use Case What the user can do How the system responds Describes one and only one function, but may have multiple paths. Content is developed in collaboration with users. There is no formal specification for a Use Case Description.

32. Use-Case Descriptions Each Use Case has at least one sequence (or flow) that a user follows when interacting with the system eg the “normal” process for withdrawing money from an ATM The Use Case may have alternative paths that illustrate alternative actions Typically to cater for exceptions eg the user enters an incorrect PIN; the user has insufficient funds. Each path through the Use Case is known as a scenario

33. Sample Elements of a Use- Case Description Use Case Name:ID:Importance Level: Primary Actor:Use Case Type: Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Preconditions: Normal Flow of Events: Subflows: Alternate/Exceptional Flows:

34. Elements of a Use Case Description Title descriptive name, matches name in use case diagram ID indentifying number Importance level Low, High Primary actor usually a user role, the trigger for the use case Stakeholders any group or individual with an interest in the function of the use case Brief description

35. Elements of a Use Case Description Type Overview vs Detail Overview: a high level view of requirements as agreed between the analyst and users Detail: documents as much relevant information as possible Essential vs Real Essential: only the minimum needed to understand the required functionality Real: describes specific steps in detail In early analysis, the type is typically overview and essential

36. Elements of a Use Case Description Precondition – conditions that must be satisfied in order to execute the use case; Where we are up to when the Use Case commences? eg For a Use Case “Purchase Items” the precondition might be: Customer has searched the web site and selected at least one item to purchase Note: preconditions not shown in textbook’s template (Fig 5-5) for Use case descriptions

37. Elements of a Use Case Description Trigger Each Use case usually has a trigger – an event or action that initiates the use case External trigger eg a customer placing an order Temporal trigger eg library book overdue

38. Use Case Elements: Relationships Association Actors that are associated with this use case Extend Any uses cases which are extensions of this use case Include Any use cases included with this one Generalization Whether this is in a hierarchy of use cases

39. Use Case Elements: Flows Normal Flows Sequence of steps that are normally executed in this particular use case Simple, clear steps Identify who initiates the step If flow “includes” other use cases, then specify that use case name eg Step 2: ….. Step 3: perform “Check Outstanding Fines”

40. Use Case Elements: Flows Sub-Flows The normal flow of events decomposed, if necessary, to keep the normal flow of events as simple as possible Alternate or Exceptional Flows Flows that do happen but are not considered to be the norm Some of these exceptional flow may cause the use case to end; others may be recoverable

41. Larman example: Place an Order UC 4: “Place an order” 1.Clerk identifies the customer, each item and quantity 2.System checks credit 3.System accepts and queues the order Extensions: 2a. Low credit: Customer is ‘Preferred’... 2b. Low credit & not Preferred customer:... 3a. Low on stock: Customer accepts reduced...

42. Use Case Writing Guidelines 1. Write in the form of subject-verb-direct object 2. Make sure it is clear who the initiator of the step is 3. Write from independent observer’s perspective 4. Write at about the same level of abstraction 5. Ensure the use case has a sensible set of steps 6. Apply the KISS principle liberally. 7. Write repeating instructions after the set of steps to be repeated

43. Summary Examining the goals a system supports makes for good functional requirements a user can understand Use Case Diagrams present a graphical overview of the main functionality of a system. Use Case Diagrams present a graphical overview of the main functionality of a system represented by the use cases shown. A description is developed for each use case shown on the use case diagram. Use Case Descriptions detail the interactions of a user with the system when undertaking a particular function.