Software Requirements Specification

for
Citrus Ordering System
Version 1.0 approved
Prepared by Caroline Mort
16onCenter
3.28.2018

Table of Contents

1. Introduction
1.1 Purpose
1.2 Definitions, Acronyms, Abbreviations
1.3 Overview
1.4 Project Scope
1.5 References
​ 2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 Assumptions and Dependencies
​3. System Features (Functional Requirements)
3.1 Log in/out
3.2 Create Request
3.3 View Request
3.4 Create Order
3.5 View Order
3.6 Order History
3.7 Send Reminder
​ 4. External Interface Requirements
4.1 User Interfaces (Online Interfaces)
4.1.2 Online Interface Mockups
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
​ 5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Security Requirements
1. Introduction

1.1. Purpose

The purpose of this document is to describe the first version of the Citrus Ordering

System. The Citrus Ordering System is intended to be developed as an add-on software to

the existing Breadcrumb POS system. The document will describe the details of how the

addition of this product to the Breadcrumb system will support collaborative ordering by

individual users and their order requests, as well as how the requests can be consolidated

and edited by the citrus orderer. This document will also describe the process and

requirements for finalizing orders and saving the orders to the order history database for

further analyzation and which information is needed in order to create data sets.

1.2. Definitions, acronyms and abbreviations

● COS (Citrus Ordering System)

● POS (Point of Sales)

● The venues are the various bars and kitchens within the building that utilize whole

citrus and/or citrus juice and may be abbreviated as PH (Punch House), TH

(Thalia Hall), TR (Tack Room), DK (Dusek’s), and K (Kitchen).

● The users are the employees that come into direct contact with the citrus ordering

system and may be abbreviated as CO (Citrus Orderer), VM (Venue Manager),

and J (Juicer).

● Requests are created by Venue Managers in order to request a specific amount of

citrus for their venue. Requests require VM to input current inventory to prevent

VM from over ordering.

 ● Orders are created by the Citrus Orderer and are based on the edited and

consolidated VM requests. The order specifies how many cases of each type of

citrus will be ordered. The order also displays how many cases of each citrus will

go to each venue, or is to be set aside to be juiced by the Juicers to fulfill the

citrus juice order.

● There are 2 orders and order cycles per week. Orders are named after the days on

which they are delivered (Mondays and Thursdays). Orders must be sent to the

vendor on the evening before the delivery day. Order cycles begin on the day of

delivery and end the evening before the next delivery.

1.3. Overview

This document is intended for developers and upper management. This document will

prove the necessity of a citrus ordering system to upper management through its

efficiency, ease of use, ability to reduce waste and product shortages, and beneficial data

output. The document will describe the system in details that will be useful to the

developers in giving them a clear path of development and useful to management in

demonstrating its value and necessity.

1.4. Project Scope

The COS’s software will serve as a collaborative data entry platform in order to create

more accurate orders by holding the individual users accountable for their input and

usage. Users will have assigned roles with varying levels of access to create a system of

checks and balances. Most users will be able to create new requests or orders and view

the order history. The order history will be able to track citrus overages and shortages
from order to order and provide data for analysis, improving order accuracy. The order

history will also be able to track the accuracy of VM requests and how often they were

edited by the CO, and whether or not the edit by the CO was accurate. Over time the

order history will accumulate enough data to help predict requests and orders with

increasing accuracy and serves as a suggestion rather than a replacement for human

judgement.

1.5. References

● Breadcrumb POS: ​https://upserve.com/platform/restaurant-pos/

● Data Design Model:

https://drive.google.com/file/d/1Q1sJw21xliAahJ0ySSeCLkruDhU8I9pa/view?us

p=sharing

2. Overall Description

2.1. Product Perspective

This product will be a feature of the building’s existing POS system, Breadcrumb. The

system is accessible via the Breadcrumb app, which is available on many tablets around

the building and personal iPads with wireless internet access. Employees will log into the

Breadcrumb system in which they will have existing jobs or roles and access levels.

Certain jobs or roles will allow the user to access the COS interface with varying levels

of access. The integration of the COS with the POS system will allow for sales data to be

integrated with order data. Breadcrumb multifaceted structure allows for data reporting

and is a good model for the COS.

2.2. Product Features

The COS will allow users to create requests and orders for citrus fruit and juice. Users

will be able to view other requests, previous request and order history and corresponding

inventory and data to help them make more informed requests. These histories will

correlate sales and inventory, including shortages and overages in the requests, for each

venue. The Juicers will also be able to view orders to see how many cases of fruit they

will juice to fulfill the order.

2.3. User Classes and Characteristics

The main users of this product will be the Venue Managers and the Citrus Orderer. The

