Customer Group #7

Response to Overall Design Document

Click here for our Supplier Group's Overall Design Document

Introduction

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).

Households

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.

Publications

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.

Carrier Functions

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.

Routes

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 this route.

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 to them.

Billing System

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.

Summary Reports

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.

Management Plan

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 answered:

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