Upload
emma-maldonado
View
225
Download
2
Tags:
Embed Size (px)
Citation preview
Writing Effective Scenarios and Use Cases
Timetable
10.00 Introductions10.10 Strategies for gathering requirements11.00 refreshments11.20 Creating a Scenario12.30 Creating a Use Case13.00 lunch14.00 Creating a Use Case (continued)15.00 Using a Use Case – gathering requirements
15.45 refreshments16.00 Review
Book
• “Writing Effective Use Cases”• Alistair Cockburn
• Page references
• Short, true stories
124
39, 54, 63, 104, 169, 170, 175
Introductions
Strategies for gathering requirements - Introduction
Charles Duncan, [email protected]
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
253-256
Structure
Project, System, Service
Use case Use case Use case Use case
Use case
ScenarioAction stepAction stepAction stepAction stepAction stepAction 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 caseGoal: Teacher locates a learning object in a repository and uses it in another web site
Primary actor: TeacherOther actors: repository, authentication system, web site Main success scenario:1. Teacher logs into repository with ATHENS authentication2. Teacher searches for object by keywords 3. Teacher identifies suitable object4. Teacher obtains reference to object5. Teacher uses reference in web siteOther scenarios (extensions):1a. Teacher’s 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 - ExperiencesEd Barker Digital Rights ManagementPeter Douglas Learning Activity DesignCharles Duncan 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
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
• 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– 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, 223-224
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