Non functional requirements for warehouse management system

Produce A Systems Design Specification For On The Spot Courier Services. Based Off Of Template And Systems Requirement Document

Revision History
2/15/2013

Deliverable 5_SRD_1.0

Kirsten Rice

Initial Draft

Document Approval
The following Software Requirements Specification has been accepted and approved by the
following:

Table of Contents
REVISION HISTORY ..............................................................................................................................................II
DOCUMENT APPROVAL .......................................................................................................................................II
1. INTRODUCTION ................................................................................................................................................ 1
1.1 PURPOSE .............................................................................................................................................................1
1.2 SCOPE .................................................................................................................................................................1
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ..............................................................................................2
1.4 REFERENCES .......................................................................................................................................................2
1.5 OVERVIEW ..........................................................................................................................................................2
2. GENERAL DESCRIPTION ..................................................................................................................................2
2.1 PRODUCT PERSPECTIVE ...................................................................................................................................... 2
2.2 PRODUCT FUNCTIONS ......................................................................................................................................... 2
2.3 USER CHARACTERISTICS .................................................................................................................................... 2
2.4 GENERAL CONSTRAINTS ..................................................................................................................................... 2
2.5 ASSUMPTIONS AND DEPENDENCIES .................................................................................................................... 2
3. SPECIFIC REQUIREMENTS ...............................................................................................................................2
3.1 EXTERNAL INTERFACE REQUIREMENTS ..............................................................................................................3
3.1.1 User Interfaces .......................................................................................................................................... 3
3.1.2 Hardware Interfaces ................................................................................................................................. 3
3.1.3 Software Interfaces.....................................................................................................................................
3
3.1.4 Communications Interfaces .......................................................................................................................
3
3.2 FUNCTIONAL REQUIREMENTS – USE CASES........................................................................................................ 3
3.2.1 Use Case #1 ...............................................................................................................................................
3
3.2.2 Use Case #2 ...............................................................................................................................................
3
3.3 NON-FUNCTIONAL REQUIREMENTS .................................................................................................................... 3
3.3.1 Performance .............................................................................................................................................. 4
3.3.2 Reliability .................................................................................................................................................. 4
3.3.3 Availability ................................................................................................................................................ 4
3.3.4 Security ......................................................................................................................................................
4
3.3.5 Maintainability .......................................................................................................................................... 4
3.3.6 Portability ..................................................................................................................................................
4
3.4 DESIGN CONSTRAINTS ........................................................................................................................................ 4
3.5 OTHER REQUIREMENTS ...................................................................................................................................... 4
3.5.1 Data Base .................................................................................................................................................. 4
3.5.2 Operations ................................................................................................................................................. 4
3.5.3 Site Adaptation .......................................................................................................................................... 4
4. ANALYSIS MODELS .............................................................................................................................................4
4.1 SEQUENCE DIAGRAMS ........................................................................................................................................ 5
4.2 USE CASE DIAGRAM ........................................................................................................................................... 5
4.3 STATE-TRANSITION DIAGRAM (STD) ................................................................................................................ 5
4.4 DOMAIN CLASS DIAGRAM .................................................................................................................................. 5
4.5 ACTIVITY DIAGRAM ........................................................................................................................................... 5
5. CHANGE MANAGEMENT PROCESS ...............................................................................................................5

A. APPENDICES (USE THIS HEADING IF NEEDED) ........................................................................................ 5

1. Introduction
1.1 Purpose
This System Resource Specification (SRS) describes the capabilities of the On the Spot (OTS)
Web Client and serves as a communication tool between the system development team and On
the Spot Company.
Intended Audience - This document serves both parties by describing what the system is
supposed to do, in non-technical terms. This document can be used as a reference by employees
in the technical area, but the intended audience is the On the Spot management and marketing
staff. This document must be signed and approved by the management at On the Spot Company
before actual work can begin.

