COMP1531
7.3 - SDLC Requirements - User Stories & UAT
SDLC
Requirements
Requirements
Requirements Engineering
Elicitation
Analysis
Specification
Validation
User Stories
User Stories - Overview
User Stories are a method of requirements engineering used to inform the development process and what features to build with the user at the centre.
User Stories - Structure
When a customer tells you what they want, try and express it in the form As a < type of user >, I want < some goal > so that < some reason >
E.G. They say:
-
E.G. They say:
- A student can purchase monthly parking passes online
-
But your story becomes:
- As a student, I want to purchase a parking pass so that I can drive to school
User Stories - Structure
Product
Epic 1
Story 1
Epic 2
Epic 3
Story 2
Story 3
Story 4
Story 5
Story 6
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
User Stories - Nature
User stories:
- Are written in non-technical language
-
Are user-goal focused, not product-feature focused
- User stories inform feature decisions
Why do we care?
- The keep customers at the centre
- Keep it problem focused, not solution focused
User Stories - Activity
Building a to-do list
User Stories - More
How do we know we've met the user story requirement?
INVEST
- I = Independent: user story could be developed independently and delivered separately
- N = Negotiable: avoid too much detail.
- V = Valuable: must hold some value to the client
- E = Estimable: we'll get to this in a later lecture
- S = Small: user story should be small
- T = Testable
User Acceptance Criteria
- Break down a user story into criteria that must be met for the user, or customer, to accept
- Written in natural language
- Can be refined before implementation
Example
As a user, I want to use a search field to type a city, name, or street, so that I can find matching hotel options.
- The search field is placed on the top bar
- Search starts once the user clicks “Search”
- The field contains a placeholder with a grey-colored text: “Where are you going?”
- The placeholder disappears once the user starts typing
- Search is performed if a user types in a city, hotel name, street, or all combined
- The user can’t type more than 200 symbols
Best practices
- Acceptance criteria should not be too broad
- ... but nor should they be too narrow
-
Minimise technical detail
- They can be more technical than the story itself, but client still needs to understand them
- While they can be updated during development, they should first be written before it starts
From Criteria to Testing
- Acceptance Tests are tests that are performed to ensure acceptance criteria have been met
- Not all acceptance criteria can easily be mapped to automated acceptance tests
- Acceptance tests are black-box tests
Example 2:
As a user, I can log in through a social media account, because I always forget my passwords
- Can log in through Facebook
- Can log in through LinkedIn
- Can log in through Twitter
Scenario Oriented AC
- The Acceptance criteria from before are often referred to a rule-based AC
- Sometimes it is preferable to have AC that describe a scenario
-
This can be done in the Given/When/Then format:
- Given some precondition
- When I do some action
- Then I expect some result
Example 3:
As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.
Scenario: Forgot password
Given: The user has navigated to the login page
When: The user selected forgot password option
And: Entered a valid email to receive a link for password recovery
Then: The system sent the link to the entered email
Given: The user received the link via the email
When: The user navigated through the link received in the email
Then: The system enables the user to set a new password
Which one to use?
- Rule-based acceptance criteria are simpler and generally work for all sorts of stories
- Scenario-based AC work for stories that imply specific user actions, but don't work for higher-level system properties (e.g. design)
- Scenario-based AC are more likely to be implementable as tests