|
|
|||||||||||||||
|
|
|
||||||||||||||
|
Get your spec right when writing briefsHow to specify what you want in a
database Start at the very
beginning. List the process on paper one function at a time, in order, e.g. 1. Customer details come in via application form, 2. The fields on application form are: xxxxx 3. Therefore all the fields from the form are to be added to the database. Attention to detail Labels: list sizes and shapes Letters: standard and freeform Reports: various types, with all their field names, sort order, search criteria, how often you need the data, etc. Searches: which types? Do you need the searches printed, viewed on screen, or exported? Maximise your
information. 2. Who needs to get information from you, and what information do they need? 3. In what format do they need to get it? 4. What other applications do you need to interface with? 5. Where is the information coming from that is to be used to populate your database? 6. How can this data be gotten into the database? Include everything. When should I use a
database? Database programming only really gets into a mess when the person specifying the system is unsure of the process they are asking to be automated, or when the programmer has not fully understood the process. If you cannot easily specify the data flow that is required, or need help in untangling existing systems, consultancy can enable you to do this. Get the information
right. A database specification report should be drawn up, detailed if possible to the last field name, and signed off before any programming starts. Programming is always costed on a time basis, "how long will your spec take to make?". So remember that further questions and amendments beyond this agreed spec may be charged for! If your specification is
sound and logical, then you'll get the system you want
- it's as simple at that! |
|
||||||||||||||
|
|
|