SOFTWARE REQUIREMENTS SPECIFICATION
For On the Spot Courier Services
ISM3113 Team 5
Nathan Freeman
Paul Hudson
Carl Meiring
Page |1
Revision History
Date
9/25/14
10/6/14
10/6/14
10/6/14
10/7/14
Description
Began working on document, focusing
on Section 1.
Expanded upon security section.
Wrote Database and Operations
sections, and revised original SSD.
Added section three
Added other sections to two and three
and formatted document
Author
Nathan Freeman
Grammar and proof check
Carl Meiring
Nathan Freeman
Comment
First revision.
Nathan Freeman
Carl Meiring
Paul Hudson
Document Approval
Signature
Printed Name
Title
Date
Nathan Freeman
Paul Hudson, III
Carl Meiring
Nathan Freeman
CEO
10/7/14
Paul Hudson, III
Technical Writer
10/7/14
Carl Meiring
System designer
10/7/14
Page |2
Contents
Revision History ............................................................................................................................................. 1
Document Approval ...................................................................................................................................... 1
1. Introduction .............................................................................................................................................. 4
1.1 Purpose ............................................................................................................................................... 4
1.2 Scope ................................................................................................................................................... 4
1.3 Definitions, Acronyms, and Abbreviations.......................................................................................... 4
1.4 References .......................................................................................................................................... 4
1.5 Overview ............................................................................................................................................. 5
2. General Description .................................................................................................................................. 6
2.1 Product Perspective ............................................................................................................................ 6
2.2 Product Functions ............................................................................................................................... 6
2.3 User Characteristics ............................................................................................................................ 6
General Constraints .............................................................................................................................. 7
Assumptions and dependencies ........................................................................................................... 7
3. Specific Requirements............................................................................................................................... 8
Pickup / delivery process. ..................................................................................................................... 8
Pricing.................................................................................................................................................... 8
3.1 External Interface Requirements ........................................................................................................ 8
3.2 User Interfaces .................................................................................................................................... 8
3.1.2 Hardware Interfaces ........................................................................................................................ 9
3.1.3 Software Interfaces .......................................................................................................................... 9
3.1.4 Communications Interfaces ............................................................................................................. 9
3.2 Functional Requirements .................................................................................................................. 10
3.2.1 Create Account and Log On use case ......................................................................................... 10
3.2.2 Create a Pickup/Delivery Request use case ............................................................................... 11
3.2.3 Create Truck Route use case ...................................................................................................... 12
3.2.4 View Pickup/Delivery Schedule use case ................................................................................... 13
3.2.5 Log Pickup use case .................................................................................................................... 14
3.2.6 Log Delivery use case ................................................................................................................. 15
3.2.7 View All Inventory use case ....................................................................................................... 16
3.2.8 View Delivery Status use case .................................................................................................... 17
3.2.9 Generate Bills use case .............................................................................................................. 18
Page |3
3.2.10 View Balance / Make Payment ................................................................................................ 19
3.2.11 Maintain Cost Table use case................................................................................................... 20
3.2.12 View and Give Service Feedback use case ............................................................................... 21
3.2.13 Record Check Payment use case.............................................................................................. 22
3.2.14 View Monthly Bills use case ..................................................................................................... 23
3.2.15 Print Label use case .................................................................................................................. 24
3.3 Non-Functional Requirements .......................................................................................................... 25
3.3.1 Performance .................................................................................................................................. 25
3.3.2 Reliability........................................................................................................................................ 25
3.3.4 Security .......................................................................................................................................... 25
3.5.1 Database ........................................................................................................................................ 25
3.5.2 Operations ..................................................................................................................................... 26
3.4 Design Constraints ............................................................................................................................ 26
3.5 Other Requirements ......................................................................................................................... 26
3.5.3 Site Adaptation .............................................................................................................................. 26
4. Analysis Models ...................................................................................................................................... 27
4.1 Use Case Diagram ............................................................................................................................. 27
4.2 Sequence Diagrams........................................................................................................................... 28
4.3 State-Machine Diagram .................................................................................................................... 29
4.4 Domain Class Diagram ...................................................................................................................... 30
4.5 Activity Diagram ................................................................................................................................ 32
5. Change Management Process................................................................................................................. 33
Page |4
1. Introduction
1.1 Purpose
This Software Requirements Specification document outlines the features of the proposed new
system for On the Spot Courier Services.
The intended audience for this document includes Bill Wiley, the founder of On the Spot, as
well as the development team of Logistics Data Solutions that will design and implement the
proposed information system solution.
1.2 Scope
The name of the proposed system is OSCS Manager. This new system will help On the Spot
Courier Service’s growing business deliver faster, more efficient service to its customers.
Currently, On the Spot has no computer support for its operations. All records are paper-based.
The new system is intended to deliver automation levels and sophistication that suit the size
and budget of the current business. This way, On the Spot can compete with larger, more
established logistics services on cost, while at the same time, it can continue to provide a
superior level of service that has fueled its growth.
OSCS Manager needs to support overnight, same-day and 3-hour delivery service levels for its
customers. The scope of operation is a single city.
Customers need to manage their service requests on the web. Drivers will use the new system
to control schedule and record package movements. Management will be able to view and
update delivery zones, cost tables, with the goal of balancing the constant change in demand
for services. They will also be able to view service feedback and influence customer satisfaction
by taking timely action. They will also have access to better, more detailed information about
the company’s performance and efficiency.
1.3 Definitions, Acronyms, and Abbreviations
Acronym
OSCS
Definition
On the Spot Courier Service
1.4 References
At present, no external documents are referenced in this Software Requirements Specification
document.
Page |5
1.5 Overview
This document is divided into five sections. Section 1 provides a high-level view of the new
system’s purpose, objectives, and benefits. Section 2 describes the factors affecting the system
and its requirements, including a comparison with related products, a summary of the functions
the software will perform, an overview of the people who will use the system, and an outline of
project constraints and assumptions. Section 3 describes the requirements in much greater
detail, from the perspectives of external interface requirements, functional requirements, nonfunctional requirements, and design constraints. This section will describe all hardware,
software, and networking interfaces required to implement this system. Section 4 lists analysis
models, including a use case diagram, sequence diagram, state machine diagram, domain class
diagram, and activity diagram. Finally, Section 5 deals with change management, which
addresses the possibility that project scope or requirements may change during development.
Page |6
2. General Description
The primary focus for software that is described in this software requirements specification is
to control the requests, routing, pickup, tracking and delivery of packages. The next focus is to
enable costing, billing and payments.
2.1 Product Perspective
The OSCS is a website that can be accessed from any device that has a web browser, such as
laptops, desktops, tablets, and smart phones. The site will both be used by customers and
employees. It will contain all necessary functions for On the Spot driver services.
The OSCS will need to be connected to a database to store customer information and package
information, along with driver information, and billing/accounting and reporting data.
The OSCS website is the standalone product that does not require integration with any other
application.
2.2 Product Functions
Below are the key functions of OSCS manager:















