Executive Summary and General Description:
Main Window Documentation:
Customer Information Interface Specification:
Order Information Interface Specification:
Product List Interface Specification:
Route List Interface Specification:
Test Plan Specification:
Database Model:
Management Plan:
Glossary:
Editors:
Final Editors:
Screen Snapshots:
HTML:
The BFI001 system, which is being developed by MacroHard Inc. for BFI, will revolve around a standard Windows interface. The system itself will be implemented in MicroSoft Access, and will allow users to obtain a wide variety of business related information. Users will have access to several ranges of data relating to their customers, their products, and the business of taking care of their customers.
Four sets of functions will work closely together to provide the user with convenience and power. Customer and product records are the first of these, and will be easily maintainable by the user. As well, new orders will be simple to place, and routes will be automatically generated on a day- to-day basis. Aside from these central tasks, many other subtasks exist. For example, it is possible to print invoices for customers, or to view previous orders made by a customer. Together these functions will work within the system to provide all users with the tools they need to make great strides in todays turbulent economy.
Windows:
The BFI001 system is laid out over five main windows. The main screen consists of buttons that allow the user to select from any of the remaining screens. The remaining windows are broken down by their major functions.
The Customer Information Window contains all information related to customers. This window allows the user to search for a particular customer, and to place a new order based on the customer they have selected. The Order Information Window contains all functions related to the placing of a new order, or the viewing of a previous order. The Product List Window contains all relevant data relating to the products that exist, and the Route List Window looks up all orders that need to be delivered and prospective customers that should be visited by the salesman. Several subwindows also exist to allow the user to search for key information, or set print options, and these are directly tied into one of the four functional windows.
Buttons:
A standard feature contained within our system is the placement of buttons on the screen. Not only are the buttons placed in similar positions from screen to screen, but the buttons found at the top of the screen contain features related to the functionality of that particular screen. The buttons located at the bottom of the screen take care of common tasks that are found on most screens, such as displaying system help, and canceling or saving information on the screen.
Fields:
Fields serve as 'containers' for relaying information to the users obtained from the databases. A large variety of fields exist in each of the different windows. Some fields can be modified, while others will remain fixed, and will be filled in by the system. Please refer to the database model towards the end of this document for more detailed information related to the fields of the system.
Menus
A menu bar is also included in the system, and appears as a constant feature available from any screen. The menu bar will contain several pull down menus, of which all include a small family of functions.
Menu: FILE
Menu: EDIT
Menu: GO
Menu: WINDOWS
Menu: HELP
[Administration]
[Customer/Order Information]
[Product List]
[Route List]
This first creates a new route list, if required, then opens up the Route List
Window.
Pseudocode for CreateRouteList:
- Open the database.
- Open the "Stored Variables" table as a recordset.
- Move to the first record in the recordset.
- If "Route List Date" in the recordset is for an earlier day:
- Run the "Clear Route List" query to clear the route list.
- Run the "Create Route List" query.
- Update "Route List Date" to the current date.
- Open "Route List" form.
Description of "Clear Route List" query:
- Delete all records in the "Route List" table.
Description of "Create Route List" query:
- Select all orders from the "Order" table that have an Order ID that matches an Order ID in either the "Undelivered Orders" query or the "Projected Orders" query, and for each selected record create a record in the Route List table with the Customer ID from the Order table in the Customer ID field, the Order ID from the "Undelivered Orders" query in the Order ID field, the Order ID from the "Projected Orders" query in the Last Order ID field, and the value True in the Active field.
Description of the "Undelivered Orders" query:
- Select the Order ID from all records in the Order table that
have a NULL value for the Delivered Date.
Description of the "Projected Orders" query:
- Select the Order ID from all records in the Order table with
an Order ID matching an Order ID from the "Customers' Last Orders"
query and a Next Order Date that is less than or equal to the current date plus five days.
Description of the "Customers' Last Orders" query:
- Select the maximum Order ID for each set of records in the Order table
grouped by Customer ID.
[Exit]
This will exit the application and MS Access.
1) Place a new order for a customer. The default order which comes up when a new order is placed by the salesman is the previous order for that customer. The salesman is also given the option to begin a new order with a blank order form.
2) Update and change an order. The program will allow the salesman to change part of an order which has yet to be delivered. The View Product list aids the salesman by assisting him in finding a product. Once a product has been found in the database, the salesman can insert it into the current order.
3) Recall a previous order. All previous orders are kept on file in the system database. This gives the user the capability to conduct research into a customer's ordering habits, or to recall a particular past order on the request of a customer.
There are also some subfunctions which the system has to assist the salesman in placing orders. As previously described there is a link to the View Product List subsystem. This system is used by the salesman to find a particular product. The salesman will be able to search on the product name and identification number (Please refer to the Product Information Screen implementation details). If the salesman can not exactly remember these he/she can guess as closely as possible and then scroll through the list of products from that point until he/she has found the desired product. After finding the product in question, the salesman has the ability to insert that product into the order.
The other subfunction available to the salesman is a Print function. This will print the order to the standard printer defined by Print Manager. As well, all other Print Manager features will be available to the salesman. The Printed order will look like an invoice. At the top will be the name, address, city, province, postal code, contact, and contact phone number of the customer. Below will be an invoice containing the elements of the order. Each product will be listed in the invoice containing such information as the product name, product number, product type, price per unit, quantity, discount percent, discount dollar value and the total for that product. Below that will be the calculations for the entire order, including the subtotal, discounts, shipping, tax number 1, tax number2 (if applicable), grand total, and the balance owing.
Error conditions:
Another type of error that can occur is when the salesman enters incorrectly formatted data into a particular area of the form. When this occurs the system will display the error "Wrong format in field. This is the proper format ______". On the blank line the system will display the proper format for that form. Then the salesman will be able to select the OK button to close the error message, and the field will be automatically cleared. The salesman can also select the [Help] button and the system will display some help pertaining to the forms.
Button: [Delete]
Button: [New Order]
Button: [Delivered Today]
Button: [Help]
Button: [Product List]
Button: [Done]
Button: [Cancel]
Field: Company Name
Field: Order ID
Entry Field: Date Delivered
Field: Date Ordered
Entry Field: Next Order Date
Entry Field: Product Name
Entry Field: Product ID
Field: Type
Field:Price/Unit
Entry Field: Quantity
Field: Quantity Discount
Field: Discount $
Field: Product Total
Field: Sub-Total
Field: Discount
Field: Shipping & Handling
Field: Tax 1
Field: Tax 2
Field: Grand Total
A) TO PRINT AN ORDER FORM:
B) TO DELETE A PRODUCT FROM AN ORDER
C) TO PLACE A NEW ORDER
D) TO VIEW PRODUCT LIST
[Print]
This button opens up a dialog box that allows the user to choose to print the
Customer Information Report (showing all information about the customer
except order information) or the Customer Order Summary Report (with summary
information about the customer and their most recent orders, sorted in
descending order by order date), or both.
[New]
This clears the current fields for a new customer record, saving any changes to
the current record.
[Delete]
This deletes the customer record currently displayed on the form, after the
user has confirmed the deletion in a dialog box.
[Search]
This opens the customer information search dialog window to allow the user
to search for another customer record. The user will be able to search by ID,
company name, contact person or phone number.
[Help]
This opens up a window displaying information on how to use this window:
[Undo]
This undoes all changes made to the current customer record since it was
last saved. (A record is saved as soon as the user goes to a new record.)
It will not restore deleted customer records, but all deletions will require
confirmation.
[Done]
This closes the customer information window, saving any changes to the
current customer record.
[Cancel]
This closes the customer information window without saving any changes made
to the current customer record since it was last saved.
[New Order]
This opens the Order Information Window to allow a new order for the customer
to be added. The order may include default entries copied from the customer's
last order (which may be edited by the user), but this feature may not be
included in the minimal system.
[Edit Order]
This opens the Order Information Window to allow the order selected in the
Order Information List to be edited. (The user can also double-click on
the selected order to do this.) If the selected order has already been
delivered, the user will not be able to edit it, but they may still view
it in the Order Information Window.
For all text fields, if the user attempts to enter a name that is too long, the extra characters will not appear, and the computer will beep.
For combo boxes, if the user selects something that is not in the list, a
message will appear telling them that they must select something from the
list, and advising them to press
ID: This field uniquely identifies the customer record. It is an integer assigned automatically by the computer (in ascending sequence) and it cannot be edited.
Company Name: This is a single-line text field, with no input restrictions beyond the length.
Contact Person: This is a single-line text field, with no input restrictions beyond the length.
Phone Number: This field will have an input mask requiring the user to enter the number in the format `(999) 999-9999', where the nines stand for any digit.
Address: This is a multiple-line text field with a vertical scroll bar. There is no input restriction beyond the length.
City: This is a single-line text field with no input restrictions beyond the length.
Province/State: This is a single-line text field, with no input restrictions beyond the length.
Country: This is a single-line text field, with no input restrictions beyond the length.
Postal Code: This is a single-line text field, with no input restrictions beyond the length.
Sector:
This is a combo box that allows the user to select the customer's sector
by name. The attached list will show both sector names and their
sequence numbers, sorted by sector name. If the user enters anything
that is not in the list and then tries to leave that field, a message
box will pop up to tell the user that they must select something from the
list (and advising them that they can press
Credit Limit: This is a single-line text field with a currency format. If the user enters something other than a number, a message box will pop up to tell the user that they must enter a number.
Comments: This is a multiple-line text field with a vertical scroll bar with no input restrictions.
Order Information List: This is a list box displaying summary information about the customer's orders, in descending order by the order date. The user can scroll through this list and select orders with the mouse, but the information in the list cannot be edited from this screen. Double-clicking on an order in this list, or selecting an order and then pressing the [Edit Order] button, will open up the Order Information Window with this record selected for editing or viewing. Note that orders that have been delivered already cannot be edited, although they may still be viewed.
This window will allow the user to choose to print one or both of the Customer Information Report and the Customer Order Summary Report. The report(s) will be displayed on the screen as they will be printed, and the user will be able to print them or select a different printer from the File menu. The [Done] button closes the print box and displays the selected report(s) for printing (one after the other if both are chosen), the [Cancel] button closes the print box without displaying or printing the reports, and the [Help] button opens the help window for the print box, with information on the reports and how to print them.
Here are two sample printouts:
This box displays four combo boxes that can be used to search for a customer: ID, Company Name, Contact Name and Phone Number. Each will have a list sorted by the associated field, but also displaying the values for the other three fields. When a selection has been made in one of these fields, the other fields will be updated to display the values for the selected customer record. By default, this box will show the information for the record currently displayed in the Customer Information Window. Clicking on Done will cause the matching record to be found and displayed in the Customer Information Window, clicking on Cancel will close this box without performing a search, and clicking on Help will open a window with information on how to use the search box.
This screen is accessed via the main menu or the order window. BCI's list of products is displayed in this screen. By default, all the products with their corresponding information are shown. Each product line consists of a product name, a unique product id number, a type identifier, and a price.
If the user has entered this window from the order window, then if they double click on one of the products, that product will be added to the current order. Of course if that product already appears on the order, double clicking on a product will do nothing. The information that will appear on the order window is the product name, the product id number, the type identifier, and the price. All other order information must be filled in later by the user. There is also an [Add to Order] button, described below, which accomplishes the same task.
If the user has entered this window from the main menu, then double clicking on any product will do nothing. Also, the [Add to Order] button is disabled and greyed out.
The format of the print would be
Button: [Filter]
Button: [Search]
Button: [Help]
Button: [Reset Filter]
Button: [Done]
There are four fields in the product list window: product name, product id number, product type, and price per box.
These fields are not editable. Product information can only be changed in the administration section, which will not be implemented in this phase.
Help:
How do I
This window is opened by clicking on the [Search] button on the Product List window. The purpose of this window is to allow users to locate a specific product in the product list if they already know all or part of the product's name or ID number.
Window Title: Search for Product
begin pseudocode (On Click event)
Query Description:
begin pseudocode (Before Update event)
begin pseudocode (After Update event)
Query Description:
begin pseudocode (Before Update event)
begin pseudocode (After Update event)
begin pseudocode (On Click event)
This window is opened by clicking on the Filter button in the Product List window. The purpose of this window is to allow users to restrict the products shown in the Product List window to those products which match certain types or price ranges.
begin pseudocode (On Click event)
begin pseudocode (On Click event)
begin pseudocode (On Click event)
begin pseudocode (On Click event)
Button: Left Arrow
begin pseudocode (On Click event)
List Box: Displayed Types
begin pseudocode (On Double-Click event)
begin pseudocode (On Double-Click event)
Before opening the window, the program checks the date of the list in the Route List table to see if it is current (i.e. it was created earlier on the same day). If it is, then the list is displayed in the window (the format is described below). If the existing list is not current then the new route list is computed and displayed, and the database is updated to reflect the new date for the route list.
How the route list is computed:
The Buttons
Route List Display Area
The column headings (fields) in the display are: Active, Order Id, Company Name, Order Type. Each row in the display is either a delivery or a prospective customer, as indicated by the Order Type field. The rows are ordered using the most efficient route, based on the sequence number for the sectors (within sectors, no ordering is done), with the first delivery in the first row and the last delivery in the last row. A vertical scroll bar can be used to move through the list.
The choices given to the user are:
The "Invoices for deliveries" choice, when selected, will print
out all of the invoices for the companies that the salesman is
supposed to visit that day.
Here is a sample invoice (condensed):
The "Prospective customers" choice, when selected, will print out
the projected orders for all of the prospective customers.
The format of the printout has not yet been finalized.
You would like to:
If there is no printer connected to the computer, the printer is not on, the printer is off-line, or the printer has no paper then MS Access will display an appropriate message.
If there are no selections made in the Print Box (no choice is
marked) and the [DONE] button is pressed, then a message dialogue box
will pop out and tell the user to select something before printing
anything. The message box will be closed after the user has finished
reading the message and has clicked on [DONE] button on the message box.
The central objectives surrounding our testing are to ensure that our system is assembled with as few logical defects as possible, and to minimize the number of programming bugs and glitches in our system. Our most extensive testing will be the unit testing of each individual screen. Once we are sure that each screen is up and running to its highest potential, we will be able to assemble the pieces to form the complete system. As the pieces are completed and individually tested, each step of the integration process will be likewise tested for compatibility amongst components. This integration testing will be of the utmost importance to make sure that the system can function as a whole. When all of the tests have been completed, all bugs fixed and all errors in logic have been worked out, we will put the system through two more types of testing. These will include passing a set of walkthrough "real life" scenarios that may occur in connection with our system. This acceptance testing will be followed up by usability tests done by subjects working with our system. Through watching these subjects work with the system that we have created, we will be better able to determine if there are any areas that need reconsideration before our product is released for use in the offices of BFI.
We have established programming and testing schedules that involve members from every division of our team. It is our feeling that there may be issues which our programmers and/or design teams have overlooked or can't see due to their closeness to the project. Hence other members of our team will be closely involved in the testing of our system to help discover additional problems and errors. This will directly boost the quality of the system being built for BFI.
Our principal objective is to make sure the system is of the highest functional quality possible. This will be achieved by meeting the following objectives:
- proper integration between modules
- correct logic
- elimination of bugs and faulty code
We have broken the system down into five basic modules, each of which will be tested individually after it has been coded, before its final integration into the system. The five modules consist of the Main Menu screen, the Product List screen, the Customer Information screen, the Order Information screen, and the Route List screen. Each of these modules must have its individual components tested, such as buttons, fields and dialog boxes. There also exists the underlying "behind the scenes" functionality associated with each model which must be tested extensively to verify correct data flow within the system. This deeper aspect of the system will be covered in more detail under integration testing.
Our unit tests are organized into sections divided by the window. For example, all the unit tests for the buttons and fields associated with the Customer Information Window would be described under the heading Customer Information Window.
Buttons:
In cases where the Test section is empty, to test that button just press it.
Fields:
The Edit, and Etest will only appear in instances where the field can be edited. In all other cases the field cannot be edited. To test these fields, try to type something into that field. A success would be if nothing happens.
The DClick, and Dtest will only appear in instances where something is supposed to happen when that field is double clicked. In all other cases to test the field double click on the field. If nothing happens, then it is a success.
This means that many of the test descriptions will only have a field name. This means that it cannot be edited and nothing should happen when you double click it, ie. it's only purpose is to display information. So to test these, just make sure that the fields have the correct information in the correct format.
Button: NEW
Button: DELETE
- No. then the currently displayed record should still be on the screen, and should still be in the database.
Button: SEARCH
Button: PRINT
Button: HELP
Button: UNDO
Button: DONE
Button: CANCEL
Button: NEW ORDER
Button: EDIT ORDER
Field: ID
Field: CUSTOMER NAME
Field: CONTACT
Field: PHONE-NUMBER
Field: ADDRESS
Field: CITY
Field: PROV
Field: COUNTRY
Field: POSTAL-CODE
Field: SECTOR (Combo box)
Field: CREDIT-LIMIT
Field: COMMENTS
Field: ORDER INFORMATION LIST (list box)
Button: HELP
Button: DONE
Button: CANCEL
CheckBox: PRINT CUSTOMER INFORMATION
CheckBox:PRINT CUSTOMER'S RECENT ORDERS
Button: HELP
Button: DONE
Button: CANCEL
Field: CUSTOMER ID, COMPANY NAME, CONTACT NAME, PHONE NUMBER
Button: PRINT
Button: SEARCH
Button: FILTER
Button: HELP
Button: ADD TO ORDER
Button: DONE
Field: PRODUCT LIST
Button: DONE
Button: CANCEL
Button: HELP
Button: >
Button: < (Identical to > except in opposite direction.)
Field: FILTER
Field: SELECTION (Identical to Filter except in opposite direction.)
Field: FROM PRICE
Field: THROUGH PRICE
Button: DONE
Button: CANCEL
Button: HELP
Field: PRODUCT ID
Button: PRINT
Button: DELETE ORDER
Button: NEW ORDER
Button: HELP
Button: VIEW PRODUCT LIST
Button: DONE
Button: CANCEL
Button: DELIVERED TODAY
Field: ORDER ID
Field: ORDER DATE
Field: DATE DELIVERED
Field: NEXT ORDER DATE
Field: PRODUCT NAME
Field: PRODUCT ID
Field: TYPE
Field: PRICE/UNIT
Field: QUANTITY
Field: DISCOUNT $
Field: PRODUCT TOTAL
Field: SUB-TOTAL
Field: DISCOUNT (PERCENT)
Field: DISCOUNT (DOLLARS)
Field: SHIPPING & HANDLING
Field: TAX 1 (PERCENT)
Field: TAX 1 (DOLLARS)
Field: TAX 2 (PERCENT)
Field: TAX 2 (DOLLARS)
Field: GRAND TOTAL
Field: BALANCE OWING
Button: HELP
Button: EDIT CUSTOMER
Button: DONE
Button: PRINT
Field: ROUTE LIST DISPLAY
Button: HELP
Button: DONE
Button: CANCEL
Checkbox: PRINT ROUTE LIST
Checkbox: PRINT INVOICES
Checkbox: PRINT INFO ABOUT PROSPECTIVE CUSTOMERS
Our integration plan calls for a bottom up approach, beginning with testing by running unit tests screen by screen. The integration tests will be conducted while connecting the various pieces of the system together. For example, some functions in the product list affect the information on order information window. These features will be tested in the integration tests.
FILTER screen from product list The test consists of performing a filter, pressing done, and then verifying that only those products which passed the filter conditions remain in the product list.
EDIT CUSTOMER from route list window This can be tested by choosing a customer from the route list and then pressing EDIT CUSTOMER. If the customer information window pops up with all of the highlighted customer's information filled in, and which the user can then edit, then it works properly.
While testing, some unexpected errors are likely occur. Depending on whether error-handling code has been put in, this may cause MS Access either to display a message with the error number and cancel the action that caused the error, or to go into a debugging mode, displaying the code that caused the problem. If either of these events occurs, or a logic error is observed (incorrect computation, etc.), the bug should be reported to the project manager (Gillian Posey) in the following format or a similar format, and she will either correct the error herself or assign the problem to the appropriate person. If the tester believes that they see the solution to the problem, they should describe it when reporting the bug.
_____________________________________________________________________________
This is a group of hypothetical situations that will serve several purposes. First, these walkthroughs are a way of testing the integration of the modules with each other. Second, the walkthroughs can be used as a script for our demonstration. Third, these walkthroughs can be used as a method of studying the usability of our system.
Situation 1:
As time permits, we would like to take the time to sit down with some test subjects and to get their reaction to the system. These subjects would include some of the actual end users (employees of BFI) and some people totally unassociated with the project. Usability testing would help us to locate potential problems relating to ease of use in our system that may have been overlooked during the design phase. These changes would then be incorporated into the next release of our product.
The actual usability tests would be set up similar to an interview, where one person from our team would meet with an interviewee. The interviewer would then ask the interviewee to try to accomplish a number of predefined tasks, and all feedback from the user would be documented in detail. This will provide us with important feedback to be used towards the further improvement of the system.
Based on the fact that we have eleven members on our team, multiple goals can be set because not everyone will be working on every aspect of the testing and coding of the modules at the same time. Please bear in mind that these are proposed dates only, and can be changed as required, of which the only is exception is the acceptance testing, which is our scheduled presentation of our system to BFI on March 26.
Friday March 8, 1996:
Monday March 11, 1996:
Friday March 15, 1996:
Monday March 18, 1996:
Thursday March 21, 1996:
Saturday March 24, 1996:
Sunday March 24, 1996:
Tuesday March 26, 1996:
Testing will be done in the following teams (still subject to acceptance by the rest of the group):
Testing Team 1: (unit testing of Product List Screen)
Testing Team 2: (unit testing of Customer Information Screen)
Testing Team 3: (unit testing of Order Information Screen)
Testing Team 4: (unit testing of Route List Screen)
Testing Team 5: (integration testing of system)
Testing Team 6: (walkthroughs)
Testing Team 7: (usability testing - if time allows)
Testing is an important means that we need to use to ensure the quality of the products we create. It is absolutely essential that we test each individual piece of our program at the lowest levels possible to ensure that every error in coding and logic is found and rooted out. Testing now, though a long and involved process, will potentially save large amounts of money in software maintenance costs down the line. Testing is a crucial and central aspect that has to be given top priority by MacroHard to ensure that the final product we produce for BFI will be of the finest fuctional quality.
The program manager will be responsible for integrating the work of other programmers (or interface designers) into single application, and will also keep track of the current work assignments and ensure that everyone is working with the most current version of the database and whatever object(s) they are working on. She will also keep backup copies of all previous versions of the application, and will probably do most of the non-routine programming (e.g. anything that cannot be done using Wizards). She may assign integration testing and the creation of suitable test data to other individuals.
Changes to the application and assignments may be decided in group meetings, but the program manager will be responsible for keeping track of all agreed-upon changes and assignments. When it is not feasible to call a group meeting to decide an issue, the program manager may make a decision unilaterally, although this should only occur for minor details.
Other programmers and designers will mainly be responsible for designing and formatting forms and reports and creating associated objects, such as the underlying queries for the form or report and its lists and combo boxes. They may also write some of the associated event code (especially code that can be produced using wizards), but not without the knowledge of the program manager. They may not edit any code except their own, although they should advise the program manager of any bugs that they encounter. If they see the solution to a bug, they should describe it or include it in comments within the code.
Only one person will be responsible for changes to any object (e.g. a form or report, including its underlying queries) at one time, unless a group of people have agreed to work together using a single copy of the application, and no one will be allowed to modify any object in the application without the knowledge and agreement of the program manager.
Each individual is expected to test their own work and advise the program manager of any problems, but all changes will also be tested by at least one other person, both in isolation and together with the remainder of the application.
In general, several work assignments will be made at one time in a meeting and all people involved will receive a copy of the most recent tested and approved version of the application. Their work will be submitted at an agreed-upon time and then integrated into a single application, which will become the current version after testing has been completed. The first version of the application will be called "BCI01.DB", the second will be called "BCI02.DB", and so on.
The tables in the database must never be modified without the knowledge and approval of the program manager. Fields in a table will not ordinarily be renamed or deleted once they have been used in any part of the application, although new fields may be added.
Any field that is bound to the query underlying a form or report should have the same name (not caption) as the field that it is bound to, and fields in the current application will not ordinarily be renamed. If a field on a form is replaced with a new one, the new one should be given the old name once the old field is deleted. Buttons in a form will also not be renamed, although their captions may be changed. Buttons and unbound fields should be given informative names when they are created.