Two Wheels Local Courier System Specification Document

Two Wheels Local Courier System Specification Document

Tiffany Bonneau Bernard Simmons Norris Walker Vianco Hall September 25, 2003 Version Final 1.0

Reviewed by Project Manager: ___________________________ Reviewed by Customer: ________________________________

Two Wheels Local Courier System Specification Document Final Version 1.0

Table of Contents
1.0INTRODUCTION....................................................................................................................................................4 1.1 PURPOSE..................................................................................................................................................................4 1.2 SCOPE......................................................................................................................................................................4 1.3 OVERVIEW ...............................................................................................................................................................4 2.0GENERAL DESCRIPTION...................................................................................................................................4 1.4 PRODUCT FUNCTIONS.................................................................................................................................................4 1.5 RELATED SYSTEM INFORMATION..................................................................................................................................4 1.6 USER CHARACTERISTICS.............................................................................................................................................4 1.7 USER OBJECTIVES/GOALS...........................................................................................................................................5 1.8 GENERAL CONSTRAINTS.............................................................................................................................................5 3.0FUNCTIONAL REQUIREMENTS.......................................................................................................................5 3.1 CREATE CUSTOMER ACCOUNT AND ID NUMBER..............................................................................................................5 1.9 GENERATE PACKAGE ID#...........................................................................................................................................6 1.10 RECORD DELIVERY CHARGES, PAYMENT AMOUNT, AND PAYMENT TYPE.............................................................................7 1.11 VERIFY THAT A CUSTOMER ACCOUNT EXISTS................................................................................................................8 1.12 SCHEDULE OR QUOTE FOR COURIER SERVICE .............................................................................................................8 1.13 CHECK IF DELIVERY IS A VALID REQUEST..................................................................................................................9 1.14 PICK-UP CONFIRMATION..........................................................................................................................................10 1.15 DELIVERY CONFIRMATION.......................................................................................................................................10 1.16 PRINT OUTSTANDING DELIVERIES REPORT...................................................................................................................11 1.17 PERFORM 15-DAY CANCELLATION VERIFICATION.........................................................................................................11 1.18 TRACK PACKAGE STATUS.......................................................................................................................................12 1.19 CALCULATE DELIVERY CHARGE..............................................................................................................................13 1.20 CANCELLATIONS OF DELIVERIES OR QUOTE FOR SERVICE............................................................................................13 1.21 CUSTOMER INFORMATION UPDATE...........................................................................................................................14 1.22 CREATING USER ACCOUNTS....................................................................................................................................15 1.23 PASSWORD PROTECTED LOGIN ................................................................................................................................15 4.0INTERFACE REQUIREMENTS........................................................................................................................16 1.24 USER INTERFACES..................................................................................................................................................16 1.25 HARDWARE INTERFACES.........................................................................................................................................16 1.26 NETWORK INTERFACES...........................................................................................................................................16 1.27 SOFTWARE INTERFACES..........................................................................................................................................17 5.0PERFORMANCE REQUIREMENTS................................................................................................................17 1.28 SPEED..................................................................................................................................................................17 1.29 MEMORY..............................................................................................................................................................17 6.0DESIGN CONSTRAINTS....................................................................................................................................17 1.30 STANDARDS COMPLIANCE.......................................................................................................................................17 1.31 HARDWARE LIMITATIONS........................................................................................................................................17 1.32 SOFTWARE LIMITATIONS.........................................................................................................................................17 7.0OTHER REQUIREMENTS.................................................................................................................................17 1.33 SECURITY.............................................................................................................................................................17 1.34 RELIABILITY.........................................................................................................................................................17 1.35 MAINTAINABILITY..................................................................................................................................................17 1.36 PORTABILITY.........................................................................................................................................................17 1.37 EXTENSIBILITY......................................................................................................................................................17 1.38 COMPATIBILITY.....................................................................................................................................................17

Two Wheels Local Courier System Specification Document Final Version 1.0

