If you are asked to generate a requirements document, it is important to know the purpose. Below are the reasons that may apply. Any and all of these are good reasons. In fact, if several reasons apply, they may result in conflicting needs that drive the requirements in different directions.
If you take one thing away from this article, it should be this:
If you don't know the purpose of the requirements you are generating, you won't be very good at generating them.
If none of the reasons below apply, then I recommend eliminating the creation of formal requirements altogether. Instead concentrate on controlling the scope of the effort or methodology of test.
A clear, agreed upon series of requirements will allow several groups or disciplines to address the design in parallel. The requirements can be technical, logistical, or financial. Schedule compression by use of requirements is described thoroughly here: Requirements: How to Use Them to Drastically Improve Schedule Performance. This is a classical technique that you need to be familiar with, even if you never use it directly. When you team with other organizations, you will probably encounter these methods.
The act of putting down requirements in a bounded manner will expose weak or incomplete areas of understanding. By stating what each feature does (and by inference, what each feature may not do), a great many problems will be forced into the open early in the design, when they can be more easily addressed. This also will lead to genuine questions, which can be approached using risk reduction activities like prototyping, breadboarding, and use studies.
Writing System Documents can be very challenging, because differences of opinion and direction may not be apparent until clarified in writing. Codifying an effort usually forces issues or contradictions into the open.
There are always forces that will try to delay or obscure decision points, to try to keep conflicting factions and options open as long as possible. This may make things easier in the beginning, but will make things much more difficult in the end.
In any multi-functional organization, a single requirement can affect many functional organizations. Agreement on requirements and allocation of responsibility for each is one of the first steps of leadership, no matter what you are doing. Each functional specialty is a stakeholder, and presumably they all want the final system to be successful, while holding risk to an acceptable level. Requirements in this case are contracts between stakeholders, to make sure that everyone understands what the team is trying to do, and what their responsibilities are.
One of the most difficult aspects of executing to a development contract is the determination of fulfillment. Have you satisfied the contract? To prove this you need evidence. By developing discrete requirement statements, each one can be verified, and the completed set or verifications provides a method of contract closure.
Closure requires evidence:
One type of evidence is physical - components, buildings, piers, furniture.
Another is documents: descriptions, plans, reports.
Another is third party acceptance: Certifications, independent tests, sales, customer feedback.
Developing discrete requirements allows you to get this situation under control, assess scope, and pursue closure logically.
Review of system documents is a classical method to determine if a contract is being worked as agreed to. ISO-9000 is an audit system that provides assurance that the employees at a company are aware of these company processes, and work to them.
So a completed requirements document, with the proper signatures, indicates that a company (and its employees) have been exposed to the requirements and are at least aware of them.
This is also a method of review by your management to see exactly what everyone is up to. I have seen system design documents used to replace internal reviews.
If you need to increase the staff to pick up schedule or address additional opportunities, formal requirements provides material needed to start up contributors without impacting existing resources. This is especially critical when attempting to recover schedule or cost. If you have requirements defined, then professionals can quickly understand the problems with the approach, and have a reference frame to allow them to contribute efficiently. Without this, adding capacity will have to be supported by your critical resources, and these resources may get the same questions many, many times. If your product/process becomes popular, you will wish you had written a spec.
A specification standardizes you product/process within your company, so that all individuals work to a consistent vision of the implementation. Or at least a more consistent vision. If the spec says "22", then that is what we are doing. If we need to revisit WHY it says "22" then write it up and we can work on that.
Even if you cannot nail down specific requirements, all efforts have needs and goals that drive them. Goals and priorities are where to start, at least to put things into perspective. Goals can become Key Performance Indicators, and evaluated using classical methods.
I developed a system to evaluate and specify priorities, which has worked well and been very popular, you can review it here.