Specifying a database

Our clients come from a range of backgrounds and we have received many different styles of specification. Some are more helpful than others. If you're a database user then the following hints might help you when you specify your next database. If you're a database developer then they might help you be more helpful to your client:

• Use the language of your workplace, don't use technical terms.
• Say what you want to achieve, not how you want to achieve it.
• Concentrate on what information you need to get out of the system, don't specify the size and type of the database fields.
• Don't tell the experts how to do their own job and don't get bogged down in the details.

The best specifications are simple ones. Give your database developers a simple request and they will be able to deliver it in a matter of a few days. You can then use this simple system for a while before you decide on the next move. The 'giant leap' method of specifying the whole system in minute detail only works where there are large teams on both sides who have plenty of spare time to argue over the contractual implications of every detail.

If database development can proceed in smaller steps then your developer c can work with you to make sure that each step is sound before making the next one.

A useful analogy

We have just paid a plumber and his assistant several thousand pounds to refit our central heating system. I trained as an engineer and am quite capable of cutting and bending pipes and soldering them together but I was persuaded to call in the experts for this job. That was a good decision because this pair did the job well and were finished in less than a week. It would have taken me a month of weekends to do the same work.

We did not specify the exact location of the radiators beforehand because the plumber needed to see how the existing pipes had been run before he could tell us the best place for the radiators. If we had given strict instructions then the system would have cost us even more money.

Whilst they were working I stayed out of their way. If they wanted a decision like 'Where would you like this radiator?' then I tried to give them a quick answer and went back to the office without offering any more advice. Telling them how to do their job would only have upset them and they might not have been as cooperative or helpful.

Treat your database developer like we treated our plumbers:

• Tell them what you want.
• Keep out of their way.
• Inspect their work afterwards.

But please don't tell them every little detail of how to do it.