ISM3113 Team 5Nathan Freeman

Paul HudsonCarl Meiring

Software Requirements Specification

For On the Spot Courier Services

P a g e | 1

Revision HistoryDate Description Author Comment9/25/14 Began working on document, focusing

on Section 1.Nathan Freeman First revision.

10/6/14 Expanded upon security section. Wrote Database and Operations sections, and revised original SSD.

Nathan Freeman

10/6/14 Added section three Carl Meiring10/6/14 Added other sections to two and three

and formatted documentPaul Hudson

10/7/14 Grammar and proof check Carl MeiringNathan Freeman

Document ApprovalSignature Printed Name Title Date

Nathan Freeman

Nathan Freeman CEO 10/7/14

Paul Hudson, III

Paul Hudson, III Technical Writer 10/7/14

Carl Meiring Carl Meiring System designer 10/7/14

P a g e | 2

ContentsRevision History.....................................................................................................................................1

Document Approval.............................................................................................................................11. 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

P a g e | 3

3.2.9 Generate Bills use case.............................................................................................................18

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

P a g e | 4

1. Introduction

1.1 PurposeThis 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 ScopeThe 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 DefinitionOSCS On the Spot Courier Service

P a g e | 5

1.4 ReferencesAt present, no external documents are referenced in this Software Requirements Specification document.

1.5 OverviewThis 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, non-functional 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.

P a g e | 6

2. General DescriptionThe 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 PerspectiveThe 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 FunctionsBelow 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 CharacteristicsThe 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

P a g e | 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.

P a g e | 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.

PricingThe 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 InterfacesThe 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

P a g e | 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 InterfacesBecause 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 Requirements3.2.1 Create Account and Log On use case

Use Case Create Account and Log OnScenario Customer, Driver or Manager needs to log in to use the systemTriggering Event ManyBrief Description Log on, create account, and validate credit card informationActors Customer, Driver, ManagerRelated use cases NoneStakeholders Users of the system; management and security teamPreconditions NonePost Conditions User is logged on. Customers have an account.Flow of activities Actor System

Customer indicates desire to log on as a new or existing customer. Employee indicates desire to log on to use the system.

If a new customer, system prompts for user and password 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 status and payment method.

System stores a Customer and 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 optionally the credit card info.

System updates the Business 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 failureCredit card validation failure

P a g e | 11

3.2.2 Create a Pickup/Delivery Request use caseUse Case Create a Pickup/Delivery RequestScenario The customer requests a package pickup on the webTriggering Event The Customer needs a package or packages to be picked up and makes the

request on the websiteBrief Description The Customer enters the information about the package into the systemActors The CustomerRelated use cases Driver may complete the request on behalf of Customer at time of pickup, on

mobile device.Stakeholders The Customer, Manager, Driver.Preconditions 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)

Post Conditions 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.

Flow of activities Actor SystemCustomer requests service by entering pickup request date and time and payment type for order.

System validates customer credit status (if applicable) and if all OK, creates Order and allows package details to be entered.

Enter package details Service type Deliver-to address Size category Signature required

System validates lead times to pickup, and stores package entities.

Customer checks order is complete 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 (3-hr/same-day/overnight). The system enables view-delivery-status.

Customer requests label(s) to be printed For each package: If recipient deliver-to address exists, print the label.

Exception Conditions

Customer payment status precludes credit order from being placed.

P a g e | 12

Use Case Create Truck RouteScenario For each truck the sequence of zones is recorded. Each zone equates to a zip

code.Triggering Event Plan the truck route.Brief Description A route is created for a truck and type of run.Actors ManagerRelated use cases View pickup/delivery scheduleStakeholders Drivers , customers and managerPreconditions nonePost Conditions A truck route with its sequence of zones will be createdFlow of activities Actor System

Employee enters the truck ID and the trip type (3-hour or daily/overnight)

System creates a Truck Route for the truck ID and trip type.

Employee enters a zip code with a short name for the zone

System creates a zone for the route and gives it a sequence number. System prompts for next zone for the route.