1.2 Scope
The name of the software program is On the Spot Web Client. The On the Spot Web Client
addresses the needs put forth in the On the Spot Company. It provides analysis by offering a
convenient, company-wide tracking and management tool. The On the Spot Web Client will be
able to keep track of real-time pickup and delivery trends that can be accessed via a company
web application interface and touch device’s application interface located at the company’s
headquarters. OTS will incorporate data from each customer and driver. It will allow user to
define different values for status of package. Data will be updated in real-time and can be
accessed via the package tracking and management software at each pickup and delivery point.
OTS will incorporate the scheduling details of packages. The user can update details which get
synchronized with the system in real time. OTS will define different categories for weight and
size of packages. OTS will incorporate the details of system. Labels and receipts for packages
that enter the system from company’s website and touch devices will be generated automatically.
It optimizes operational and transportation costs.
The subsystems of OTS are:
i.

Package management system - Will keep track of labeled (existing), non-labeled (new),
delivered, cancelled, ready-to-pickup, picked-up, arrived-at-warehouse and out-ofdelivery.

ii.

Customer management system - Will manage information being entered by customer in
online form for package delivery and pickup.

iii.

Inventory management system - Workstations upgraded with the OTS Inventory
Management software application and connected to the On the Spot Company’s intranet
will have the capability to receive package request from each customer.

iv.

Truck management system - Will track each truck’s movement from warehouse.

1.3 Definitions, Acronyms and Abbreviations
OTS

On the Spot

SRS

System Resource Specification, this document

SQL

Structured Query Language, a standard language used for data base information storage
and retrieval.

OLTP On-Line Transaction Processing, a data base model used for day-to-day queries and
inputs.
OLAP On-Line Analytical Processing, a data base model used for analytical research of data
trends and relationships.

1.4 References
IEEE Std. 830-1998
http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf

1.5 Overview
The document is concerned with the product and functions of OTS. It will discuss about
automated package management by defining its specific needs, constraints and assumptions.

2. General Description
2.1 Product Perspective
OTS is a standalone system. It will not be getting any input and supply output to any other
device/system/application. It will be interacting with human resources and printers.

2.2 Product Functions
User can register on the system. Only authorized users are allowed to enter the system. A user should
be able to order online. A customer should be able to place package using the website, or through a
staff using OTS Web Client. Customer can register their information so that they can make requests
repeatedly. Customer does not have to be registered to make request again and again. System will give
different access rights to administrator, customer, driver and high-management. The system will track
the transaction of each delivery and pickup. The user can prepare package request using the system.
The driver can check for package details in the system. Details can be updated as well depending on the
details provided by label on package. The system keeps track of the payment done by customer. It gets
updated automatically depending on mode of payment. The system will generate reports: delivery
report, pickup report, customer report and criteria-based reports. The system will provide scheduling

and delivery mechanism. The systems will different statues to packages depending on the scheduling
and delivery algorithm. An average request will take 60 seconds to complete. The driver can enter
information regarding new packages in the system. Customer will take 2 minutes to place the request.
Every Receipt sent to user will have order Number will be printed on it. The System records cash flow
and track packages. The system can analyze profit and loss on an ongoing basis. The system must be
able to generate a prompt which will inform user about the next step. An easy to use graphical user
interface will provided by system for smooth operation. Administrator should be able to add/delete/edit
the items/users of the system. Driver can see his/her scheduled pickups and delivery for a particular
run. User can define categories of weight and size of products. Automatic generations of time-interval
are to be taken for pickup and delivery.

2.3 User Characteristics
The end-user of OTS falls into following categories: Customer, driver, inventory/warehouse
manager and administrator.
i.

Customer - Customers are non-skilled users. They are assumed to be non-tech savvy.
They possess basic computer knowledge only.

ii.

Driver - Driver is like customer but is quite familiar with system or functioning of
OTS.

iii.

Inventory/Warehouse manager - They possess a little more computer knowledge than
customer’s. They are also familiar with functioning of OTS. The user is expected to
possess junior-level certificate.

