Part IV: Professional Database Development
900
Building to a specification
All databases are meant to solve some problem experienced by users. The problem might be an
inefficiency in their current methods or an inability to view or retrieve data in a format they need.
Or you may simply be converting an obsolete database to a more modern equivalent. The effective-
ness of the solution you build will be judged by how well it resolves the problem the users are hav-
ing. Your best guarantee of success is to carefully plan the application before building any table,
query, or form. Only by working to a plan will you know how well the application will solve the
user’s problem.Most Access development projects follow this general sequence of events:- Define the problem.
Something is wrong or inadequate with the current methods — a better system is needed
and Access appears to be a good candidate to produce the new system.
- Determine the requirements.
Interviews with the client yield a description of the basic features the program should
provide. The product of these discussions is the design specification, a written document
that outlines and details the application.
- Finalize the specifications.
Review the design specifications with the client to ensure accuracy and completeness.
- Design the application.
The developer uses the initial design specification to design the basic structure of the
database and its user interface.
- Develop the application.
This is where most developers spend most of their time. You spend a great deal of time
building the tables, queries, forms, and other database objects needed to meet the specifi-
cation produced in Step 2.
- Test.
The developer and client exercise the application to verify that it performs as expected.
The application is tested against the requirements defined in the design specification, and
discrepancies are noted and corrected for Step 6.
- Distribute and roll out.
After the application’s performance has been verified, it’s distributed to its users. If neces-
sary, users are trained in the application’s use and instructed on how to report problems
or make suggestions for future versions.
Many Access developers dive right into development without adequately defining the application’s
objectives or designing the database’s structure. Unless the application is incredibly simple, a
developer who doesn’t work to a specification will surely end up with a buggy, unreliable, and
trouble-prone database.