Hi Jeanne,
Doing such an application is one of the things on my list of things to
do. I did a very simplistic version several years ago. I started a
more formal and enhanced effort last year. I'm still working on the
front end documents for the new version on a sharply reduced schedule.
Higher priority projects intervene... So, I have lots of ideas
regarding the subject but will only share a few.
*Need* is a four letter word. Please define "I need" in the context
in which you used the phrase. What is your actual motivation? What
do you hope to achieve? The answers to those questions are very
important.
Try going through the formal steps in project/product planning:
Problem Statement - characterize the problem or universe of related
problems that you will consider. This isn't a trivial exercise, think
it through and capture it in a machine readable document such as Word
or Excel.
Make a copy of that first document and call it your Pre-
Solution Statement (Product Specification) - State what your product
will do regarding each item in the Problem Statement. List each item
to demonstrate that you have considered it, For those that you will
not resolve in the current project, say so.
Make a copy of the document above and remove the "Pre-" prefix. Edit
out of this document all of the things you do not intend to address in
your current effort. You now have your project goals.
For each item in the Product Specification above, list the high level
strategies you'll use to deliver a solution. If you're using Word in
Outline view, it's a natural for continuing right on down the
hierarchy of functions displaying ever greater detail as you go.
That's what I do to arrive at my Functional Specification.
Using pencil and paper, chalk board, what ever tools work best for
you, identify all (as many as you can) of the entities in your
application.
It is important to do things as well and as completely as you can
before you move along to the next thing. I recommend that you
separate each of the major steps above by at least one day. Review
the last step before you begin the next one.
Note that the above can apply to any application you develop. The
work on the front end to develop those documents can save you
tremendous work and wasted effort. For the lack of that front end
work, lots of bloated over budget and overdue projects are really
small but poorly defined projects trying to get out. People who write
software (who design and deliver projects of any kind), want to get at
their craft, they don't want to write documents. However the joy of
getting things done right the first time will banish the fears and
hate of the documents. Another complicated and bothersome part of the
process is that the documentation itself requires maintenance as the
project moves along. A nice "waterfall" progression is assumed in the
dependencies between the various documents. Life isn't that simple.
You have to imagine circles and spirals wherein discoveries during
later phases of the project feed back into earlier levels, which may
require changes in the later documents.
You have sort of identified a few entities. From the few you have
identified you look to have a pretty ambitious application on your
hands.
If your motivation is to enhance your expertise in Access then you
have picked a great target application. Enjoy the journey.
If you just want to solve an immediate problem then I recommend some
research using google and other tools. You'll find lots of test
generation software and lots of related software. Some one or more of
them will meet most of your needs at significantly less expense than
creating your own solution starting from scratch.
If you have more issues, please post back.
Due to the fact that your project is similar to one of mine, I would
welcome private correspondence on it.