VM and CO will create requests and orders which will generate data. The VM and CO

will have access to this data for analysis. The CO will have editing power and be able to

override requests. Juicers will use the product to view the order but will not interact with

other users, create data, or give input. The following process model further illustrates the

various users and their functions within the system:

2.4. Operating Environment

The software will operate within the Breadcrumb app. The Breadcrumb app exists for the

latest iOS for Apple products. The app is available for Apple iPad Air 2, iPad Mini 2, and

iPad Pro.

2.5. Design and Implementation Constraints

The main limitation of this product is the existing Breadcrumb software. Developers will

be forced to work within the restraints of the existing software system, or develop a

separate system that interacts with the Breadcrumb system and seamlessly as possible.

Another limitation is that the Breadcrumb app is only available for iPad. This should not

be a major limitation, as iPads are generously available in each venue. However, the

ability to use the COS on personal smartphones is ideal. Another limitation is memory.

The COS will be connected to the internet and ideally a cloud-based drive, which will

prevent the need to print out data reports and orders.

2.6. Assumptions and Dependencies

The main assumption in this project is that the developers will be able to work with the

existing Breadcrumb software of which the constraints and limitations are assumed and

unknown. The dependency on the existing Breadcrumb software is flexible and

developers may be able to develop software that works with Breadcrumb if they are

unable to amend the existing software.

3. System Features

3.1. Log in/out

3.1.1 Priority

Top Priority. Required to access the COS.

3.1.2 Requirement

User will enter their 4 digit employee ID number to log into Breadcrumb. The ID number

will be associated with a role and access levels. If the ID number allows for the employee

to access the COS they will be able to do so through the POS system’s main menu.

3.2. Create Request

3.2.1 Priority

Top Priority. Required to create an order.

3.2.2 Requirement

The VM will have access to create a request. The request has two columns labeled

“Have” and “Need”. The columns have text entry boxes associated with rows of citrus

fruits and juices. The VM takes inventory and enters the citrus amounts in the “Have”

column. The numbers can be positive or negative to indicate excess or an estimated

shortage. The numbers will represent cases of citrus or quarts of juice and can be whole

numbers, integers, or decimals. The VM will also enter numbers in the “Need” column to

represent the desired number of cases of citrus or quarts of juice. These numbers must be

whole, positive numbers. Every text entry box must be filled in order to submit the

requests. The number 0 is acceptable. The VM submits the request by hitting the

“submit” button once all text boxes are filled with appropriate entries. An error message
will occur if text entry boxes are left blank or have unacceptable characters. When

entering numbers in the text entry boxes the VM will only be able to use a number pad

with decimal points. When the VM fills in the “special request” or “notes” section they

will have access to a full keyboard.

3.3. View Requests

3.3.1 Priority

Top Priority. The CO must be able to view requests in order to make an order.

3.3.2 Requirement

The VM and CO can view requests. Requests are sorted in a list from newest to oldest

and are automatically archived in the order history after the order has been made. The

VM and CO can click on the requests and view the original request. The CO can edit the

requests. Once all five VM have submitted their requests a button labeled “create order”

will appear below the list of requests and be visible to the CO.

3.4. Create Order

3.4.1 Priority

Top Priority. Required to make an order.

3.4.2 Requirement

The CO can make an order two ways. The first is by hitting the “Create Order” button on

the home page. This will only create the order if all five venues have entered their

requests. If a request is missing an error will occur that will tell the CO which venue still

needs to submit a request. The CO can then “send a reminder” to the VM by email or as a

notification when the VM logs into Breadcrumb. The second way to create an order is to
click the “View Requests” button from the homepage. If all five requests have been

entered the CO will see a “Create Order” button. The “Create Order” button will

consolidate the five requests into a single, adjustable order in the same text entry box

format as “Need” column of the request. Numbers must be whole and positive. Zero is an

acceptable entry and no text box may be left blank or an error message stating the

absence will occur. A number keypad will be the only option when entering or editing

numbers. A full keyboard will be available when entering “special requests” or “notes”.

Edits to the requests made by the CO will be honored and carried over into the order. The

CO can “save” the order to the order history and come back later. “Download” and

“Print” buttons will also be available below the order. The CO can return to edit the order

further or “submit” the order, which will automatically save it to the order history. The

“submit” button will present a small window in which an automatically saved email

address is entered. The CO can edit the email address and hit “send” or just hit “send”.

The window will say “sent” or specify an error with the email address. The CO can “x”

the prompt window and return to the order screen.

3.5. View Order

3.5.1 Priority

Top Priority. This is how the Juicers will view the current order.

3.5.2 Requirement

The VM, CO, and J will be able to view the current order. The current order is the order

