1 Design of User Interfaces (Misbah Islam) Representing Requirements Scenarios and Use Cases Introduction to Scenarios and Use Cases: In order to elicit requirements we have to acquire knowledge about the domain and the activities that are usually performed in the system. Each activity is associated with a given goal and can be performed by a set of actors or actor instances. The description of a specific goal-related activity (for given actor instance or data conditions) may be called a Scenario. A use case also is also meant to achieve the same purpose but is more general as it is meant to cover all possible actor instances and data conditions. Use cases are important because the set of all use case descriptions specifies the complete functionality of the system. Car Fender Bender (accident) Claim Example: Scenario System under discussion: Federal Union Insurance Company Primary Actor: John Smith, the claimant Goal: John Smith gets paid for his car accident Conditions: Everything is in order Outcome: Insurance company pays claim 1. John Smith submits claim with substantiating data to the local office 2. Insurance company verifies claimant owns a valid policy (failure here probably means goal failure) 3. Insurance company assigns agent (Mr. Jack Strong) to examine case 4. Agent verifies all details are within policy guidelines. (an interaction between the agent and secondary actors) 5. Insurance company pays claimant (implies all preceding goals managed to pass 2 Example Use Case: System under discussion: Federal Union Insurance Company Primary Actor: The claimant Goals: Get paid for car accident Outcome of use case: (success path) 1. Claimant submits claim with substantiating data. 2. Insurance company verifies claimant owns a valid policy 3. Insurance company assigns agent to examine case 4. Agent verifies all details are within policy guidelines 5. Insurance company pays claimant Extensions of use case: (exceptions / error paths) - 1a. Submitted data is incomplete: - 1a1. Insurance company requests missing information - 1a2. Claimant supplies missing information - - 2a. Claimant does not own a valid policy - 2a1. Insurance company declines claim, notifies claimant, records all this, and terminates proceedings. - - 3a. No agents are available at this time - 3a1. (What does the insurance company do here?) - - 4a. Accident violates basic policy guidelines: - 4a1. Insurance company declines claim, notifies claimant, records all this, and terminates proceedings. - 4b. Accident violates some minor policy guidelines: - 4b1. Insurance company begins negotiation with claimant as to degree of payment to be made. Variations on use case: - 1. Claimant is i. a person ii. another insurance company iii. the government - 5. Payment is by i. check ii. interbank transfer iii. automatic prepayment of next instalment iv. creation and payment of another policy 3 Definitions of Scenarios and Use Cases: Scenario: Scenario is used as an example to illustrate common cases and the flow of events and the involved actors. The focus is on understandability. It is described from the perspective of one or more actors or situations. - Is an instance of a use case describing a concrete set of actions. - A sequence of interactions between the actor/s and the system occurring under certain (system) conditions, to achieve the primary actor's goal. Desirable Properties of Scenarios: Scenario representation should conform to these properties: No Domain knowledge in the representation Understandable to people with different backgrounds Support for both diagram representation and description Data structure independence If domain knowledge is added these can be adapted as building blocks for requirements specification Provide insight into temporal and causal behaviour The task of a developer is to analyze existing scenarios and to come up with new, better and efficient scenarios. The developer should not try to implement the old and inefficient modes of operation. Representing Scenarios: Through scenario template Using sequence diagrams State charts Uses of Scenarios: In addition to be used as a source for developing use cases, scenarios can be used to form customized Scripts and Storyboards describing how the system may be put to use by various actors in different circumstances. For example, a tourist may use a fixed set of ordered scenarios (in the form of a script) to negotiate and purchase holiday tickets. He may also set up a „storyboard‟ of his entire program describing what he did or will do while on vacation. 4 Triggering of Scenarios: Can be an event or state which initiates the start of actor-system interactions which continue until the goal is delivered or abandoned. The system is supposed to complete whatever responsibilities it has with respect to the interaction. Actors: Actors are basically users of the system. Actors are external entities (people or other systems) who interact with the system to achieve a desired goal. Use Case: Use Cases are what happens when actors interact with the system. An actor uses the system to achieve a desired goal. By recording all the ways our system is used ("cases of use" or Use Cases) we can find out the requirements of our system. A use case can be defined as The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system A sequence of transactions in a system whose task is to yield value to an individual actor of the system A collection of possible scenarios concerning the system and the actor. A use case is specified from the perspective of the primary actor‟s goal. It is system‟s responsibility to help achieve that goal. The use case must show how the primary actor's goal might be delivered or might fail. For use cases to be included in formal requirements they should be sufficient detail to allow their transformation into design requirements, high level design and test specifications. Use case and OO Design: Unlike OO design where the emphasis is on objects, the constraints on their use and their behaviour, the use cases emphasize ordering, e.g. “When a customer places and order, the order and credit limit are validated, the database is updated if these are OK and confirmation number is issued”. OO designers need to transform use case descriptions into objects and behaviour. The sequentiality can be built-in using constraints and state machines. 5 Change cases: Are specialized use cases intended to capture anticipated future changes to a design. Change cases have links to affected use cases. Change cases cater to the following situations: It is a good idea to write change cases where ever possible. Functionality changes Market and business requirement changes Operational changes such as new policies or operational processes Technology related changes Representing Use cases: Structured English (Template) description of - Main - Alternative - Exceptional behaviours Interaction Diagram showing different paths of actor interactions - iteration - repetition - branching, and - parallelism Pre-and post conditions may also be specified. Interface Specifications for each actor. The interface is a contract that the actor must provide to other actors. A contract may involve execution of multiple use cases. Internally use cases may also provide contracts shared by multiple actors. State-transition diagram in which a stimulus from an actor will cause the use case to leave its current state and perform a transaction. Each transaction is associated with pre- and post-conditions. 6 How to create Use Cases: Use case can be created using the following methodologies: Structured Analysis Structured Design (SASD) or top down hierarchical design. Unstructured aggregation - Collect and classification of all the “shall” statements of the form “When the free memory goes below 32 K, the operating system shall do garbage collection and free block aggregation”. “When the credit balance is less than $100 the system shall post a warning note and shall not credit any interest on the account”. Scenario story-driven discovery - use cases are discovered by analyzing written descriptions of day-to-day activity or desired activity. Actor or responsibility discovery - first define the actors and roles, then define their collaborations and responsibilities Relationship between Scenarios and Use Cases: The relationship between a use case and a scenario can be described as Specialization of a use case An instance of a use case and As a component of a use case A possible (data or condition dependent) path in the use case Collection of Collection of Use Cases Scenarios A Specific A Specific Scenario Use Case 7 Validation and review of Use cases: Once use cases are designed these need to be validated and reviewed. The following questions need to be answered: Is the Use Case complete? Are there any details that need to be added? Is the actor's goal going to be properly met? Are there any procedural or requirement changes that can be proposed to simplify the process? Are there any additional Goals of the Actors that are not addressed? Any other Actors that should have been considered? Use case refinement and relationships: In addition to validation there is also a need to discover commonalities or redundancies between use cases and to promote re-usability (good SE practice). The following operations can be done to achieve this: Extend relationship: Use case A extends use case B, if B includes the behaviour of A under certain conditions. Example: Fire reporting system: There are two actors Field Officer and a Dispatcher. The Field Officer employs a use case called ‘Report Fire’ and then communicates with the Dispatcher to allocate resources. If somehow the Field Officer is unable to get through via normal means, he then invokes another Use case called ‘Report Fire under Emergency’ which is an extension of the first, since it uses other channels to get through. Include relationship: If use case A functionality is common to the operations of B and C then both B and C can include use case A. Example: Both the Field Officer and the Dispatcher to invoke a common use case called ‘View City Map’. We need to write ‘View City Map’ only once and it can be included in the use cases wherever it is needed. Specialization relationship: If use case A and B want to customize use case C for their purposes then they can specialize C as C(A) and C(B) and then include. Example: The Field Officer and the Dispatcher need to see the city map at different levels of detail, then they can specialize ‘View City Map’ according to their requirements. 8 Use case Template: The following are the typical fields in a Use case template: Name: the name of the use case Goal: the goal of the use case Primary actor: The actor using the system to achieve the goal Secondary actors: Needed to achieve Primary actor‟s goal Scope: the scope that the use case is covering (System, Sub-function) Level: system, user, summary (collection of user level, e.g. Config DB) Preconditions: any prerequisites before the use case can be started Success Condition: what is considered a successful end to the use case Failure Condition: what is considered a failed end to the use case Trigger: what external event happens that triggers its start Notes: Performance issues, frequency of use and other issues. Scenario Descriptions: These can be of the types - Main (success) path - Extension: Failure path, Recovery path An Example Use Case Template: Use Case Sell Parts to Customer #112299 Goal Customer issues request directly to Our company, expects Parts to be shipped and to be invoiced Priority Very High Performance 1. Order Acceptance Turn Around Time: 8 hours 2. Shipping Time:Min: 5 working days. 1 day additional per 1000 Items, if Items > 5000 3. Bill reception: 21 Working days Frequency 10 Orders per day Scope Company, Subcontractor/s. Customer Base Preconditions Customer Credit Rating >= A End Conditions: 1. Customer receives the Parts. Success 2. My company receives amount. 3. Customer Credit Rating A++ if $ > 10K End Conditions: 1. My company cannot ship on time, full quantity or with Failure acceptable quality. Company reputation A-- 2. Customer cannot pay. Credit rating A-- Actors: Primary Customer’s agent or computer Actors: Secondary Bank, Shipping Agent, Subcontractor Trigger Receipt of Purchase Order via email or Web Subordinate 1. Purchase Order Acceptance Use cases 9 2. Manufacturing Order (Internal) 3. Subcontractor Order/Billing/Invoicing 4. Bill reception 5. Credit Rating Adjustment 6. Returned Parts Handling Super ordinate Manage Customer Relationship Use cases Scenario Descriptions Steps Main Course 1 Customer RFQ received 2 Response sent (price list, delivery date etc) 3 Customer Order received 4 Customer Credit Rating and Limit evaluated 5 Inventory is checked and shipping note issues 6 Parts collected. Pre-shipping verification: Quality and Quantity 7 Parts Shipped. Invoice prepared and shipped 8 Customer Acceptance Test successful 9 Invoice is paid by the customer Scenario Descriptions Steps Extensions 4e Customer Credit Rating and Limit is NOK 4.e.1: Email Customer Order that may not be (fully) processed 5e Inventory is not sufficient 5e.1: Internal/subcontract order to re-supply issued. 6e Pre-shipment verification (Quality, Quantity) NOK 6e.1: Re-supply order issued 6e.2: Failed products sent back for corrective action 7e Shipping delay 7e.1: Customer notified 8e Customer acceptance test NOK 8e.1: Tests reproduced 8e.1e: Error is confirmed 8e.1e.1: Apology issued 8e.1e.2: Root Cause Analysis (RCA) done 8e.1e.3: Shipment recalled 8e.1e.4: New shipment prepared (after new verification tests) 10 8e.1.1: Error is not confirmed 8e.1.2: Customer requested to redo/recalibrate 9e.1 Customer payment not received before due date 9e.2 Customer check bounced 9e.1.1: Reminder(s) sent 9e.2.1: Reminder sent 9e.3 Payment not received. 9e.3.1: Credit rating adjusted. 9e.3.2: Legal proceeding initiated Exercise: Rewrite the following Use case in the form of a template Restaurant use case: a. The actor Guest enters the restaurant b. The actor Guest has the possibility of leaving his/her coat in the cloakroom, after which he/she is shown to a table and given a menu. c. When the actor Guest has had sufficient time to make up his/her mind, he/she is asked to state his/her order. Alternatively, Guest can attract the waiter's attention so that the order can be placed. d. When the Guest has ordered, the kitchen is informed what food and beverages the order contains. e. In the kitchen, certain basic ingredients, such as sauces, rice, and potatoes, have already been prepared. Cooking therefore involves collecting together these basic ingredients, adding spices and so on and sorting out what needs to be done just before the dish is served. Also, the required beverages are fetched from the refrigerator. f. When the dish is ready, it is served to the actor Guest. When it has been eaten, the actor is expected to attract the waiter's attention in order to pay. g. Once payment has been made, Guest can fetch his/her coat from the cloakroom and leave the restaurant. The use case is then complete."