Exception Conditions

3.2.3 Create Truck Route use case

P a g e | 13

Use Case View Pickup/Delivery ScheduleScenario Driver or management wants to view the delivery schedule for a truck and type

of run (trip type)Triggering Event Desire to view pickups and deliveriesBrief Description A route with its pickups and deliveries is displayed on a screen.Actors Driver, ManagerRelated use cases noneStakeholders Drivers and managementPreconditions Truck route must be createdPost Conditions Pickups and deliveries are displayed. There are no updates.Flow of activities Actor System

Driver indicates the truck code, trip type, the target start and end date and time for the run, and whether the run has started.

System displays all packages grouped by zone, in the zone 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. same-day/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.

Exception Conditions

3.2.4 View Pickup/Delivery Schedule use case

P a g e | 14

Use Case Log PickupScenario Package is being picked upTriggering Event Package is being picked upBrief Description Package pickup generates one of two statuses: “picked up” or “out for delivery”Actors Driver Related use cases Record check payment, print label Stakeholders Driver, Customer, managementPreconditions Package data must be complete and package must have a label.Post Conditions Packages for order or at the warehouse are picked up. Customer packages must

be paid for if not a credit order.Flow of activities Actor System

Driver will enter package ID or scan package label, and enter truck ID and source (customer or warehouse).

Set Current Truck on the package to the truck ID. If 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”.

Exception Conditions

Package volume not entered correctly

3.2.5 Log Pickup use case

P a g e | 15

3.2.6 Log Delivery use case

Use Case Log DeliveryScenario Package is delivered to recipient or to the warehouse.Triggering Event DeliveryBrief Description Packages get a status of “delivered” or “atWarehouse”.Actors DriverRelated use cases noneStakeholders Driver, Customer, ManagementPreconditions Package status must be “picked up” or “out for delivery”Post Conditions Package status is “delivered” or “ at warehouse”Flow of activities Actor System

Driver will enter package ID or scan package label, and enter truck ID and destination type (recipient or warehouse).

If delivering to final destination, set the final delivery date and 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.

Exception Conditions

P a g e | 16

3.2.7 View All Inventory use case

Use Case View All InventoryScenario View list of packages stored at the warehouseTriggering Event Ad hoc requestBrief Description Shows management which packages are at the warehouseActors ManagerRelated use cases NoneStakeholders Driver, ManagementPreconditions NonePost Conditions List of packages at the warehouse is printedFlow of activities Actor System

Request display of all packages at the warehouse.

Display all packages with a 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 View Delivery StatusScenario Customer or Employee checks on the delivery status of a package.Triggering Event Desire to check delivery progress.Brief Description Display delivery status for packages associated with an order or for the

packages for a customer (multiple orders).Actors Customer, ManagerRelated use cases noneStakeholders Customer, ManagerPreconditions nonePost Conditions Delivery status displayed for all selected packagesFlow of activities Actor System

Customer requests delivery status function and optionally enters an order number.

If no order number entered 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.

Exception Conditions

Use Case Generate BillsScenario Generate a monthly customer invoice for one or more orders that have been

picked up.Triggering Event System generated each month

P a g e | 18

Brief Description System generates invoices for orders (of type “bill”) that have been picked up during the relevant month.

Actors None – temporalRelated use cases NoneStakeholders Management, customersPreconditions It must be the first day of the month.Post Conditions Picked up orders of type “bill” are invoicedFlow of activities Actor System

System will initiate on the first of the month for the prior month.

The system will create an 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.

Exception Conditions

3.2.9 Generate Bills use case

P a g e | 19

Use Case View Balance / Make PaymentScenario Customer checks balance and optionally makes a credit card payment.Triggering Event Desire to check account balance and/or desire to make a payment.Brief Description System shows account balance and allows a credit card payment to be made.Actors CustomerRelated use cases NoneStakeholders Customer, managementPreconditions At least one cash order or at least one invoicePost Conditions An outstanding balance has been displayed and optionally a payment has been

made Flow of activities Actor System

Customer requests online payment.Enter order number or invoice number.

