What is a Use Case Script?

1. What is a Use Case Script? • The text to describe a particular Use Case interaction • Takes the form of a 2-way dialogue between the actor and the system • Provides the supporting detail for the Use Case diagram • Do not start until the diagram is complete or nearly complete • Also known as Use Case Descriptions

2. What to describe • Describe the most common/normal form of interaction first - the basic course • Describe possible variations separately - the alternative courses • The script should be in a conversational style: • actor requests…. • System responds by…. • Actor does….. • Etc..

3. System Response - Rent DVD 3. System provides member details of: status of loans and fines 5. System accepts ids and gives fee payable 7. System logs payment details Example of a Use Case Script • DVD rental shop interaction may be: Actor Actions - Shop Assistant 1. Customer tenders DVD(s) to be rented and membership card 2. Counter assistant enters member and number into system 4. Assistant enters identification of eachDVD to be rented 6. Assistant requests payment, takes money and enters payment made

4. Guidelines • Include a series of numbered sections or steps which describe noteworthy events and possibly related context, constraints and business rules • Steps may alternate between actor and system • May be a series of consecutive steps taken by either of them • Written from the user’s point of view • Consists of user’s vocabulary

5. Conversational Style • This conversational style script (as if for a theatre play) is a good compromise between the advantages and disadvantages of other methods: • it is quick and easy to write (important for capturing early, outline information)‏ • it is quick and easy to read and to understand • it encourages conciseness • it identifies the required sequence of actions • it highlights causes and effects

6. Styles of Description • In addition to the conversational style script, there are other ways of describing the interactions e.g. • unstructured narrative • structured English • decision tree • decision table • Out of interest let us just pause for thought about the first two….

7. Unstructured Narrative • A text description of what happens in standard English sentences. • Advantages: • easy to write • Disadvantages: • easy to include ambiguity, • lengthy both to read and to check, • does not highlight cause and effect • does not highlight sequence of actions

8. Example of Narrative Description How long does it take to understand this narrative? A DVD shop primarily rents DVDs to customers. Customers can only borrow DVDs if they are registered members, and need to produce their membership card each time they borrow a DVD. Customers come into the shop and once they have chosen the DVDs that they wish to borrow they take them to the checkout and hand them to the shop assistant.

9. How long does it take to understand this narrative? The shop assistant then enters the membership number into the system. This will produce on screen the member’s personal details, and whether any other DVDs are currently on loan. Customers cannot borrow more DVDs if there is an overdue balance owing. Providing the customer does not owe money, the shop assistant enters the DVD code which shows the rental period and the rental amount. This is repeated for each DVD. The shop assistant then asks the customer for the amount of money. Customers can pay by cash or credit card. Example of Narrative Description

10. Structured English • A text description of what happens but using a limited range of phrases. • Advantages: concise, eliminates ambiguity, highlights sequence of actions • Disadvantages: does not highlight cause and effect, may use phrases which are unfamiliar to some users

11. “Essential” Use Cases • These are used during the feasibility and analysis stages of the project. • The aim is to be free of implementation detail to show the essence of the business requirements (the conceptual model). • Enables analysts, developers, users and clients to understand the scope of the problem and the processes required

12. “Real” Use Cases • Now the Essential Use Cases will be used as the basis for lateral, creative thinking with the opportunity for new ideas on how create the system. • Real Use Cases are used to document the design of the project i.e. how it will work in reality. • For a user interface it may include prototype screen shots, print layouts, form layouts, menus. • For a system interface it may include file layouts.

13. Template Sections • Use Case - its identifier/name • Actors - list of actors involved. Show which one initiates the use case and any other actors involved – can be more than one • Overview - short outline description summarising the use case • Type - category of the use case – see next slide • Cross References - use case relationships

14. Categories of Use Cases • A category is useful as a check that the main processes have been identified • The category is loosely allocated – it is an attempt to think about whether the use case (process) is a major process or a minor one or optional process 1. Primary - major common process e.g. Rent Video 2. Secondary - minor or rare processes e.g. Request to supply unstocked New Video 3. Optional - processes that may or may not be used

15. Alternative Courses • Alternative courses – very important • Remember Use Case Diagrams can show this • Getting down to the detail of how this use case script operates • Can describe alternative events to the typical story. These are the less common, the exceptional or error cases.

16. Alternative Courses • Place all the alternatives after all the typical course of events • Example: 7. Customer pays clerk by cash or credit Alternative Courses 7. Customer has unpaid late charges and will not pay them. Collect payment or cancel rental transaction

17. Use Case Summary • Use Case descriptions supply the detail of system requirements • Very useful and augment Use Case Diagrams • Use Case Diagrams have what we call a granularity problem i.e. the level of detail is limited • Use Case Scripts deal with this limitation • Conversational scripts are used to describe the interactions between actors and use cases • The basic course may be followed by 1 or more alternative courses • Essential Use Cases are used during Analysis, Real Use Cases are used during Design

18. Lecture recap questions • What is an <<extends>> relationship between Use Cases? (“is” or “has”?) • What is an <<includes>> relationship? (“is” or “has”?)‏ • Would “returning a DVD to the shelf” be likely to be a Use Case? …….. Why? • Why is the Use Case description written as a script like a play? • How are <<extends>> relationships shown on a Use Case Script? • What is meant by “an essential Use Case”?