that corresponds with the current order cycle. The VM can view the order to verify that

their order is correct. The J views the order to determine how much citrus they will juice.
3.6. Order History

3.6.1 Priority

Medium Priority. The order history is not required in order to make an order but contains

important information for the VM and CO to reference for future ordering.

3.6.2 Requirement

The VM, CO, and J can view the order history. The orders will be listed by date with the

most recent first. When the user clicks on the order they will be taken to a copy of the

order and its corresponding requests. The user will also be able to view statistics on the

order history page by hitting the “statistics” button. Statistics will analyze the order

history and report shortages, overages, and perfect orders chronologically by venue by

stringing together the “Have” and “Need” columns from week to week to determine such

differences.

3.7. Send Reminder

3.7.1 Priority

Low Priority. This is not necessary, as the CO can contact the VM by other means; but it

is useful.

3.7.2 Requirement

The CO will be able to send the VM a reminder if they have not yet submitted a request.

The CO will hit the “Send Reminder” button on the home and requests page which will

open a window. The window will have a drop down menu with the names of the VMs

and a text entry box to add a note. The CO will be able to select whether or not the

reminder will go into their email inbox or appear as a notification on the user’s
Breadcrumb interface. The CO will be able to send the reminder to one, multiple, or all

VMs. When the reminder is sent the window will report so.

4. External Interface Requirements

4.1. User Interfaces (Online Interfaces)

The system’s user interface will be suitable for Apple product touchscreens and follow

the existing design aesthetic of the Breadcrumb interface. The user interface will exist as

an online interface, as the Breadcrumb system relies on internet connection and cloud

storage. An off-line mode is available but will limit functions or force functions to be

batched for later function implementation. The options on the COS home menu will vary

depending on the user’s access level. Both the VM and CO will have the option to view

requests but the request interfaces will look different depending on the access level of the

user. The VM will be able to create a new request. The CO will have added options on

the request interface to edit the requests and make the requests into an order. The CO will

be able to send a reminder to the VM or J. The Order interface will be available for

editing to the CO, but only available to view to the VM and J. Examples of the online

user interfaces will be presented below in 4.1.2.

4.1.2 Online Interface Mockups

Home Interfaces:
Request Interfaces:
Order Interfaces:
4.2. Hardware Interfaces

The product will run on Apple products that are supported by the Breadcrumb interface.

These currently include the Apple iPad Air 2, iPad Mini 2, and iPad Pro. A smartphone
app will be developed for added accessibility and ease of use if the development of the

app software is supported by the iPhone hardware.

4.3. Software Interfaces

The architecture of the software system will exist in three layers. The user interface will

be the top layer and run within the Breadcrumb software system, as described in 4.1. The

second two layers will include a business access layer and a data layer. The CO, upper

management, and owners of the company will have access to the business layer; although

the CO will be the main person accessing the information. The Business layer will also

run within the Breadcrumb system and includes the interfaces that allow for back-end

editing, which includes editing requests and other submitted data, consolidating data into

orders, and sending and viewing the status of reminders. The data access layer includes

the order history and the reminder and message history. The reminder and message

history will be described further in 4.4. The order history will consist of a database that

exists on the cloud with the other Breadcrumb databases and be easily accessible by the

Breadcrumb system when it is functioning in the online mode. The order history database

is where all requests and orders in all of their various edited forms will be stored for

analysis. Over time the system will recognize data patterns and be able to predict and

suggests orders and requests to the users. The following diagram displays the system’s

architecture:
4.4. Communications Interfaces

This product will be able to send emails to preloaded email addresses outside of the

system associated with user accounts or vendors in order to export orders and other data.

This product will also allow for communication through a system messaging system. The

messaging system will be available to upper management, such as the Citrus Orderer, to

send reminders to employees. This messaging system data will exist in the data access

layer, in the cloud.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

The system will perform best if it is connected to the internet and cloud database system

so that it can run in online mode. In the event that the system must run in offline mode,

data will be temporarily stored on the hardware’s drive until the system comes back

online and the data can be uploaded as a batch to the cloud.

5.2 Security Requirements

Security concerns include data stored on the cloud and user access levels. Although most

of the COS data that will be stored on the cloud system will not contain sensitive

information, the data is important enough to require that it is protected to ensure that it is

not deleted or compromised. A lesser security concern is user access and authentication.

Breadcrumb identifies its users by a 4 digit PIN. The 4 digit PIN is associated with

various jobs or roles that have varying levels of system access. If an employee finds out

another employee’s PIN they can potentially access areas of the system that they

normally would not have authority to access. This can be fixed by continuously changing

user PIN numbers, which is a solution that is currently in use within the company.