IT:AD:User Story
* (UP)
* See also:
Summary
Notes
- It is written in the language of the System/End Users (whether they be Business Users or Business Customer Users).
- It does not contain the design detail one would expect to find in a System Design Requirement.
- The most common syntax used is “As a <role>, I want <goal/desire> so that <benefit>“
- A suggested alternate is to “hunt the value”: “In order to <receive benefit> as a <role>, I want <goal/desire>“
- Advantages:
- Written in the language of business users, therefore good conversation starters.
- The Agile process requires constant business engagement.
- Considerations:
- A user story is an informal statement of a requirement.
- The User Story's corresponding Acceptance Tests are required.
- Disadvantages:
- Incomplete specifications that on their own are considered weak and open to interpretation.
- This leads to several risks:
- the Developers must remember to refer separate NFR documentation at all times.
- Acceptance tests have to refer to separate Supplemental/NFR documentation.
- Differences interpretations will occur.