On reviewing the subject material for DMT over the past two weeks I have come to think a lot about the practices I do at work when developing databases, requesting quotes for others to create databases and upgrading databases…All fun things to do…but complicated and often you need a working knowledge of the content/data before embarking on such a journey.
I have reviewed my processes and provided a summary list of questions that will better assist me in the workpklace, to assist developers and also to make sure the quote we receive can be better tailored (rather than the quotee having to guess what we may be talking about in a project proposal/plan). Hope they will assist you to.
Databases – Questions to answer and document
1. What are the objectives of the database?
To reduce manual input? To provide an approval process of content? To provide some information about a product/service to the public on a website? To create an authoritative source for staff to access across multiple locations? To store procedures
2. What are the fields/tables of the database?
Data modeling is a great starting point – I found that brainstorming what will be in the tables using a spreadsheet really help when there are multiple people in the process. It provides an opportunity for the developer to think about the type of technology that will best assist and the sheer amount of work required (for example, you may have twenty fields, or two hundred fields – this helps in the quoting process). It will also assist you work out where relationships need to be formed in the table. As time progresses, you may find that the tables / fields evolove. This is a good thing to work out on paper, before you create the database.
My spreadsheet template has the following headings (so you are thinking about the content from the beginning):
- Field Content Type (text, memo, numeric, list etc)
- Options (one, multiple)
- Content Owner
- Data Source (if fed from database / source)
3. Where will your data be coming from?
Will you be utilising content from other systems? How will content feed into your database – FTP, CSV upload, manual? What are the fields that will have content fed into them automatically? Note: A flow chart is a great way to open the conversation with a developer.
4. Who will be using your database?
How many administrators will be accessing the database? How many reviewers? What are the admin, reviewers, editors roles? Is a log in required? Is some information for some users, and other information for other users?
5. What reports will you need from the database?
And in what file format? Who will need to access the report
6. Is there any special functionality you require?
Do you want a person to enter a form and then a personalised automatic email / PDF is generated and sent to the person completing the form? Make sure you relate the special functionality back to the objectives.
Bringing it all together!
The final part before sending out to vendors for review and the quoting process is to document Functional Specifications – that will include all of the above, plus wireframes if you have an idea of how you would like the data organised on a page.
Most of all, remember, it is a work in progress and the developer may have some ideas to input in relation to technology platform, table structure, field labels and relationships. Take on the feedback and make a decision based on whether your objectives will still be met if the suggested update is made.