Customer Group #7
Response to Overall Design Document
Click here for our Supplier Group's Overall Design Document
There is a simple correction. Definition of publications should read:
Publications -- defined as the magazines and newspapers delivered
by the service (as opposed to the publishers
of these magazines and newspapers).
When adding a new customer, it states that "the user will not be allowed to
continue until all record fields are complete". We do not feel that this
is needed, or even desired. For example, if a household has no "special
data" for notes, or if the household's phone number has yet to be
obtained, the operator should still be able to enter a valid household
into the system.
The postal code entry should also include other forms of postal addresses
(eg. Zip Codes from the U.S.) in case we wish to expand.
A simple clarification is desired here about the method of searching
for a publication upon selecting either Edit or Delete.
We want the searching engine and interface to be identical in both cases
as with just a normal Searchfor a publication. As well, it would
desirable if the option to edit or delete were made available after a normal
search has been performed, as opposed to having to exit the Search
screen and enter a different window to perform the action.
When adding a new publication, it is stated that "it will not allow the
addition of a new publication that is already in the database."
The exact criteria used in determining if one publication is the same as
another needs to be specified, since it is quite possible that two or more
different publications can use the same name, pricing scheme, publisher, etc.
As well, in step 3 of entering the "appropriate data", we would very much
like the option NOT to have enter every field listed at that exact time.
For example, if the operator does not know the phone number of the
distributor at the moment of entering a new publication, the system should
allow the field to be left blank.
When deleting a publication, the document states "their accounts should be
updated". It does not specify whether the system will do this or if it is
required by the operator. We require that the system handle this detail.
Concerning the list box of routes to select from when adding a carrier, we
are assuming that it is only the list of routes that are currently NOT
assigned to anyone else (as opposed to a list of every route in the system).
This is simply because only one carrier should be assigned to one route at
any given time. If a route becomes too large for a single carrier, the
operator would manually change/add routes to remedy the situation.
In "Adding New Routes", since a route should be assigned only to existing
carriers, why not just select from a list of carriers rather than require the
operator to enter the carrier's surname and given name (as in steps 3 and 4).
Step 5 seems completely out of place, since publications are not even involved
in defining a new route (they are handled by a different part of the system
entirely). Step 6 seems redundant if a carrier has already been defined for
In addition, there is no mention of postal codes assigned to a new route
(which is presumably how a newly entered household is assigned a default
route). We would also like a clarification on how the system would handle a
carrier quitting. The route should be reassigned to another carrier, or at
least a notification provided if there are routes without carriers assigned
Changing a household's billing information must be a controlled access
function of the system available only through a specific set of transactions
such as applying payments, discounts, NSF charges, or late charges to a
household. A minimal billing system would require only the generating and
printing of one or all invoices for households with an outstanding balance.
We require a daily list of publication sales. It is important that we are
able to produce summary sales information so we can forecast future
requirements (eg. staffing, number of publications to order, etc). This
should be a simple calculation based on the daily delivery output sent to the
carriers, and all that is required is a straight-forward summary page
displaying totals for all of our publications.
We are disappointed that the billing and summary reports are not part of the
minimal system and therefore would like you to consider implementing the
minimum functions of these systems as mentioned above.
A small and easy change in the "publications" section should be taken into
consideration. The 'type' of publication -- magazine or newspaper -- could
be expanded to include an 'other' category in case our company wishes to
expand, or perhaps just promote a one-time delivery item. So, 'magazine',
'newspaper', or 'other' should be in the information structure (still only
requiring one character of data).
In the 'Project Features' section, a couple questions posed by your group are
- First of all, the system should be geared towards novice users (as
opposed to expert database professionals), although minor introductory
training will be assumed to occur before the system is operationally
used in our company.
- We certainly prefer the Intel-based implementation (ie. 486DX, 16Mb RAM,
etc) over the Unix alternative, for desktop PC's are considerably cheaper
to purchase, and more commercial software is available for this platform,
making the computers more useful for other tasks such as word processing
and spreadsheet applications (external to this project, of course).
We are slightly concerned with the statement "every one of the team members
will be involved with some aspect of the testing (Team Structure, 4th para.)".
This seems to be the only sentence mentioning the issue of software testing,
which is deemed by us as an essential part of software development. More
consideration towards this topic should be allotted in the management plan
to insure that the quality of the final product is at our level of expectation.
As a final note, we feel that the summary of this overall design document
is weak in substance. A summary should outline the main features of the
system in a brief, concise format which allows the reader to know the
general functionality of the system. The summary here only specifies the
obvious of what a system should be (ie. user-friendly, helpful, uses good
programming techniques, etc.)
Back to our home page
Last Modified Feb. 15, 1996 by