System checks that the 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.

3.2.10 View Balance / Make Payment

P a g e | 20

3.2.11 Maintain Cost Table use case Use Case Maintain Cost Table Scenario Maintain table so packages can get pricedTriggering Event Employee sets up or makes a change to the cost tableBrief Description Add multiple cost records, each record being for a volume range Actors EmployeeRelated use cases NoneStakeholders ManagerPreconditions NonePost Conditions A table of costs by service-type / package volume range is createdFlow of activities Actor System

Employee enters service-Type (3hr or sameDay or overnight)

System displays all cost records for service type (if any).

Customer selects cost record to modify or delete or indicates an additional cost record is required.

Add/modify/delete cost record. From cubic inches To cubic inches Service type Cost

Exception Conditions

No volume gaps are allowed for a service type

P a g e | 21

Use Case View and Give Service Feedback Scenario Customer can initiate feedback or manager can respondTriggering Event Initiate feedback or respond to customer feedbackBrief Description Customer only can create feedback records, Employee can update with a

responseActors Customer, ManagerRelated use cases NoneStakeholders Customers, ManagementPreconditions NonePost Conditions Feedback record is viewed and optionally updated or new feedback record is

createdFlow of activities Actor System

Customer or employee indicates a desire to view feedback.

System identifies the customer from logon type and customer object else prompts for a search

Employee enters search criteria (customer # or date range or “all feedback with no response”)

System displays feedback records based on selection 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 recordInternal logons can update customer response notes or internal-only notes

Update feedback record

Exception Conditions

3.2.12 View and Give Service Feedback use case

P a g e | 22

Use Case Record Check Payment Scenario 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.Triggering Event Invoice payment or order paymentBrief Description System records payment against an order or allocates payments against one or

more invoices Actors Manager, DriverRelated use cases NoneStakeholders Customer, management, DriverPreconditions An unpaid order or unpaid invoice must existPost Conditions One or more payment records are createdFlow of activities Actor System

Employee requests to record a check payment, and enters customer ID or name, and whether payment is for invoice or order

System selects either all unpaid invoices or unpaid “cash” 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 balanceCheck underpays or overpays “cash” order

3.2.13 Record Check Payment use case

P a g e | 23

Use Case View Monthly Bills Scenario Management wishes to view credit billing statusTriggering Event Management wishes to view billed business and paymentsBrief Description Display invoices and associated payments by various criteriaActors ManagerRelated use cases NoneStakeholders ManagementPreconditions Invoices must existPost Conditions Invoices are viewedFlow of activities Actor System

Employee enters desired month or “to current date”.

System displays a list of 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.

Exception Conditions

3.2.14 View Monthly Bills use case

P a g e | 24

3.2.15 Print Label use case Use Case Print Label Scenario Customer cannot print the labelTriggering Event Driver prints the labelBrief Description Driver prints the labelActors DriverRelated use cases NoneStakeholders Customer, driverPreconditions Package must have a delivery addressPost Conditions A label is printedFlow of activates Actor System

Driver enters customer ID or name System displays a list of packages not picked up yet for the customer. The packages displayed must have delivery addresses.

Select a package requiring a label. Print label to portable label printer using the Package ID as the label ID on the bar code.

Exception Conditions

Printer has a malfunction; Package has no delivery address

P a g e | 25

3.3 Non-Functional Requirements

3.3.1 PerformanceOSCS 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 ReliabilityBecause 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 SecuritySecurity 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 brute-

force attacks.

3.5.1 DatabaseThe 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 OperationsThe 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 RequirementsThe 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 AdaptationSince this is a new website, OSCS will be launched all at once on a predefined date.

P a g e | 27

4. Analysis Models4.1 Use Case Diagram

P a g e | 28

4.2 Sequence Diagrams

P a g e | 29

4.3 State-Machine Diagram

P a g e | 30

4.4 Domain Class Diagram

P a g e | 31

P a g e | 32

4.5 Activity Diagram

P a g e | 33

5. Change Management ProcessThe 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.