The requirements of a software project

Finding the requirements for a software project is very important. It might turn out in the requirement analysis phase that no new software is needed at all. Without a requirement specification it is hard to tell wether or not the project has been done well. However, the quality of a typical software project can not only be measured by how well the requirements have been matched. It is also important to find out the requirements. Usually the client does not specify the exact requirements precisely. Often that is not even possible, because of the limitations of natural languages. Many requirements are not expressed by the client.
A typical implicit requirement is to develop the software in such a way that the developer can easily maintain it, adding the yet unknown features that are required in the future. A typical derivation of this implicit requirement is that ANYONE can easily maintain it. This makes a huge difference for judging the quality of the software: In the first case it would be perfectly fine if the developer uses his own weird, deprecated ways, as long as this works for him. In the second case it is important to stick with the conventional ways to give the software the desired flexibility and extensibility. A typical example of an implicit "wrong" requirement, one that is stated between the lines although it is irrelevant for the actual problem, is that a new software is needed at all. Sometimes a clarification of the requirements reveals that there is already a software that can do what is required.

A good way to find out additional requirements that did not turn out in the preceding communication is to watch the later users of the system do the tasks for which the software is being developed. I do that whereever it is applicable and possible, and so far it always revealed valuable information; implicit requirements that I have not been aware of yet.

The common XP way of having a representative later user of the system present during the entire development process is very good, too. I experienced the advantages of this method in several software projects for a university. The initial costs for the client are high, though: The client has to work without this representative during the entire development process. This representative must be "the expert", as the XP rules clearly state.

To summarize, without an exact requirement specification determining the quality of a piece of software is very subjective. Judging how good someone is at finding out about the actual requirements always is quite subjective.