Datasheet

Chapter 1
16
Ironically, the importance of sound requirements analysis is most clearly seen in its absence.
When requirements are not properly defined or documented, one of two consequences almost
inevitably follows. Either the requirements remain unmodified, with the result that the
application fails to achieve its client's objectives; or the requirements are modified later in the
development cycle. Late changes such as these can have a huge impact on project costs as their
effects 'ripple' out and affect other areas such as documentation, design, coding, testing,
personnel assignments, subcontractor requirements, and so on. Indeed, some studies indicate
that such changes can be 50 to 200 times more expensive than they would have been if they had
been made at the appropriate time!
Prototyping
Prototypes, pre-development versions, proof of concepts, nailed-up versions – it doesn't matter
what name you give them; they are all attempts to further refine the analysis phase of the
project. Access used to be seen as being "only" a prototyping tool with the "real" development
given over to something more "industrial strength". This is no longer the case, however (if
indeed it ever really was). Access is perfectly up to the job of all but the most demanding
projects. It still makes a marvellous tool for prototyping though.
A prototype is a scaled-down version of the final application, which can be achieved at low cost
and within a short timescale. It may have certain functionality incomplete or missing entirely. It
may even only implement a tiny part of the whole project. The whole point of the prototype is
to test those areas of the design that are currently uncertain. This may include a number of
different methods to achieve the desired functionality, or perhaps alternative GUI designs to
see which is easiest to use, or maybe sample queries with test data to determine what kind of
hardware platforms will be required to attain the desired performance.
One thing you should never see is a prototype as v1.0 of the application. This is invariably a
recipe for disaster. The temptation is to take the prototype and keep developing it without first
going through all the other formal processes described below. You should always see the
prototype as part of the analysis phase of the project and not the end of it; it exists to ask
questions and to get them answered. If certain parts of the prototype later make their way into
the final application (the GUI design would be a good example) then all well and good, but
ideally you should plan and cost the work separately.
Technical Analysis
As well as determining the nature of the solution required by the users of the application, it is
also necessary to determine the technical infrastructure that will support this solution. The
types of questions posed are ones such as these:
❑ What operating system will the application run on?
❑ Will we need different versions of the application for different clients (for example,
one for customers and one for managers)?
❑ What is the specification (that is, in terms of processor, memory, disk space) of the
machines that the application will run on?