As a book lover I want to be able to buy books simply and securely, So that I do not run out of reading materials.
User stories describe the needs that an IT system is meant to fulfil from a stakeholder group’s point of view. This is why they are requirements.
But can user stories be good requirements? According to the International Requirements Engineering Board (IREB), a good requirement has to fulfill the following criteria
Children, laypersons and management have to understand
User stories are a common form for requirements because they are easy for the end user to understand. They are compatible with children, laypersons and management – all of whom should all be able to understand requirements in this form.[2, in German] This is certainly the case here.
However, it’s not possible to determine whether user stories are agreed or necessary without further information.
Traceability can be documented in a tool or on a story card by entering a source and linking to the code, for example, by entering a story number in the code’s version management system.
However, sometimes inconsistencies and realization problems can be built into a three-line text. In the example, “simply and securely,” contains an inherent contradiction between simplicity and security. Secure orders are complicated and simple order are often not secure. And to make sure that our reader does not run out of reading materials, we also rely on the speed of the provider. These quality problems can be fixed with a more vague user story:
As a book lover I want to buy books with simplicity and security, So that I can order more books when I run out.
Instead of deciding between security and simplicity, here we select the state of the technology. The unhelpful word “not” can also be removed from the requirement due to this re-formulation.
There’s one question still: Is this user story unambiguous, verifiable and complete?
“Simply and securely” is not verifiable, but the phrase “with simplicity and security” doesn’t make it any better. A requirement is verifiable when it contains test case information. According to behavior-driven development, there are three elements for this: prerequisite, trigger and result.
Something like this:
Under the prerequisite that the bookworm has an active account and is logged in, When they select a book and click “put in shopping cart”, Then the book is in their shopping cart.
This would be an optimum test case but it doesn’t verify the entire process of buying a book. It’s missing searching, ordering, paying, a whole list of other test cases. This user story only includes one business process, the entire modelling of which would take up more than an an A4 piece of paper
To really be unambiguous, verifiable and complete, the entire shopping process has to be modelled, as well as the exceptions and errors within it. Customers can buy one book, or more. What if a customer cancels during the process? Can they take books out of the shopping cart? Which payment types should be accepted? We need a shipping address to deliver purchases to. How and when do we make sure that we have one? When creating an account, or only when making a purchase?
This information or these requirements could be in other user stories, indeed they have to be, because a single story should not be too extensive – it should be possible to implement it in one iteration. According to the INVEST criteria from Bill Wake(independent, negotiable, valuable, estimable, small, testable), they should also be independent from other user stories.
It’s hard to write good requirements. High-quality user stories can’t really exist in a classical sense. They are either too short (three lines), too small (one iteration scope) or too simple (only the ideal case is presented).
 see IREB Foundation Level Syllabus, Chapter 4.6 https://www.ireb.org/content/downloads/2-syllabus-foundation-level/ireb_cpre_syllabus_fl_en_v222.pdf