Publication Home Delivery System


Functional Specifications


The Publication Home Delivery System(PHDS) is a user interactive computer system designed specifically for a newspaper and magazine distributor. Its objective will be to manage existing and potential new customers, publications, carriers, routes, and billing information and summary reports as required by this type of business in today's market.

The system will be under the authority of the distribution manager whose task will include the coordination of the entire delivery system. Operators, working under the manager, can be easily trained to efficiently and effectively use the system. The system will make seemingly routine tasks easier by methodically organizing the all important aspects, from adding a new customer to printing summary reports. Once in place, the amount of time needed to perform tasks and update the data base in the delivery system will be reduced, requiring only a few mouse clicks and key strokes to accomplish most tasks.

The system consists of six main sections. They are described briefly here to provide an overview as to their function. A more detailed description can be found in the latter pages of this document. There are six main sections:

The database managed by the system is expected to be quite large and it is therefore essential that the system perform all required tasks as rapidly as possible. This will be accomplished primarily by the high speed computer recommended as well as efficient algorithms used to access the data.

Since no hardware platform was specified in the informal specifications, we recommend, following current industry trends, that each system be run on an IBM compatible workstation. The system will require a minimum of a Pentium microprocessor, 100MHz or higher, 16MB of RAM, 17" SVGA color monitor, a minimum of 200MB of free disk space and access to two printers, a line printer to cheaply print route information for the carriers and a high speed laser printer for quality summary reports. Further we strongly recommend the use of a secondary backup medium such as a tape drive or read/write optical disk to ensure maximum information safety. As Graphical User Interface environments are becoming more popular, we will be designing the system to function with Microsoft Windows 3.1 (or greater) operating system.

Our goal is to develop a system that will function efficiently while maintaining simplicity. Our interface will be very simple, to address all user skill levels from beginner to expert.

Documentation will be thorough and complete. Training of the users will be made available by the developers of the system to ensure a complete understanding of its operations. It is expected that the system will greatly simplify the publication delivery service by reducing the overall amount of time required for setup and maintenance, as well as facilitate the day-to-day operations of the business.


This data base contains customer reference information. Specifically the system will contain the customer’s name, address, phone number, the status of their delivery, the publications they receive, their route information, and any notes specific to user requests or needs. This information will be entered via a keyboard into the computer or modified/edited by the computer using the following functions which will be selected by the user using either the mouse, or specific key strokes.For route name, a pop-up list of all available route names will be available to select from. The route postal code will be matched to a route and this route will appear either highlighted in the list, or displayed as a suggestion.

Adding a customer

The data mentioned above will be entered into fields on the computer screen. If any data fields are left blank, except the notes information, (there will be a not applicable default for the notes field), or the incorrect format of information is entered, the system will prompt the user to enter data for all fields or correctly reenter the data in the proper format. The user will not be allowed to continue until all record fields are complete. An example of the transaction “adding a customer,” and the format for the data to be entered is shown below.

	1) the user selects the add a customer function
	2) enter the customer name
	    E.g.,  	Doe, John   (last name, first name)
	3) enter the customer’s address
	    E.g.,	123, Main Street   (street name)
      			Calgary, AB     (city, province)
      			T5W 3K3    (Canadian postal code)
	4) enter the user phone number
    	    E.g.,  	(403) 555-1234 ((area code) phone number with dash)
	5) select the users publications from a list of publications offered by the company
	6) fill in special data for notes
    	    E.g.,  	be sure to put paper in mail box not on the step
	7) select a route from pop-up list and systems suggested route
	8) enter the status of delivery
    	    E.g.,  	suspended indefinitely, suspended for a specific time period, or regular delivery
NOTE: If any mistakes are made in entering the data they can be corrected using the modify function described below.

Deleting a customer

A user selecting this function would enter the Query of Customer Records interface described below.{edit out} The system would return the data from the search for this customer in the data base, and the customers information would be displayed to the screen. The user could now choose to remove the customer information from the database at this time, or exit from this function and do nothing.

