Writing Effective Scenarios and Use Cases Timetable 10

Writing Effective Scenarios and Use Cases

Timetable 10. 00 10. 10 11. 00 11. 20 12. 30 13. 00 14. 00 15. 45 16. 00 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 124 • Short, true stories 39, 54, 63, 104, 169, 170, 175

Introductions

Strategies for gathering requirements - Introduction Charles Duncan, Intrallect C. Duncan@intrallect. com

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 253 -256 • 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 Usecase Use case Use Scenario Action Action step 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): 1 a. Teacher’s authentication refused (fail) 1 b. Teacher authenticates using a local LDAP authentication (s) 3 a. 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 Barker Peter Douglas Charles Duncan Digital Rights Management Learning Activity Design Agile 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” • http: //www. intrallect. com/drm-study/ • 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

LADi. E 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 e. Framework • http: //www. elframework. org/refmodels/ladie/ 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 187, 223 -224 – 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

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