iv.

Administrator - They are the most tech-savvy user. They understand the know-how of
system and its technicalities. They are expected to have high school certificate or
equivalent.

2.4 General Constraints
Allotted time may get affected in absence of accurate current data. Allotted time may get
impacted by the lack of skilled human resources hired for the project. Allotted time may also
affect the project delivery deadline because of huge amount of data to be entered in to new
databases for automated system. Existing staff may resist changing as they do not have
sufficient knowledge. During implementation of project information may get lost because of
absence of staff resources. Issues regarding the staffing may impact the project as the staff will
require intensive computer training so that they can use the new system. Existing staff may
resist changing because of their long tenure in the company. Customers may get dissatisfied
because of implementation of changes. IT related issues because of supervision of staff for new
system. Increase in absence of staff because of lack of proper motivation and confidence.
Frustrations of supervisor as he/she is involved in managing both systems and staff during
implementation phase.

2.5 Assumptions and Dependencies
Project Size: The project is assumed to spend under USD 1million and will be involving less
than 20 people.
Stable Platform: It is assumed that once the specified implementation platform has been made to
work, it will not get changed in the near future. It is so assumed because a stable platform forms
the backbone of project. If it keeps on changing then it would stand as a threat to the project’s
viability.
Stable Infrastructure: The allotted operating system for networks, file servers, database servers
and web servers will not get changed in the near future because a change in them will mean a
significant change to OTS system and would stand as a threat to the project’s viability.

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
The user shall be able to access the web client from any web browser (i.e. Mozilla Firefox,
Internet Explorer, and Safari).

3.1.2 Hardware Interfaces
The On the Spot Web Client shall let users log in to their personal profiles. When accessing the
web client, the user will be asked to either sign-in with their established user name and password,
sign up as a user for the web client, or continue as a guest. As a guest, the user will not be able
to save any information to the web client’s database, and must re-enter their information upon
each use. When a user logs in, a request will be sent to log this particular user in with their saved
information (i.e. name, address, and payment information).

3.1.3 Software Interfaces
When the user logs in successfully, a “welcome” screen will be shown. From the “welcome”
screen, the user will be able to ship using their saved shipping address and payment method. The
customer will then fill out the information for the package they want shipped. The information
filled out (i.e. the ship-to address) can be saved to an online “address book,” in which the
registered user can use for faster shipping in the future. As a guest, you cannot save this
information to the “address book.” The customer can either pay for the shipment on the web
client, or opt to pay the courier directly. After the payment method has processed, the customer
will then be prompted to print out two receipts (one for personal records, and one for the
courier). The receipt will display whether or not the bill has been paid. Once the user has printed
out the receipt, the web client will let you either: a) Complete another order, b) Manage Previous

Orders, c) Edit Profile Information, or d) Log out of profile. For guests, once the payment has
been completed, they will have the option to: a) Create an account, or b) Edit previous order.

3.1.4 Communications Interfaces
An e-mail will be sent to the user after the order has been submitted. For registered users,
tracking the progress of the shipment can be completed through the web client. For “guest”
users, the tracking is done through e-mail updates sent by the system.

3.2 Functional Requirements—Use Cases
User/Customer

Logs into the system

User/Customer

Enters shipment information

User/Customer

Makes payment

Courier

Records order and pickup time

Courier

Receives Payment

Courier

Collects packages for shipping

Courier

Records package information

Courier

Labels package

Courier

Scans package

Courier

Sorts package at warehouse

Courier

Delivers package

3.3 Non-Functional Requirements
3.3.1 Availability
This system is available at any time throughout the day or night, but any order put in past
4:00pm EST will not have a same-day delivery. That order will be put in the system, and the
courier will be notified for it to be picked-up at the beginning of the next business day. On the
Spot Courier Services are closed on Sundays, but just like any time after 4:00pm EST, shipments
can still be scheduled. If any maintenance is deemed required, a notification would be posted at
least 24 hours before the maintenance occurs. When maintenance is needed, it occurs after the
end of the business day (5:00pm EST).

