Datasheet

Chapter 1

The principles behind sound data analysis are straightforward enough:

❑ Identify all of the data entities you will be dealing with

❑ Establish the attributes of these entities

❑ Define the relationships between these entities

❑ Document, document, document…

As with the requirements analysis and the technical analysis, a variety of methods and tools can

be employed to assist in the task of data analysis. Whichever you choose to employ, I would

encourage you to bear the following two principles in mind.

First, when selecting a tool, it is paramount that you choose one that allows you to clearly

document the results of the analysis in formats that everyone involved can understand.

Remember that you may have to present your designs to a wide range of people from clients

through developers and possibly up to management – they will all have different technical

abilities and focus, so bear in mind that you will need to be able to easily vary the level of detail

included. Your primary audience, however, is technical, so use diagrams to illustrate the

relationships between your entities, by all means, but don't forget the fine detail (however

boring it might be to gather!). Complex entity relationship diagrams may look very impressive

and professional, but if you can't use your documentation to tell you whether Widget Part

Codes are 8 or 9 characters long, then you are going to struggle.

Second, it is very seldom that I have come across data analysis that has suffered from being too

detailed. Document everything – data types, field lengths, allowable values, calculated values –

get it all down on paper and do so while it is fresh in your mind. If there is something you are

not sure about, don't guess. Go back, check it out, and write it down. The temptation is always

there to wrap up the data analysis early and get on with the fun part of the project (design and

development). Resist the temptation. You'll thank yourself for it later on.

Design and Coding

So then, now that the analysis is out of the way, it's time to get on with coding. Right? Wrong!

As tempting as it might be to just plunge in and start coding straight away, you first need to

spend some time deciding on an appropriate design for the application. One of the chief aims of

the design process is to establish the blueprints from which the application can be built. A few

of the issues that you will need to consider when designing the solution are:

❑ Data Storage / Location

❑ Import / Export Mechanisms

❑ Error Handling

❑ Portability Issues