User Story captures what the user wants to do with the system at a high level. I understand that the user story would further drive a number low level requirements. Is user story same as high level requirement for the system?

  • "User Story captures what the user wants to do with the system at a high level". I consider this contentious. I'd find myself agreeing if you replaced high level with feature level.
    – 8bitjunkie
    Commented Oct 21, 2015 at 13:14

8 Answers 8


To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement".

It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in well-written functional requirements. It's just as easy to write a bad user story as it is to write a bad requirement ("as [our company name], I want [vague feature] so that I can [do something that's self-evidently part of my job, like 'sell more to customers']").

What user stories almost never capture, in my experience, are non-functional requirements like performance and security. These kinds of requirements are very difficult to write properly and the format of the user story simply isn't very good for capturing them, because they're more about general product quality and mitigating (but not eliminating) risks rather than meeting a specific user's need.

So, I really think of user stories as a subset of requirements, with a specific formula, and still use the terms pretty much interchangeably.

The one major advantage user stories do have over requirements is that the word "requirement" suggests that a feature is required where it is often just desired. User stories can in theory be prioritized and slotted in for any release, whereas requirements appear to be a prerequisite for every release.

Of course, for the aforementioned distinction to matter, your customers and/or senior management must embrace it; it does you no good whatsoever if you have 30 user stories all grouped into a "project" that must all be completed at the same time. You might as well call them "requirements" in that case because they are in fact required.

  • 5
    I disagree: requirements focus on HOW the user interacts with the system, stories on WHAT purpose do features have. They are completely different things.
    – Sklivvz
    Commented Sep 30, 2013 at 10:06
  • 2
    @Sklivvz: I don't think I've ever read a user story that doesn't say something about how the user interacts with the system, and like I said, good requirements come with a statement of purpose so they can be understood in context. For some reason, a lot of people seem to automatically assume that "traditional requirements = bad requirements" and "user stories = good requirements". Neither is necessarily true. Take for example "EVO", which ties every requirement not only to a business goal but to an actual metric.
    – Aaronaught
    Commented Oct 1, 2013 at 0:07
  • 1
    @hanzolo: Now that's just silly. Tasks are way too granular to be of any use as functional requirements. Tasks are frequently stated at highly technical levels as in "implement a fringle parser using the jibbler library". You could maybe make a case for tasks being kinda-sorta-almost like specifications, but those come after the requirements. User Stories are supposed to come with Acceptance Criteria - those are a lot more like the detailed functional requirements used in Waterfall/RUP type models.
    – Aaronaught
    Commented Oct 1, 2013 at 0:11
  • 1
    @Aaronaught - Silly? "Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the actions the system will let users take" Where an example might be: "The user must be able to sort the project list in forward and reverse alphabetical Order" [Software Requirements 2, Karl Wiegers].
    – hanzolo
    Commented Oct 1, 2013 at 16:09
  • 2
    @Sklivvz: The "what" is generally an interaction between the user and the system. "I want to be able to see total votes on answers" is a typical example of the middle part of a user story, and is worded almost identically to a functional requirement ("The user should be able to see total votes on answers"). The "who" and "why" are the only parts that are ostensibly different, and many requirements tracking systems/methodologies other than user stories expect those to be provided as well.
    – Aaronaught
    Commented Oct 2, 2013 at 1:33

