Project Requirements
There are many, many, many, many, many, many articles, cliche’s and of course peoples opinions on requirements writing and gathering, most of them stress the importance of thinking of the specifics of how a product should function before starting any development work. In this article I will briefly touch the surface of this topic and implicitly describe my experiences with some of the requirements documents I have read.
The importance of good requirements definition is difficult to argue with, the fact is that if you are presented with good specification documentation that is presented in a logical way that is easy to follow and presents requirements for all possible cases the development work becomes a lot easier. However, proper requirements writing is underrated in how much time should be spent writing specifications and how difficult it is.
How is this relevant to project management? Regardless of the methodology you decide to use and aside from the fact that requirements writing must be taken into account when creating a plan for the project. Good requirements are the basis for a well defined project road-map; Project requirements are often the bridge between the business and the technical team and they must be understood by both technical people and business people. If the requirements are vague and do not describe all features which will be included in the product or iteration correctly, then it is not possible for even remotely accurate development time estimations to be defined. The development time estimations will be little more than guesses, it is difficult enough to estimate the time it would take to develop a functionality if the specifications are clear and well defined but with vague requirements it becomes next to impossible. I would argue that this is one of the main causes for projects that do not meet the deadline.
So how are some ways we can improve our requirements writing skills? One of the differences between a well written and a badly written requirements document is the language used. This does not only mean that if the development team only speaks English then the requirements should be in English 
. This also means that you should only use words that you understand ( look them up in a dictionary if you are unsure of their meaning ). Another way that requirements can be improved is that they must be written using a logical hierarchical structure, with many titles, subtitles and bullet points grouping relevant pieces of information under single subtitles. It must not be written in the form of an article or essay. This of course assumes that the person writing the requirements knows what the requirements should be, that’s a completely different issue and I won’t go into that, yet…