We require clarification about what will become of information with regards to customers owing money to the company. Would this information be printed out to be acted upon and the customer deleted from the system? Or would this information be flagged showing money owing until all accounts were settled? When a customer has a balance other than zero, a warning should be issued and confirmation asked for. The confirmation proccess should offer the option of removing the customer information, remove the customer information and print an invoice or to exit. Once a customer is removed, the route and products data-bases should be updated.

NOTE: The unique customer key data for searches has not been determined. It has been assumed that a customer number would be given to each subscriber to make the search key unique. The unique search key should be the last two digits of the year they joined-up followed by the first two letters of thier route name, followed by a 3 digit number that is unique within the route. A change in the route of a customer should trigger a change in their reference number.

Modifications to customer information

In this function the user uses the Query on Customer Records interface as described below, after which the system would search for the customer record and display it to the screen. At this point all data fields could be accessed by tabbing to them, and re-entering the correct, or new customer information via the keyboard. This data would then be saved in the data base.

NOTE: Specific security measures are not required {snip} so it has been assumed that all fields of a customer record can be changed at any time by any person with access to the system.

Suspend Delivery to a customer

If a customer does not require delivery for a period of time, they could contact the delivery service and request a suspension of delivery. The user would search for the customer in the database by the standard query on customer records {snip}and the data field for status would be set for delivery suspension or the data field would be set for delivery suspension and the data field for the date of delivery continuation filled in (This could be replaced with a time interval for which delivery is to be suspended, instead of entering a date). It is assumed that delivery charges are suspended at this time, and the account charges, or credits will carry over to when the suspension is discontinued.

The suspension would be ended by entering data as above except the status data field would be set for delivery continuation and charges/credits would be reinstated.

Query of customer records

The user starts a query using route number, route name, customer name, phone number, postal code, address or reference number. The query finds any unique match or gives the user a list of multiple matches to select form. The list will be formatted to have one customer per line, and any data on a customer not displayed will be accesible via a button click. Once a single customer is selected, all their information is displayed on screen.{edit}


Add publication

When creating a new publication, the user has to enter the following:

   	1) Name
	2) Publisher
   	3) Supplier Name
   	4) Supplier Phone Number
   	5) Subscription Rate
   	6) Type of Publication (i.e., Newspaper/Magazine)
   	7) Frequency of Delivery (i.e., Daily/Weekly/Monthly)
   	8) General Description of the Publication
   	9) Total Number of Subscribers is set to zero
	10)Key words(ie. Automotive, trucks, tractor-pull)

Before the above information is stored, the system will ask for confirmation so that the user can make necessary changes. The system will also check for duplicate publication. It will not allow the addition of a new publication that is already in the database.

NOTE: Any mistakes that are not corrected here can be addressed by the modify function described below.

Delete publication

The user has to select from a list or enter the name of a publication that is to be deleted.{snip} Otherwise, it responds by displaying all information of the publication. The user confirms the delete action. All subscribers of the publication should be notified, but this is not required by the system, however their accounts should be updated.

Modify publication information

Any information of a publication can be changed. The user selects from a list or enters the name of the publication. The system returns an error if the publication does not exist. Otherwise, it responds by displaying all information of the publication. The user then can make modification in the appropriate field(s). When adjustment is made in price, the new price only applies to new subscribers, it does not affect existing subscriptions.


All information of a publication can be listed on the screen by selecting or entering the publication name. The system returns an error if the publication does not exist. Information displayed here is for view only and it cannot be modified.

Carrier functions

The data base must be able to record and keep track of the carriers and the routes they deliver to. Items recorded into the data base will be the carrier’s name, address, phone number, and the routes they deliver to. These records will be created and modified using functions similar to the ones mentioned in household specifications.

Adding a carrier

