Use Case modelling 3 How to go from a diagram to a further definition

Details of a Use Case Intent. Description –also known as the happy path. –The most normal branch of each path is taken. Alternate courses. Pre-condition(s). Post condition(s).

Name and Intent The name of a use case is derived from the perspective of the actor with respect to the system. The intent describes the desired objective of this interaction in terms of benefit and value to the actor and is reflected in the use case name.

Description The use case description describes all possible sequence of interactions that may branch into a number of courses or flows. Describes the sequence and flow of dialogue between the actor and the system. Must be two-way (conversational). –Actor requests… system responds… actor requests…etc.

Description Contd. Describe the basic course in natural language (The Happy path). Be written from the user’s perspective. Use actor’s own vocabulary. Clearly define user’s intent. Present terminology that is consistent (i.e. Customer or client). Clearly define start and end points – end point typically yielding value to the actor.

Third Party Claims so far

Example Please note that the example that follows is from a simulated working computerised system. In a manual system, the current physical description would be given. In most cases, this would consist of the filling in of paper based forms or exchanging information over the phone or through conversation.

Example – Assess a claim According to the Claims Assessor: –When I’m ready to assess claims, I start up the ‘Assess claims’task. This shows me a screen of all claims that haven’t been assessed yet but are ready for assessment. It shows me the date the claim was reported, the date of the incident, the claimant’s name and first 40 characters of the address. If there are more than eight, I can only see the first eight, but there is a scroll-bar that lets me scroll down if there are any more. Thankfully, that doesn’t happen too often! As soon as I highlight and double click on the one that I want to assess, I get a screen full of all the details of that claim.

Contd. – Those include the claim reported date and the nature of the claim (injury or damage). The Claimant’s name, address and phone no are also displayed. There is a button ‘View Accident’ that I can click if I want to see the details of the accident, but usually I don’t need to do that. There is also a button that I can click to look up prior claims made by the claimant – some of them do try it on a bit!. I then click one of the four radio buttons to choose settle, reject, refer to underwriter or choose an expert. If I choose an expert, a button is enabled that allows me to go into another screen and allocate an expert depending on what type of expert I need. If I choose to settle, I must put a valuation on the claim.

Sub- and Alternative flows Sub-flows are reused sub-tasks that are used by this task. Alternative flows are flows that are used when conditions are not as expected in the task.

Pre- and Post-Conditions The pre-conditions are conditions that need to be in place before a task can be carried out. –e.g. Task = make a cup of tea Pre-condition = tea bag / tea leaves, boiling water, cup. The post-condition is the condition that the task leaves behind it –e.g. Task = withdraw cash from ATM. Post-conditions = card retrieved, cash dispensed, account balance adjusted (also known as exit conditions). What are the pre-conditions for ‘Assess a Claim’?

Requirements Elicitation Use scenarios to communicate with users and to validate functionality. First, refine a simplified view (i.e., Many not-very detailed scenarios) to define the scope of the system. Validate with the user. Use mock-ups as a visual support only; User interface design should occur as a separate task once the functionality is sufficiently stable. Present the user with multiple alternatives (as opposed to extracting a single alternative from the user).

Documenting the Use Case Lay out the headings as shown previously in slide 5 above. Put the details of each below. Rational Rose is NOT good for documenting Use Case details at this level, but this documentation can be put in at operation level. E.g. Verify an Incident

Intent The intent of this task is to verify that an incident that has been reported by a third party did in fact occur and that all the details are correct. The driver views the details of the incident as reported by the third party and verifies, amends or rejects them.

Description The driver calls up the screen with the details that the third party has supplied. If the driver agrees to the text, he clicks a button labelled 'verify'. If the driver has some disagreement, he clicks a button labelled 'adjust'. This causes an empty incident form to be displayed, which he fills and clicks 'submit'. If the driver disagrees that the incident happened at all, he clicks 'reject'.

Pre- and Post-conditions Pre –Driver is aware that a report needs to be verified –An unverified incident report has been filed Post –The incident report changes status to verified, verified with amendments or rejected.

Updated claims system

Extras in this diagram Extra Use Cases from screens added Underwriter stereotype displayed as a label with a decoration. –This is more appropriate, because the Underwriter is a firm, not a person.