When starting my last project, I spend on this topic several days. Should I use requirements or user stories for definition of what user needs?
Both have Pros and Cons. Let’s look at it.
Requirements
- can contain any information you choose or consider as important. Even a business wish or proposed (not demanded) solution.
- can be small or large
- can be structured or unstructured
- can be specified for detail or high-level
- usually providing exact information (limitations or obligations) not the purpose or the intention behind
- used in waterfall / SDLC structured projects
User stories
As a man, I want to see the sun, so that I will stay healthy and relaxed…
- are nothing more, than a structured and minimized format of requirements
- contains role, what has to be done and reason why
- can be detailed or mid-level (on higher levels, grouping of user stories makes an Epic)
- need to add acceptance criteria to develop more detail level
- used in agile delivery
So overall what to pick? Flexibility, but with lots of space to miss the intention of user, or user stories, which are more fuzzy on the details?
Well, the hardest part in any project in our lives is communication. Remember silent post game from childhood? And it’s a long way from end-user to a programmer, even in agile environment. So if you transfer the intention by creating a good user story, you will also transfer a lot of context with it too. Then the guy on the solution side, can use his own creativity to find feasible solution within technical limitations or possibilities in front of him.
In short: your probability of success to meet the user needs will raise dramatically.
Game Changer 