When you agree that software requirements are necessary, make sure you understand what the word "requirement" means. If you ask ten people (starting with the developer and ending with the client), you will see that each of them understands something else. Make a quick note, this will give you an idea of one of the biggest problems you'll have to face: different people use the same words with different meanings.

Usually, the requirements are divided on several levels. The first level consists of the specific business requirements - business background and market needs, objectives, dependencies, scope and constraints. These are usually beyond the control of any stakeholder, but they should never be self-implied. They need to be discussed and detailed like all the rest, and included into a document usually referred to as the "Vision and scope document". This is the place to discuss the operating environment - something that will have a major impact on everything else. For instance, it the client plans to implement the software in China, it may be a good idea to find out now, since this will impact on every other aspect. Or, another example, if there will be many users and they will need different access and security levels, again, it may be better to plan in advance.

Now, when this is settled, it's time to discuss the user requirements. As said before, clients are not always very cooperative at this point, and it will be your job to convince them. Don't take for granted everything they say, insist on every single detail, and insist on talking directly to the final users of the program, or on getting information from them in one way or another. In the end, if something goes wrong, it will be your fault, since you can't blame the client.

Users will use all types of meaningless words, such the "the best", "the easiest", "user-friendly", "fully compatible with", and so on. It's your job to turn these into clear, measurable and traceable requirements. You cannot tell your client frankly that he won't get "the best" feature, but you can't tell the developer that he needs to "do his best", either. This is more or less similar to translating from one language to another. Fortunately, there are specific methods of doing so, and we'll look at them later.

You will turn the user specifications into functional requirements and quality requirements. Sometimes there's no need to bother with the difference between the two, but, in most cases, there is, because you'll need different measuring instruments once you start implementing them. Also, here you need to consider other external, non-functional requirements, which are not related to your client.

Now it's the time to turn all of these into software requirements specifications (SRS) and to hand them over to people who need to use them. It is vital to prioritize them - be realistic, some things may not be ready in time, others may not even to possible. Decide which requirements are absolutely necessary, which are necessary, but can be implemented later on (after making sure that everything else works, or even in a later version of the program), and which would be really useful to have, but, if the deadline is tight, may be skipped altogether. While you are doing this, check to see if there are some requirements that are not necessary at all - this happens more often than you may think. Sometimes the clients insist on functions they don't really need, in other cases you "assume" or "guess" what they need, and sometimes unnecessary requirements are leftovers from constraints that have disappeared or changed in the meantime. Make sure you can trace each requirement back to the constraint or function that generated it. If you think the client insists on an unnecessary requirement, check with your developers how long it takes to implement it, and then inform the client of the additional costs. Usually, when faced with the cost/usefulness ration, many people change their mind or review the situation more carefully.

Up to this point, you had to perform an appraisal for a program that did not exist; from this moment on, you will mainly need to evaluate what has already been created, to test and verify that the requirements were implemented correctly. Of course, you may still need to modify them or to ad new requirements when this is the case.

When something changes, make sure everybody is aware it, don't just inform the developer directly about what has changed. The entire team should have a strict set of rules, and all the changes should be written down for every stage affected. For every requirement document you write, make sure you also record, right on top, which version it is and when it was written/modified. Organized, efficient communication is vital. Also, this will prevent people from returning to mistakes which have already been eliminated by introducing a new requirement.

Make sure you check all the processes and instances affected by the new change. One of the worst things that can happen is to have a requirement implemented in one process, but ignored in all the other processes related to or deriving from the first one. For complex projects, it may be a good idea to organize a control board to approve or reject changes at regular intervals, and to make sure everybody is informed about the change and its status. There's no need of making it a very formal affair, or a very large board, as long as it does its job correctly.