The user selects the function, and enters the data via the keyboard as shown in the script below (similar to the add household described above).

	1) the user selects the add a carrier function
	2) enters the carrier’s name E.g.,  Doe, John
	3) enters the carrier’s address
 		E.g.,	456 Center Street  (street)
      		Calgary, AB  (city, province)
        	T8W 4E5    (Canadian postal code)
	4) enters the carrier’s phone number. E.g.,  (403) 555-1234
	5) enters the routes the carrier delivers to
	 	E.g.,  R1 R4 R6    (route #1 route #2 route #3)

The user will be shown the entered information when finished and asked for conformation that the information is correct. Errors can now be corrected, or the function can be exited adding the information to the data base.

NOTE: If any mistakes are made in entering the data they can be corrected using the modify function described below.

Deleting a carrier

In this function the user enters or selects from a list the carrier’s name and performs a search to display it to the screen. The user will then print the carrier routes for reassignment to other or new carriers, their routes are deleted, and finally the carrier can be removed from the data base.

NOTE: If routes are still assigned to the carrier then the carrier cannot be removed until their routes have been printed out.

Modifications to carrier information

In this function the user enters or selects from a list the carriers name. After which the system would search for the carrier record and display it to the screen. At this point all data fields could be accessed by tabbing to them, and reentering the correct, or new carrier information via the keyboard. This data would then be saved in the data base.


Add new route

When creating a new route, a route name and a carrier have to be assigned to that route. In addition a list of postal codes to define the boundaries of the route. Note that postal codes may be assigned to multiple routes(ie. the same postal code can be found in more than one route). This is to help find which route a new customer should be placed on. The postal codes, customer reference numbers, and addresses of all the households and the number of households belong to the new route are also needed.

Delete route

Entering or selecting a route will remove it, but a route can only be removed if there is no household in that route, i.e., the number of households is zero.

Display route information

When a valid route name is entered or selected from a list, the user has the option of viewing either all household belonging to the route or the total number of deliveries for each product on the current day. An error message will be displayed if the route name is invalid.

Generate Printout

A printout which contains route name, carrier name, carrier address, carrier phone number, route household addresses and status, and the publication(s) received by each household is generated and given to the carrier before he or she makes the deliveries. The user can print either a single route or the entire set of routes or a subset of routes may be selected from a list.

Billing System

The Billing system is responsible for periodically updating household accounts. This function should be performed at the end of every week, and additionally at the end of each month.

This system will allow the user to display,print or update billing information for a household or all households with a balance outstanding for subscriptions. When the billing system is started, it will ask the user if they want to generate a new set of bills for all households with an outstanding balance or find an individual household's bill , and either display or generate it.

If the user selects generate bills the system prints off a bill for each household which has an outstanding balance and returns the user to the main screen. Each bill is formatted in the following way:

If the user selects an individual household through the Query of Customer Records interface,{cut original query description}. Once a household is selected, the user will be able to view and modify the household's billing information (i.e., update their record of outstanding balance for a payment received). They can then print this household's bill out if they choose.

Summary Reports

The system will be able to produce a variety of summary reports on request from the user. All reports can be viewed on the screen or be printed out. Summary reports contain the following information:

	1) A list of total balance outstanding and number of subscribers, listed by publication, with grand totals at the bottom
	2) A daily report for each publication, with the number of subscription sales and their value, listed by route, with totals at the bottom
	3) A daily report with the number of subscription sales and their value, listed by publication, with totals at the bottom


System Structure

