It seems so obvious that we should develop systems based on requirements, and yet it turns out to be rather hard to do and thus many organizations are doing it very badly. From a CM standpoint, we could perhaps leave the whole process of requirements engineering to one side and focus on the management of requirements and thus the aspects of change control and traceability. That would perhaps be unduly ducking the issue, and of course we can’t resist giving an opinion anyway!
For definitions and descriptions of the process of gathering requirements, you can do a lot worse than use SWEBOK as a starter . Requirements can be split into: functional, non-functional (interface, quality and other “ilities,” performance, safety), derived, behavioral and operational. Dennis Linscomb  makes some interesting recommendations as to how the requirements aspect of CMMI might be improved to reflect a level of maturity in requirements.
So first a quick review followed by an agile SCM slant on things and some suggestions for improvement.
Big Bang (Waterfall) Developments
What came to be known as the waterfall approach presented a vision of a set of requirements all specified upfront which could be verified, signed off and then implemented with an ecstatic set of users at the end of it. This turned out to be a siren call which resulted in the shipwreck of many, many projects over the years.
It is very hard to specify requirements, since often no one knows precisely what they want, and in any case the requirements are almost certain to have changed by the time they are implemented.
Interestingly, there are situations where a rather accurate requirements definition is available – for example re-engineering or re-developing an existing system. In such cases the requirements process can be to point at the existing system and “replicate that,” even down to the level of replicating existing mistakes.
Of course not all waterfall projects were failures. One of the authors well remembers a 7 figure fixed price development project where the requirements specification mixed one liners that implied whole subsystems and months of effort and in other parts spent pages on specific details of how certain screens should look (that turned out not to be needed at all).
The fact that the project was a success was down to some excellent people being involved on all sides, and also that while we didn’t quite ignore the spec, we did rather rewrite it. The project was likely to have been even more successful if done in a more evolutionary manner since the implications of various (some relatively minor) decisions did not fully manifest themselves until it was much too expensive to change them.
This approach has been around for a long time, based on the idea that the faster you can deliver something, the more feedback you get and the more likely you are to get something useful.
Richard Brooksby, in “Changing How You Change”  discusses the process of developing software to add value to your company, e.g. by understanding what is valuable to customers and solving their problems. He nicely summarises Tom Gilb’s work in this area.
Richard came up with the wonderful image of seemingly random changes in the software that often occur – very much like the apparently random (Brownian) motion of small dust particles in a gas. Have you ever seen new release of software come out with apparently pointless features and changes? The sign of a company that doesn’t know which features are valuable, or that doesn’t know how to ensure that they are the ones