3.3.2 Usability
This system takes very minimal effort to operate and understand. Using a SQL Server Database,
the information entered into the web client gets stored and updated in a database. When the order
is ready to ship, it takes the information and prints out a receipt. The user does not see any of
these actions, so they do not have to comprehend how to use databases or character recognition.

3.3.3 Security
Our databases are constantly being backed up onto multiple external drives and Cloud services,
ensuring that a loss of data shall never occur. Also, we have installed many measures to secure
our website from both viruses and data theft. We use PayPal as our preferred method of online
payments, but also have a top-of-the-line credit card service.

3.7 Design Constraints
Software Constraints
a.i.
a.ii.
a.iii.
a.iv.
a.v.
a.vi.

The system will be used on a variety of device types (PDA’s, desktop computers, and
laptop computers). The interface must have scalable buttons, icons, and text entry boxes
that can adapt to each specific device.
User interface must be bi-lingual (English and Spanish).
The system must be accessible from any browser laid out in the software constraints
section.
All information containing user’s personal information must be encrypted.
Access rules for various user levels must be implemented.
Software must be designed to work on off-the-shelf components

Hardware Constraints
i.
ii.
iii.
iv.
v.

The database and website must be hosted with “five nines” availability.
Data redundancy must be used for all servers.
PDA devices must have mobile internet connections, as well as Wi-Fi.
Servers should be off-the-shelf units that can be easily replaced if needed.
In order to maximize reliability and ease of repair/replacement, there should be no
custom designed hardware for this system.

3.8 Other Requirements
3.8.1 Data Base
The data base for OTS will be a two part system. The working data base will be an OLTP model
using Structured Query Language (SQL). This data base will be used for new and open
transactions. It will also contain archival information of past transactions, as well as all user
information. In addition, an OLAP data base will be maintained for reference and research. This
data base will be used for running analysis on transaction histories, delivery speeds, and system
productivity.

3.8.2 Operations
The system is expected to maintain a 24/7/365 operational period. Any required periods of
downtime will be scheduled during non-business and non-operational hours (i.e. from 12:0005:00 M-F or on weekends). Downtime periods should not exceed a timeframe greater than one
hour. Any required downtime that exceeds these specifications must be approved by company
management and IT and must be scheduled in advance.
Data base backup from OLTP to OLAP will be performed every day at the operational closing
time (12:00am). Any needed recoveries should be processed immediately.

3.8.3 Site Adaptation

Physical AdaptationA server closet will be added to the mechanical room at On The Spot headquarters. In addition,
new PDA devices will be distributed to all applicable employees. Five new workstations will be
installed in the manager’s office (1), the reception desk (1), the warehouse (2), and the
mechanical room (1).
System InstallationThe system will be rolled out in three phases.
TrainingWorkstation raining will be provided on a test bed the week prior to installation. PDA training
will be provided at the same time by a specialized team. To minimize work disruption,
employees will be trained in small groups at one of three available training sessions.
InstallationOn The Spot offices will shut down on Friday evening, and the system will be installed over the
weekend. This timeframe allows for physical installation, testing, and software initialization.
InitializationThe new PDA devices and workstations will be activated by 20:00 on Sunday in preparation for
operational opening on Monday morning. The web site portion of the system will go live on
Monday morning at 12:01am.

4. Analysis Models

4.1 Sequence Diagram
This sequence diagram shows the interaction between an online Customer and the system during
a request for package pick-up. The Customer enters various pieces information relating to the
pick-up, and the system records the information and prompts the Customer at each step for the
next piece of information.

4.2 Use Case Diagram
User Goal Diagram:
The following use case diagram shows the user goals that occurred during the scheduling, pickup, storage and package delivery using On-The-Spot’s existing system. This shows the basic
goals that must be handled by the new OTS system.
User
Customer