1.39 SERVICEABILITY....................................................................................................................................................18 8.0OPERATIONAL SCENARIOS............................................................................................................................18 1.40 CASE 1: SCHEDULING A PICK UP............................................................................................................................18 1.41 CASE 2: CANCELING A PICK UP..............................................................................................................................18 1.42 CASE 3: PACKAGE TRACKING.................................................................................................................................18 1.43 CASE 4: PACKAGE DELIVERED................................................................................................................................18 9.0PRELIMINARY SCHEDULE..............................................................................................................................18 1.44 DESIGN DOCUMENT...............................................................................................................................................18 1.45 TEST PLAN...........................................................................................................................................................19 1.46 PROTOTYPE...........................................................................................................................................................19 1.47 INITIAL USER MANUAL..........................................................................................................................................19

Two Wheels Local Courier System Specification Document Final Version 1.0

1.0
1.1

Introduction
Purpose

The purpose of this document is intended to describe the design specifications for the Two Wheels Courier Company System for Susan VandeVen, instructor for SWE 4624, and other interested parties.

1.2

Scope

This document was developed by Tiffany Bonneau, Norris Walker, Vianco Hall, and Bernard Simmons as required by our instructor, Susan VandeVen, for SWE 4624. Requirements in this document were developed from our instructors system description found in the Two Wheels Local Courier System Data Sheet, Version 1.0. We are constrained to use resources available to us as students at Southern Polytechnic State University and there is no budget for this project since we are not being monetarily reimbursed for this project.

1.3

Overview

This system is designed to provide a package tracking system for the Two Wheels Courier Company. This system must be able to schedule package pickup and deliveries, cancel customer requests if needed, track each package, record customer information, and provide price quotes for package service. Managers will be able to access the report section of this system for reports on package status, billing/money received, and daily activity summary reports.

2.0
1.4

General Description
Product Functions

This system is designed to provide a package tracking system for the Two Wheels Courier Company. This system must be able to schedule package pickup and deliveries, cancel customer requests if needed, track each package, record customer information, and provide price quotes for package service. Managers will be able to access the report section of this system for reports on package status, billing/money received, and daily activity summary reports.

1.5

Related System Information

This system is required to record information in a database assessable by the employees of the Two Wheels Courier Company through the user interface for this project.

1.6

User Characteristics

1.6.1 Customers
Customers of Two Wheels Courier Company will not be directly using this system. Clerks of Two Wheels Courier Company will assess the system on the customers behalf while customers are on the phone.

1.6.2 Clerk
Clerks will be responsible for inputting data into system from both customers and delivery personnel over the phone. Must be able to track packages, input customer information, schedule package pickup and deliveries, cancel package reservations/quotes, and delivery information from delivery personnel.

1.6.3 Managers
Must be able to access reports for package status, billing/money received, and daily activity summary reports, as well as perform all functions that the clerks can.

Two Wheels Local Courier System Specification Document Final Version 1.0

1.6.4 Delivery Personnel

Will call in package information to the clerk once a package is picked up or delivered. The information that the delivery personnel will provide will be package tracking number and package status (pickup, delivery, address not found, or refused/returned). Delivery personnel must also be able to receive an accurate listing of packages assigned to them for pickup and/or delivery.

1.7

User Objectives/Goals

The main goals of our system are as follows:

1.7.1 Better record keeping of package information to eliminate loss

Packages need to be accurately tracked from time of pick up to time of delivery to avoid loss or misplacing of packages. This means that all packages need to have a tracking number and recorded in the system at all phases while in the custody of Two Wheels Courier Company.

1.7.2 Speed up time to answer customer questions

All customer questions need to be answered as quick as possible because customers are usually placed on hold while the clerk is accessing the system. The Two Wheels Local Courier Company would like to have all transactions to the system take place in less than 15 seconds.

1.7.3 Correctly perform package shipping cost calculations

Package costs must be accurately calculated. Currently these calculations are done manually and with out the use of a computer. Automation of this calculation would be a great benefit to the users and would reduce the chance of an incorrect quote for service.

1.7.4 Correctly schedule package pick ups/deliveries

The system should correctly schedule package pick up and deliveries. The schedule should be balanced based on couriers available. All packages must be delivered within two hours of pick up. Customers can request a pickup time in a 4-hour window for no more than 14 days in advance.

1.7.5 Correctly identify if request is within service range

The system should also identify if the request for service is within the allowable service range. The maximum allowed range for service is ten miles from pick up to delivery and a distance of no more than 10 miles from the company.

1.7.6 Maintain and keep good records

The need for good record keeping and access to records is very high because of liability and billing reasons. At a minimum, package information and status should be maintained, as well as good records of customer information for invoicing purposes.

1.8

General Constraints

This system must be able to run on a desktop computer in a WinTel compatible environment with at least 256mb of RAM and 6G of available hard drive space. This system must be fully prototyped by November 25, 2003.

3.0
3.1

Functional Requirements
Create customer account and ID number

1.8.1 Description
This algorithm creates a new record in the database for a new customer account creating a unique customer id (XXX-XXXX) as the primary search key.

Two Wheels Local Courier System Specification Document Final Version 1.0

1.8.2 Inputs
Customers namefirst, middle initial, last; addressstreet, city, state, and zip; telephone number (xxxxxx-xxxx); customer preferred billing method

1.8.3 Processing
If all fields are filled, verify that user account does not already exist. If it does not exist, verify data formats and create a new record in the database. Add new customer information to new record and generate a new customer id. Customer ids are created by taking the first character of customers first, middle and last name; if middle name does not exist, then substitute X character for missing initial and appending it with the last four digits of their phone number, separated by a dash. Customer ids are in the format of (XXXXXXX). If a customers initials and last four digits are the same as a customer id already in the system, the computer will increment the last digit of the customer number by one until a unique number is found. When creating a new customer ID, the system will prompt user for customers prefered billing method: charge credit card (and ask for credit card number), draft bank account (and ask for bank account number), or bill to address (and ask for preferred monthly billing date). If record already exists, retrieve previous customer record from database.

1.8.4 Outputs
New customer record created, if needed. If record already exists, then return existing customer number.

1.8.5 Criticality
High

1.8.6 Technical Issues

Creates a unique customer account for which a majority of the system functions will search for.

1.8.7 Risks
Customer numbers must be unique. If different accounts exist at the same phone number, there must be a way to identify unique customers. We decided to append the account numbers with the customers initials to determine unique accounts at the same phone number.

1.8.8 Dependencies
None.

1.9

Generate package ID#

1.9.1 Description
This function generates a package id number, which is used for tracking the status of a given package

1.9.2 Inputs
Customer namefirst, middle initial, last; customers zip code, customer id (last four digits of telephone number); current data (MMDDYY), number of packages (3 digit integer number greater than 1)

1.9.3 Processing
Take first character of customers first, middle and last name; if middle name does not exist, then substitute X character for missing initial. Append customers zip code, customer id, current date, and number of packages (insert 0 for digits not used) . All parts of the package id are separated by - a character.)

Two Wheels Local Courier System Specification Document Final Version 1.0

1.9.4 Outputs
Package id# (xxx-xxxxx-xxxx-xxxxxx-xxx)

1.9.5 Criticality
High.

1.9.6 Technical Issues

Each package must have a unique package number.

1.9.7 Risks
The risk of having multiple packages from the same location creating identical tracking is eliminated by adding the digit integer number at the end of the tracking number to identify the package picked up that day. The first package picked up from a single location on any given day will be given the package id of xxx-xxxx-xxxx-xxxxxx-001. Each subsequent package would get a package number in their tracking number one number higher. If more than 999 packages are accepted from one account in a single day, increasing alpha characters will be used to replace the digits.

1.9.8 Dependencies
3. 1 Create Customer Account and ID number: a customer number must exist before accepting packages for pickup or delivery.

