After collecting the data from the customers, it's time to write them down, in plain English (or whatever other natural language) for the developers. Now, if you are really good at creative writing, this is not the place to show off your talents. Keep everything as concise as possible.

When formulating a requirement statement, you have to think of several elements: the actor (or the owner), the action performed, the target (or, again, the owner, as the case may be), the object, the localization and the constraints that apply. A statement may not contain all of these elements, but, if it refers to them, make sure they are specified.

Make sure your statements are not too long. One rule says that, if a specification has three or more punctuation marks, it needs rephrasing. If you have more things to say, break them down into several phrases, even if that means repeating some of the words. Also, check to see that you didn't include two different requirements in the same sentence - this is a sure way to make the developers ignore one of them. If you can think of many different tests and measurements for the respective specification, then probably it contains more than one constraint and need to be re-phrased and broken into several pieces.

When writing in the natural language, use the words as precisely as possible. Avoid the office slang, even when you are pretty sure that the entire team will understand it. The IEEE standards have pretty clear definitions for words that you are sure to use, such as failure, error, fault - make sure you stick to those definitions. It's very easy to get carried away, particularly when you know exactly what you want to say, and you "assume" that everybody will understand it, because it's so "obvious". Guesses, assumptions, taking the obvious for granted - these are some of the most common mistakes made in defining the process requirements.

Use the correct grammar, punctuation, spelling, even pay attention to typing mistakes - they are known to alter the final meaning with great ease. Pay attention every time you use conjunctions "and" and "or". Often they indicate that you need to break the respective statement into several shorter ones. Never use words like "etc", "and so on", which leave a lot of space for interpretation and personal preference.

Give as many examples and create as many scenarios as possible. You can test your work, particularly when you're new at this, by asking several people to read your requirements and to tell you what they've understood and how they see the possible solutions. Ask people from several departments, just to make sure that they all understand the same.

Again, cooperate closely with the client to make sure your requirements are correct. As long as they are written in the natural language, it's likely that the client will still understand them, even if this phase. Also, keep a close contact with the team of developers to make sure the requirements can be implemented, and you're not asking for too much.

Also, it's vital that your requirements can be tested and measures, otherwise they are simply useless. We will cover the tests in a different chapter, for the time being, just think that you can't measure if one solution is "the best" available, "the most efficient" or the "quickest" one of all.

When you have the full set of requirements, make sure it is complete, at least from the point of view of the current stage of the project. Now, check them one by one and see that they don't contradict each other. This happens a lot more often than you may think, and, in many cases, people don't realize until it's too late. Don't make the set too rigid, leave room to maneuver in case you need to modify or put in new requirements. Remember that the requirements have to make sense as a whole, as well as each taken individually. Also, all of them and each one separately have to be measurable and verifiable.

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.

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.