Requirements document is a written statement of what software will do.
It does not state how the software will do what it is intended for.
The “how” is specified in the design document.

The main purpose of a requirements document is an agreement between the developers and the users on what the software will do.
Some advantages of a requirements document are:

– Defines the needs of the end user
– Helps the developers and the end users come to an agreement on the purpose of the software
– Estimates the effort involved in the project
– Provides functional specification of the software

You may be able to get away with not having a requirements document if the application has a very small use case.
However, if you intended audience is more than one, you should write out a requirements document.
Some guidelines for requirements documents are:

According to IEEE Software Requirements Specification (SRS) (IEEE Std 830-1998), should be:

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable

Parts of a requirements document:

• Objectives
• Functionality
• Scope
• Performance
• Usability
• Administration
• Integration
• Deployment
• Constraints
• Reliability
• Portability
• Assumptions
• Dependencies
• Maintainability
• Security
• Auditing
• Disaster Recovery
• Rollback
• Reporting