This section describes the advantages of using documentation styles and properties over ad hoc document formatting.

Microsoft Office was not intended as a software development tool yet analysts spend more time working with text in a word processing application than possibly any other tool. Why! Because it is the lowest common denominator application that everyone who needs access to the requirements, is familiar with. This means that analysts often find that their development tools are specified by the business. Can you imagine your programmers being told that the only tool they are going to be given to write code with is Notepad?

I like to think of requirements as a form of software, but at a higher level of abstraction than source code or design. Ideally they are expressed in a formal language, but previous attempts to specify requirements in anything other than a natural language have mostly failed. Why is this?

Formal languages are difficult to understand and even more difficult to write (look at requirements specified in Z, VDM and OCL for example). Personally, I find it easier to read and write code than to write formal language specifications. Reviewers of requirements want to read them in a natural language that they can understand. Using a formal language will generally mean that the requirement have to be specified twice.

So let’s forget formal languages and ‘real’ requirements management tools and assume that our requirements are going to be written using natural language with a word processor.

We can at least go some way towards formalizing requirements written in English. As mentioned earlier, we already removed many English words from our requirements specifications; adjectives and adverbs for example. Other improvements are to introduce a glossary into the project. We want to restrict the use of English to a minimum subset of the language. If two words can convey the same meaning choose one, and use it consistently (we are not writing a romance novel; requirements are boring on purpose).

Other ways to make our requirements documents consistent is to make use of MS Word properties and styles. This chapter describes some best practices for using properties and styles with MS word.