The following is the information structure that we are planning on using in the proposed system. The following lists the size of and expected contents of each field for each of the major sections.


     * Unique Customer Number (recommended addition)
          - {snip} last 2 digits of the year the customer signed up, first 2 letters of the route name
		the customer belongs to, and a 3 digit number unique to the route.
     * Name (surname, first name)
          - 20 Characters last name, 15 characters first name
     * Address (street, house number, apartment number and postal code)
          - 15 characters street, 7 characters house number, 6 digits postal
     * Phone number
          - 10 character phone number (XXX) XXX-XXXX
     * Status - Whether the household is suspended or not
          - suspension for an extended period, for a specific time period, or
	     delivery as usual check boxes, with a field that is activated
	     if the specific time period is to be entered with the form
	     (DD/MM to DD/MM)
     * What newspapers or magazines the household is currently
     subscribed to
          - Name of magazine {edit out--to a maximum of 5 entries}, selected from a menu 
	    or check boxes.   The number of subscriptions will be unlimited.
     * Present credit on the household account. A negative balance will imply
     a prepayment on the account, while a positive balance implies an amount
          - Account balance - $XXXX.XX approx. 8 characters to a maximum value of
     * A notes section to help the delivery people be aware of any special
     instructions indicated by the household. 
          - special notes 'n' rows of 30 characters apiece
     * A route name to identify which route the household is related to. This
     should be automatically related to the household based on their postal
     code and the predefined routes already entered into the system
          - unique route number approx. 5-15 characters and the route name.


     * Name, Publisher, Supplier Name, Supplier Phone Number
          - 30 characters name, 30 characters publisher, 30 characters
          supplier name, 10 digits phone number
     * Selection of(ie. home weekend, home daily, coporate rate for doctors offices or coffee shops)  Price Scheme - Price per issue/Weekly/Monthly deals (e.g. 2 year
     subscription for 50% off, etc.)
          - $xxx.xx per issue/x issues
     * Type - magazine or newspaper
          - one char for magazine or newspaper
     * Frequency of Delivery
          - ??  Daily delivery, able to specify which days.(eg. Fri,Sat,Sun or Mon and Sat)
	        Weekly delivery, able to specify which day
		Bi-weekly delivery, able to specify which day or dates
		Monthly delivery, able to specify date of delivery
		Irregular, able to specify a number of specific dates 
     * General Description - A brief summary of the publication, originally
     entered by the user
          - special notes 'n' rows of 30 characters apiece
     * Key Descriptors - (eg. Automotiv, trucks, tractor pull)
     * Total Number of people that are subscribed to the publication,
     calculated automatically.
          - XXXXXXX number of people subscribed (9999999 maximum)


     * Name (Surname, first name)
          - 20 Characters last name, 15 characters first name
     * Address (Street, House Number, Apartment number and Postal Code)
          - 15 characters street, 7 characters house number,6 digits postal
     * Phone number
          - 10 character phone number (XXX) XXX-XXXX
     * Routes they deliver to
          - unique route identifier X 'n' rows


     * Name
          - name of route, 20 characters
     * Unique route identifier X 'n' rows
     * A list of postal codes that are in the route
          - 'xxx-xxx' X 'n' postal codes in route
     * How many households are in the route
          - XXXX number of households in route
     * Which carrier is assigned to this route unique carrier name
     * Lists of households in route

Billing Information

     * All household information and our company letterhead should be
     produced at the top of the bill
     * Name (surname, first name)
          - 20 Characters last name 15 characters first name
     * Address (street, house number, apartment number and postal code)
          - 15 characters street, 7 characters house number, 6 digits postal
     * Phone number
          - 10 character phone number (XXX) XXX-XXXX
     * All of the households subscriptions should be on the same bill, with a
     bottom line total of the amount owed
          - Name of magazine/paper, 20 characters, to a maximum or 5 entries
          - with expiration date of subscription - Day/month/year e.g. 00/00/00
          - Account owed - $XXXX.XX approx. 8 characters, to a maximum value of
          - late charges if applicable $XXX.XX
     * Any late charges and expiration date for each subscription should be
     listed as well
     * All of the transactions since the last time a bill was printed for
     this household should be listed (e.g. payments received, new
     subscriptions, etc.)
          - previous balance
          - $XXXX.XX
          - list of transactions
          - date (00/00/00) type of transaction amount
          - new balance $XXXX.XX

Summary Reports

     * A summary sheet should be produced on request with total money owed
     and total number of subscribers by publication:
          - Publication Name  
	  - # of subscribers 
          - Total money owed $XXXXXXX.XX  maximum $9999999.99
     * Ability to generate daily summary information showing how many copies
     of each publication were sold that day. The number of copies sold and
     the total monetary value should be included.


