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.
Functional
Specification and Management Plan Department of Computer
Science Page maintainer: Terrence
Asgar-Deen |
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
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:
Functionality
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.
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.
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 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.
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.
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 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.
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:
The
number of calls is an excellent idea -- of course you mean for a user
specified time period.
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:
The order report summarizes all information concerned with an order. The following list includes the information required in this report:
Referring
to 'Products' above implies more that one product per order, that is exactly
what we want. We would also like Product # ad Motif #, and the total price
of the order on the 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.
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.
This report displays a list of all the salespeople. This report includes all pertinent information for each salesperson.
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.
Correct us
if we are wrong but isn't Novell NetWare 4.11 a software product, not hardware.
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.
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 | SALESPERSON | PRODUCT |
|---|---|---|
| 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.
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:
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 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.
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:
It would be
great if the 'Item' changed to the specific item it was referring to at that
time.
Custom
reports are a great idea!!!
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, 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 resides at the bottom of the window and displays information on the status of operations, and descriptions of menu commands.
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 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.
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.
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.
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.
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 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 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:
For a salesperson, the user interface makes the following changes to the View menu and associated toolbar buttons:
As
we have said in other comments, we want the salesman to have the option
of viewing the entire customer list.
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.
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.
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.
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?