72 lines
2.3 KiB
Markdown
72 lines
2.3 KiB
Markdown
|
### Feature: `Role or Persona` `Priority` `Objective`
|
|||
|
|
|
|||
|
|
`Role or persona` What kind of users are we talking about in this particular user story?
|
|||
|
|
`Priority` We need to ask users about how important each feature is. Using the MoSCow method to prioritize requirements. This method is based on four main categories: must, should, could, and won't.
|
|||
|
|
`Objective` What is the users' final objective by using this feature?
|
|||
|
|
|
|||
|
|
*Example*
|
|||
|
|
|
|||
|
|
> Feature: User must log in to access the app.
|
|||
|
|
|
|||
|
|
#### User story:
|
|||
|
|
|
|||
|
|
As a `role or persona`
|
|||
|
|
I `must/should/could/won't` `goal/need`
|
|||
|
|
So that `value`
|
|||
|
|
|
|||
|
|
*Example*
|
|||
|
|
|
|||
|
|
> User story:
|
|||
|
|
>
|
|||
|
|
> As a user,
|
|||
|
|
> I must be sent a link to reinitialize password when requested,
|
|||
|
|
> So that I can log in and access the app.
|
|||
|
|
|
|||
|
|
#### Acceptance criteria
|
|||
|
|
|
|||
|
|
|
|||
|
|
###### Scenario-oriented acceptance criteria
|
|||
|
|
|
|||
|
|
`Scenario` the name for the behavior that will be described
|
|||
|
|
- `Given` the beginning state of the scenario
|
|||
|
|
- `When` specific action that the user makes
|
|||
|
|
- `Then` the outcome of the action in “When”
|
|||
|
|
- `And` used to continue any previous statement
|
|||
|
|
|
|||
|
|
*Example*
|
|||
|
|
|
|||
|
|
> Scenario: User 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
|
|||
|
|
|
|||
|
|
|
|||
|
|
###### Rule-oriented acceptance criteria format
|
|||
|
|
|
|||
|
|
In some cases, it’s difficult to fit acceptance criteria into the Given/When/Then structure. For instance, design and UX features. Also when visuals exist they should be linked.
|
|||
|
|
|
|||
|
|
- [ ] item 1
|
|||
|
|
- [ ] item 1-1
|
|||
|
|
- [ ] item 1-2
|
|||
|
|
- [ ] item 1-3
|
|||
|
|
- [ ] item 1-4
|
|||
|
|
- [ ] item 2
|
|||
|
|
- [ ] item 2-1
|
|||
|
|
- [ ] item 2-2
|
|||
|
|
- [ ] item 2-3
|
|||
|
|
- [ ] item 2-4
|
|||
|
|
|
|||
|
|
*Example*
|
|||
|
|
|
|||
|
|
> - [ ] Basic new password interface acceptance criteria
|
|||
|
|
> - [ ] Password must be > 8 characters
|
|||
|
|
> - [ ] Password must contain at least one special character
|
|||
|
|
> - [ ] Password must contain at least one upper case letter
|
|||
|
|
> - [ ] Password must contain at least one minus case letter
|
|||
|
|
> - [ ] Password must contain at least one number
|
|||
|
|
> - [ ] Max password length is 255 characters
|