Essentially there are four basic functions involved in the system. They include add, delete, modify, and query. These functions are described below in their generic format since more than one major section may involve one or many of them. A more in depth description of their function per section is described above in the functional specifications.

          - will permit the addition of any new "entity" such as a customer
          or a publication
          - corresponds only to the desired fields pertaining to that

          - will permit the deletion of any existing "entity" such as a
          customer or a publication
          - corresponds only to the desired fields pertaining to a section

          - will permit the modification of any existing "entity" such as a
          customer or a publication
          - corresponds only to the desired fields pertaining to a section

          - will perform a query corresponding to the search keys provided
          by the user
          - queries will differ by section, as per described in the
          functional specifications

NOTE: regardless of the function performed, all database updates must be cross referenced with other affected data bases (eg. adding a household, results in a route taking on a new household and an increment to a product's total delivery)

Project Features

The proposed Newspaper Delivery system will include the following features. It will keep track of all the customers (households) of the newspaper; recording such information as the name, address, phone number, status, and money owed by the household with the option to modify and query households individually. Modifying specific household information fields is possible, as well as adding and deleting all information for a household. Publications will also be listed along with their relevant information, giving the user the ability to modify information fields, add or delete publications as well as query selected publications. The system will also keep track of carriers that will deliver the publications to the households. The user will be able to hire/fire carriers as well as modify their personal information.

Households will be linked to carriers through routes, which will list items such as the name of the route and the number of households on that route and be defined by a list of postal codes (even though a household may be placed on a route though its postal code is not on that list). Through the routes, the system will allow the user to view the total number of deliveries per day to each individual route, as well as show all the households on a route. It will also be able to make print-outs per route or for an entire set of routes or a sub-set of selected routes.

Billing households will also be a part of the Publication Home Delivery System. It will list all the subscriptions, with totals and late charges and any transactions left owing {edit out -- since the last bill was printed}. Any household's bill can be generated at request. When payments are received, it will update the outstanding balance of a customer. A summary sheet will also be available that will list the total money owed and the total number of subscriptions. Daily reports will also be available that will show the number of copies of each publication sold and their total monetary value.

There are many different implementation options for a database system of this nature. In this case, the type of implementation is assumed to be synonymous with the computer architecture required to run the system, and the software used to create the database. Firstly, we must know whether the current hardware possessed is satisfactory to run a database system of this size, or are upgrades required or already planned for. If this is the case, how much money is available for upgrades. Secondly, what level of user knowledge should be required to use the database efficiently. For example, is the system meant for a computer novice or an expert. Once this is known, a better assessment can be made of possible implementations. Regardless, here are a couple of suggestions. *** Previously stated in this document was that the system would be designed for any level of user. This is an interface requirement of the system.

Our favored choice is an IBM compatible personal computer with the following minimum requirements: 486DX processor, 16 megabytes of memory, an SVGA monitor, 200 megabytes of free hard drive space, a tape drive for backup, a line printer, and a commercial quality laser printer. It also must have at least MS-DOS 6.0 and Microsoft Windows 3.1 installed. The database program will be programmed using Microsoft Access or a similar language such as Oracle. This options seems to make the most sense since many organizations already posses some or all of this hardware and have other uses for it such as running modern word processors, spreadsheets, etc. In addition, upgrades could be made relatively cheap and quickly.

The system needs to handle access by management, accounting, mail-room supervisors, region managers, distributor supervisors. And may be ported to affiliates in large urban centers(eg. New York). Perhaps a file server, some workstation, some terminals and some network software could be added in for the final deliverable. Also a most plausible enhancement in the future would be multi-level access, so that accountants are not deleting carriers for example.

If such hardware is not possessed nor is it wanted, a package might be able to be designed for a different system. This would require much more time though, and therefore would come at a greater cost. In this case, the specific software used would be dependent of the type of computers. If an older IBM compatible is the target, something such as Lotus 1-2-3 may be practical. If the machines are UNIX compatible with a graphical operating system (i.e.. X-Windows) something such as SYBASE and TCL could be used, again at greater cost. The user's knowledge of computers becomes relevant in this case, since the result of the later options would most likely require a greater level of comprehension of databases.

We would like to point out that a few assumptions have been made with regard to some missing information. Our assumptions are based on suggestions that would make the programming easier, in the case of missing fields, to making the system conform to current industry, such as the recommendation of the hardware and software platforms. As not all the assumptions are flagged, please be sure to review the functional specifications thoroughly and decide if our proposed system meets or even exceeds your requirements.

The missed requirements have been noted and updated within this document. Most contradictions in your specifications have been corrected, but by the nature of the document, please be careful not to overlook required specifications only because they do not appear in a certain section of this document but are found elsewhere.

Team Structure

The team structure was created with efficiency and high communication as the priorities. First of all, to avoid the problems that are often associated with larger groups it was decided that three smaller groups would be created. Each of these groups would represent one of the major of the major aspect of the project which are: interface, documentation and programming. The members for the teams were picked so that each of members strong points would be uses to the greatest potential. These teams are as follows:

	Interface       : Sean O'Rourke, Ian Mayhood, Henry Wong, Mike Ksenak
        Documentation   : Blair Whitford, Janice Webster, Guy Gravel
        Programming     : Dave Neufeld, Steve Thompson, Andy Lum, Michael Boonstra (4GL)
        Presentations   : Blair Whitford, Dave Neufeld, Janice Webster

The interface team will be responsible for creating the user friendly GUI between the users and the program. The documentation team will be responsible for the writing of most of the documentation, such as the user manual, as well as editing and typesetting any documents that are to be placed on the Web. The programming team will essentially write the program in the selected programming language. Note that all of the groups will interact with each other in that all members may be required to assist other groups if needed. As well all groups will participate in creating the documents.

To manage and coordinate the different needs of the teams a Product Manager was appointed and in order for there to be enough communication throughout the teams, a representative from each team was chosen. Meeting would be held with the team representatives and the product manager in order to make certain that: everyone is keeping up to the schedule, there are no misunderstanding ambiguities with the project, and to make sure that any concerns and problems conceding the entire project are dealt with and solved. The selections for these positions is as follows:

	Product Manager : Mike Boonstra
     	Interface       : Ian Mayhood
     	Documentation   : Blair Whitford
     	Programming     : Steve Thompson

In order to keep everyone informed of the current events, a secretarial and document manager position were assigned. The secretary is responsible for writing the minutes of the meetings and the document manager is in charge of posting this information along with all the other pertinent information, on the World Wide Web. These positions are filled by Ian (document manager), and Sean (Secretary).

Everyone of the team members will be involved with some aspect of the testing. Which aspect they will be involved in will be determined by the individuals strengths but not necessarily by which sub-team they are in.

Minimal System

The minimal system that will be implemented is separated into five major subject components: customers, publications, subscription, routes, and carriers. Each one of these parts will contain functions that will allow the user to add, modify and delete their perspective data. This data and the rules for its entry are covered in the previous paragraphs. There will also be various functions that allow the user to view the data of one of the subjects by individual record, and by a group of records.

There are also more specific functions. A user will be able to suspend a customers account for a specific time period or indefinitely. There will also be a function that will create a print out of the days deliveries as was specified previously.

Due to perceived time constraints this proposed system will not contain a billing system. After much discussion it was determined that the billing system was too complex to be created as scheduled. An enhancement that may be added in the future is to add a partial billing system. This would not include anything as specific as a list of payments for a particular invoice, but more likely would include enough functionality for it to work along side a separated billing system. Some the functions covered in this system would include summary showing total Money owed and total number of subscribers by publication, daily summary information showing how many copies of each publication were sold that day, ability to generate bills for households, and ability to update balances when a payment for an invoice is received.


This system when completed will be user friendly to help employees complete their everyday work, tasks, and projects. A graphical or windows interface will guide the users through the functions described by the users to keep the newspaper service running smoothly.

We believe good programming techniques, and meticulous attention to data base manipulation will make our system both efficient, and reliable so everyone can meet their goals, and get their jobs done.

Back to the INFO SYSTEMS Inc. Homepage.

last modified by Darrell Nash
Last Updated:  January 30, 1996