Create account and logon
Create pickup/delivery request
Create truck route (replaces “maintain pickup/delivery zones”
View pickup/delivery schedule
Log pickup
Log delivery
View all inventory
View delivery status
Generate bill (this one is temporal and has no actor)
View balance/make payment
Maintain cost table
View and give service feedback
Record check payment
View monthly bills
Print labels
2.3 User Characteristics
The system needs to have the look and feel of a modern web store. The various functions need
to have multiple points of entry and be easy to navigate. The costing method does not rely on
Page |7
weight, but simply on package dimension, which is easy for customers to measure. Labels can
be printed by customers on regular laser printers.
All functions used by drivers are geared toward efficiency, as they must handle hundreds of
packages each day.
General Constraints
1. Mobile internet access could be limited in certain situations, such as being inside
buildings.
2. Must have up-to-date plugins such as Flash and Java.
3. Must have up-to-date web browser.
Assumptions and dependencies
1. The users of OSCS Manager will always need some type of Internet access.
2. Users will possess an understanding of basic computer skills.
3. Customers will need at least one of the following: laptop, desktop, tablet, or smart
phone.
4. Driver will have an access point in his truck that connects a wireless LAN to the cellular
network.
5. Driver will require a tablet, label printer, and portable scanner.
Page |8
3. Specific Requirements
Pickup / delivery process.
To achieve a 3-hour delivery, one truck will repeat a circular route through the city zones that
we service every 1.5 hours. The truck will pick up and deliver only the 3-hour packages. The
truck will start at 8 A.M. and do 6 circular trips ending at 5 P.M. A package may be delivered on
the same trip or not, depending on pickup and delivery locations, but is guaranteed to be
delivered after 2 circular trips (within 3 hours). So the system will cut off 3-hour deliveries at 2
P.M. Since it takes 1.5 hours to do a circular route, the requested pickup times must be entered
at least 1.5 hours before pickup.
The other truck handles same-day and overnight deliveries. Overnight deliveries are just
handled as two same-day deliveries (same-day to warehouse + same-day from warehouse to
customer). That truck does only four circular runs, two in the morning (starting 8 A.M. and
10:15 A.M.) and two in the afternoon (starting 12:30 P.M. and 2:45 P.M.). Afternoon trips start
at 12:30 P.M. So any same-day delivery request is guaranteed to be delivered by 5 P.M. if it is
placed by 12:30 P.M. (cutoff). The runs start and end at the warehouse. Overnight delivery
packages are dropped off at the warehouse after each run, while same-day delivery packages
stay on the truck. Overnight delivery packages are delivered on the first morning run. If the
volumes are high they can be delivered by the second run. Thus they are guaranteed to be
delivered by 12:30 P.M. on the next day. The cutoff for overnight delivery is thus 2:45 P.M. on
the prior day because that is when the last run of the day will start. Same day and overnight
requested pickup times must be put into the system at least 2.25 hours ahead of pickup to
allow pickup to be achieved on time.
The system pickup/delivery schedule is dynamic. The system displays both outstanding pickups
and deliveries in the zone sequence of the truck route. System only controls the zone sequence
for deliveries and pickups. The driver is responsible for determining how to travel within the
zone. Zones can be made smaller by using the full zip codes.
Pricing
The package pricing will be based on cubic inches rather than weight because it is easier for
customer to measure the length, width and height of the package than to weigh it.
3.1 External Interface Requirements
The system will interface to the banking and credit card payment services.
3.2 User Interfaces
The user interface for OCSC must be easy for users to understand and require very little training
to learn. The buttons on the website must have text representation, ether placed by the button
or when the mouse hovers over the button. The menu bar will be located on the left of the
Page |9
page and the content located besides the menu. The company logo must appear on every page
on the OCSC website. The user interface must contain the following:
 Welcome screen
 Password-protected customer and employee login
 Simple, highly readable color palate (nothing dark)
3.1.2 Hardware Interfaces





Web server and associated application and database server
Firewall
Access points for the trucks
Tablets, label printers and bar-code scanners
2 PCs with LAN and printer
3.1.3 Software Interfaces
The design will need to evaluate appropriate compatible software products for the web server,
programming tools, and language and database management system. There must be a secure
https payment interface to credit card companies and banks. Label software will be required for
the label printer.
3.1.4 Communications Interfaces
Because OSCS is web-based users will need high-speed internet to access the site. Smart phone
users they will need 3G or 4G LTE access to view the OSCS website. Laptop users will need Wi-Fi
or a 4G card to connect to the cell phone network.
P a g e | 10
3.2 Functional Requirements
3.2.1 Create Account and Log On use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Create Account and Log On
Customer, Driver or Manager needs to log in to use the system
Many
Log on, create account, and validate credit card information
Customer, Driver, Manager
None
Users of the system; management and security team
None
User is logged on. Customers have an account.
System
Actor
Customer indicates desire to log on as a new If a new customer, system
or existing customer. Employee indicates
prompts for user and password
desire to log on to use the system.
data.
User is logged in after user code
and password is validated.
New customer is prompted to
identify if they are individuals or
a corporation, and payment
method.
Customer enters individual/corporation
System stores a Customer and
status and payment method.
Account.
Customer is prompted for
name, address, and contact info
associated with the type of
customer.
Billing customers are
additionally prompted to
provide credit card info.
Employees, including Drivers,
don’t have this step.
Customer enters name, address, contact and System updates the Business
optionally the credit card info.
customer or Individual
customer.
System validates the credit card
info and stores the credit card
number and sets the customer
as “Bill” or “Cash”.
Employees including drivers
don’t have this step.
Exception
Conditions
Logon failure
Credit card validation failure
P a g e | 11
3.2.2 Create a Pickup/Delivery Request use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Create a Pickup/Delivery Request
The customer requests a package pickup on the web
The Customer needs a package or packages to be picked up and makes the
request on the website
The Customer enters the information about the package into the system
The Customer
Driver may complete the request on behalf of Customer at time of pickup, on
mobile device.
The Customer, Manager, Driver.
Customer must have an account with logon and password.
Customer details must be entered as per account type.
Customer account must be in good standing (for credit account)
The pickup address and pickup date is confirmed (mandatory).
The service type is entered for each package (mandatory).
It is preferable but optional to have the labels printed upon order completion.
Actor
Customer requests service by entering
pickup request date and time and payment
type for order.
Enter package details
 Service type
 Deliver-to address
 Size category
 Signature required
Customer checks order is complete
Customer requests label(s) to be printed
Exception
Conditions
System
System validates customer
credit status (if applicable) and
if all OK, creates Order and
allows package details to be
entered.
System validates lead times to
pickup, and stores package
entities.
System calculates and shows
cost (if necessary parameters
have been entered).
An estimated delivery time and
date per package is generated
based on the service-type (3hr/same-day/overnight). The
system enables view-deliverystatus.
For each package: If recipient
deliver-to address exists, print
the label.
Customer payment status precludes credit order from being placed.
P a g e | 12
3.2.3 Create Truck Route use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
Create Truck Route
For each truck the sequence of zones is recorded. Each zone equates to a zip
code.
Plan the truck route.
A route is created for a truck and type of run.
Manager
View pickup/delivery schedule
Drivers , customers and manager
none
A truck route with its sequence of zones will be created
Actor
System
Employee enters the truck ID and the trip
System creates a Truck Route
type (3-hour or daily/overnight)
for the truck ID and trip type.
Employee enters a zip code with a short
System creates a zone for the
name for the zone
route and gives it a sequence
number.
System prompts for next zone
for the route.
P a g e | 13
3.2.4 View Pickup/Delivery Schedule use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
View Pickup/Delivery Schedule
Driver or management wants to view the delivery schedule for a truck and type
of run (trip type)
Desire to view pickups and deliveries
A route with its pickups and deliveries is displayed on a screen.
Driver, Manager
none
Drivers and management
Truck route must be created
Pickups and deliveries are displayed. There are no updates.
System
Actor
Driver indicates the truck code, trip type, the System displays all packages
target start and end date and time for the
grouped by zone, in the zone
run, and whether the run has started.
sequence of the truck route.
Each package is selected for
display as “pickup” or
“delivery”.
“Pickup” packages are packages
not yet picked up, with the
service-type selected, where
the requested pickup date and
time falls within the date and
time for the run.
“Delivery” packages (if the run
has started) are packages on
the truck, or 3-hr. packages to
be picked up with a delivery
zone that is later in the route. If
the run has not started and the
run is 8 A.M. sameday/overnight then the
“delivery” packages would
include packages due for
delivery that are at or expected
to be at the warehouse from
the prior day.
P a g e | 14
3.2.5 Log Pickup use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
Log Pickup
Package is being picked up
Package is being picked up
Package pickup generates one of two statuses: “picked up” or “out for delivery”
Driver
Record check payment, print label
Driver, Customer, management
Package data must be complete and package must have a label.
Packages for order or at the warehouse are picked up. Customer packages must
be paid for if not a credit order.
System
Actor
Driver will enter package ID or scan package Set Current Truck on the
label, and enter truck ID and source
package to the truck ID. If
(customer or warehouse).
picking up from a customer, set
the customer-pickup date and
time and set Current Status to
“picked up” unless it is a 3-hr.
delivery, in which case the
status goes to “out for
delivery”.
If picking up from the
warehouse, set the warehouse
pickup date and time. Set the
current status to “out for
delivery”.
System prompts for check to be
recorded if order is “cash”.
Package volume not entered correctly
P a g e | 15
3.2.6 Log Delivery use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
Log Delivery
Package is delivered to recipient or to the warehouse.
Delivery
Packages get a status of “delivered” or “atWarehouse”.
Driver
none
Driver, Customer, Management
Package status must be “picked up” or “out for delivery”
Package status is “delivered” or “ at warehouse”
System
Actor
Driver will enter package ID or scan package If delivering to final destination,
label, and enter truck ID and destination
set the final delivery date and
type (recipient or warehouse).
time, and set current status to
“delivered”.
If delivering to the warehouse,
set the warehouse delivery date
and time and set the current
status to “atWarehouse”.
Blank the CurrentTruck for the
package.
P a g e | 16
3.2.7 View All Inventory use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
View All Inventory
View list of packages stored at the warehouse
Ad hoc request
Shows management which packages are at the warehouse
Manager
None
Driver, Management
None
List of packages at the warehouse is printed
Actor
System
Request display of all packages at the
Display all packages with a
warehouse.
current status of
“atWarehouse” in Warehouse
delivery date/time sequence.
Show total number of packages.
Show total package volume.
Exception
Conditions
System inventory may not match actual physical inventory.
P a g e | 17
3.2.8 View Delivery Status use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
View Delivery Status
Customer or Employee checks on the delivery status of a package.
Desire to check delivery progress.
Display delivery status for packages associated with an order or for the
packages for a customer (multiple orders).
Customer, Manager
none
Customer, Manager
none
Delivery status displayed for all selected packages
System
Actor
Customer requests delivery status function
If no order number entered
and optionally enters an order number.
select all orders for customer,
else only select the order
entered. Display all packages for
each order selected, along with
the current status.
If current status is “pickedup”
display the pickup date and
time.
If the current status is
“atWarehouse” show the
warehouse delivery date and
time.
For overnight packages: If the
current status is “out
forDelivery” show the
warehouse pickup date and
time. For 3-hour or same day
deliveries a status of “out for
delivery” will display the pickup
date and time.
If “delivered” show the final
delivery date and time.
P a g e | 18
3.2.9 Generate Bills use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
Generate Bills
Generate a monthly customer invoice for one or more orders that have been
picked up.
System generated each month
System generates invoices for orders (of type “bill”) that have been picked up
during the relevant month.
None – temporal
None
Management, customers
It must be the first day of the month.
Picked up orders of type “bill” are invoiced
Actor
System
System will initiate on the first of the month The system will create an
for the prior month.
invoice record for each order,
where the packages have been
picked up and the order is of
type=”bill”. Place the invoice
number on the order and
accumulate order package costs
and add to Total invoice balance
on the account. Subtract
package costs transferred to
invoice from “Balance not yet
billed”.
Print each customer invoice;
showing
 Balance not yet billed
 Total invoice balance
And each order picked up and
each package with cost on the
order.
Show payment(s) made since
last invoice.
P a g e | 19
3.2.10 View Balance / Make Payment
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
View Balance / Make Payment
Customer checks balance and optionally makes a credit card payment.
Desire to check account balance and/or desire to make a payment.
System shows account balance and allows a credit card payment to be made.
Customer
None
Customer, management
At least one cash order or at least one invoice
An outstanding balance has been displayed and optionally a payment has been
made
Actor
System
Customer requests online payment.
System checks that the
Enter order number or invoice number.
customer record has a credit
card account.
Display the outstanding balance
for the invoice or for the order
to be pre-paid.
Customer enters payment amount.
For invoice payment:
Create a payment record
against the oldest invoice, and
update Total invoice balance. If
necessary split the payment
across multiple invoices. Create
a payment record per invoice
with the allocated payment
amount on each.
For order pre-payment:
Validate the order is “cash” not
“billed”
Create a payment against the
order prior to pickup.
Send transaction to credit card
company.
Exception
Conditions
Cannot pay a “billed” order. Payments for Billed orders are made against
invoice.
P a g e | 20
3.2.11 Maintain Cost Table use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Maintain Cost Table
Maintain table so packages can get priced
Employee sets up or makes a change to the cost table
Add multiple cost records, each record being for a volume range
Employee
None
Manager
None
A table of costs by service-type / package volume range is created
System
Actor
Employee enters service-Type (3hr or
System displays all cost records
sameDay or overnight)
for service type (if any).
Customer selects cost record to modify or
Add/modify/delete cost record.
delete or indicates an additional cost record
 From cubic inches
is required.
 To cubic inches
 Service type
 Cost
Exception
Conditions
No volume gaps are allowed for a service type
P a g e | 21
3.2.12 View and Give Service Feedback use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
View and Give Service Feedback
Customer can initiate feedback or manager can respond
Initiate feedback or respond to customer feedback
Customer only can create feedback records, Employee can update with a
response
Customer, Manager
None
Customers, Management
None
Feedback record is viewed and optionally updated or new feedback record is
created
Actor
System
Customer or employee indicates a desire to
System identifies the customer
view feedback.
from logon type and customer
object else prompts for a search
Employee enters search criteria (customer # System displays feedback
or date range or “all feedback with no
records based on selection
response”)
criteria. Customer notes are
made visible for customer logon
while internal notes are
additionally displayed for
internal logons.
Customers can enter new feedback
Create new feedback record
Internal logons can update customer
Update feedback record
response notes or internal-only notes
P a g e | 22
3.2.13 Record Check Payment use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Record Check Payment
A check is presented at time of pickup for a cash order or a check is mailed as
payment for one or more monthly invoices.
Invoice payment or order payment
System records payment against an order or allocates payments against one or
more invoices
Manager, Driver
None
Customer, management, Driver
An unpaid order or unpaid invoice must exist
One or more payment records are created
System
Actor
Employee requests to record a check
System selects either all unpaid
payment, and enters customer ID or name,
invoices or unpaid “cash”
and whether payment is for invoice or order orders.
Customer enters check number and amount. For orders:
Amount must equal outstanding
amount exactly, allocate check
to one or more orders.
For invoices:
System allocates check amount
starting with oldest outstanding
invoice up to current invoice. So
system creates a payment per
invoice that references same
check number.
Exception
Conditions
Check exceeds outstanding balance
Check underpays or overpays “cash” order
P a g e | 23
3.2.14 View Monthly Bills use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activities
Exception
Conditions
View Monthly Bills
Management wishes to view credit billing status
Management wishes to view billed business and payments
Display invoices and associated payments by various criteria
Manager
None
Management
Invoices must exist
Invoices are viewed
Actor
System
Employee enters desired month or
System displays a list of
“to current date”.
customers with billed amounts
and payments. Display total
billed, total paid and total
outstanding for the period.
Select a particular customer if desired.
Display customer invoice
amount and associated
payments.
P a g e | 24
3.2.15 Print Label use case
Use Case
Scenario
Triggering Event
Brief Description
Actors
Related use cases
Stakeholders
Preconditions
Post Conditions
Flow of activates
Print Label
Customer cannot print the label
Driver prints the label
Driver prints the label
Driver
None
Customer, driver
Package must have a delivery address
A label is printed
Actor
Driver enters customer ID or name
Select a package requiring a label.
Exception
Conditions
System
System displays a list of
packages not picked up yet for
the customer. The packages
displayed must have delivery
addresses.
Print label to portable label
printer using the Package ID as
the label ID on the bar code.
Printer has a malfunction; Package has no delivery address
P a g e | 25
3.3 Non-Functional Requirements
3.3.1 Performance
OSCS Manager must consistently deliver fast performance. One of the primary objectives of the
new system is to enable drivers to deliver faster service to customers, and this goal can be met
only if we design a Web site that is fast and responsive. The home page should load on a typical
high-speed Internet connection in four seconds or less, and other operations must be able to be
completed in the same amount of time.
3.3.2 Reliability
Because On the Spot is switching from a low-tech system based on paper records, the new
system must deliver the same reliability of the older methods. An unplanned period of
downtime could cause a serious disruption to the company’s business processes. Implementing
redundant servers will help alleviate the risk of a server going down, and On the Spot will
contract with an ISP that guarantees 99.99% uptime during business hours.
All maintenance affecting the delivery system must be performed after business hours.
Maintenance that prevents customers from logging in must be performed late at night to
minimize possible disruptions to customer payments and other mission-critical services.
3.3.4 Security
Security is a concern for any business, especially one that processes customer payments online
and stores credit card information in a database. The follow security requirements guard
against unauthorized access to data and help preserve the integrity of the system:




All customer transactions will occur using TLS encryption.
All data will be backed up nightly, and redundant servers help ensure the integrity of
data during business hours.
The system administrator will be the only person allowed to change access permissions
or interact directly with the database.
Accounts will be locked out after eight unsuccessful log-in attempts to prevent bruteforce attacks.
3.5.1 Database
The database needs to store information as described in the UML Domain Class Diagram
(Section 4.4). The following is a summary of the most important data stored in the database:

Accounts: User name, password, login type, balance
P a g e | 26





Customers: Name, address, payment information
Invoices: Account, bill date, amount due, print status
Orders: Customer, order date/time, order status, address
Packages: Order, recipient name/address, service type, size, cost, status, truck, pickup
times
Payments: Order, payment date, amount
3.5.2 Operations
The system must remain operable during On the Spot’s regular business hours. Redundant
servers will be used to help prevent a server outage from disrupting mission-critical business
processes.
Maintenance windows should be scheduled after regular business hours to prevent scheduled
maintenance from disrupting pickup and delivery. If possible, maintenance windows should
provide a means for customers to access the Web site and payment system. This way,
customers will not experience a disruption when they use the Web site to find information
about the company, pay bills, or look up a package’s status.
Backups will be performed automatically at midnight every night to ensure that the backup
system does not affect network performance during business hours.
3.4 Design Constraints
The website must work with multiple browsers. Each browser can display OSCS differently. Each
browser will need to be tested on multiple devices to ensure compatibility.
3.5 Other Requirements
The OSCS website and database hosting must be reliable and have more than 99.9% uptime
guarantee and pay credits when up time is not meet. The database will need to perform basic
CRUD. The database and website will need to be designed in such a way to be easily updated
and expanded in the future.
3.5.3 Site Adaptation
Since this is a new website, OSCS will be launched all at once on a predefined date.
P a g e | 27
4. Analysis Models
4.1 Use Case Diagram
P a g e | 28
4.2 Sequence Diagrams
Customer
System
requestService (date, time, paymentType)
validateCredit (customerCredit)
packageDetails (serviceType, deliveryAddress, size, weight, signatureRequired)
calculateCost ()
requestLabel (recipient, deliveryAddress)
confirmLabel ()
P a g e | 29
4.3 State-Machine Diagram
Requestforpackagepickup()
Package awaiting Pickup
Packagepickup()
Package Had been Picked up
Request a package Pickup
Arrival@warehouse()
Out For delivery
Oncouriertruckfordelivery()
Package arrived @ warehouse
PackageDelivered()
Package is delivered
TrackingClosed()
P a g e | 30
4.4 Domain Class Diagram
Business Customer
Account
Account Number
User Code
Password
Logon type (customer or employee)
Balance Not Yet Billed
Total Invoice balance
Business Name
Contact Name
Contact Tel Number
Customer
1
0..1
0..*
1
Customer ID
Address
credit card number
credit card expiry date
credit card 3-digit code
BillorCash
Invoice (Bill)
Individual Customer
Individual Name
Tel Number
1
Invoice number
Account Number
Invoice Bill Date
Invoice Amount
Invoice Due Date
Printed-YN
0..*
0..1
Order
1..*
0..1
0..*
0..1
Payment
Payment ID
Order ID (optional)
Invoice ID (optional)
Payment Date
Amount (applied to invoice)
Check number
Check amount
0..*
Customer ID
Order ID
Order Date
Order Time
Order Status (open/satisfied)
Pickup Address
Request Pickup Date&Time
BillorCash
Invoice number
Package
1
1..*
Order ID
Package ID (=label ID)
Recipient Name
Recipient Address
ServiceType (3hr/sameDay/overnight)
Volume (cubic inches)
Cost
Current Status ('atCustomer', 'picked
up', 'atWarehouse', 'outForDelivery',
'delivered')
Current Truck
Customer Pick-up Date&Time
Warehouse Delivery Date&Time
Warehouse Pick-up Date&Time
Final Delivery Date&Time
P a g e | 31
Truck Route
Cost Table
Truck Code
TripType (3hr or sameDay/overnight)
Route Hours
1
CubicInchesFrom
CubicInchesTo
ServiceType (3hr or sameDay or
overnight)
Cost
0..*
Truck Zone Sequence
Truck Code
Sequence Number
Zone name
Zone Zip Code
Global Table
Next package ID
next invoice number
Service feedback
Customer ID
Feedback Date
Feedback Time
Customer comments
Response Notes for Customer view
Response Notes for Internal view
P a g e | 32
4.5 Activity Diagram
Activity Diagram for 'Request a package pickup' use case.
Customer
System
bad
Request pickup
Validate Credit
Good
Create Order
Enter Package
For each package
Create package
End For each package
Confirm Order is
complete
Request Labels
Phase
No
Calculate Cost
Yes
Print labels
request a payment
P a g e | 33
5. Change Management Process
The changes can only be approved by Bill Wiley. Changes that are recommended by other users
will have to make the suggestions to Bill. The changes to the SRS can be made by email or by
phone. However, if changes are made over the phone, a follow-up email will be sent from
Logistics Data Solutions or Bill detailing and highlight the changes. The changes will be approved
by Logistics Data Solutions and Bill.