Functional specifications are often used on bespoke software development projects to supposedly document the business requirements of a system.. As you might expect from the name of the document, they are structured by function. Superficially this seems fine, but in reality they are vague and difficult to relate to the final system. The result is that the project goes out of control, time and money are wasted, people get stressed and burned-out, and the business gets a system that doesn't meet requirements, is bug-ridden, or is never delivered at all.

Why is this? Well just the name of the document is part of its undoing. The name functional specifications focuses people's minds on functions. Such functions are often viewed as paragraphs of narrative or a series of boxes joined by lines. Both have their uses, but the problem is that they obscure the objectives, and so create vagueness. The objective of an information system, after its business objectives, is to produce outputs. The function is the means, not the end.

There is also the problem of relating to other documents. The Functional Specifications are often followed by the Computer System Design document, which attempts to specify the computer system. The problem here, is that it repeats much of the business part of the specification that is already in the Functional Specification, embellishes it with more detail and structures it in a different way to fit in with the Computer System Design. On top of this it is a technical document too, so the user often never sees it. This duplication, embellishment and mixing of technical aspects of documentation leads to an unnecessary increase in costs, delays and a communication gap between business and IT people.

What you need instead of a functional specification is a document with a different name that encourages precision and avoids vagueness. So a name such as Detailed Specifications should be used. You can differentiate from IT technical specifications by using a qualifier, as in, User Detailed Specifications. Changing the name will help but IT Standards, or IT Policies and Procedures, need to be created or changed to ensure that developers specify properly. In particular they should state that outputs must be specified.

To avoid duplication of documentation, design the documentation as a system, so that the business part of the specification can be presented by itself to the user and later integrated with the technical specifications, without duplication.

This is not to say that there isn't a place for a general specification of user requirements. It just isn't here.

Copyright © Vic Lilley 2002