Ron Jeffries wrote a long time ago about the 3Cs of user stories (http://xprogramming.com/articles/expcardconversationconfirmation/) with the emphasis on a card (short description), conversation between the customers and the delivery team once a user story becomes actionable, and the agreed confirmation of a story after that conversation.

essentially, before the conversation, user stories are just planned scope - rough ideas about what we might do. after the conversation, you should have a way to confirm that the story is complete. So depending on the time when you look at the story in this timeline, a story might be just a broad idea about scope, or a detailed requirement.

these days, the meaning of "user story" seems to be narrowed to just the "card" part of Jeffries' 3Cs. in that case, a user story is not a requirement but a promise to hold a conversation about the requriements.

You can find a ton of gold nuggets of wisdom about user stories on the c2 wiki (http://xp.c2.com/UserStory.html)


To me, a critical element of a User Story is that it captures Why and How a user uses the system. It is especially useful because it does not specify much in the way of how the system delivers the required functionality. When UI and Usability testing is needed, the User Story may be the most important document.

Sure, you can have selenium verify that certain nodes are present in the HTML or take screen shots, or verify that certain pixels are where you hope that they are. But if there is misleading text, or it is not apparent how the user should use the system or it is hard for a user to figure out how to achieve their goal, suddenly you don't have a complete system any more. Now training is required in order to use the system. Reviewing the completed system against the user scenarios is a critical component of manual testing.

There is a mind set captured in user stories/scenarios which should influence many detailed design decisions about the implementation. Unless developers talk directly to users or watch them use the system, the user scenario may be the only link to allow them to understand user needs.

Finally, they allow the business people to specify what they need without suggesting how that should be achieved. It is much easier to describe a solution, than a need, and user scenarios provide a framework for describing needs without proposing a specific solution. The most common business requirement I've heard is, "I want it to be just like Excel, but on the web" which has never yet been what they actually needed.

So I would say that a good story should not include any specific details about how the system should be implemented. It should say, "Once a month, system A needs to be updated with any new data from system B. That data may require corrections. The client has a history of inputting invalid data and not realizing the problem for weeks." It should not say, "The system must accept a latin1 CSV file at least once a month and throw a NumberFormatException if column 3 is not a number." Do you see the difference? The scenario describes the need, not any specific solution. Then in testing you circle back to the scenario to make sure that the solution fits the need. Requirements may mix some needs with some solutions, or even focus entirely on solutions.

  • Thanks Glen! But shouldn't requirement or user story for that matter be system / solution agnostic? This is another question I keep pondering over when creating a user story / requirement but haven't been able to successfully to do it in a number of cases Commented Sep 29, 2013 at 13:41
  • You might start by asking the user about the business problem the system will address. How do you handle this problem now? Will you work the same way once you have the system? Who does these tasks now? Where do they do it? What are the most common challenges? It makes sense that requirements should be fairly system agnostic in theory. But practice is messier. I want a system that does all my work for me in such a way that I can still get paid for doing nothing. That's system agnostic, but useless. What we care about are requirements that the development team is capable of building. Commented Sep 30, 2013 at 22:20

User stories and requirements are very different beasts.


Requirements presuppose that the design of the application is done beforehand, and that development is the implementation of that design. Requirements therefore focus on how to implement a functionality.

Example of requirement:

  • Build a user contact form with the following fields: name, surname, email, free text and a submit button. When the submit button is pressed, an email is sent to our support team.

User stories

User stories focus on what to achieve, and insist that the design of the product is done at the last minute and it is a collaboration between a product person and a developer person. The details are decided during implementation based on opportunity.

Example of a story:

  • As Jimmy the user I want to contact your support team when I can't use the site properly so they can help me.

What is the difference?

As you can see, there is certainly a difference in the amount of details provided, but there is also a lot of information that is only available in the story, namely the purpose what it is that we are trying to achieve with this feature.

While it may appear that the purpose is relatively unimportant, this is a wrong assumption in agile development. There are typically two cases in which knowing the purpose is very important: reducing the cost of opportunity and enabling agility.

Cost of opportunity

If there are hidden assumptions in the requirement, it could be very hard to achieve. For example: is there a mail server available? If not, the requirement might take a much longer time to be developed. In some other cases a simpler way of achieving the same goal might be missed because of the design.

In contrast, the user story is about a user contacting our support department. If sending a mail is unfeasible or too expensive, we can devise a different solution on the spot: write to a database, for example, or use a form via Google docs, or simply put an email address instead of the form. This can't be easily done with a requirement, but it's easily done with a story and a product person present.


For this reason, with requirements we generally tend to think of these hidden assumptions beforehand and make sure there are no hitches. So in this case there might be a different requirement, scheduled before hand, which made sure a mail server was present.

This leads us to another huge difference between stories and requirements which is hierarchy. As I've exemplified above, requirements must, by their own nature, be ordered in some natural hierarchy so that dependencies are met. Stories, on the other hand, focus on purpose and have no such constraints.

This is by design, as in agile it is of fundamental importance to add, remove, reschedule and modify stories as needed during the execution of the project. Requirements can generally be added, sometimes modified or removed, but it's generally very painful to move them around because of all the dependencies. It is simply not done very often. If you are working with requirements, your agile implementation will suffer, or will probably not be very agile at all, in the sense of being able to embrace change.

  • 6
    I'd say you've got those the wrong way round - requirements are "let the user contact support", the story is how to define that into something that makes sense by adding detail. Maybe it is all down to terminology and we're thus getting all het up over nothing.
    – gbjbaanb
    Commented Sep 30, 2013 at 11:16
  • 2
    I am quite sure I didn't get them wrong.
    – Sklivvz
    Commented Sep 30, 2013 at 13:05
  • 1
    See for example: en.wikipedia.org/wiki/Requirement and en.wikipedia.org/wiki/User_story#Benefits
    – Sklivvz
    Commented Sep 30, 2013 at 13:13
  • 19
    "Requirements therefore focus on how to implement a functionality." - This is very wrong. If a requirement says how to do something, it's not a good requirement. Unless there's a known constraint, requirements do not include any design or implementation details. If I saw your sample "requirement", I'd reject that right off - it specifies implementation details.
    – Thomas Owens
    Commented Sep 30, 2013 at 15:00
  • 5
    Multiple (highly regarded and often cited) sources plus my training and experience in requirements engineering tell me otherwise. If you say anything about how you accomplish something, you have done design work. A mock-up is design and not requirements. Regardless of the format, a requirement is "anything that drives design choices", not the design choices themselves. I fully agree with Aaronaught's answer that a user story is just one format with which to capture functional requirements, making most of this answer incorrect with respect to commonly accepted terms.
    – Thomas Owens
    Commented Sep 30, 2013 at 18:54

Stumbled upon this during a google search and thought I would throw my opinion in.

There is really no difference between a requirement and a user story. Both are stating the desired outcome or goal from a user perspective.

The only difference is the way this goal or outcome is captured by a business analyst. In this case it is in the wording.


As a team lead I want to view which of my team are working on mortgage cases so that I can monitor their performance.

The solution shall display team members working on mortgage cases.

Both of the above could be interpreted in the same way but both also have a lot of ambiguity. The main point here is a difference in style. I think the issue we mostly see is how far into defining the solution do we go before we have moved out of the world of requirement and into the world of functional design. Is it down to the business analyst to state "list logged in users by first and second name on the main application menu" or is that too much information? When we are sat talking to our stakeholders and we all know the solution and can interpret what it will look like, even the likely code language it will be built on and the way it will deployed do we really need to play the pureist game of "let's define objectives and not solutions". This is where I feel the confusion really is.

Requirements often make the assumption we know nothing about the solution just desired outcomes. Yes this makes everything solution agnostic but does that really help us in the development cycle? If we can accurately define something early then why not do it?

All in all though I would not worry about user stories and requirements differences. Ultimately you want to define enough information for.someone to develop a solution. A user story that is too high level will simply be knocked back and requested to be broken down into smaller user stories. The same as a " the system shall" style.requirement will probably be knocked back as being too ambiguous if it does not have enough detail.

In the end go with what your developers and stakeholders like to see and work from that.


I think there is a lot of inconsistency on what the word requirements means, even within classic text books. The same inconsistency applies to user stories. Different organizations and textbooks treat these terms differently. For example, How Roger Pressman's classic Software Engineering textbook talks about requirements is quite different than Dean Leffingwell's Agile Software Requirements book. I respect them both and they both can be valid.

Requirements can be things we code to that have extraordinary specificity with little left to the imagination. On the other hand, it can be argued that requirements should specify what is the business problem and not specify the solution. I think that it is more nuanced though and the answer is somewhere on a spectrum that is unique to each company and industry (not all software development occurs in IT).

I was taught that requirements elicitation leads to analysis, that leads to design, that leads to architecture that leads to requirements elaboration or specification, that leads to something that can be coded. I don't believe this goes away with agile. The timing of when these things happens does change and that is the most important difference. In the waterfall model, elicitation and elaboration happens early. In lean and scrum, elicitation and elaboration happens at various stages with more elaboration happening as you get closer to implementation in a sprint. As does emergent design work.

In our organization, we are leaning towards the Leffingwell model of Epics, Features and Stories, not as requirements but as work breakdown and prioritization. Requirements are a different thing. Requirements are managed separately because we are required to do so for regulatory agencies. And yet some teams are certainly developing requirements within user stories during program increment and sprint planning.


Functional requirements are usually a formal specification that allow you to know exactly if your software work or not. User story are usually a much more informal way to describe a need of one your user story. It does not specify a rigid specification to determine if the software is "valid" or "invalid". While you can test some part of it, the real completion of a user story (if you do them right) is when your user say "yep, that solve my problem!". Remember the agile manifesto :

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In his book "User Story Applied", Mike Cohn say specifically that some things don't map to user story and you don't have to use only that.

In my own team, we use the following :

  • User story : a business need of some kind of user. Emphasis here is on the need, and why does he need it. As other have said, the important here is not to specify how it's done, and to go deep in the real need of the user (ex : he does not need to view data in a table, he need to see the exact value of the data, and he is familiar with table to do just that).
  • Bug : An unexpected behaviour of the software that impair normal usage. Usually come with an "Importance" (independant of the priority of development) that rate how much it affect the user workflow.
  • Technical debt. Something that does not prevent usage the usage of the software but will impair us, the developers, in the future. Example : some class is hard to read, the build is slow, some code is not unit tested, the IDE show weird warnings...
  • Improvement : a change to the software that does not allow new scenarios, but make for a nicer experience. Example : changing the fonts, redesigning a form to make it clearer, adding sensible default to the application, etc.

Functional requirements would not allow us to realize that a feature we implemented don't solve the need of a user, even though our cucumber test pass and we implemented every written word. A story is a discussion, and it's informal. The point is for the implementation guys to understand what is the problematic. They are not a contract tool. If you do "scrum but..." and your story are simply a funny way to write the requirements of the software, then yes, there is no difference.

The point is not the user story, the point is the huge shift in paradigm in the way you approach the work to be done. You are not doing a contract, you are helping some of your user solving a problem. If you don't see your user stories as discussion tool with a real user, then you are not using user stories, you are using a funky requirements syntax.

The rest here is my opinion : user story can never succeed in a unilateral way. You need your customer to work with it. Water-scrum-fall is doomed to be a weird requirement-but-not-requirements mess. If you have a fixed bid contract with specific requirements, don't use iterations and user story, there is no point. Use the rest of the agile toolkit : Automated unit/functional test, code review, continuous integration, refactoring, etc. Ensure that your software is continuously working and that you can ship it at a moment notice. Make it available in its unfinished form to the customer so he can give as much feedback as possible. If you do that my friend, even if you didn't do "User story" and "Scrum", you would have been more agile than many so called "Agile" shop.


I believe that everyone will implement and label everything differently depending on past experience and whatever language works for that company which gets the job done is not worth arguing over.

However, IMO, A User Story follows the Agile's approach of "a customers in the building or the customer is immediately available" approach, where documentation isn't necessarily needed because the details are in the customers head and readily available so a formal SRS may not be required. Now a "Task" of a "User story" is how a developer is going to build the user stories in digestible.

An example user story might be:

As an admin user I want to view my clients data listed in a grid

and a "task" might be:

  1. Create a Grid which lists the data to be displayed

  2. Enable Sorting on the grid which will sort the column selected

Now each of the tasks is estimated and completed in its respective sprint.

From a "traditional" perspective, where "the customer is hard to get a hold of, we need to write this down so that they can confirm we've got it right before we start planning / coding" approach, the Software Requirement Specification is going to be the ideas that were in the customers head and elicited and then written down and formalized and then baselined and managed.

In this case, a "functional requirement" is the nitty-gritty detail of that SRS, and a part of the larger Idea. So in my opinion, a user story could be seen as a (portion of the) formal "Requirement", and the task of that user story is a (or one of the many) functional-requirement.

In the example user story, the formal "Requirement" would be a lengthy document with flow charts and generally is going to be documentation-centric, as opposed to the more "Agile" approach which is customer-centric.

The difference being, the formal "Requirement" is going to be along the lines of some 10 page document outlining the administration section of the app which indicates some listings will be needed, some role based security, etc.. and then some of the functional requirements will be "the listing grids shall enable sorting", "the user information shall be listed in a grid", etc..

and i do believe these days the terms are all mixed and mingled.. which doesnt matter at all

  • 2
    The notion that "the customer is available so we don't need to elaborate" is part of what I call "Bad Agile". The real essence of Agile is that you plan in sprints and deliver functionality incrementally as opposed to doing everything in a "big bang". But to really be agile over the long haul, you need tests, and in order to write or perform tests you need specifications, which in Agile-land come in the form of acceptance criteria, which are the same as requirements, just organized by sprint rather than system or project. The idea that "requirements" are huge, dusty old documents is just FUD.
    – Aaronaught
    Commented Nov 6, 2013 at 0:47
  • @Aaronaught I agree. There has to be a point where the scope is limited particularly in situations where there is a fixed implementation budget. If the budget is fixed but the product design is not known and the project needs to get going quickly then for me agile works (and if it's an ongoing software product development activity done in sprints i.e. not a true project) but the scope must constrained using the acceptance criteria which would be baked into the requirements themselves (with some semantic changes) if you were going with a waterfall approach
    – br3w5
    Commented Nov 6, 2013 at 14:50
  • @Aaronaught - you are absolutely right.. however, Agile stems from the XP methodologies and the process you stated is a hybrid borrowing from the best of both worlds.. one the one hand, you have "documentation-light" and on the other you have "documentation-heavy". Finding the balance will be determined by the company defining their process..
    – hanzolo
    Commented Nov 6, 2013 at 16:53
  • @ssbrewster - I agree with you too. In the pure form of each methodology, waterfall and agile, one will require documentation and validation of the written requirements, the other will require very little if any documentation and validation of the development efforts.
    – hanzolo
    Commented Nov 6, 2013 at 16:56
  • 1
    @ssbrewster It's not just about constraining scope, it's about being able to say when a story is actually done. If you can't make that decision without some hand-waving from the business then you have no chance of turning out products of consistent quality, or of accurately measuring things like velocity. We prefer acceptance criteria to be documented in acceptance tests - but they're still written down.
    – Aaronaught
    Commented Nov 7, 2013 at 2:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.