Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
What is a requirement?
Wikipedia: A statement that identifies a necessary
attribute, capability, characteristic or quality of a system,
for it to have value and utility to a customer or
stakeholder
Succinct definition: Describes what the system must be or
provide in order to be useful
Techniques for documenting requirements
Lightweight to heavyweight
Traditional to modern
Formal to casual
We will discuss three:
Use Cases
User Stories
Specification by Example (discussed later in the course, if
we have time)
Use Cases
First described by Ivar Jacobson in mid 80s
Important contributions from Alistair Cockburn
What is a Use Case?
A contract between the stakeholders of a system about its behaviour
Describes the systems behaviour as it responds to a request from one of the stakeholders, called the primary actor
Use cases are best presented as prose (simple writing)
Use Case Example I
Primary Actor:
Scope: Finance package (’package’)
Level: User goal
Stakeholders and Interests: Purchaser - wants to buy stocks, get them added to the package portfolio automatically.
Stock agency - wants full purchase information.
Precondition: User already has package open.
Minimal guarantee: sufficient logging information that package
can detect that something went wrong and can ask the user to
provide details.
Success guarantee: remote web site has acknowledged the
purchase, the logs and the user’s portfolio are updated.
Use Case Example II
Main success scenario:
1. User selects to buy stocks over the web.
2. Package gets name of web site to use (E*Trade, Schwabb,
etc.) from user.
3. Package opens web connection to the site, retaining
control.
etc...
Use Case Example III
Extensions:
2a. User wants a web site package does not support:
2a1. System gets new suggestion from user, with option to
cancel use case.
etc...
How would you classify Use Cases?
Lightweight or heavyweight?
Traditional or modern?
Formal or casual
Pros of Use Cases
Good for understanding intent and goals
Possible flows (extensions)
Finding stakeholders
Other actors and systems
Cons of Use Cases
Verifiability (tests) are not explicit
Planning – represent relatively large chunks of work, hard
to break down and estimate
Prose - ambiguity
Longer - harder to write and maintain, require more
investment (in some contexts, too much) in the
requirements phase
User Stories
First described by Kent Beck in late 90s as part of XP
Important contributions by others over time
Pros of User Stories
Short, lightweight - easy to maintain
Conveys user goals well - derive value
Includes verifiability criteria
Promotes conversation
Cons of User Stories
Easy to leave incomplete
Potential lack of context
May not scale well for large projects
User Stories Overview
What are User Stories?
Story slicing
Story size
Acceptance tests
User roles
Story mapping
Story estimation
Aspects to a user story
Three aspects to a story:
1. A brief written description of the story
2. Conversations about the story to flesh out the
detail
3. Tests that convey and document details. Used to
determine when the story is complete
3Cs: Card, Conversation, Confirmation
Story Size
A right-sized story from a user’s perspective is one
that fulfils a need.
A right-sized story from a development team’s
perspective is one that takes just a few days to build and
test.
A right-sized story from a business perspective is one
that helps a business achieve a business outcome.
An epic is a story that we expect is large, and know needs
to be broken down.
Written Description; Levels of Detail
As a <type of user>, I want <some goal> so that <some
reason>
An Epic Story:
As a user, I can backup my entire hard drive.
Too large for a single iteration, split into one or more
stories
Splitting the Epic
As a <type of user>, I want <some goal> so that <some reason>
As a power user, I can specify files or folders to
backup based on file size, date created and date
modified.
As a user, I can indicate folders not to backup so that
my backup drive isn't filled up with things I don't need
saved.
Acceptance Tests or “Conditions of
Satisfaction”
Write on the back of the story card
Example
Context: Managing the shopping cart on a book seller’s
site
The user story in question:
A user can put books into a “shopping cart” and buy
them when she is done shopping.
The Acceptance Tests
Put an out-of-stock book into the cart. Verify that the user is
told that the book will be shipped when it becomes available.
Put a book that hasn’t been published yet into the cart. Verify
that the user is told that the book will ship when available.
Put a book that is in stock into the cart. Verify that it appears
in the cart
Put a second copy of a book into the cart. Verify that the count
goes up.
User Roles or Personas
As a <type of user>, I want <some goal> so that <some reason>
Consider a job posting and recruitment site
Identify different types of job seekers
User Roles or Personas
As a <type of user>, I want <some goal> so that <some reason>
Consider a job posting and recruitment site
Different types of job seekers:
Tumi – university graduate looking for her first professional job
Allan – looking for any job in Cape Town so that he can windsurf after work
Ashish – has a job but is on the lookout for a better one
Brainstorm and Identify Roles/Personas
Job Seeker (eg. Tumi)
Geographic Searcher (eg. Allan)
Monitor (eg. Ashish)
Story Size
A right-sized story from a user’s perspective is one
that fulfils a need.
A right-sized story from a development team’s
perspective is one that takes just a few days to build and
test.
A right-sized story from a business perspective is one
that helps a business achieve a business outcome.
An epic is a story that we expect is large, and know needs
to be broken down.
Independent
Dependencies complicate planning and prioritization, and estimation
Worse:
A company can pay for a job posting with a Visa card.
A company can pay for a job posting with a MasterCard.
A company can pay for a job posting with an American Express card.
Better:
A customer can pay with one type of credit card.
A customer can pay with two additional types of credit cards.
Solutions: combine dependent stories or find a different split
Negotiable
Stories are short descriptions of functionality - not
contracts
Details to be negotiated in a discussion
Stories should not include detailed requirements even if
known. Can be annotated with key details
A company can pay for a job posting with a credit card.
Note: Accept Visa, MasterCard, and American Express.
Consider Discovery.
Negotiable
Too much detail could give the impression that the story
contains all of the requirements; no further need to have a
conversation
A company can pay for a job posting with a credit card.
Note: Accept Visa, MasterCard, and American Express. Consider
Discovery. On purchases over R100, ask for card ID number
from back of card. The system can tell what type of card it is
from the first two digits of the card number. The system can
store a card number for future use. Collect the expiration month
and date of the card.
Story cards are reminders to have a conversation, can contain
notes about issues to resolve during the conversation
Negotiable
Details become acceptance tests
A company can pay for a job posting with a credit card.
Note: Will we accept Discovery cards?
Note for UI: Don’t have a field for card type (it can be derived from first two digits on the card)
Tests on the back of the card
Test with Visa, MasterCard and American Express (pass).
Test with Diner’s Club (fail).
Test with good, bad and missing card ID numbers.
Test with expired cards.
Test with over R100 and under R100.
Valuable
To users
Also include stories valuable to purchasers (stakeholders)
All configuration information is read from a central location.
(Product is installed on multiple machines in an enterprise)
Throughout the development process, the development
team will produce documentation suitable for an ISO 9001
audit.
Valuable
Avoid stories which are only valued by developers (don’t
mention technology assumptions)
All connections to the database are through a connection
pool.
All error handling and logging is done through a set of
common classes.
Better variations
Up to fifty users should be able to use the application with
a five-user database license.
All errors are presented to the user and logged in a
consistent manner.
Estimable
May not be possible:
Lack of domain knowledge – discuss with customer
Lack of technical knowledge (first time use) - use a spike story
to gather information to estimate along with a story to do the
real work
Estimation in the large is inaccurate split large stories
into smaller stories.
Small
Stories which are too large or too small cannot be used
in planning
Epics or Activities in the user story map are useful to
have but are difficult to work with
Split stories to make them smaller but they still need to
be vertically slices!
Too small stories typically take longer to write down and
estimate then to just do them eg. Bug reports and UI
glitches. Combine into larger stories and schedule just
like any other stories
Split this story into smaller stories
“As a content manager, I can publish a news story to the
corporate website.”
From the conversation with the customer it turns out that:
The news article requires both editorial and legal
approval before publication
The news article requires a final review on the staging
website
Testable
Describe functionality which is testable
Automate tests as much as possible
Not testable (non-functional requirement)
A user must never have to wait long for any screen to
appear.
Testable version
New screens appear within two seconds in 95% of all cases.
Closed Stories
Finishes with a meaningful goal and sense of achievement
Context: A Recruitment Site
User Story: “A recruiter can manage the ads she has placed.”
Lacks closure as this is an ongoing activity
Prefer:
A recruiter can review resumes from applicants to one of her ads.
A recruiter can change the expiration date of an ad.
A recruiter can delete an application that is not a good match for a job.
Playing planning poker
A technique to compare estimates between team
members.
Root out any assumptions or lack of information.
For each user story, each team member plays a card.
Other variations use T-shirt sizes (small, medium and large)
What about the very large values ?
Each person places cards face down, and then turn them
over at the same time (why ?)
Resolve the spread by group discussion.
Large spreads can be caused by a misunderstanding.
Acknowledgements
Selected images used from “Head First Software Development” by Pilone/ Miles, the prescribed book for course.
“User Stories Applied for Agile Software Development” by Mike Cohn
“User Story Mapping” by Jeff Patton
Mike Cohn’s website:
http://www.mountaingoatsoftware.com/agile/user-stories
Images from the Elephant Carpaccio facilitation guide
http://bit.ly/1ktFnaY
Some slides by Joshua Lewis