1. 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