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.