Course Title
4.5 Requirements management
Figure 4.5: Requirements in Agile
- Stories – statement of requirement, defining a stand-alone portion of functionality in the everyday or business language. Fine granular. May also be written to developers for non-functional requirements (performance, security, etc.)
- Have a format:
- Title:
- As a [ROLE] I would/should/must [DO SG] to be able to [ACHIEVE SG]
- Acceptance criteria detailed
- Linked to an Epic, can have labels, Planned release version labels and a Fix version
- E.g.:
- As an end-user I must be able to add search criteria on the UI to make me able to find services on-line with the on-line Yellow pages software.
- Acceptance criteria:
- On the UI there must be two fields:
- Search by name: text field of a max. of 30 characters
- Search by phone number: text field, validating that only [0-9] numerical entry is provided
- Only one field is to be filled; if one has even only 1 character of entry, other field will get disabled and turned into grey on the push of a key
- Below the fields, there is a search button: on click, search is started (functionality detailed in related user story, ID: Phonebook-2)
- On click validation of 30 char limit and numerical entry is provided; if validation fails, pop-up is shown (functionality detailed in related user story, ID: Phonebook-3)
- EPIC link of the Story: “Phonebook-Search”
- On the UI there must be two fields:
- Acceptance criteria:
- As an end-user I must be able to add search criteria on the UI to make me able to find services on-line with the on-line Yellow pages software.
- Title:
- Have a format:
- Tasks – small pieces of work required to complete a story; including low level technical details needed for engineers
- Epics group user stories defining the same functionality. Block of requirements.
- E.g. Search & view results of phonebook
- Product backlog
- A prioritized list of user stories, representing Stakeholders' needs and requests
- The higher the priority is, the higher the likelihood is to add the item to the next Sprint's Backlog (which is a distinct list of items committed for the upcoming Sprint)
- Requests range from functional to non-functional requirements, technical infrastructure requests, support and maintenance tasks.
- What is not in the backlog, should not be taken care of
- PO is responsible to maintain the backlog
- Backlog items have estimates
- A prioritized list of user stories, representing Stakeholders' needs and requests
- Sprint Backlog
- List of items committed to be done for the actual Sprint