Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well – only they did a different job from what they were supposed to.

The definition of a successful program is that it is 100% compliant with its initial requirements. But it those requirements contain mistakes, are unclear or poorly defined, then there is very little one can do to correct the problem later in the process. So, a bit of advance planning simply doubles the success changes of any software project.

The persons in charge with writing the requirements should be the project managers and the team in charge with software engineering, all the stakeholders, the clients and the end-users. Writing good requirements takes time and practice, and, even with all the new tools designed to help you, it will not happen overnight. You need a good, clear, organized mind, good programming knowledge (because you'll need to know exactly what your team of developers can do, and you need to make sure that you speak the same language with them) and, to a certain extent, good people skills. You will need to get in touch with the clients during this period, and to find out exactly what they want and how they want it. Some of them are not capable of explaining what they need, others don't have the time to meet you and look over the drafts, other thinks they know better and they give you all the wrong ideas, and others will simply be very happy to approve your specifications without having a second look at them. You need to persuade all of them about the importance of this step, hold long, boring meeting, and then "translate" their needs for the programmers and developers. If customers or end-users are not available, despite your best efforts, you can use "surrogates" to simulate the actual users.

Make sure you remain in close contact with the client for the entire duration of the process. Their needs may change, or they may find out about something they forgot to tell you in the beginning – so inform them that you will always be available to meet with them and look at all the options again.

Also, the quality testing department needs to be informed about the requirements from the very beginning, because they will design their tests accordingly, and also they may have some details about what can go wrong in some cases.

One of the biggest issues is the time you have available for writing the requirements. Sometimes, when the deadline is very tight, the developers may start working before you completed the requirements, and this can cause a lot of problems later on.

The process of requirement management ends when the final product is shipped, and the customer is fully satisfied by it. However, the fewer modifications your requirements will suffer, the better for everybody. You should be able to trace your requirements all the time, and we'll have a look, later on, at the tools that enable you to do this.

In some cases, when a client comes up with an additional issue, it may be too late to change a requirement or ad a new one – the workload and the costs are simply too big to make it worth it. This remains subject to negotiation between you and the client – but your task is to know exactly what would be the effect of implementing new requirements, and to translate it into the language of the client (meaning that the client may not be receptive when he sees how many code lines need to be changed, but he may understand when you tell him how much this will cost).

Tracing requirements also involves additional tests, performed from time to time, to insure that the process runs smoothly and errors are identified and corrected early on. When faced with a big project, you may have different sets of requirements, some that apply to the entire project, and some for parts of it. When a certain design is implemented for a certain requirements, make a note about the effects and the alternatives – it may be useful for future projects (or even for the same project, if the client is not satisfied with the result).

So far, we've seen what software requirements are. In the following sections, we'll show some tips and tools about what good software requirements are. If this section is your responsibility, the wisest thing you can do is to get the IEEE Software Engineering Standards Collection. At 400 dollars, it may be somewhat expensive, but it will give you a lot of useful details about terminology, processes, the quality assurance and the user documentation needed. Also, the standards are conveniently given for each separate unit of the process – the specific part about software requirements specification is IEEE STD 830-1998, which describes the content of good requirements specifications and provides some useful samples. The guide is designed for in-house software, but it can be used for commercial software as well, with minor changes. Another useful reference is the "Standards Guidelines and Examples of System and Software Requirements Engineering" by M. Dorfman and R. Thayer, a compilation covering all the major standards (IEEE, ANSI, NASA and US Military). These are all flexible instruments, and should be used as such.