Are User stories same as Requirements?

A requirement is a "statement that translates or expresses a need and its associated constraints and conditions". In Extreme Programming, where user stories originated, stories began as a card to serve as a reminder about things to talk to stakeholders about, and, through conversations, the team would learn more about their needs and desires and constraints.

The gap, if any exists between "requirement" and "story", is not very large.

The area of concern is the other "stuff" you do with requirements. The field of requirements management considers the traceability of requirements through designs, to implementations, and to testing. It also considers the control of changes to requirements and ensuring a complete set of requirements that describe the capabilities of the system. However, even considering these, the gap isn't big. There are electronic tools that allow for traceability between an electronic story card and various other artifacts, like documents or code or test cases. The notion of executable specifications and test automation has shifted the perspective on how to capture the capabilities of the system.

For the fundamental question of needing a functional specification and user stories, I'd say no. It seems wasteful to duplicate work like that, and avoiding waste is a key principle of both agile and lean methods. You should choose the method of capturing stakeholder needs and any other constraints that works best for all involved stakeholders.

what factors drive having a requirement document and then from this create user stories.

Empirical experimentation, that's the driving force. Scrum is not a reductionist process of breaking requirements down. The work on a Product Backlog is meant to feed experimentation each Sprint by assisting in the formulation of meaningful Sprint Goals. That's it.

Product backlog is the single source to know what will be needed to fulfill the product goal and it should be emergent. Product Backlog items are the work undertaken by the Scrum team. The requirement document you will create is it not going to change ? When you get feedback from Sprint review, do you update the requirement document or product backlog ? 

In my opinion, this all depends on the product and what type of outside oversight it is being subjected to.  For many of my Scrum Teams, the Product Backlog contained everything needed to understand what to do.  The code that was generated contained the information on what was done in order to satisfy the need.  With the use of electronic tools to maintain the Product Backlog and code base, it was possible to produce reports that could be used to satisfy audits. 

However, some products that are subject to government oversight might require more or specific types of tracking.  Then you have to do what is required in order for your product to pass audits. 

Remember that the Scrum Guide never uses the word "story" to describe a Product Backlog Item.  In fact, the word "story" is not used at all in the Scrum Guide.  So, you can create your Product Backlog Items using any format that makes sense for the need of that item. This is the entire section of the Scrum Guide that explains the Product Backlog.

Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

If the use of user stories is causing confusion and possible extra work, stop using user stories and start using something that works for your situation.  Does it really matter if all the items in the Product Backlog start with "As a <user>, I want to ..."?  How many times has it been useful to see that everything has that statement? What is important is that the Developers can look at the Product Backlog Item and understand the change/update/addition that is being requested well enough to refine it to a body of work that can be completed in a single Sprint. 

I am having this discussion within my team if user story is a way to Capture requirements from user perspective or we need to write requirements first (what product should do, not as user story, but conventional document requirements "Functional Specification") . There are also thoughts that requirements is what product should do and user story is what developers should do, which i disagree.

 

Would like to know thoughts from this forum, how do you decide on this ? Or what factors drive having a requirement document and then from this create user stories.

I disagree with the idea that requirements are what the product should do and user stories are what developers should do. User stories are a way to capture the user's needs and expectations, and they should be used to drive the development process. Requirements documentation, on the other hand, provides a more detailed and technical description of the product's functionality. In my experience, it's best to start with user stories and then create a functional specification that outlines the technical requirements for implementing the user story.