Mfrhtyj

In this accepted answer (from Software Engineering StackExchange) to a question targeting my blocker, one can read:

(...) think of user stories as a subset of requirements (...)

It's quite tempting to take this and move on...

So, what exactly is requirement, user-story and how they relate to each other?
(Please consider adding some examples so that it's easier to create a mental model)

While user stories can absolutely be considered a type of requirement, there are distinct differences between user stories and other requirements that I don't see here or in the accepted answer on the Software Engineering site (though it is touched on in other answers).

Most important amongst those differences is the way in which they encourage the team and user to engage. Remember that in XP, where User Stories originate, that there is no product owner. The customer writes user stories. Because of this, the User Story is an exercise in understanding the needs of the customer. Some of the most effective user stories are completely lacking in any requirements and only discuss the need and let the team come up with a solution.

A common example I use to illustrate this difference is a hypothetical story from a tax filing application. This would be a bad user story:

As a tax payer, I want to fill out my tax form so that I can file my
taxes.

This "user story" matches the commonly accepted form for a user story and would be relatively easy for a team to understand and implement, so why is it a poor user story? The problem is it fails at the fundamental purpose of a user story - understanding the customer. No one wants to fill out a tax form. A more appropriate user story would probably look something like this:

As a tax payer, I want my taxes filed accurately so that I get my
refund back.

Notice, no implementation details at all. Just a need for the team to solve. Now, these are hypothetical, but if you've used TurboTax, you probably know that not only do they dominate their market, but they also never ask you to fill out a tax form, so it's not far off of reality.

It's best to think as user stories as a sub-class of requirements.

IEEE and IIBA both use a three-part definition for what a requirement is:

1. a condition or capability needed by a user to solve a problem or achieve an objective


2. a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or
   other formally imposed document


3. a documented representation of a condition or capability as in (1) or (2)

User stories are #3 with regards to #1 or #2 -- they're (very light) documentation of a condition or capability the product needs to have.

What's the difference between user stories and (e.g.) functional requirements? A few would include:

• User stories tend to be at a slightly higher level than functional requirements (more in line with what Karl Wiegers called "user requirements"). Functional requirements are typically more similar to the user story's acceptance criteria.


• The typical user story and functional formats are quite different ("As a... I want... So I..." vs. "The system will [...]"


• User stories tend to be used in agile environments, and functional reqs tend to be used in non-agile projects

It's worth pointing out that there are dozens of other types of requirements (e.g. business, user, non-functional, data, interaction), and they're distinct from user stories for the same or similar reasons.