Thanks guys,
Lots of useful insights there.
kmajoos, great point about large specifications. If you start with a massive list of requirements there is a good chance that throughout the project many of these will be dropped or changed beyond recognition. You also mentioned main reason behind my documentation drive - the Fixed Price Contract. Clients like to know in advance what they are going to get for their money hence I can't get away without documentation entirely.
I like the sound of Agile although I don't know how applicable it is to Fixed Price Contracts, I'd have to research. My approach at the moment is to split the project into increments of well defined requirements, each increment delivered to the customer for approval before embarking on the next. Features that have major implications if they change are developed in early increments. That way, we (hopefully) catch the big changes early on before they can impact dependent features.
Good to hear your comments on EA - gives me confidence I have the right tool and makes it easier to move away from textual requirements.
Yes, you have flexibility with your documents. As long as your project team understands what they are looking at and you can maintain it, go for it.
brought to you by enabling practitioners & organizations to achieve their goals using: