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: _______________________________
1
Two Wheels Local Courier System
Specification Document
Final Version 1.0
Table of Contents
1.0
1.1
1.2
1.3
2.0
2.1
2.2
2.3
2.4
2.5
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
4.0
4.1
4.2
4.3
4.4
5.0
5.1
5.2
6.0
6.1
6.2
6.3
7.0
7.1
7.2
7.3
7.4
7.5
7.6
7.7
INTRODUCTION ...........................................................................................................................................4
PURPOSE .........................................................................................................................................................4
SCOPE .............................................................................................................................................................4
OVERVIEW......................................................................................................................................................4
GENERAL DESCRIPTION ...........................................................................................................................4
PRODUCT FUNCTIONS .....................................................................................................................................4
RELATED SYSTEM INFORMATION ...................................................................................................................4
USER CHARACTERISTICS ................................................................................................................................4
USER OBJECTIVES/GOALS ..............................................................................................................................5
GENERAL CONSTRAINTS.................................................................................................................................5
FUNCTIONAL REQUIREMENTS ...............................................................................................................5
CREATE CUSTOMER ACCOUNT AND ID NUMBER .............................................................................................5
GENERATE PACKAGE ID# ...............................................................................................................................6
RECORD DELIVERY CHARGES, PAYMENT AMOUNT, AND PAYMENT TYPE. .......................................................7
VERIFY THAT A CUSTOMER ACCOUNT EXISTS .................................................................................................8
SCHEDULE OR QUOTE FOR COURIER SERVICE ................................................................................................8
CHECK IF DELIVERY IS A VALID REQUEST .....................................................................................................9
PICK-UP CONFIRMATION ............................................................................................................................... 10
DELIVERY CONFIRMATION............................................................................................................................ 10
PRINT OUTSTANDING DELIVERIES REPORT .................................................................................................... 11
PERFORM 15-DAY CANCELLATION VERIFICATION......................................................................................... 11
TRACK PACKAGE STATUS ............................................................................................................................ 12
CALCULATE DELIVERY CHARGE .................................................................................................................. 13
CANCELLATIONS OF DELIVERIES OR QUOTE FOR SERVICE ........................................................................... 13
CUSTOMER INFORMATION UPDATE .............................................................................................................. 14
CREATING USER ACCOUNTS......................................................................................................................... 15
PASSWORD PROTECTED LOGIN ..................................................................................................................... 15
INTERFACE REQUIREMENTS ................................................................................................................ 16
USER INTERFACES ........................................................................................................................................ 16
HARDWARE INTERFACES .............................................................................................................................. 16
NETWORK INTERFACES ................................................................................................................................ 16
SOFTWARE INTERFACES ............................................................................................................................... 17
PERFORMANCE REQUIREMENTS ........................................................................................................ 17
SPEED ........................................................................................................................................................... 17
MEMORY ...................................................................................................................................................... 17
DESIGN CONSTRAINTS ............................................................................................................................ 17
STANDARDS COMPLIANCE ............................................................................................................................ 17
HARDWARE LIMITATIONS ............................................................................................................................ 17
SOFTWARE LIMITATIONS .............................................................................................................................. 17
OTHER REQUIREMENTS ......................................................................................................................... 17
SECURITY ..................................................................................................................................................... 17
RELIABILITY ................................................................................................................................................. 17
MAINTAINABILITY ........................................................................................................................................ 17
PORTABILITY ................................................................................................................................................ 17
EXTENSIBILITY ............................................................................................................................................. 17
COMPATIBILITY ............................................................................................................................................ 17
SERVICEABILITY ........................................................................................................................................... 18
Two Wheels Local Courier System
Specification Document
Final Version 1.0
8.0
8.1
8.2
8.3
8.4
9.0
9.1
9.2
9.3
9.4
OPERATIONAL SCENARIOS ................................................................................................................... 18
CASE 1: SCHEDULING A PICK UP .................................................................................................................. 18
CASE 2: CANCELING A PICK UP .................................................................................................................... 18
CASE 3: PACKAGE TRACKING ....................................................................................................................... 18
CASE 4: PACKAGE DELIVERED ..................................................................................................................... 18
PRELIMINARY SCHEDULE ..................................................................................................................... 18
DESIGN DOCUMENT...................................................................................................................................... 18
TEST PLAN.................................................................................................................................................... 19
PROTOTYPE .................................................................................................................................................. 19
INITIAL USER MANUAL ................................................................................................................................ 19
Two Wheels Local Courier System
Specification Document
Final Version 1.0
1.0
Introduction
1.1
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 instructor’s 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
General Description
2.1
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.
2.2
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.
2.3
User Characteristics
2.3.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 customer’s behalf while customers are on the phone.
2.3.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.
2.3.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.
4
Two Wheels Local Courier System
Specification Document
Final Version 1.0
2.3.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.
2.4
User Objectives/Goals
The main goals of our system are as follows:
2.4.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.
2.4.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.
2.4.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.
2.4.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.
2.4.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.
2.4.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.
2.5
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
Functional Requirements
3.1
Create customer account and ID number
3.1.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.
5
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.1.2 Inputs
Customer’s name—first, middle initial, last; address—street, city, state, and zip; telephone number (xxxxxx-xxxx); customer preferred billing method
3.1.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 customer’s 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 id’s are in the format of (XXXXXXX). If a customer’s 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 customer’s 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.
3.1.4 Outputs
New customer record created, if needed. If record already exists, then return existing customer number.
3.1.5 Criticality
High
3.1.6 Technical Issues
Creates a unique customer account for which a majority of the system functions will search for.
3.1.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 customer’s initials
to determine unique accounts at the same phone number.
3.1.8 Dependencies
None.
3.2
Generate package ID#
3.2.1 Description
This function generates a package id number, which is used for tracking the status of a given package
3.2.2 Inputs
Customer name—first, middle initial, last; customer’s zip code, customer id (last four digits of telephone
number); current data (MMDDYY), number of packages (3 digit integer number greater than 1)
3.2.3 Processing
Take first character of customer’s first, middle and last name; if middle name does not exist, then substitute
‘X’ character for missing initial. Append customer’s 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.)
6
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.2.4 Outputs
Package id# (xxx-xxxxx-xxxx-xxxxxx-xxx)
3.2.5 Criticality
High.
3.2.6 Technical Issues
Each package must have a unique package number.
3.2.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.
3.2.8 Dependencies
3. 1 Create Customer Account and ID number: a customer number must exist before accepting packages for
pickup or delivery.
3.3
Record delivery charges, payment amount, and payment type.
3.3.1 Description
This algorithm records the delivery charges to user accounts, payment type—cash, check (check #),
debit/check card, or credit card (Visa/MC, Amex, Disc), and payment amount to the customer’s account—
i.e., the record in the database corresponding to the customer’s unique id#.
3.3.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)
3.3.3 Processing:
Record charges, payment amount, and payment type into customer’s 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.
3.3.4 Outputs
None
3.3.5 Criticality
Medium
3.3.6 Technical Issues
This requirement addresses the need to keep an accurate accounting of a customer’s account.
3.3.7 Risks
This requirement assumes that all payments are valid.
7
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.3.8 Dependencies
3. 1 Create Customer Account and ID number: a customer number must exist before charging to a customer
account.
3.4
Verify that a customer account exists
3.4.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.
3.4.2 Inputs
Customer’s first and last name, customer’s telephone number (xxx-xxx-xxxx)
3.4.3 Processing
If no existing record in the database containing a match of the customer’s first and last name and telephone
number, respond negative (no); otherwise, respond positive (yes.). If there are multiple matches, display all
matches.
3.4.4 Outputs
Response (“yes”, “no”, or a listing of multiple matches)
3.4.5 Criticality
Medium
3.4.6 Technical Issues
This requirement helps to avoid multiple accounts by one individual at a particular phone number.
3.4.7 Risks
A risk associated with this requirement is if there are multiple personal accounts for the same individual at
the same address.
3.4.8 Dependencies
None
3.5
Schedule or Quote for Courier Service
3.5.1 Description
This function collects and stores all information relevant to a customer’s request for courier service in the
system database. Information is collected from the customer over the telephone and logged by the clerk.
3.5.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.
3.5.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.
8
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.5.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.
3.5.5 Criticality
High
3.5.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.
3.5.7 Risks
If customer reservations are not handled promptly, this could lead to customer dissatisfaction with the
company’s service.
3.5.8 Dependencies
3.6 Check if Delivery is a Valid Request
3.6
Check if Delivery is a Valid Request
3.6.1 Description
This function will check to see if request for delivery service is valid.
3.6.2 Inputs
Pickup Address, Destination Address
3.6.3 Processing
This function checks that delivery address is within 10 miles of pickup address and within 25 miles of
company location.
3.6.4 Outputs
Returns true if delivery request is valid. Error: “Delivery Request is outside of delivery range.”
3.6.5 Criticality
High
3.6.6 Technical Issues
Do not allow packages to be scheduled that are outside the delivery area without manager approval.
3.6.7 Risks
If delivery range is not verified in the system, requests for service may be taken that cannot be serviced.
3.6.8 Dependencies
3.5 Schedule Courier Service
9
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.7
Pick-up confirmation
3.7.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.
3.7.2 Inputs
Package id# (xxx-xxxxx-xxxx-xxxxxx-xxx); customer name—first, last; source address—street, city, state,
zip; pick-up date; pick-up time; courier id
3.7.3 Processing:
Record (write) inputted data into system .log file for later viewing, editing, and package tracking.
3.7.4 Outputs
None
3.7.5 Criticality
Medium
3.7.6 Technical Issues
The clerk must enter pick up confirmation data into the system.
3.7.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.
3.7.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.8
Delivery confirmation
3.8.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.
3.8.2 Inputs
Package id# (xxx-xxxxx-xxxx-xxxxxx); recipient’s address—street, city, state, zip; delivery date; delivery
time, courier name
3.8.3 Processing
Record (write) inputted data into system .log file for later viewing, editing, and package tracking.
3.8.4 Outputs
None.
3.8.5 Criticality
High.
10
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.8.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).”
3.8.7 Risks
Packages will lost or misplaced if not accurately tracked.
3.8.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.9
Print outstanding deliveries report
3.9.1 Description
This algorithm prints a basic end-of-day report indicating any outstanding or pending for the next day
deliveries—i.e., any packages that have not been delivered.
3.9.2 Inputs
None.
3.9.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.
3.9.4 Outputs
Package id# (xxx-xxxxx-xxxx-xxxxxx-xxx); recipient’s name—first, last; destination address—street, city,
state, zip in list format as described above
3.9.5 Criticality
Low.
3.9.6 Technical Issues
Managers need reports of daily and outstanding activity of system.
3.9.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.
3.9.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.10
Perform 15-day cancellation verification
3.10.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
3.10.2 Inputs
None
3.10.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.
3.10.4 Outputs
None
3.10.5 Criticality
Medium
3.10.6 Technical Issues
Managers need to know of upcoming activity to schedule the correct number of couriers.
3.10.7 Risks
Reservations not cancelled after 14 days will potentially bog down the system.
3.10.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.11
Track Package Status
3.11.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.
3.11.2 Inputs
Package ID.
3.11.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.
3.11.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.
3.11.5 Criticality
Medium
3.11.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
3.11.7 Risks
If time requirement is not met, this could lead to customer dissatisfaction.
3.11.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.12
Calculate Delivery Charge
3.12.1 Description
This function calculates the delivery charge based on package weight, package size, and distance between
pickup and delivery.
3.12.2 Inputs
Inputs to the function are package weight (lbs), package length (inches), package depth (inches), package
height (inches), and distance (miles).
3.12.3 Processing
The function calculates delivery charge using the formula:
Charge = (distance * length * height * depth * weight) / 100.0
3.12.4 Output
Delivery charge outputted from this function is used to update customer account.
3.12.5 Criticality
High
3.12.6 Technical Issues
Delivery charges must be accurately computed so the customer is not over or under charge for service.
3.12.7 Risks
There are risks of lost revenue and/or customer dissatisfaction if charges are not accurately and completely
captured.
3.12.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.13
Cancellations of Deliveries or Quote for Service
3.13.1 Description
Clerks must be able to cancel deliveries or quotes for delivery service, if the customer request this action to
be performed.
3.13.2 Inputs
Package ID
13
Two Wheels Local Courier System
Specification Document
Final Version 1.0
3.13.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.
3.13.4 Outputs
Verification that the correct action has been taken to given package id.
3.13.5 Criticality
Medium
3.13.6 Technical Issues
Clerks must be able to cancel packages in the system as needed before package is delivered.
3.13.7 Risks
Customer requests cancellations after packages have been picked up or delivered.
3.13.8 Dependencies
3.5 Schedule Courier Service: a package id must exist.
3.14
Customer Information Update
3.14.1 Description
Clerks must be able to update customer information as needed.
3.14.2 Inputs
Information needing to be updated: Customer’s name—first, middle initial, last; address—street, city, state,
and zip; telephone number (xxx-xxx-xxxx); or customer preferred billing method
3.14.3 Processing
Update customer account with new information provided.
3.14.4 Outputs
Verification that the correct information is now in the system.
3.14.5 Criticality
Medium
3.14.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.
3.14.7 Risks
If customer information is not current, then customers may not be correctly billed or contacted.
3.14.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
3.15
Creating User Accounts
3.15.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.
3.15.2 Inputs
Requested User ID, Requested Password, Level of Access for User
3.15.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.
3.15.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.
3.15.5 Criticality
Medium
3.15.6 Technical Issues
User Ids must be unique.
3.15.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.
3.15.8 Dependencies
None.
3.16
Password Protected Login
3.16.1 Description
The system should be password protected. Access to system should be based on user level.
3.16.2 Inputs
User Id, Password
3.16.3 Processing
This function should verify that the correct password for user id provided has been given.
3.16.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
3.16.5 Criticality
High
3.16.6 Technical Issues
Security must be provided in this system.
3.16.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.
3.16.8 Dependencies
3.15 Creating User Accounts: a user id and password must exist.
4.0
Interface Requirements
4.1
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.
4.1.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
4.1.2 Command Line Interfaces (CLI)
None.
4.1.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.
4.2
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.
4.3
Network Interfaces
This system is not designed to be networked.
16
Two Wheels Local Courier System
Specification Document
Final Version 1.0
4.4
Software Interfaces
This system does not need to interface with any additional software outside of the system.
5.0
Performance Requirements
5.1
Speed
Transactions must not take longer than 15 seconds to complete.
5.2
Memory
This system must be able to run on a minimum of 256mb RAM.
6.0
Design Constraints
6.1
Standards Compliance
There are no requirements for compliance to any particular design standards.
6.2
Hardware Limitations
This system must be able to be run on a WinTel desktop computer with at least 256mb RAM and 6G available
6.3
Software Limitations
This system must run on a Windows platform. Linux compatibility is optional.
7.0
Other Requirements
7.1
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.
7.2
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.
7.3
Maintainability
System must be able to handle potential future upgrades like networking and additional input devices.
7.4
Portability
This system is currently stand-alone and does not currently need to be ported to a portable device.
7.5
Extensibility
The system must be able to be upgraded as needed.
7.6
Compatibility
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
7.7
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.
8.1
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 Simpson’s 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.
8.2
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.
8.3
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.
8.4
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
Preliminary Schedule
9.1
Design Document
9.1.1 Dependencies
Specification Document
18
Two Wheels Local Courier System
Specification Document
Final Version 1.0
9.1.2 Draft 1 Due: October 7, 2003
9.1.3 Group Draft Review: October 8, 2003
9.1.4 Draft 2 Due: October 14, 2003
9.1.5 Final Draft Review: October 15, 2003
9.1.6 Due Date: October 23, 2003
9.2
Test Plan
9.2.1 Dependencies
Specification Document
9.2.2 Draft 1 Due: October 21, 2003
9.2.3 Group Draft Review: October 22, 2003
9.2.4 Draft 2 Due: October 28, 2003
9.2.5 Final Draft Review: : October 29, 2003
9.2.6 Due Date: November 6, 2003
9.3
Prototype
9.3.1 Dependencies
Specification Document
Design Document
9.3.2 Prototype 1 Due: November 11, 2003
9.3.3 Group Review: November 12, 2003
9.3.4 Prototype 2 Due: November 18, 2003
9.3.5 Group Review: November 19, 2003
9.3.6 Due Date: November 25, 2003
9.4
Initial User Manual
9.4.1 Dependencies
Specification Document
19
Two Wheels Local Courier System
Specification Document
Final Version 1.0
Design Document
Prototype
9.4.2 Draft 1 Due: November 11, 2003
9.4.3 Group Draft Review: November 12, 2003
9.4.4 Draft 2 Due: November 18, 2003
9.4.5 Final Draft Review: November 19, 2003
9.4.6 Due Date: November 25, 2003
20