- Specification (User stories and scenarios)
Elaboration
Use of narratives/storytelling are effective in eliciting/validating useful information from concrete examples of
How they should be running in the system-to-be
How things are running in the system-as-is
Storyboards: tells a story in terms of a sequence of snapshots
Who the players are
What happens to them
How it happens through specific episodes
Why this happens
What if such and such an event occurs
What could go wrong as a consequence
Specification: document all requirements
User story
Brief description of the user and his/her core need
Narrative descriptions of user roles or personas using a product to achieve specific goals
As a <user role> I want to <goal> so that <benefit>
Level of detail: multiple levels of abstraction
Months: bigger than a release = EPIC (high-level overview of what is desired, broken down just-in-time into sprintable stories)
INVEST criteria for user stories
Weeks: bigger than a sprint = FEATURES
Days: sprint ready = SPRITABLE STORIES (themes are collections of related sprintable stories)
Hours: tasks
Independent
Can easily develop
Independent or at least only loosely couple with one another
Negotiable
Details of the stories should also be negotiable
User stories leave room for the product owner, stakeholders and team to negotiate the details
Valuable
User stories need to be valuabe to a customer, user or both
Expect change in agile
Estimatable
User stories should be estimatable by the team that will design, built and test
The development team can know how much they can get done
Sized appropriately
User stories worked on in sprints should be small
Can be finished within a sprint
Testable
User stories should be testable in a binary way - pass/fail
Writing user stories
Use personas for user stories
Go back to goal model: sub-goals are generally sprintable stories
All team members should write the user stories
User scenarios
Detailed description of what users do with the product + why they do it
Longer + more informative than a user story
Describe an experience, focusing on people, and how they think and behave
Capture the non-verbal dialogue between the user and a product
Can role-play prsonas as the characters in these scenarios
Context scenarios
Day-in-the-life scenario
Used to explore, at a high level, how the product can best serve the needs of the personas
An ideal user experience
What primary activities does the persona need to performm to meet her goals?
What is the expected end result of using the product?
Key-path scenario
Advantages
Disadvantages
More specfically describing user interactions with the software
Concrete examples provide a good basis for
Asking specific questions about them
Understand the underlying objectives
These scenarios focus on the most significant user interactions, always maintaining attention on how a persona uses the product to achieve their goals
Types of scenarios
Positive: what should happen in terms of one behaviour that the system should cover
Negative: what may not happens in terms of one behaviour that the system should exclude
Normal scenario: a course of interaction where everything proceeds as normally expected
Abnormal scenario: capture desired interaction sequences under exceptional circumstances that depart from the normal course of interaction
Used to build a shared understanding
Can be used as test cases when we define acceptance tests from the requirements
Inherently partial: just examples, do not cover all possible system behaviours under all possible circumstances
Too early use of scenarios may introduce some risk of over specification
Unified modeling language (UML)
Widely adopted for object-oriented modeling and design
Use cases are used for requirement specification in UML
Consists of a series of actions that a user must initiate with theh system to carry out some useful work and to achieve his/her goal
Produces measurable result for a particular actor
Must represent the point of view of the people who will use/interact with the system
Should be considered as a unit or requirement defintion (user goal)
A complete set of use cases = system requirements
Notation
Use case
Actor
System boundary
Association
Prioritise using MoSCoW
Must have
Should have
Could have
Would have