I am often asked this when delivering training on writing requirements. The most obvious difference is semantics. A user story is generally written as a statement of something a user wants to do with a system and for what purpose. For example:
I want to find clothing that is my size.
While a requirement statement is traditionally written in a more formal style, starting with “The system shall”
The system shall provide a list of the available shirt sizes.
The system shall enable a user to select a size of shirt to purchase.
The system will inform a user when an item is out of stock.
It is often also pointed out that requirement statements provide more detail, while a user story is almost intentionally vague. A user story is a placeholder to be used to make rough estimates on the time and effort required to implement it and to have enough understanding of what it entails to be able to prioritize it against other user stories. User stories are intended to emphasize face to face communication, so you leave much of the detail to be fleshed out later.
Traditionally, requirement statements are written to express a need unambiguously, implying that after reading the requirements a developer will have enough information to start designing and developing without further communication with the customer.
You can see with my above examples how quickly a requirement document can reach several hundred pages, while the user stories for the same system could be written on a collection of note cards. Agile proponents, including Michael Cohn, are fond of taking the IEEE guidelines for writing requirement statements and pointing out how reading 300 pages of requirement statements gives the developer no perspective on what the system is intended to satisfy, and that as no one reads these documents they are a waste of time and effort when compared to user stories. Also, in highly fluid environments where requirements change frequently, specifying this much detail up front is meaningless because the details will likely change before implementation anyway.
On the other hand, project managers at aircraft manufacturers are quick to point out that stating “The plane shouldn’t crash in a storm” and relying on face to face communication across tens or hundreds of contractors and suppliers and hundreds or even thousands of engineers across corporate barriers, time zones and languages isn’t very practical.
So, when asked this question, I respond in true consultant fashion – by saying ‘It depends” and then asking another question. In most cases, what people want to know is not the difference between user stories and requirements, but which should they should use.
I see statements of need as a continuum, not a dichotomy, and I don’t see them as mutually exclusive. User stories, and Epics, are on one end of the spectrum, where high fidelity communication between development and its customers is available. IEEE requirement statements are more useful at the other side of the spectrum, where customers are inaccessible and face to face communication even between engineers is often impossible.
Most of us are somewhere in the middle, however, and a combination or blend of the two is probably the most effective. In environments where most development is outsourced overseas, for example, user stories are going to be less efficient and will probably have to be supplemented with more explicit requirement statements than if it were being developed in-house. On the other hand, if the software is going to be purchased off the shelf, user stories may be sufficient to narrow down a list of products for demonstration and evaluation.
One last point is that there is no right or wrong level of detail for a requirement statement. Technically, all of the following are “correct.”
The system shall provide multiple payment methods
The system shall allow payment with credit card.
The system shall allow payment with VISA and Mastercard, but not American Express.
Which level of detail is right for your environment depends mainly on how much you can rely on face to face communication with subject matter experts to flesh out the details later, and on how likely details are to change in the near future.