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.