How to write a requirement document?

A good document should satisfy the three C's - Concise, Clear and Complete. It is very true for the requirement document also. When a business analyst writes the requirement document, they may write the document, in a condensed or restrictive language, assuming that the other person would understand. Each user works in their specific business domain or "circle", where there would be certain terms and understanding among the colleagues. When communicating with each other in the department, using this restrictive language would be fine, as both the teams are on the same level of understanding.

BAs are comfortable in their domain and while documenting the requirements, unconsciously the restrictive language might come in the writing. IT team is not from the same domain as the BA and it is not necessary that they understand the implied meaning. Many a time, the defects caught can be traced back to a requirement, that was not clear or complete.

Business Domains 

BA must take conscious effort to make sure that the document is written in the elaborative language. One way to make sure that the requirement is elaborate is to have a review done by a peer from another department. Some examples of restrictive and elaborate requirements are listed

Restrictive	Elaborate
The data has to be backed up once a week	The data has to be backed up on every Saturday at 9pm and two copies has to be saved – one online and one offline
The system must allow users to view account summary	The system must allow users to view their account summary for the past one year
The system must provide summary report on Friday	The system must provide a summary report to the accounts manager on Friday 3pm UCT and it can be viewed from --- section

As can be seen from the examples above, elaborate requirements, ensure that there is no ambiguity and therefore helps IT to design better solutions. 

What are User Stories and Epics?

User Stories are high-level functional requirements, mainly used in Agile projects.
A user story typically has 3 parts-

• AS A - this identifies the user - it could be a general user, for example, the customer browsing the website, or it could be a specific set of users (business class users) or it could even be a system. The user/actor defines WHO wants the requirement.
• WANT - this refers to the action. WHAT is required? For example, I want to cancel the order, I want to open a new account, etc
• SO THAT - this refers to the WHY section, i.e, the advantage or use of the requirement. 

Some examples of user stories are

• The customer can order gift cards online using their credit cards
• As a patient, I should be able to make a reservation for a doctor online, so that I can see the doctor without waiting

User stories are very high-level requirements, that can be used as the starting point to flush out more details of the requirement. User stories are easy to write than use cases and functional requirements and it is typically written by stakeholders or business analysts. 

Good user stories would have the following characteristics - Independent, Negotiable, Valuable, Estimable, Small and Testable.

Epics are larger user stories that can be further broken down into several user stories. Epics are usually lower priority user stories, which when later is taken for development, is examined more closely and divided into several user stories and may be completed in more than one iteration