Requirements &
Writing User Stories
Requirements size aligns with technological and economic changes
Large requirements (large requirements specifications or formal specs) -- needed for situations where coding, linking, building, are expensive. (still true for aircraft)
Medium requirements (use cases) -- came in when coding, linking, building and shipping became cheaper, but were NOT free
Tiny requirements (stories) -- an option finally when coding, testing, shipping are effectively free (now, humans are the most expensive element)
Story!
Peruvian Taxes System
Requirements: Starting point
When computation was expensive, people took a long time planning their implementation, and that involved writing lengthy requirements.
Another reason was that systems were applied to high-risk problems, so fully specifying the requirements was important.
Hence:
Requirements used to be very very large documents
And used to be written very formally
Actually they still are, in situations where life is at risk!
First came big requirements
Thinking about big requirements
Then came medium requirements
And on...
And on!
Thinking about medium requirements
Then came smaller requirements
Then PICTORIAL requirements:
Thinking about smaller requirements
DEEP DIVE:
USER STORIES
USER STORIES
Role Goal Benefit
Sometimes just called the “User Story”
Definitions of Done
Sometimes called Acceptance Criteria
Engineering Tasks
Finally tiny requirements
RGB: As a shopper, I want to be able to buy something and then see it in my purchased list so that I can spend money on the site.
Definition of done: User clicks the button buy, and it appears in their purchased items, and is shipped to their home and the user will see the money deducted from their account
RGB: When I’m told that I’m not approved for purchase by the system, I want to be able to click “request approval” and then receive confirmation that the approval request has been sent
Definition of done: User is seeing “not approved, and clicks “request approval”, and then user’s ID appears in the list of approval requests, and an email is sent back to the user that their request is in processing
Engineering Tasks
User stories are then broken down by developers into engineering tasks.
These are NOT from a user perspective -- they are just things that need to be done to get the work completed (finish the parser; investigate the JSON library; set up the database; setup mocks for testing; etc)
Based on those tasks, the developers estimate how much time the story will take.
Thinking about tiny requirements
ROLE
GOAL
BENEFIT
DEFINITIONS
OF DONE
ENGINEERING
TASKS
Which users to test with
What behaviour to build
What tests to specify
Informs
What needs to be done
STORY POINTS
Informs
# of hours it will take
Helps prioritize user stories
Role Goal Benefit Statement
Have a Role (the specific type of user expressing the need)
Have a Goal (the behaviour desired)
Have a Benefit (the outcome of the behaviour)
RGB statement:
As a customer,
I want to be able to buy something
and then get it
Not Role Goal Benefit statements:
These are engineering tasks
Good definitions of done
These are your contracts with your clients
This is how you know you have completed a user story, and can mark it resolved
This is how you know whether you can test your user story (if you can’t, you need a different user story!!)
Definition of done: User clicks the button buy, and the item appears in their purchased items, and is shipped to their home.
User Stories: INVEST
(story points are the number of hours it will take one person)
STEPWISE REFINEMENT. (US->DoD->ET)
Each level is as precise as it can be for its level.
Bad Sample MT question:
T/F: It’s okay for US’s to be kind of vague because definitions of done will clarify them.
User story: As a customer, I want to be able to buy something and then get it
Definition of done: User clicks the button buy, and it appears in their purchased items, and is shipped to their home.
Engineering Tasks: Developer level tasks like refactor, set up database, set up framework, get the server up and running...
I: Independent
User stories should be independent of one another, but obviously they’re not implemented in a vacuum.
User requirements used to be hierarchical like this:
Edit Feature
Put red squiggles under misspelled words
Change text font
Copy and Paste Text
To implement the “Buy Something” feature, you would have to implement all the sub features. Only then would the product be done and ready to ship
That hierarchy vanished, leaving independent user stories
Put red squiggles under misspelled words
Change Text Font
Copy and Paste Text
Each of these user stories can be implemented independently. They may be prioritised differently, and their engineering tasks may build on each other, but they can be thought of without thinking of them as a collection. The product can ship with one of these, without having to have the rest.
N: Negotiable
Users didn’t used to have a lot of bargaining power when talking about the requirements specifications for their systems. This was mainly down to the fact that the requirements were very difficult to read. Users would not be able to play out what the eventual look of a feature would be -- they would assume they knew, and they might well be wrong. At the time the finished product was released, there were often unpleasant surprises.
Negotiable means that clients have to be able to fully understand and critique how a feature will look in the end. This means that they are clearly written. The time estimates also have to be present so a customer can decide whether the amount of time spent on a particular story is worth it to them.
V: Valuable
You MUST be providing value to a customer. They are the ones paying for the development effort. Extra stuff like “cleaning up the documentation so you’ll have an easier time later” either needs to be thrown out, or put into an engineering task and revealed to the customer so that they can negotiate whether it’s valuable to them.
E: Estimable
This is one where I think they kind of just needed the letter “E”, but it generally works. Estimable means that the user story should be written in a precise enough way that a developer can estimate how long it will take. This is a value hugely to the developer because projects can run over time if requirements are vague. “Not realising what they really wanted” is not an option here, because the work must be estimable.
S: Small
This is in direct contrast to “Big”. Which is how requirements used to be. They used to be WHOLE FEATURES that spanned the entire lifetime of the product. So ALL of the “Edit” feature, for instance, would chunk in at once from the user’s perspective, and so “Edit” was one massive requirements document, with a thousand sub-requirements that might take a year to complete.
Now, stories are added incrementally to products (in clusters, but you get the idea), and so they are small enough to fit within the work span of a couple of weeks. If it’s larger than that, you need to split it up.
T: Testable
This is how you know you’re done, and that you’ve built what you said you were going to build. You need to know how to test, what to test, and what it means when all those tests pass (and this refers to either user or unit tests). Some things are NOT testable. For instance “Make the user happy” is not testable. You can’t actually measure whether someone is happy. “Help the user select x things in y seconds” is testable. You can see whether, on average, over a certain population, users are generally able to be able to come through with that timing.
Let’s examine:
Architectural context: email system with a database of contacts.
User story: As a user, I want to search for contacts so I can message them.
Definitions of done: user can enter a name into a text box and then see a message button [and shows the list of contacts matching the search with buttons next to each one]
Let’s examine:
User story: As an employer, I want to post a job on the website so people can apply for it.
Write a user story for Checkpoint 1. Remember you need a Role, a Goal, a Benefit. And it needs to be independent, estimable, testable, etc.
Examinable skills from this lecture:
Write user stories with the correct format, and meaning
Write unambiguous definitions of done
Identify why some user stories are not good user stories (because they are ambiguous, or too large, or not testable, for instance -- INVEST principles)
Explain why, as professionals, definitions of done are important
Explain how definitions of done drive test suites
Explain the difference between a story and a task, and identify which is which
Explain how requirement lengths are motivated to some extent by technological and economic concerns
Explain how user stories relate the problem domain to the solution domain to capture client expectations
Requirements and Writing User Stories