User Goal

Resulting Use Case
1. Record Order and
Pickup Time

2. Hand-Off Package

Courier (Bill)

1. Place Order

2. Ship Package

3. Make Payment
1. Receive package
information

3. Receive Receipt
1. Pick up package

2. Receive package to
ship

2. Record package
information

3. Take package to
warehouse

3. Sort package

4. Put package on the
delivery truck

4. Deliver package

5. Give package to
customer

5. Receive payment

Use Case Diagram and Description:
The following use case diagram shows the involvement of the actors involved in the package
delivery system. This diagram covers the steps from the initial pick-up order through the
package delivery. The second diagram is a use case description containing specific details for
each use case.
Use Cases

Description

Actors

Record Order and Pickup
Time

Order is received via phone
and the call time and time of
desired pickup is recorded.
Packages are collected from
the customer at the pickup
location
Name, address or delivery
location, time of pickup,
requested delivery time, and
weight are all recorded from
the customer.
Bill, or another courier,
prints a label and attaches it
to each package.
Payments are received at the
time of pickup for some
customers, and added to a
monthly account for repeat
customers.
Packages are scanned when
entered into the warehouse
for sorting.
Delivery time and recipient
are recorded at the time of
delivery. A signature may be
required as well.

Customer, Bill/Courier

Collect Packages
Record Package Information

Label Package
Receive Payment

Scan Package
Deliver Package

4.3 State Machine Diagram

Customer, Bill/Courier
Customer, Bill/Courier

Bill/Courier,
Bill/Courier, Customer

Bill/Courier
Bill/Courier, Customer

This state machine diagram shows the states of the system during the package pick-up and
delivery process. This is a good overview of the major processes and states that will need to be
addressed during system design.

4.4 Domain Class Diagram
This domain class diagram shows the different entities, actors, and their related attributes for the
package pick-up and delivery system. It illustrates the constraints and relationships between
these entities and provides an overview of the system for the designers.

4.5 Activity Diagram
This activity diagram also illustrates the interaction between the Customer and the system during
an online order for package pick-up. This diagram shows a sequential flow of the activities
involved in the order process.

5. Change Management Process
Requests for changes must be submitted using a change submittal form. In addition, the project
manager will evaluate the project for possible risks and expected changes throughout the
progress of the project. Change requests will be evaluated within two weeks and approved or
denied. All change requests must be submitted to the project manager prior to implementation.
Upon approval, the SRS will be updated to reflect the new changes. A summary of changes will
also be appended to the end of the document. Any budgetary or timeframe changes must be
approved by the client as well as the project manager, regardless of the party submitting the
change. Team managers will be notified of any changes affecting their tasks. The project
manager will submit a monthly status report detailing any changes made during that time.

ISM 3113 Modified Design Specification Template (02/07/12)

ISM 3113 – Systems Analysis and Design Template for Software Design Specification (based on IEEE Std. 1016) 1.0 Introduction

1.1 Purpose of the Document

Provides why the document is written and identifies its intended audience

1.2 Scope of the Development Project

A general description of the software is presented. This often comes from other documentation.

1.3 Definitions, Acronyms, and Abbreviations

Includes a list of any definitions, acronyms and abbreviations meant to help the reader understand the document better

1.4 References

Any other documentation used to assist in completing the Software Design Specification (SDS)

1.5 Overview of the Document

Provides an overview of the content of the SDS 2.0 System Architecture Description

2.1 Overview of the modules/components

Provide a high-level overview of how the functionality and responsibilities of the system were portioned and assigned to its subsystem/components.

2.2 Structure and Relationship

Identifies flow of system (often graphical format)

2.3 User Interface Issues 3.0 Detail Description of Components 4.0 Design Decisions and Tradeoffs

Describe any design decisions and/or strategies that affect the overall organization of the system. Also reference any decisions made as a result of circumstances.

5.0 Appendix