1.10

Record delivery charges, payment amount, and payment type.

1.10.1 Description
This algorithm records the delivery charges to user accounts, payment typecash, check (check #), debit/check card, or credit card (Visa/MC, Amex, Disc), and payment amount to the customers account i.e., the record in the database corresponding to the customers unique id#.

1.10.2 Inputs
charges US$ (xxx.xx), payment US$ (xxx.xx), payment type [cash, check, check card, credit], credit type [visa/mc, amex, disc], check number (xxxxxx)

1.10.3 Processing:
Record charges, payment amount, and payment type into customers account. If payment type = check, then record payment type and check number into account. If payment type = credit, then record payment type and credit type into account. If payment type = cash or check card, then record payment type.

1.10.4 Outputs
None

1.10.5 Criticality
Medium

1.10.6 Technical Issues

This requirement addresses the need to keep an accurate accounting of a customers account.

1.10.7 Risks
This requirement assumes that all payments are valid.

Two Wheels Local Courier System Specification Document Final Version 1.0

1.10.8 Dependencies
3. 1 Create Customer Account and ID number: a customer number must exist before charging to a customer account.

1.11

Verify that a customer account exists

1.11.1 Description
This function performs a check against the database to confirm that a supposedly new customer does not already exist in the database to avoid multiple accounts by the same customer.

1.11.2 Inputs
Customers first and last name, customers telephone number (xxx-xxx-xxxx)

1.11.3 Processing
If no existing record in the database containing a match of the customers first and last name and telephone number, respond negative (no); otherwise, respond positive (yes.). If there are multiple matches, display all matches.

1.11.4 Outputs
Response (yes, no, or a listing of multiple matches)

1.11.5 Criticality
Medium

1.11.6 Technical Issues

This requirement helps to avoid multiple accounts by one individual at a particular phone number.

1.11.7 Risks
A risk associated with this requirement is if there are multiple personal accounts for the same individual at the same address.

1.11.8 Dependencies
None

1.12

Schedule or Quote for Courier Service

1.12.1 Description
This function collects and stores all information relevant to a customers request for courier service in the system database. Information is collected from the customer over the telephone and logged by the clerk.

1.12.2 Input
The inputs to this function are customer ID, pickup contact, pickup address, pickup phone number, pickup/delivery date, pickup time window, delivery address, recipient name, and recipient phone number. Clerk must enter if this is a quote only.

1.12.3 Processing
This function records reservation data, and checks that delivery address is within 10 miles of pickup address and within 25 miles of company location.

Two Wheels Local Courier System Specification Document Final Version 1.0

1.12.4 Output
Validated data is stored in the system database. Returns errors if request is outside of delivery area. Ask clerk if customer wants to schedule for pickup or reserve quote in system for 14 days.

1.12.5 Criticality
High

1.12.6 Technical Issues

The interface must allow operators to enter reservation data quickly to ensure high productivity and customer satisfaction. All system transactions must take less than 15 seconds to complete. Requests for service cannot be more than 14 days in advance.

1.12.7 Risks
If customer reservations are not handled promptly, this could lead to customer dissatisfaction with the companys service.

1.12.8 Dependencies
3.6 Check if Delivery is a Valid Request

1.13

Check if Delivery is a Valid Request

1.13.1 Description
This function will check to see if request for delivery service is valid.

1.13.2 Inputs
Pickup Address, Destination Address

1.13.3 Processing
This function checks that delivery address is within 10 miles of pickup address and within 25 miles of company location.

1.13.4 Outputs
Returns true if delivery request is valid. Error: Delivery Request is outside of delivery range.

1.13.5 Criticality
High

1.13.6 Technical Issues

Do not allow packages to be scheduled that are outside the delivery area without manager approval.

1.13.7 Risks
If delivery range is not verified in the system, requests for service may be taken that cannot be serviced.

1.13.8 Dependencies
3.5 Schedule Courier Service

Two Wheels Local Courier System Specification Document Final Version 1.0

1.14

Pick-up confirmation

1.14.1 Description
This algorithm logs pertinent information concerning the pick-up of a given package into a .log file for tracking purposes and customer confirmation.

1.14.2 Inputs
Package id# (xxx-xxxxx-xxxx-xxxxxx-xxx); customer namefirst, last; source addressstreet, city, state, zip; pick-up date; pick-up time; courier id

1.14.3 Processing:
Record (write) inputted data into system .log file for later viewing, editing, and package tracking.

1.14.4 Outputs
None

1.14.5 Criticality
Medium

1.14.6 Technical Issues

The clerk must enter pick up confirmation data into the system.

1.14.7 Risks
Entering data into the system twice could cause erroneous data. Clerk should be verifying pick up address and name against system information already collected, rather than reentering data.

1.14.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.15

Delivery confirmation

1.15.1 Description
This algorithm logs pertinent information about the delivery of a given package to its destination into a .log file for tracking purposes and customer confirmation.

1.15.2 Inputs
Package id# (xxx-xxxxx-xxxx-xxxxxx); recipients addressstreet, city, state, zip; delivery date; delivery time, courier name

1.15.3 Processing
Record (write) inputted data into system .log file for later viewing, editing, and package tracking.

1.15.4 Outputs
None.

1.15.5 Criticality
High.

10

Two Wheels Local Courier System Specification Document Final Version 1.0

1.15.6 Technical Issues

All packages must be tracked and their status recorded in the system. All packages should have one of the following status associated with their id: Scheduled for pick-up (and provide time), picked up by (courier id), in transit, delivery by (courier id) to (recipient name), or returned to sender (provide reason for return).

1.15.7 Risks
Packages will lost or misplaced if not accurately tracked.

1.15.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.16

Print outstanding deliveries report

1.16.1 Description
This algorithm prints a basic end-of-day report indicating any outstanding or pending for the next day deliveriesi.e., any packages that have not been delivered.

1.16.2 Inputs
None.

1.16.3 Processing
Print report header. Print outstanding package header. Traverse both the database and the .log file and search for any packages sent out for the current date. Compare these data values with the package ids of the .log file. If no package id# match is found, print package information for the given package id#; otherwise, go to the next package id# and repeat comparison until end. Print next day deliveries header. Search database for scheduled deliveries for the next day and print results. Print report footer.

1.16.4 Outputs
Package id# (xxx-xxxxx-xxxx-xxxxxx-xxx); recipients namefirst, last; destination addressstreet, city, state, zip in list format as described above

1.16.5 Criticality
Low.

1.16.6 Technical Issues

Managers need reports of daily and outstanding activity of system.

1.16.7 Risks
If printed too early in the day, packages listed, as outstanding may not actually reflect result if courier does not call the clerk right after the delivery is made.

1.16.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.17

Perform 15-day cancellation verification

1.17.1 Description
This algorithm performs a daily check in order to cancel customer pick-up/deliveries 14 days after their reservation dates have passed.

11

Two Wheels Local Courier System Specification Document Final Version 1.0

1.17.2 Inputs
None

1.17.3 Processing
Traverse the system reservation file searching for reserve dates. If date difference of current date and reserve date is greater than 14, do not add current reservation to updated system file; otherwise, re-write reserve information into new reserve file. Close files and erase old file from system directory.

1.17.4 Outputs
None

1.17.5 Criticality
Medium

1.17.6 Technical Issues

Managers need to know of upcoming activity to schedule the correct number of couriers.

1.17.7 Risks
Reservations not cancelled after 14 days will potentially bog down the system.

1.17.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.18

Track Package Status

1.18.1 Description
This function tracks packages from pickup through delivery. Operators should be able to retrieve package status information within 15 seconds of entering package ID.

1.18.2 Inputs
Package ID.

1.18.3 Processing
The function uses package ID to retrieve the pickup and delivery times for the package. The function should allow additional details (pickup address, delivery address and courier id) to be retrieved if necessary to resolve customer queries.

1.18.4 Outputs
Standard outputs from the function are pickup and delivery times. Additional outputs are pickup address, delivery address and driver name. These outputs should be formatted to allow operators to discern information quickly.

1.18.5 Criticality
Medium

1.18.6 Technical Issues

This requirement implies that attention should be paid to user interface design and database response time.

12

Two Wheels Local Courier System Specification Document Final Version 1.0

1.18.7 Risks
If time requirement is not met, this could lead to customer dissatisfaction.

1.18.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.19

Calculate Delivery Charge

1.19.1 Description
This function calculates the delivery charge based on package weight, package size, and distance between pickup and delivery.

1.19.2 Inputs
Inputs to the function are package weight (lbs), package length (inches), package depth (inches), package height (inches), and distance (miles).

1.19.3 Processing
The function calculates delivery charge using the formula: Charge = (distance * length * height * depth * weight) / 100.0

1.19.4 Output
Delivery charge outputted from this function is used to update customer account.

1.19.5 Criticality
High

1.19.6 Technical Issues

Delivery charges must be accurately computed so the customer is not over or under charge for service.

1.19.7 Risks
There are risks of lost revenue and/or customer dissatisfaction if charges are not accurately and completely captured.

1.19.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.20

Cancellations of Deliveries or Quote for Service

1.20.1 Description
Clerks must be able to cancel deliveries or quotes for delivery service, if the customer request this action to be performed.

1.20.2 Inputs
Package ID

13

Two Wheels Local Courier System Specification Document Final Version 1.0

1.20.3 Processing
This function takes in the package ID and sets its status to canceled. If the package has been picked up, courier id needs to be displayed so clerk can contact courier before package is delivered to its destination. If package has been delivered, clerk will not be able to cancel package.

1.20.4 Outputs
Verification that the correct action has been taken to given package id.

1.20.5 Criticality
Medium

1.20.6 Technical Issues

Clerks must be able to cancel packages in the system as needed before package is delivered.

1.20.7 Risks
Customer requests cancellations after packages have been picked up or delivered.

1.20.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.

1.21

Customer Information Update

1.21.1 Description
Clerks must be able to update customer information as needed.

1.21.2 Inputs
Information needing to be updated: Customers namefirst, middle initial, last; addressstreet, city, state, and zip; telephone number (xxx-xxx-xxxx); or customer preferred billing method

1.21.3 Processing
Update customer account with new information provided.

1.21.4 Outputs
Verification that the correct information is now in the system.

1.21.5 Criticality
Medium

1.21.6 Technical Issues

The number of multiple accounts should be limited to a particular individual or company. User Ids remain the same, even after updates to account.

1.21.7 Risks
If customer information is not current, then customers may not be correctly billed or contacted.

1.21.8 Dependencies
3.1 Create customer account and id number: customer id must already exist

14

Two Wheels Local Courier System Specification Document Final Version 1.0

1.22

Creating User Accounts

1.22.1 Description
Administrators must be able to create user accounts for the system and set the appropriate level of access for each user. User Ids can be any combination of 6 to 12 alphanumeric characters. Passwords must be between 8 and 12 alphanumeric characters with at least one digit. Levels of access are Guest, Clerk, Manager, Administrator, or Delivery Personnel.

1.22.2 Inputs
Requested User ID, Requested Password, Level of Access for User

1.22.3 Processing
This function checks to see if requested user id does not exist. If it does not, this function will add requested user id to list of users, and associate given password and user level access with given user id. If user id already exists, a message will be returned that user id already exists.

1.22.4 Outputs
Message: User ID Created if user id is unique to list of users for system, User ID already exists: please choose an other if user id already exists in the system.

1.22.5 Criticality
Medium

1.22.6 Technical Issues

User Ids must be unique.

1.22.7 Risks
User Ids that are not unique may give more access to those who should not have access or inaccurately log user transactions in the system.

1.22.8 Dependencies
None.

1.23

Password Protected Login

1.23.1 Description
The system should be password protected. Access to system should be based on user level.

1.23.2 Inputs
User Id, Password

1.23.3 Processing
This function should verify that the correct password for user id provided has been given.

1.23.4 Outputs
Show approriate welcome screen for user level if password is valid. An error message should be provided if password is invalid

15

Two Wheels Local Courier System Specification Document Final Version 1.0

1.23.5 Criticality
High

1.23.6 Technical Issues

Security must be provided in this system.

1.23.7 Risks
If the system is unsecured, unauthorized changes could be made by those who should not have access to the system or particular parts of the system.

1.23.8 Dependencies
3.15 Creating User Accounts: a user id and password must exist.

4.0
1.24

Interface Requirements
User Interfaces

User interfaces with system must be easy to understand and require little to no training on use. All graphical buttons must have text associated with each button either beside the button or as a roll over pop up once the mouse rolls over the graphical button.

1.24.1 Graphical User Interfaces (GUI)

The GUI user interface should allow the operator to log data quickly. The interface should be menu driven, minimizing operator key strokes. Real-time reports generated by the system should contain only relevant information that can be quickly assimilated by the operator. The list of screens required for system are as follows: Password Protected Log-In Screen User Level Appropriate Welcome Screen with Functions Available to User Track Package Screen Administrative Features Screen Delivery Confirmation Call-In Screen Pick-Up Confirmation Call-In Screen Package Scheduling/Quote Screen Package Cancellation Screen Reports Screen

1.24.2 Command Line Interfaces (CLI)

None.

1.24.3 Debugging/Diagnostic Interface

Pop up windows will be displayed once an error is detected. Error handling will try to shut down program gracefully if error is detected.

1.25

Hardware Interfaces

This system will be run on a desktop computer with a keyboard and mouse for data entry. Interfacing with any other hardware is beyond the scope of this project.

1.26

Network Interfaces

This system is not designed to be networked.

16

Two Wheels Local Courier System Specification Document Final Version 1.0

1.27

Software Interfaces

This system does not need to interface with any additional software outside of the system.

5.0
1.28 1.29

Performance Requirements
Speed Memory

Transactions must not take longer than 15 seconds to complete.

This system must be able to run on a minimum of 256mb RAM.

6.0
1.30 1.31 1.32

Design Constraints
Standards Compliance Hardware Limitations Software Limitations

There are no requirements for compliance to any particular design standards.

This system must be able to be run on a WinTel desktop computer with at least 256mb RAM and 6G available

This system must run on a Windows platform. Linux compatibility is optional.

7.0
1.33

Other Requirements
Security

This system must be password protected and users need to log in using a unique id and password. There are four levels of users from lowest to highest authority in the system are guest, clerk, manager, and administrator. Guests should be able to type in tracking numbers and view status of particular package. Clerks need to be able to enter data into the system. Managers need to do all functions of a clerk, as well as compile reports. Administrators need to have full access to all features of the system and must be able to create user ids and initial passwords. All users need the ability to change their passwords. If users forget passwords, administrators need to change the passwords for users.

1.34

Reliability

This system needs to be reliable. If an error is detected, a pop up with type of error needs to be displayed before shutting down system if needed.

1.35 1.36 1.37 1.38

Maintainability Portability Extensibility Compatibility

System must be able to handle potential future upgrades like networking and additional input devices.

This system is currently stand-alone and does not currently need to be ported to a portable device.

The system must be able to be upgraded as needed.

This system must be able to be compatible with a WinTel platform. Linux/Unix compatibility is optional.

17

Two Wheels Local Courier System Specification Document Final Version 1.0

1.39

Serviceability

This system must be serviceable by employees from the Two Wheels Courier Company with administrator access to the system.

8.0

Operational Scenarios

The scenarios given in this section are given as example use cases. This section is a start of potential uses and is not by any way an exhaustive list of all the potential use cases of this system.

1.40

Case 1: Scheduling a Pick Up

Customer Susie Q Simpson calls the clerk to schedule a pick up of a package 5 miles from the company to be delivered 8 miles away from the pick up location. The clerk asks for the Susie Q Simpsons user Id which is SQS7817 (her initials and last four digits of her initial phone number on the account). If Susie Q Simpson did not have a customer id, the clerk would have had to create a new customer id before scheduling the pick up. After The clerk than pulls up the package pick-up screen to schedule a pick up for Susie Q Simpson. The clerk needs to get the pick up address, delivery address, time requested for pickup, package height, weight, length, and depth. Inside the system, the program should schedule the appropriate delivery personnel to pick up the package and deliver to its destination within two hours of pick up.

1.41

Case 2: Canceling a Pick Up

Customer Susie Q Simpson has decided to cancel a pick up that she had already requested. She calls the clerk who pulls up a tracking screen. The clerk then asks for the package id and then enters it on the tracking screen. If the package is found and is not yet picked up or assigned to a delivery person, the clerk can hit a cancel button on the result screen to cancel the pick up. If the package found, has not yet been picked up but has been assigned to a delivery person, the clerk will need to contact the delivery person (currently via radio or phone) to verify that package has not yet been picked up before canceling the package in the system. If the package is in transit, the clerk needs to contact the delivery person (currently via radio or phone) to return the package to pick up location. The package needs to marked as returned in the computer.

1.42

Case 3: Package Tracking

Customer Joe A Davis needs the status of a package. He calls the clerk who pulls up a tracking screen. The clerk then asks for the package id and then enters it on the tracking screen. The tracking screen should have a field for entering the tracking number, an enter button, and a clear button. Once the tracking number has been entered the clerk will hit the enter button. Once a request has been submitted and a package found, a new screen should be displayed with the package id and the package status. A package status could be: scheduled for pick up (and time for scheduled pick up recorded), in transit (with estimated delivery time), delivered (with time delivered), and returned (with reason for return). If package id is not found in the system, the system needs to display a package not found in the result screen.

1.43

Case 4: Package Delivered

The delivery person is about to deliver a package to the correct location. The delivery person calls or contacts the clerk via phone giving the clerk the package id number and time of delivery. The clerk then enters this information in a package delivered screen.

9.0
1.44

Preliminary Schedule
Design Document

1.44.1 Dependencies
Specification Document

18

Two Wheels Local Courier System Specification Document Final Version 1.0

1.44.2 Draft 1 Due: October 7, 2003 1.44.3 Group Draft Review: October 8, 2003 1.44.4 Draft 2 Due: October 14, 2003 1.44.5 Final Draft Review: October 15, 2003 1.44.6 Due Date: October 23, 2003 1.45 Test Plan

1.45.1 Dependencies
Specification Document

1.45.2 Draft 1 Due: October 21, 2003 1.45.3 Group Draft Review: October 22, 2003 1.45.4 Draft 2 Due: October 28, 2003 1.45.5 Final Draft Review: : October 29, 2003 1.45.6 Due Date: November 6, 2003 1.46 Prototype

1.46.1 Dependencies
Specification Document Design Document

1.46.2 Prototype 1 Due: November 11, 2003 1.46.3 Group Review: November 12, 2003 1.46.4 Prototype 2 Due: November 18, 2003 1.46.5 Group Review: November 19, 2003 1.46.6 Due Date: November 25, 2003 1.47 Initial User Manual

1.47.1 Dependencies
Specification Document

19

Two Wheels Local Courier System Specification Document Final Version 1.0

Design Document Prototype

1.47.2 Draft 1 Due: November 11, 2003 1.47.3 Group Draft Review: November 12, 2003 1.47.4 Draft 2 Due: November 18, 2003 1.47.5 Final Draft Review: November 19, 2003 1.47.6 Due Date: November 25, 2003

20