Writing Effective Scenarios and Use Cases

Timetable Introductions Strategies for gathering requirements refreshments Creating a Scenario Creating a Use Case lunch Creating a Use Case (continued) Using a Use Case – gathering requirements refreshments Review

Book Writing Effective Use Cases Alistair Cockburn Page references Short, true stories , 54, 63, 104, 169, 170, 175

Introductions

Strategies for gathering requirements - Introduction Charles Duncan, Intrallect

Why use scenarios and use cases? Scenarios and Use Cases are not an end in themselves, they are for: –Eliciting requirements (e.g. of software systems) –Modelling business processes –Drafting or sizing system requirements –Writing functional requirements For a small (short-timescale) project For an iteration in a larger project In all cases they are a basis for communication and discussion 132

Glossary Important to share a common vocabulary See handout See book Important terms –Action step: Single active-verb phrase/sentence –Actor: Someone playing a role (e.g. teacher, student) –Scenario: Narrative describing how an actor achieves a goal through a series of action steps –Use Case: Collection of scenarios, expressing all possible behaviours as actor tries to achieve goal

Structure Project, System, Service Use case Scenario Action step Use case

Example – action step Alan (teacher) logs into repository using ATHENS authentication –Other actions may achieve the same result –This action may result in success or failure –This high-level action step could be defined in much more detail in a use case of its own

Example - scenario Alan, a maths lecturer, uses a learning object repository to find a simulation of the behaviour of an equation. He logs in using his Athens account, searches using suitable keywords, finds the object and obtains a reference to the object that he uses in the class web site. He demonstrates the simulation in a lecture by using the class web site. –Describes usage, not requirements –Defines key stakeholder (primary actor) and his goal –Lists the action steps in a narrative text –Scenarios are often written to reflect success

Example - use case Goal: Teacher locates a learning object in a repository and uses it in another web site Primary actor: Teacher Other actors: repository, authentication system, web site Main success scenario: 1. Teacher logs into repository with ATHENS authentication 2. Teacher searches for object by keywords 3. Teacher identifies suitable object 4. Teacher obtains reference to object 5. Teacher uses reference in web site Other scenarios (extensions): 1a. Teachers authentication refused (fail) 1b. Teacher authenticates using a local LDAP authentication (s) 3a. Teacher cannot find suitable object (f)

Use Case – points to note Expresses behaviour of the system in response to the primary actor trying to achieve the goal Takes account of different success and failure scenarios Identifies all actors – systems, as well as people Use cases can be: –User-goal –summary (involving many user goals over a prolonged period) –sub-function (low-level detail, e.g. how authentication is implemented)

Use Cases versus Scenarios Use cases and scenarios are not alternative approaches – they are different stages of the same approach Scenarios are easier to gather from non-technical groups, but they often only describe success Use cases gather common scenarios (those that use largely the same action steps) but also handle all the success and failure extensions Scenarios without use cases are useful for discussion but are incomplete for expressing behaviour. Use Cases are contracts for behaviour

Strategies for gathering requirements - Experiences Ed BarkerDigital Rights Management Peter DouglasLearning Activity Design Charles DuncanAgile Software Development

Digital Rights Management Project Details funded by JISC and completed in November 2004 The aim was to determine the best approaches for JISC and the UK education and research communities to adopt in relation to DRM Use cases were produced from five workshops – Produced 32 detailed use cases and 125 use case summaries. Key Points Objective was very wide There was uncertainty about processes and stakeholders

Methodology Explain aims of project and how they relate to the aims of the workshop (45 minutes) Explain the methodology for producing use cases (45 minutes) Attendees worked in pairs to create a full use case Attendees given time at end of workshop to ask questions and make further points

Results and Analysis Use Cases were anonomised and included in final report. Statistics about primary actors and objectives were collected. A set of requirements were extracted from the use cases

Strengths and Weaknesses Strengths Allowed us to identify the main concerns of the community Captured user requirements in a technology independent way Allowed each person at workshop to have input to the study Weaknesses Requirements gathering is open to interpretation. Some use cases were a bit vague or away from the point. Time Consuming

LADiE Project Details Learning Activity Design in Education funded by JISC and to be completed in March 2004 The aim is to develop a Reference Model for Learning Activities based on the principals of the eFramework Key Points Scope of domain is very wide Wanting to encourage imaginative/innovative learning activities

Methodology Same as DRM project! Held one workshop which was not a success –Confusion between delivering learning activity with creating a learning activity –Use Case generation proved difficult - where is the student? –Tried to achieve too much in one day Conclusion? –Tutors not the ones to write the use cases, but they do have useful information to provide

What we are doing now Holding workshops with tutors, but focusing on capturing the structure of the learning activity. Project team uses this information to generate more formal Use Cases Some use cases coming in directly from groups/projects

Agile Software Development NOT the waterfall method –User requirements, specification, development, testing, installation Small iterations, XP –Define usage (scenarios/stories), create tests for usage unit, develop only necessary code, run unit tests, integrate unit into system, run all tests, working system exists Scenarios/stories are written throughout the project lifecycle, not just at the start 187,

Example story

Example tests

Pros and Cons Pros –Fast, well-tested, always a working system –Only essential code is produced –Flexible – can change priorities each iteration –Rapidly builds huge test bank –Dynamic balance of resources, time, requirements –Stories can be used for effort estimation and prioritisation Cons –Not so suitable for database and user-interface design –Periodic refactoring (revision) is needed to improve structure (but tests are invaluable at this stage)

Use cases? Scenarios are short, light narratives, enough for the customer and the developer to agree on what is needed Tests are where the behaviour is handled, again defined in a way that allow the customer and developer to agree what needs to be satisfied to recognise that the scenario behaves as expected