Functional Specification and Management Plan
CPSC 451 Supplier Group #1

Department of Computer Science
University of Calgary
26 January 1997

Page maintainer: Terrence Asgar-Deen

  • Terrence Asgar-Deen
  • Patrick Chan
  • Thomas Hui
  • Carsten Jaeger
  • Matthew Johnson
  • Brian Low
  • Hoang Nguyen
  • Kevin Pattison
  • Csaba Suveges
  • Jeremy Tang
  • Leena Thakkar
  • Al-Amin Vira
  • Lin Zhang
  • Editor: Terrence Asgar-Deen
    Co-Editors: Carsten Jaeger and Matthew Johnson

    The original page can be found Here. All comments on this page appear in the same format as this message.

    Table of Contents

    Company Organization

    Don't Have A Clue Software, Inc. (dHACs) is based on the principles of open cooperation and not on internal competition. Unlike most organizations, this allows for very efficient and organized design and analysis of the systems to be developed. Internal competition creates an atmosphere of ego and superiority which limits the abilities of the organization as a whole. The open cooperation method allows for ease of transition between projects and creates a constructive atmosphere for the employees to work effectively.

    For the specification of this document, the organization divided into two groups. There is no hierarchy within the organization, so everyone has the right to comment on anything discussed. The two groups are known as the Functionality Group and the User Interface Group.

    The members of these groups include:


    Please send our webmaster the names of one or two contacts for us to keep in touch with. You may send your questions and comments to the webmaster, or simply to the entire group

    User Interface

    The Functionality Group is responsible for the various functions that are useful to the user. This includes but is not limited to the following: generated reports, actions that are performed and functions required for accessing the database. In addition, the Functionality Group is responsible for the functions that are necessary for the system to run most effectively for your needs.

    The User Interface Group is responsible for the actual appearance of the system. This includes what graphical user interface is to be used and what windows are necessary to make the system easy to use for all the users. In addition, the Interface Group is responsible for the look and feel of the system and how the user interacts with the system as a whole.

    Project Summary

    The focus of this project is the design and implementation of a sales routing system for Peachy Business Forms (PBF) Ltd. PBF is a major supplier of business forms in the city of Calgary. A sophisticated system is required to assist their dynamic sales team in the management of their daily routes in an efficient manner. The central goal of this project is to provide the sales representatives at PBF with an easy-to-use system with a consistent user interface. Two important facets of the system will be the ability to anticipate PBF's customer's needs in a dynamic fashion and the ability to generate various user-defined reports of the data maintained in the system. The limited security requirements specified will also be met.

    System Highlights

    Through meetings with PBF's representatives, the system requirements were clarified and a excellent understanding of system's features was achieved.

    Some of the highlights of the system include:

    A more detailed analysis of the system requirements and functionality is presented below.

    The Users

    The users of this system are categorized as follows:

    The majority of the system's users will be salespeople. Their major responsibilities include:

    The major responsibilities of the administrators include:

    The division of the users also defines the security access restrictions. In order to provide a consistent interface, the entire user interface will be identical for both the administrators and the salespeople. When used by a salesperson, the system will display the majority of the administrator functions. However, access to the administrator functions will be disallowed though "greying" techniques. When used by the administrators, the "greyed" areas will become accessible. Since the administrator functions are a superset of the salesperson functions, additional screens may be required. However, these additional screens will have an interface identical to the more generic functions. For more information, see the section, Differences between Salespeople and Administrators.

    Hardware Requirements

    dHACs Software specializes in PC applications running on the Intel architecture. The system will run in a networked environment, such as Novell 4.xx or Windows NT Server 4.x. Workstations on the local area network (LAN) will be running Windows 95 or Windows NT Workstation. One of the business philosophies of dHACs Software is "every software solution requires a hardware solution". In order to provide PBF with a reliable system, both hardware and software, dHACs will provide hardware integration services. See Integration Plan.

    Document Outline

    This document, Functional Specification and Management Plan, is divided into the following sections: System Features describes the reports required by PBF. System Limitations and Constraints outlines the requirements that are beyond the scope of the system in terms of both time and cost. Design Merits describes strengths of various design decisions. Data and Algorithms describes data organization and associated algorithms for data operations. System Integration summarizes issues involved in the system's integration into PBF.

    System Features

    System features include the generation of reports required by PBF. The generation of reports neatly encompasses most of the required system features. In addition to the stock reports, dHACs Software will also provide the ability to generate new report types on the fly as required. This requirement was suggested during a recent meeting with PBF.

    Salesperson Report

    The salesperson report summarized the personal information and the activities of a given salesperson. This report is accessed through the salesperson's name or employee identification number. Under Canadian law, under no circumstances may a person's social insurance number (SIN) be used as a means of identifying them. As a result, PBF's suggestion that the employee number be a SIN is not feasible. The following list summarizes the information required on the salesperson report:

    Inventory Report

    This report summarizes the ordering information for all the forms. The following describes the content of the report:

    For each form, the report will generate the following information:

    Order Report

    The order report summarizes all information concerned with an order. The following list includes the information required in this report:

    Individual Customer Report

    This report summarizes a customer’s ordering history. This reported includes:

    We would also like the Cust Phone #, address, and contact person in the Individual Customer Report.

    List of All Customers

    This report generates information on all of PBF's customers. This report will include all pertinent information
    All pertinent information refers to all information of that customer, including the saleperson assigned to it.
    related to the customer. This report will be sorted based on a user-definable criterion. Examples of the various sorting criteria include:

    Daily Combined Customer Report

    This report lists all of the customers that must be visited by all of the salespeople for any particular day.

    List of Sales People

    This report displays a list of all the salespeople. This report includes all pertinent information for each salesperson.

    List of All Products

    This report displays information on all of PBF's products. The information generated for each form includes:

    We would also like the product description, unit size, prices on the report. Plus we could not locate Product name in the data storage area.

    Salesperson Customer Information

    This report contains a sorted list of all of the customers on a salesperson's route. Each customer on this report includes the following information:

    We would also like the customer address, phone #, and contact person on the report.

    Salesperson's Daily Route List

    This report lists any particular salesperson's customers that must be visited on a given day. The list will be sorted according to the salesperson's master route list.

    System Limitations and Constraints

    After meeting with PBF representatives, dHACs obtained clarification on some of the system's requirements. This section describes some of the major limitations and constraints of the Sales Routing System.

    Design Merits

    The System

    The system that is being designed will run most efficiently in a networked PC environment. The responsiveness of the applications will largely depend on the speed of the systems that PBF purchases. The design team at dHACs is well respected in industry for maximizing the potential of the hardware platforms used.

    Storage space efficiency will depend mainly on the size PBF’s customer base and invoice records. As the number of customers and invoices increases, the amount of space required will also increase. With the general availability of inexpensive large storage devices, this should not be a concern.

    For generating reports, PBF will also require printers. Depending on available funds, dHACs Software recommends a large networked laser printer. Such a printer provides high quality reports at a moderate price. The use of bubblejets and dot matrix printers are not recommended due to the high maintenance costs of such devices.


    The system will have two levels of security. One level for the administrators and another level for the salespeople. All users will be assigned a eight character username. In addition, to obtain access to the system, all users will be required to enter their corresponding password. The system will automatically adjust the user's access privileges based on the username.

    Login name size is ok. What about password size? We suggest a minimum of 5 and a maximum of 8 characters. We would like it to be case sensitive and encrypted, as well atleast one character is an alpha ( A-Z ) and one character is not an alpha.

    Administrators will have access to the entire system. This security level allows the user complete control over all information maintained by the system including the ability to add, delete, or modify records. In addition to the administrator functions, users at this level have access of all salesperson functions.

    Salespeople may only access certain data. They will only be allowed to view information pertaining to their route. In addition, salespeople will have the ability to view and generate reports based on their customers information. They will also be able to modify the ordering of their route. Salespeople will not have access to any other salesperson's customers or any other information that does not pertain directly to them.

    We would like the salesmen to be able to VIEW the Customer list, they should not be allowed to edit but they should be able to search through it. We figure this is a simple use of graying buttons on your part.


    Reliability is not a problem in this system.
    But will it be a problem?
    Since there is always a chance of something going wrong, dHACs will provide a backup solution to prevent data loss. Growth rate of PBF data will indicate how often backups will be required. This function will be administrator definable.

    Data Storage and Algorithms

    The system will store relevant data as described in the informal specification. See the section entitled System Features for a summary of the various reports and information to be generated by the system. This section focuses on what data is stored.

    The data will be grouped into various categories known as entities. These entities include SALESPERSON, CUSTOMER, and PRODUCT.

    Each entity stores several data items including a unique key. The data items stored by each entity are described below. Data elements marked with a * are the unique keys):

    The following summarizes how the data will be stored:

    Customer ID number* Name Product number*
    Company name Territory Motif number
    Street address Cellular/Pager/Email Type of form
    Postal code Office Phone/FAX number Size
    Telephone number Salesperson ID number* Comments
    Contact's name Max. visits / day  
    Contact's telephone number Comments  
    Company description    
    Company type    
    Date last contacted    

    We have some comments about the data structures. First of all, we would like customer to include City and Province for mailing purposes. Plus, again, should Product need a Name, and Price attribute? Is Size, under Product, the units/package? What do you mean by Company type? Finally, should Product # and Motif # be a compund key since one product number can have many motif numbers? And you did not specify the format of the product # and motif #. We specified NNNN-MMM for the format.

    In addition, an internal data entity is maintained to hold the relationship between the postal code and the territory. This relation maps the first three digits of the postal code to the corresponding territory. This relation determines in which territory a customer is in based on their postal code. In addition, this table is administrator modifiable to allow for the addition or modification of territories.

    The default you discuss is a good idea, but do we have to follow Postal Code standards? For example, it may be the case that two salesman have different customers in the same postal reference and we want to accomodate this.

    A password data entity maintains the usernames, passwords and security levels of all users. This entity is responsible for controlling system access. Password will be encrypted to maintain proper security. See the section entitled Security for more information regarding the various security levels.

    Additional information that must be stored includes the routes and ordering invoices. Routes are stored as a tuple involving a single salesperson and a single customer. Each customer may have only one salesperson, but any salesperson may have many customers. Each salesperson’s customer will be stored as a separate entry in a routes table. Storing the data in this fashion facilitates easy manipulation of the data as well as report generation. Orders are stored in a manner similar to the routes. An order consists of a triple involving a customer, a salesperson and a list of products ordered. Additional information to be stored with each order includes:

    All orders will be stored individually as well, for the reasons described above.

    User Interaction

    dHACs believes that the user interface is the most critical component of any successful system. A successful user interface allows users to perform their work effectively and efficiently. More specifically, dHACs sees two important goals:

    Simply, a well designed user interface reduces the total cost of a system because of less training, fewer support calls and reduced user frustration. As a result, dHACs has invested a considerable amount of effort to design an effective user interface.

    The following several strategies were utilized in the design of the interface:

    System Appearance

    The Main Window

    The entire program is based around a single window. A single window provides a constant frame for the rest of the system. The main window is made up of 5 main elements. The standard application window, the menu bar, the toolbar, the status bar, and the remaining work area is devoted to the actual operation of the application.

    The Application Window

    The entire application resides in a standard MS Windows window, and includes all the components of a standard MS Windows program. This includes the title bar, minimize button, maximize button, close button and resizable borders. Using the Windows look and feel keeps the system consistent with other applications the user may already be familiar with.

    The Menu Bar

    In designing the menu bar, dHACs wanted to have all possible functionality incorporated into a layout familiar to Windows users. The menus are laid out as follows:

    The File, Edit, and Help menus are standard Windows menus. The View menu lists the various areas of the program the user can jump to. The Item menu lists actions that can be performed on selected items. The Reports menu lists commonly generated reports. See the section System Operations for a full explanation of these menu commands.

    Commonly used menu commands will also have shortcut keys associated with them.

    The Toolbar

    The toolbar, which is used for quick access to commonly used commands, is located below menu bar. The default toolbar will contain buttons for:

    The toolbar will have simple, informative buttons, using standard images where possible. One possible enhancement is to provide the ability to customize the toolbar to suit the needs of individual users. This could possibly be accomplished using a drop and drop style similar to products like MS Word.

    Do you mean 'drag and drop'???

    The Status Bar

    The status bar resides at the bottom of the window and displays information on the status of operations, and descriptions of menu commands.

    The Work Area

    Finally, the work area is where the actual work in the program is done. This is where users view their daily route or browse the product list. The work area changes dynamically as the user moves from one area of the application to another. dHACs has avoided the use of dialog boxes wherever possible and kept major operations entirely within the work area. This makes it easy to predict where new information will be displayed and doesn't force the user into a particular program state.

    Starting and Stopping the System

    This system requires no special procedures to start, therefore it can be started just like any other Windows application (e.g. with the Windows 95 Start Menu).

    When the system first starts up, the user will be presented with the usual application window with a blank work area. The user will prompted for his/her username and password to login. Once completed, the system will determine if the user is a salesperson or an administrator and act accordingly. The section on Differences Between Salespeople and Administrators outlines the differences in the user interface between these two classes of users.

    Once the user has logged on, she or he may use the system to do their work. When finished, they have two choices. The first option is to exit the system. The second is to log out. This brings up the prompt to login again, allowing another user to login and use the system.

    A possible enhancement is to provide an auto-logout feature. This automatically logs out a user after they have not used the system for a predetermined amount of time. This is useful when users forget to log out or exit the program.

    The auto-logout is a good idea, you may include it if you wish.

    The Major Areas of the System

    Navigating the System

    The system has five main areas of information: the Daily Route information, the Customer information, the Product information, the Salespeople information, and the Orders information. Jumping to a particular area is as simple as selecting the area from the View menu or by pressing the corresponding toolbar button. This makes navigating the system quick and easy.

    Add New Customer Window

    When the Add New Customer Window is opened, the user is presented with a screen containing fields to enter the new information about the customer. The layout will be placed in two categories, Customer Information and Customer History. Within the Customer Information category there will be fields for the Customer ID, Company name, address, contact, phone number, and a field to override the default territory. The access to this window is unrestricted. In other words, a salesperson may add a new customer to the system.

    Add New Salesperson Window

    When the Add New Salesperson Window is opened, the user is presented with a screen containing fields to enter the new information about the salesperson. The layout will be placed in two categories, Salesperson Information and Comments. Within the Salesperson Information, there will be fields for Salesperson ID, Name, Password, Phone number, and Route Number. The access to this window is restricted to an administrator. In other words, a salesperson cannot add another salesperson to the system.

    Max Visits/Day should be included in the requested fields.

    Add New Product Window

    When the Add New Product Window is opened, the user is presented with a screen containing fields to enter the new information about the Product. The layout will be placed in two categories, Product Information and Product Description. Within the Product Information category there will be fields for Product ID, Name, Price per unit, and Quantity. The access to this window is restricted to an administrator. In other words, a salesperson cannot add a new product to the system.

    You have a field for product ID, I assume this is the Product number and Motif number combined. You request Name here yet you do not include it in the Product data structure. When you refer to Price per unit and Quantity, I hope you mean the units/package ( ie sheets per box ), and the corresponding price of that package. We are confused as this is not consistent with the data structures previously defined.

    Add New Order Window

    When the Add New Order Window is opened, the user is presented with a screen containing fields to enter the new information about the Order. The layout will be placed in two categories, Order and Order Description. Within the Order category there will be fields for Order number Customer ID, Product ID, Price, Date of Delivery, Company Name, Phone number, Address, Quantity, and Date of Order. The access to this window is unrestricted. Hence, a salesperson may add an order to the system.

    The Order Number should be automatically generated by the system and ensure uniqueness. Each order allows for multiple products on one order as your described under Order Report with 'Products ordered including:'.

    We are also unclear on the ordering concept and end of day processing for salesman. For example, how does a salesman tell the system that it did not visit someone on his list so that the system can include that customer in the next days list.

    Supporting Interface Functionality

    The Items Menu: Add, Modify, Delete and View Details

    The Items menu provides all the basic operations for managing the system's information. These menu commands allow the user to manipulate individual items in lists. They are available whenever lists of information are displayed. Each command is best described in terms of a particular area of the system. See the corresponding section in Major Areas of the System. For example, consider the situation when a user is viewing a list of customers: selecting Add from the Items menu will display a data entry form where the user can input the data to create a new customer. Selecting Modify from the Items menu will display the currently selected customer in a data entry form, and the user can modify any information on that particular customer. Selecting Delete, will delete the currently selected customer. Lastly, selecting View Details, will display all information on the currently selected customer, much like Modify, but without the ability to change any of the information.

    The Find Command on the Edit Menu

    The Find commands provides a simple and flexible process for quickly finding the information a user needs. The Find command is available when viewing a list of information (e.g. the Customer list). Selecting the Find command brings up a dialog that allows the user to specify the field to search on, and the criteria for that field. Clicking the OK button performs the search, and the results are displayed in the list. Just above the list would be displayed the criteria used to perform the search. This lets the user know that they are looking at the results of a search rather than all the information.

    For example, when viewing the Products list, the user can select the Find command from the Edit menu. In the Find dialog, the user can specify to search on the Color field, and enter "green". This will look for all products whose color is green. The list of products found would then be listed in the products list.

    A possible enhancement is to provide more advanced search capabilities. Specifically, the ability to search on several criteria. This might be implemented as an Advanced button on the Find dialog.

    The advanced button you described is also a nice feature, feel free to add it if you wish.

    The Reports Menu

    The Reports menu provides a list of commonly generated reports. Selecting one of these reports will prompt the user for the range of dates the report should include, then display a preview of the report. From there the user can simply use the report from the screen or print a hard copy.

    We really like the idea or being able to view a report before printing it. As well the 'saving' of customized reports in the Reports Menu is a great enhancement to the program, feel free to add it.

    A possible enhancement is to add the capability to create customized reports and list them in the Report menu.

    The Print and Print Preview Commands in the File Menu

    The Print command, familiar to most users, creates a report of the information that the user is currently viewing. When viewing one of the lists (e.g. Customer list, Product list, etc.), a report containing the same information as the list will be created. When viewing an individual Customer or Salesperson, a report containing all the information on the particular Customer or Salesperson will be generated. Before printing, the standard Windows Print dialog box will appear permitting the user to change printers, the number of copies, etc.

    The Print Preview command, allows the user to preview the report before printing it.

    The Help System

    The on-line help will be an important component in the system. dHACs realizes the need for complete and thorough documentation on-line and readily available. The entire User Manual will be on-line, fully indexed and searchable using the standard Windows Help system. Throughout the system, context-sensitive help will be available either on the Help menu or by pressing F1.

    We can't wait to see this option working!!

    Differences between Salespeople and Administrators

    Since Salespeople and Administrators have access to different area of the system, each requires a different user interface. dHACs has minimized these differences to provide a consistent user interface. There are only two differences:

    1. making unavailable menu items and toolbar buttons "greyed". The menu items and toolbars buttons still appear in the their normal positions, but they are colored grey and cannot be pressed or selected.
    2. changing the meaning of certain menu items. To a salesperson, "a list of customers" means a list of all the salesperson's customers. On the other hand, to an administrator, "a list of customers" means a list of all customers in the system. The menu items and toolbar buttons remain the same, but change slightly in meaning depending on the security level of the user.


    For a salesperson, the user interface makes the following changes to the View menu and associated toolbar buttons:

    The following changes are made in the Reports menu


    For an administrator, the user interface makes the following changes:

    These changes are good as long as this means access to everything as we required.

    Summary of Functionality

    This section provides a summary of the major points made in the previous sections.

    The main goal of the system is to satisfy the daily responsibilities of route administration for salespeople who service multiple customers. It will allow PBF to maintain records of which salespeople are responsible for which clients, the products that each salesperson is to deliver to the clients for each day and to suggest an order for which the customers are to be serviced. Additionally, the system will have the capability to generate invoices, guarantee security levels and provide up to date information about the status of certain orders. While its primary function is not to replace the existing paper-based system in place at PBF, it will certainly accomplish all that was possible before with the additional benefit of efficiency and accuracy. In short, the system strives to relieve the burden of administrative tasks, freeing time for more productive use.

    Integration Plan

    dHACs will provide all the necessary integration services including training and hardware purchases. dHACs feels the most ideal solution is to recommend the purchase of several personal computer systems running, at minimum, a 32 bit windows operating system. dHACs believes that staying current with a mainstream operating system, Microsoft Windows 95 or NT, will allow the needed flexibility to purchase and utilize office software packages. Furthermore, office software packages are more likely to maintain compatibility with those operating systems in the future, and thus adopting those systems will provide excellent foresight. The system itself will be developed in the latest version of Microsoft Access which is supported by both version of Windows. Microsoft Access provides the user with the familiar Windows environment and allows PBF the flexibility to support future hardware purchases, (such as faster printers or upgraded PC's) that are compatible with Windows, without the need to contact the developers. A formal proposal will be issued on a later date after the development of the system itself to describe the recommended hardware and network system needed to fully support this system.

    Using the System

    The system's user interface is an important aspect of the system design and is a high priority in purchasing systems. A clean and understandable interface will minimize costly hours of training needed for users to become proficient with the system. dHACs considers interface to be an integral part of the design functionality and have already taken many of the necessary steps to ensure a user effective system.

    Along with the fully developed system, dHACs will provide PBF with full user documentation with an initial full time training program. As part of the integration procedure, dHACs software will offer a full year of additional support and service maintenance for the system. All ownership rights to the system's source code will be accorded to PBF upon payment of the invoiced amounts. Finally, dHACs will recommend a contracting company to administer and maintain the system after the first year. dHACs software is closely affiliated with many technology contract service companies which ensures close communication between system support administrators and software developers.

    During the use of the system, dHACs software can be contacted for immediate service at any time of the day through our 1-800-number.

    What's the 1-800 number we should call?? :)

    dHACs Software looks forward to a long-lasting business relationship with PBF, not only on this project, but on other system development projects which may arise in the future.


    application the Sales Routing System also referred to as the "system" and the "program"
    data entry form an on-screen form that allows the user to enter data
    greyed to show that a menu item or toolbar button is unavailable by coloring it grey
    hard copy a physical printout of information
    logon identify yourself to the system, after logon, the system assumes all further interaction is with the identified user
    logout to inform the system that you will no longer be interacting with it
    maximize to expand a window to fill the entire screen
    menu commands also referred to as "menu item"
    menu items also referred to as "menu commands"
    minimize to reduce the size of a window to a minimum
    program the Sales Routing System, also referred to as the "application" and the "program"
    toolbar a (usually) horizontal bar containing small buttons that provide quick access to common functions

    Some other words that need clarification in the glossary : Tuple, Entity, Key.

    Just wondering what the minimal system you will be producing for us will consist of?