Chapter 26: Bulletproofing Access Applications
901
Another major error is allowing the database to stray too far from the initial design specification.
Adding lots of bells and whistles to an otherwise simple and straightforward database is all too
tempting. If implementation digresses too far from the design specification, the project may fail
because too much time is spent on features that don’t directly address the users’ problems. This is
one of the reasons for the third step (Finalize the specifications). The developer and the user are
essentially entering into a contract at that point, and you might want to include a process to be fol-
lowed in order for either party to make changes to the specification once it’s been agreed upon.
Before any work begins, most professional application developers expect the client to submit a
written document describing the intended application and specifying what the program is expected
to do. A well-written design specification includes the following information:
l (^) Expected inputs: What kind of data (text, numeric, binary) will the database have to han-
dle? Will the data be shared with other applications like Excel or another database system?
Does the data exist in a format that is easily imported into an Access database, or will the
data have to be re-keyed at runtime? Will all the data always be available? Is there a
chance that the type might vary? For example, birth dates are obviously dates, but what
happens if you know the year of birth but not the month or day?
l (^) User interface: Will the users be comfortable with simple forms, or will they need custom
menus and ribbons, and other user-interface components? Is context-sensitive online help
required?
l Expected outputs: What kind of reports are needed by the user? Will simple select que-
ries be adequate to produce the desired results, or are totals, crosstabs, and other
advanced queries necessary as well?
The whole point of a design specification is to avoid adding unplanned features that decrease the
database’s reliability without contributing to its utility. Writing a design specification before begin-
ning the actual implementation will consistently yield the following benefits:
l A guide to development effort: Without some kind of design specification, how can you
possibly know whether you’re building an application that truly meets the client’s expecta-
tions? As you work through the development phase, you can avoid adding features that
don’t contribute to the application’s objectives and concentrate on those items that the
client has identified as having priority.
l (^) Verification that the application meets expectations: All aspects of the application
must be tested to verify its operation. The best way to conduct testing is to confirm that all
design objectives have been met and that no unexpected behavior is observed during the
testing phase.
l (^) Minimization of design changes during implementation: Many problems can be
avoided by sticking to the specification. One of the easiest ways to break an application
is to add new features not included in the original design. If the application was properly
planned, the specified features will have been designed to work together. Introducing new
features after development has begun most likely will result in a less reliable system.