3 pages

CSC 480 A/B

Computer Science Project

Professor Jeffrey Appel

Software Requirements Specification

For

7 January 2016

Prepared for:

Grand Ole BBQ y Asado

The purpose of this SRS is to identify the requirements and specifications for the BBQ Dash application, as well as initiate collaboration efforts between DPC and the managing team of the Grand Ole BBQ y Asado, the client.

The intended audience of SRS document is the managing and operation team of the Grand Ole BBQ y Asado and the Digital Pit Crew who will evaluate the design, documentation, and the BBQ Pit system prototype.

The BBQ dash will consist of the following modules:

• Dashboard GUI.

• Temperature Monitoring System.

• Temperature Alarm.

• Logging and Data Display.

• Mobile Application.

• Web Services

The BBQ Dash will allow the operation crew of the Grand Ole BBQ y Asado to accurately monitor the temperatures inside the cooking environment as well as the internal temperatures of the meat. The system will provide data logging and processing, and alarms based on user-defined thresholds. The software will provide the information and alarms only. It will not control the temperatures or adjust it.

The objective of BBQ dash is to replace the unreliable solution that is currently used by the operation team of the Grand Ole BBQ y Asado, where baby monitors are used to keep track of the temperatures. The BBQ dash will bring a number of benefits to the customer. The owner and operators will be able to spend more time in the front of the restaurant, interfacing with customers, rather than repeatedly going to the back of the building to check the pit temperatures. A dashboard GUI will show the current temperature values for different temperature zones of each BBQ Pit. It will also display how close internal meat temperature is to being finished. An alarm will warn the cooking staff if the temperature changes above or below determined limits, or if the internal meat temperature has risen to the point that it is finished cooking. The product is intended to increase the efficiency of cooking operations and thus overall the productivity of the business.

Android: Google’s Linux based mobile device operating system.

BBQ Pit: A cooking unit used to hold a fire and deliver mild heat to food items over an extended time period. Each Pit has one or more levels, and each level has one or more cooking zones.

Pit Master: Person in charge of monitoring fire and food temperatures inside the BBQ Pit.

Raspbian Linux: "Raspbian is a free operating system based on Debian optimized for the Raspberry Pi hardware." (Welcome to Raspbian)

Temperature Sensor: "A temperature sensor is a device... that provides for temperature measurement through an electrical signal." (Trerice)

APP        Mobile Software Application

BBQ        Barbeque

DBMS        Database Management System

DPC         Digital Pit Crew

GUI           Graphical User Interface

HTTP       Hypertext Transfer Protocol

iOS        Apple’s mobile device operating system

LAN        Local Area Network

RBPI        Raspberry Pi computing platform

SRS         Software Requirement Specifications

TCP/IP    Transport Control Protocol / Internet Protocol

WLAN        Wireless Local Area Network

Pressman, R. (2010). Software engineering: A practitioner's approach (7th ed.). New York: McGraw-Hill Higher Education.

Trerice (2001). What is a Temperature Sensor? Retrieved on December 12, 2015 from http://www.cpinc.com/Trerice/Temperature/63%20-%2064%20temperature.pdf

Wira, W., Kosko, M., Shafer, M., Stepro, J. (2015) Operational Concept Document. Unpublished manuscript, Department of Computer Science, Information and Media Systems, National University, La Jolla, CA.

Wira, W., Kosko, M., Shafer, M., Stepro, J. (2015) Software Program Management Plan. Unpublished manuscript, Department of Computer Science, Information and Media Systems, National University, La Jolla, CA.

Microchip MCP3004/3008 Datasheet. (2008). Retrieved on December 26, 2015 from http://ww1.microchip.com/downloads/en/DeviceDoc/21295d.pdf

Understanding The FCC Regulations For Low-power, Non-licensed Transmitters. (1993). Retrieved on December 26, 2015 from https://transition.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet63/oet63rev.pdf

Welcome to Raspbian. (n.d.). Retrieved on January 4, 2016 from https://www.raspbian.org

The SRS is divided into three sections: 1.) Introduction, 2.) Overall Description, and 3.) Specific Requirements.

The Introduction gives an overview of the SRS document and contain following sections: Purpose (1.1), Scope (1.2), Definitions, Acronyms and Abbreviations (1.3), References (1.4), and Overview (1.5).

The Overall Description section describes general factors that affect the product and its requirements and it covers the following topics: Product Perspective (2.1), Product Functions (2.2), User Characteristics (2.3), Constraints (2.4), Assumptions and Dependencies (2.5), and Apportioning of Requirements (2.6).

The Specific Requirements section covers in more detail the specifications required for the design and testing of the BBQ dash product. It covers the sections of External Interfaces (3.1), Functions (3.2), Performance Requirements (3.3), Logical Database Requirements (3.4), Design Constraints (3.5), Software System Attributes (3.6) and Organizing the Specific Requirements (3.7).

The BBQ Dash is a supplemental system to our clients BBQ Pit infrastructure that is already in place. It will operate as a stand-alone system that takes input from the BBQ pit, stores measured values in a DBMS, and outputs information to an end user via a GUI.

The BBQ Dash Temperature Monitoring System receives temperature data from the customer’s BBQ Pits. Temperature data are saved to a database of a DBMS. Remote GUIs send requests and receive reply data concerning specific pit temperatures via the client’s wireless data. The temperature data sent to the remote GUIs may contain multiple temperature sensor sources and also the air temperature at the client's location.

Figure 2.1.1: Block Diagram for BBQ Dash System

Not applicable, as BBQ Dash is a stand-alone product.

The BBQ Dash will have two potential User Interfaces. The user can interact with the product through the GUI interface of a web portal, or the GUI interface of a handheld device. The GUI of the APP will have the same data as the web application but will be displayed in a more compact format layout due to the space restriction.

The data presented on the web interface will be available in tabular as well as graphical format, while on the mobile app it shall be only be shown in tabular format. Updating one format should cause the other presentations to be updated as well.  The controls for starting, resetting and stopping the application will be available via programmable function keys.

The Alarm area of the interface will display a message depending if the cooking environment temperatures are within the determined limits. If the temperatures exceed the required upper or lower limits, the Alarm message along with the Alarm signal will be issued.

The BBQ Dash system requires temperature sensor readings to be processed and communicated to external devices of varying platforms. As a result, there are a number of hardware interfaces that require definition.

The data acquisition function of BBQ Dash requires an interface between the software product and the Raspberry Pi hardware platform, which processes signals from multiple temperature sensors.  The software will monitor Raspberry Pi ports that are connected to temperature sensors.

A second hardware interface is required to communicate temperature data from the software running on Raspberry Pi to a BBQ Dash UI. The UI can be hosted on multiple wired and wireless platform devices, so therefore the information from Raspberry Pi will be communicated using IEEE 802.11g/n protocol to the company’s wireless router.

Secondary devices will either be mobile devices or computer workstations. Software running on either iOS or Android will be connected using IEEE 802.11 g/n protocol to the company’s wireless router. Software on computer workstations running Windows or OSX can also be connected to the company LAN, either through IEEE 802.11 g/n to the wireless router or directly to the network through a wired Ethernet connection.

BBQ Dash software will require communication with a data management system. This system will be used facilitate storage and retrieval of temperature data readings for different BBQ Pit zones. Temperature data points will consist of temperature value, current time, and zone of BBQ Pit.

Software will also need to interface with a web server, so that processed temperature data can be distributed to remote clients. The web server will run on Raspbian Linux, and software will write data files that the server can distribute.

Remote clients are a key part of the BBQ Dash system.  For iOS devices, DPC will develop an APP that is compatible with iOS 9.0. For Android devices, DPC will develop an APP that is compatible with the current Android OS.

DPC will also write software that interfaces with web browsers. The interface will be compatible with a wide range of web browser applications, such as those hosted on Windows, Mac and Linux-based operating systems.

The user of BBQ Dash will communicate with project units by using either Ethernet or IEEE 802.11 g/n wireless access to a Local Area Network (LAN).  All devices involved in the BBQ Dash suite will have network capability.  These interfaces will directly or indirectly utilize the Hypertext Transfer Protocol (HTTP) to access BBQ Dash information.

BBQ Dash will use TCP/IP to communicate statistical information via the Customer’s Intranet using WLAN or LAN utilizing the Ethernet interface. The computer peripherals shall interface with the General Purpose Input/Output pins, USB interface, or HDMI port. Preferably, the USB interface shall interface all peripherals of the system not directly involved in data acquisition.  All data acquisition peripherals will make use of the General Purpose Input/Output interface.

Memory requirements for long-term storage are anticipated to be small.  All devices selected for use on this project are produced at the factory with an adequate amount of RAM and physical memory; constraints due to memory storage are not expected within the scope of this project.

The BBQ Dash is a self-contained and independent design product. BBQ Dash shall be running and available to the users 24 hours a day and 7 days a week except during regularly scheduled maintenance. It is not necessary to operate BBQ Dash for any specified frequency. Backups shall be scheduled on regular bases in order to avoid lost data and system recovery due to power failures and mishaps.

The temperature monitoring system will need to be waterproof and UV resistant to protect the system from weather, since the customer’s BBQ pits on location are located outside. Placement of the system will also be chosen to limit direct sunlight and interference with employee operations.

This GUI will present relevant temperature data. It will show the current temperature data in various zones of an individual BBQ pit, as well as average temperatures among all pits currently in use. Internal meat temperature information will also be available, and the dashboard will show how close each piece of meat is to a desired “optimal” temperature.

This hardware solution will allow temperature monitoring in the pit, and as well as the value of any food thermometers. Temperature sensors that are used as a part of this system will be used to measure either air temperature in a BBQ Pit, or the internal temperature of meat as it is cooking.

An alarm will be raised when a BBQ Pit zone's temperature is out of range, or when meat is at optimal internal temperature. The definitions for “out of range” and “optimal” will be made by restaurant management, and set in the BBQ Dash software by the System Administrator of DPC, or the customer.

Temperature sensor values will be stored over time in a DBMS and accessible for future reference. Temperature plots over time can be generated from this data.

This app will show the dashboard GUI on a handheld device. It will be require access to the customer’s intranet through its WLAN to function correctly.

The dashboard GUI will be accessible through a web site. The website will be hosted at the customer’s site, and available through the company intranet.

Users of BBQ Dash product fall into following categories: cooking personnel, managers and administrator. Cooking operators will be the primary users of the product. They should possess basic knowledge in computer usage as well as handheld devices.

The managers will use the program in order to monitor the setup performance making sure the cooking personnel is operating the system correctly. Both the cooking personnel and restaurant managers will be given 3 hours of operational training on this product in order to become familiar with all its features. And administrator is the user whose function is to perform maintenance of the BBQ Dash to make sure the product’s functions are performed correctly according to the specification.

The BBQ Dash design and implementation effort is inhibited by the constraints that apply to hardware limitations, interfaces to other applications, parallel operation, and control functions. DPC has identified the following constraints:

• Limited time of three months to complete project. Due to the nature of the project, the development effort is constrained by the limited time that can be applied.

• Limited budget. The development effort is constrained by the limited amount of funds available to the Digital Pit Crew.

• BBQ Dash will only work correctly when a WLAN network is available for DPC hardware.

• BBQ Dash system can only be operated properly after customer received training from DPC.

• BBQ Dash prototype can only be setup and tested when customer provides DPC with access to BBQ Pits.

• Customer must have a Desktop computer or mobile device on the company LAN for access to DPC’s BBQ Dash software application.

• DPC won’t build a DBMS for BBQ Dash, only a database within an existing DBMS system.

• DPC won’t create a web server for BBQ Dash. DPC will instance an existing web server and construct custom elements.

In order to provide a complete, robust and reliable solution for its client, DPC has made the following assumptions:

• DPC assumes it will have exactly three months to complete the prototype for the BBQ Dash.

• DPC assumes it will pay for up-front costs to prototype the BBQ Dash.

• Customer will have a WLAN available for DPC hardware to interface.

• Users will have experience using web browsers on a computer, or mobile applications on iOS or Android devices.

• Customer will agree to receive training from DPC before operating BBQ Dash system.

• Customer will provide DPC with necessary access to setup and test the BBQ Dash system.

• Customer has a Desktop computer or mobile device on the company LAN that can be used to access DPC’s BBQ Dash software application.

• DPC will be able to identify and utilize a DBMS, with which it can create and access a database.

• DPC will be able to identify and utilize a web server, which it can instance and use to share custom elements.

Development of BBQ Dash depends on the following:

• DPC requires three months to complete the prototype for the BBQ Dash.

• The budget of BBQ Dash is small as it is sourced from members of DPC. As such, functionality cannot increase past the current indicated processes to be included in BBQ Dash.

• BBQ Dash requires a WLAN network for DPC’s hardware to interface with customer devices.

• BBQ Dash is dependent on operation and maintenance by trained individuals. Proper usage is dependent on the customer accepting training from DPC.

• DPC is dependent on customer-provided access to its BBQ Pits and devices to setup and test out system.

• BBQ Dash will only be accessible to users through a web browser and mobile apps running on IOS or Android mobile devices.

• BBQ Dash interface requires a Desktop computer or mobile device on the company LAN so the customer can access DPC’s software application.

• DPC requires a DBMS that it can utilize, so that it can create a database for BBQ Dash.

• DPC requires web server that it can utilize for BBQ Dash.

BBQ Dash has some features that will be deferred until the enhanced version of BBQ Dash. These features include:

• Dashboard GUI will be made available over the Internet to authorized users. In contrast to the modest version of the Dashboard GUI, which will only be available over company intranet, this feature will allow users to monitor BBQ Pits from anywhere in the world.

• Dashboard GUI display will vary based on time of day or environment. Our customer's BBQ Pits are located outside; therefore the environment can change throughout the day. With this feature, the display color and contrast of the GUI will change depending on the brightness of the surrounding area, so it will be easier to read.

• BBQ Dash will automatically control temperature inside a BBQ Pit, using a fan. This feature will allow BBQ Dash to adjust the temperature inside the BBQ pit if it deviates from the specified range. It will require changes to the hardware component of the product.

• Streaming video of meat cooking in BBQ Pit. This feature will take advantage of a camera feed from inside a BBQ Pit, and stream the video in real-time to the Internet. Our customer could allow the public to view this stream, and use it as part of their restaurant promotion.

1. Name of item:  Dashboard

1. Description of purpose:  The dashboard is the primary means for the user to specify a preferred way to view temperature data, and for the system to present acquired data to the user.

1. Source of input or destination of output:  The user shall make choices on data views by using the mouse or keyboard on a desktop platform, or by finger press and selection on a mobile device.  Data that shall be presented to the user by the system shall be displayed on PC screen or mobile device display.

1. Valid range, accuracy and/or tolerance:  GUI shall only show temperature data to an accuracy of a whole degree.  User input accuracy and tolerance is handled by each OS’s built in user input schemes.  

1. Units of measure:  Not Applicable

1. Timing:  Timing is not critical for the Dashboard GUI, however latency exceeding 5 seconds shall be suppressed.

1. Relationships to other inputs/outputs:  The Dashboard GUI shall display data gathered through temperature sensing.

1. Screen formats/organization:  Dashboard GUI shall have several different screen views available to the user:

Overview of all BBQ Pit temperatures shall show temperatures of all BBQ Pit temperatures.

Overview of one BBQ Pit temperature shall show the temperature of one BBQ Pit temperature, as well as a graph of the average temperature of the Pit over the course of the day.

Detailed view of all Zone temperatures in one BBQ Pit shall show temperatures of all Zones in a BBQ Pit, as well as a graph of the average temperature of the Pit over the course of the day.

Detailed view of one BBQ Pit Zone temperature shall show temperature of one Zone in a BBQ Pit, as well as a graph of the Zone temperature over the course of the day.

1. Window format organization:  This system shall use a main window split with a notification panel window underneath.

1. Data formats:  Textual data will be presented in standard block fonts using plain English language phrases.  Numeric data shall be presented using the Arabic numeral system.

1. Command formats:  Issuing commands shall follow this format: “Input/Select, Actuate, Confirm” method.

1. Name of item:  Temperature Monitoring System

1. Description of purpose:  This system translates physical sensory data to digital format for use by the Raspberry Pi.

1. Source of input or destination of output:  Sensory data from the DAQ hardware is input to the software system through the Raspberry Pi’s General Purpose Input and Output Pins.  Control signals issued by the software system originate at the GPIO pins on the RBPI and are received by the DAQ hardware.

1. Valid range, accuracy and/or tolerance:  The valid range of data is an integer between 0 and 1024.  Accuracy shall be limited to the resolution of the 10-bit DAC.  Temperature accuracy shall be to nearest whole number.  Tolerance shall be plus or minus half of a degree.

1. Units of measure:  Temperature data shall be presented to the user in degrees Fahrenheit.  

1. Timing: Each measurement should take less than one second.

1. Relationships to other inputs/outputs:  The temperature monitoring system stands alone and does not need user input during normal operation.

1. Screen formats/organization:  This module does not have a screen or graphical representation.

1. Window format organization:  This module does not have a screen or graphical representation.

1. Data formats:  Straight binary format at a 3.3V DC level shall be used to send data to and from the DAQ equipment.  

1. Command formats: Commands issued to the DAQ equipment shall follow the specifications outlined in the product data sheet provided by the manufacturer.

1. Name of item:  Temperature Alarm

1. Description of purpose:  The Temperature Alarm provides a visual and an auditory alert to the user when selected criteria depart from specification.

1. Source of input or destination of output:  Audio output shall be through the built in audio systems in mobile devices and through the sound port built into the RBPI.  Visual output shall be through graphic notification at the presentation level of the GUI.

1. Valid range, accuracy and/or tolerance:  Valid alert tones must be within the 300 Hz to 20 KHz audio ranges.  Alarm tones generated by the system shall interface aurally with the user.  This communication method requires little accuracy and has a wide tolerance for acceptable data due to the robust nature of the human hearing ability.

1. Units of measure:  Alert tones shall be measured in Hertz and Decibels.

1. Timing:  Alerts need to occur within 30 seconds of their occurrence.

1. Relationships to other inputs/outputs:  This module shall make use of the GUI to add alert content to the user’s presentation.

1. Screen formats/organization:  Alarm notifications on screen shall be in high contrast to surrounding text.

1. Window format organization:  Alarm messages shall not display in their own windows. They shall display in a notifications section of Dashboard GUI.

1. Data formats:  Audio alarm data shall be a series of flat pulses in the audio range.  Graphic alarm data shall be in the “Pit#, Probe#, Data Exception” format.

1. Command formats:  The only command required by the alarm system shall be acknowledgment of alerts.

Name of item:  Logging and Data Display

Description of purpose:  Delivers values and images of data representations, such as graphs, to user screen.

Source of input or destination of output: Out from the Data Display module shall be to the presentation level for the user on either a PC screen or mobile device screen as part of the Dashboard GUI.

Valid range, accuracy and/or tolerance:  Temperature data values shall be displayed as whole numbers.

Units of measure:  Temperature data values shall be displayed in degrees Fahrenheit.

Timing:  Data shall be transmitted to Dashboard GUI as determined by Dashboard GUI refresh policies.

Relationships to other inputs/outputs: Data values and image representations of data shall be embedded in Dashboard UI.

Screen formats/organization:  Temperature data values shall be displayed on Dashboard GUI on each screen. Image representations of data, such as graphs, shall be located in Dashboard UI section that displays detailed information on a BBQ Pit, or detailed information of a BBQ Pit Zone.

Window format organization:  Image representation of data shall not be displayed outside of Dashboard GUI.

Data formats:  Temperature data shall be sent to Dashboard GUI display as whole numbers. Image representations of data shall be sent in a compressed image format that is compatible with web browsing applications.

Command formats:  Not applicable for this module.

End message:  Not applicable for this module.

1. Name of item:  Mobile Application

1. Description of purpose:  APPs allow the BBQ Dash system as a whole to present an external portable interface to the user.

1. Source of input or destination of output:  APPs shall take tactile input from the user in the form of finger gestures.  They shall also take external inputs from the Wi-Fi network, which shall be carrying DAQ data from the RBPI.

1. Valid range, accuracy and/or tolerance:  Valid data that APPs handle shall vary only a small amount.  The primary mode of communication shall be textual over TCP/IP.  Using this method, a high degree of accuracy and a large tolerance for connectivity deficiencies present in mobile devices can be overcome with ease.

1. Units of measure:  Not applicable for this module.

1. Timing:  Latency over 5 seconds shall cause an alarm to be issued notifying the Dashboard GUI to present an error.

1. Relationships to other inputs/outputs:  The mobile apps shall interface bi-directionally with the Dashboard GUI, the Login Data module, the Temperature Alarm module, and the Temperature Monitoring module.

1. Screen formats/organization:  The screen format and organization for the mobile apps shall closely resemble the Dashboard GUI available to the desktop clients.  The mobile apps shall present data in a scalable format conforming to the physical shape of the presentation device.  A data item shall be presented to the right of the corresponding label.  Selectable items shall have pull down menus or radio buttons available to the immediate right.  Data shall be presented in a top down format.

1. Window format organization:  The mobile apps shall not make use of windows; the goal is to have a flat single page display.

1. Data formats:  Data input by the user shall be in string or Boolean types while data sent to RBPI clients shall be strings or integers encapsulated in TCP/IP packets.

1. Command formats: Issuing commands shall follow this format: “Input/Select, Actuate, Confirm” method.

1. End message:  Upon exiting, mobile apps shall return the host platform to their regular operating environment.

1. Name of item:  Web Service

1. Description of purpose:  Web service shall allow the RBPI to use HTTP traffic as its primary method of external interface.  It shall carry both data and control signals to and from the user and hardware.

1. Source of input or destination of output:  Web Service shall gather and supply data to the user via the RBPI network port.  In the planned configuration, Wi-Fi or Ethernet make no difference in network operation.  Inputs shall be from PC consoles or Mobile apps via the network interface.

1. Valid range, accuracy and/or tolerance:  Any correctly formed network traffic intended for use by the system shall be valid.  Accuracy shall be ensured by error correction in the TCP/IP protocol.  Tolerance for errors is wide because of the electronically slow nature of the DAQ process.

1. Units of measure:  Data moved through the network interfaces shall be measured by megabits per second for speed and megabits total for the amount of data moved.

1. Timing:  Network timing shall be in according with IEEE 802.11g/n and IEEE 802.3 for wired Ethernet clients.

1. Relationships to other inputs/outputs:  Mobile apps shall not function correctly without data from the Dashboard GUI.  Web services may convey erroneous data if the Temperature Monitoring System has a fault.  Web services shall not present data to clients that remain unauthenticated by the Login & Data module.

1. Screen formats/organization:  The screen format and organization for the Web Services shall make Dashboard GUI available to the desktop clients.  Web Services shall present data in a scalable web-page format conforming to the physical shape of the presentation device.  A data item shall be presented to the right of the corresponding label.  Selectable items shall have pull down menus or radio buttons available to the immediate right.  Data shall be presented in a top down format.

1. Window format organization:  The window format for Web Services shall vary depending on the client's choice of Web Browser.  Even though tabbed browsing is a standard on almost all modern browsers, BBQ Dash data shall be shown on single page to ensure quick user interpretation.

1. Data formats:  Data input by the user shall be in Boolean or string formats.  Data output by Web Services shall be in text encapsulated in HTTP data.

1. Command formats:  Issuing commands shall follow this format: “Input/Select, Actuate, Confirm” method.

1. End message:  Web services shall only present an end message when the system is told to shut down.  In this case, a typical “Are you sure you want to shut down?” message shall be presented to the user.  In cases where web browsers are simply directed away from Web Services, no message is necessary.

Necessary functions of BBQ Dash are identified based on the needs of the users of the system. There are two primary users of BBQ Dash. The first user is a Pit Master, who controls the restaurant’s BBQ Pits, and needs to monitor them. The Pit Master must know everything about the BBQ Pit, including the different levels, zones and temperatures in each pit. The second user is a System Administrator, who sets up the BBQ Dash system for use. The System Administrator's use cases define the number of BBQ Pits and Temperature Sensors in use at the restaurant.

Figure 3.2.1: Use Case Diagram for BBQ Dash System

The BBQ Dash function requirements are designed to facilitate both forms of usage of the BBQ Dash system.

For the Pit Master, function groups BBQ Pit, BBQ Level, BBQ Zone and Temperature Sensor shall handle reading information related to the different aspects of the customer's BBQ. There is a group for alarm functions, which can also have different implementations based on the local run-time environment. A Web Service group also exists to send relevant information to BBQ Dash UI.

For the System Administrator, function groups BBQ Pit, BBQ Level, BBQ Zone and Temperature Sensor shall also handle writing information related to the different aspects of the customer's BBQ.

The Temperature Sensor function group shall be used to read and process temperature information from the DBMS used by BBQ Dash. It shall also be used to place identifying temperature sensor attributes in the DBMS, read incoming temperature values, and store the values in the DBMS.

This function shall create an entry for this Temperature Sensor in data storage.

This function shall read data attributes of a Temperature Sensor from data storage.

This function shall update attributes of this Temperature Sensor in data storage.

This function shall create new data entries storing recent temperature values, time each entry was recorded, and temperature sensor source.

This function shall return the most recent temperature measurement in either degrees Fahrenheit or degrees Celsius.

This function shall return the last n temperature measurements for this sensor.

This function shall return temperature measurements of this sensor which were recorded during a given time range.

This function shall return the path to an image of a graph that displays the provided temperature measurements as a function of time.

This function shall return the role of the sensor, either “meat” for internal meat thermometer, or “air” for an ambient thermometer.

This function group shall be used to store and retrieve information regarding a BBQ Pit. Each BBQ Pit is composed of one or more BBQ Pit Levels.

This function shall create an entry for this BBQ Pit in data storage.

This function shall read data attributes of a BBQ Pit from data storage.

This function shall update attributes of this BBQ Pit in data storage.

This function shall return a list of all BBQ Pit Levels located in this BBQ Pit.

This function shall return the average temperature among all BBQ Pit Levels associated with this BBQ Pit.

This function shall return the highest temperature among all BBQ Pit Levels associated with this BBQ Pit.

This function shall return the lowest temperature among all BBQ Pit Levels associated with this BBQ Pit.

This function shall add a BBQ Pit Level to the list of BBQ Pit Levels associated with this BBQ Pit.

This function group shall be used to store and retrieve information regarding a BBQ Pit Level. Each BBQ Pit Level is composed of one or more BBQ Pit Zones.

This function shall create an entry for this BBQ Pit Level in data storage.

This function shall read data attributes of a BBQ Pit Level from data storage.

This function shall update attributes of this BBQ Pit Level in data storage.

This function shall return a list of all BBQ Pit Zones located in this BBQ Pit Level.

This function shall return the average temperature among all BBQ Pit Zones associated with this BBQ Pit Level.

This function shall return the highest temperature among all BBQ Pit Zones associated with this BBQ Pit Level.

This function shall return the lowest temperature among all BBQ Pit Zones associated with this BBQ Pit Level.

This function shall add a BBQ Pit Zone to the list of BBQ Pit Zones associated with this BBQ Pit Level.

This function group shall be used to store and retrieve information regarding a BBQ Pit Zone. Each BBQ Pit Zone has zero or more Temperature Sensors.

This function shall create an entry for this BBQ Pit Zone in data storage.

This function shall read data attributes of a BBQ Pit Zone from data storage.

This function shall update attributes of this BBQ Pit Zone in data storage.

This function shall return a list of all Temperature Sensors associated with this BBQ Pit Zone.

This function shall return the current temperature value of a given sensor in the BBQ Pit Zone.

This function shall make the alarm active if it is inactive.

This function shall make the alarm inactive if it is active.

This function shall display an alarm warning within the BBQ Dash web application. An alert sound shall also emit once when the alarm starts.

This function shall switch GUI view to All BBQ Pits (Simple data).

This function shall switch GUI view to One BBQ Pit (Simple data).

This function shall switch GUI view to BBQ Pit (Detailed Data).

This function shall switch GUI view to BBQ Pit (One Zone).

This function shall load All BBQ Pits (Simple data) data from web service.

This function shall load One BBQ Pit (Simple data) data from web service.

This function shall load BBQ Pit (All Zones) data from web service.

This function shall load BBQ Pit (One Zone) data from web service.

This function shall create a generic data container.

This function shall generate data holding latest values for All BBQ Pits (Simple data).

This function shall generate data holding latest values for one BBQ Pit (Simple data).

This function shall generate data holding latest values for BBQ Pit (Detailed data).

This function shall generate data holding latest values for BBQ Pit (One Zone).

This function shall store data to the proper location for the web service.

As stated in 3.2.1, there are two modes that the BBQ Dash system can be executed in: User mode and Admin mode.

User mode allows for monitoring of the BBQ Pits in use at a site. This state diagram illustrates the top four of the six Use Cases of the Pit Master in Figure 3.2.1.

Figure 3.2.8.1: State Diagram for User Mode of BBQ Dash System

BBQ Dash’s Admin mode provides setup tools for a site, allowing the user to properly identify the actual BBQ Pits and Temperature Sensors available for use. This state diagram represents all four Use Cases of the System Administrator in Figure 3.2.1.

Figure 3.2.8.2: State Diagram for Admin Mode of BBQ Dash System

While many of the use cases for BBQ Dash were illustrated through the state diagram, additional explanation is required for alarm handling. There are two types of alarms: alarm due to BBQ Pit air sensor, and alarm due to BBQ Pit internal meat sensor.

The sequence of events for a BBQ Pit air temperature alarm is shown below. When the allowable temperature threshold of the sensor is reached, an alarm sounds. The Pit Master then corrects the Pit temperature, resulting in a cancellation of the alarm.

Figure 3.2.9.1: Sequence Diagram for Air Sensor Alarm

The sequence of events for a BBQ Pit internal meat sensor alarm is shown below. When the allowable temperature threshold of the sensor is reached, an alarm sounds. The Pit Master then removes the meat from the BBQ Pit. When the meat is removed, the sensor temperature value decreases, resulting in a cancellation of the alarm.

Figure 3.2.9.1: Sequence Diagram for Internal Meat Sensor Alarm

For BBQ Dash to operate properly, this software must meet some performance requirements. These requirements are presented in the following subsections, and assume that the minimum hardware specified in section 2.1.3 is being used.

For system software attributes related to performance, please refer to section 3.6.5.

There are a total of four employees at Grand Ole BBQ y Asado & there are four members of the BBQ Dash team.  In a realistic setting, all eight users could possibly use physical terminals to access the Dashboard GUI.  In order to ensure non-blocking access, there shall be support for sixteen terminals.

The software shall receive sporadic amount of requests. Higher loads of requests shall be when the training of the new users is concluded. BBQ Dash must be capable to handle all the requests from the cooking personnel, managers and administrators, and there should be no pauses/delays between the time of a user-entered command and the system’s appropriate response. There are a total of four employees at Grand Ole BBQ y Asado & there are four members of the BBQ Dash team.  In a realistic setting, all eight users could possibly need support services provided by the Dashboard GUI.  Given this requirement possibility, the system shall be capable of handling the needs of no less than 16 users simultaneously.

The current BBQ Pit configuration at Grand Ole BBQ y Asado has a maximum of seven pits running simultaneously.  There are two levels per pit and also three zones.  This factor generates six measurement points over each pit.  That results in six measurements per second for each RBPI and 42 measurements per second distributed over the entire group of RBPIs.  When a theoretical sixteen users request all data from all pits to their individual Dashboard GUI, 336 transactions per second can be possible.  Each of these requests must be fulfilled within a certain time limit. The system is expected to respond to at least 97% of all requests in less than one second time period. It is only acceptable only 3% of all the user requests to take longer than one second. This may occur during unusually high usage periods.

BBQ Dash software shall require communication with a DBMS to facilitate the storage and retrieval of the temperature data readings for different BBQ Pit Zones. The Database in the DBMS shall have one entity to model a Temperature Sensor, and one entity, Temperature, to store temperature data. It shall also have three entities to model the BBQ Pit: Pit, Level and Zone.

Figure 3.4.1: Entity-Relationship Diagram

In each BBQ Pit, there shall be one or more temperature sensors to provide BBQ Dash with temperature data.  Each sensor shall have an attribute that stores its location in a BBQ Pit. A sensor shall also have an attribute that indicates how it is being used, either for measuring air temperature or internal meat temperature. There shall be an entity in the database to hold a sensor’s attributes, and an additional entity to store temperature readings.

A Temperature Sensor entry shall be made only when a new sensor is added to the BBQ Dash system. Temperature readings shall occur on a regular basis when the system is active. These entries shall be retained as long as restaurant management deems necessary.

Each BBQ Pit consists of several cooking levels, and each level has a number of cooking “zones” that meat can be placed at. Data entities shall include a BBQ Pit, BBQ Pit Level, and BBQ Pit Zone. Every BBQ Pit Level shall be part of exactly one BBQ Pit, and every BBQ Pit Zone shall be part of exactly one BBQ Pit Level. Additionally, each BBQ Pit Zone can hold multiple Temperature Sensors.

The database shall hold attributes for each BBQ Pit, so that they can be properly identified by the BBQ Dash system. The types of BBQ Pits shall be available to the BBQ Dash software.

BBQ Pit information, once entered, must be kept as long as temperature data associated with that Pit is to be kept. For a BBQ Pit entry to be preserved, but not show up in the BBQ Dash UI, there shall be a “retired” attribute that indicates whether the Pit is in or out of service.

We shall also need to provide the ability to produce reports. These shall include statistics of BBQ Pit temperatures over a certain time frame. We can also provide reports that shall help our client make business decisions, such as the amount of time the BBQ Pits are used per day, to indicate whether the site has enough (or too many) BBQ Pits in service. A report could also be generated to identify over time when a pit is holding heat less efficiently than others.

At the time of production of this document, there has been no formal reporting requirement expressed by customer.  More specifically, the BBQ Dash shall not be required to produce a formal and correctly formatted report that would be issued directly to any regulating authority.  In this aspect, there are no legal constraints.

Hardware design in the BBQ Dash DAQ hardware package is constrained by its operating voltage and interface bus (SPI).  The RBPI uses a 3.3-volt DC logic & core voltage; the MCP 3008 analog to digital converter also makes use of 3.3-volt DC logic signals.  These two units were specifically chosen to operate within this physical constraint.

DPC made the decision to use standard COTS IEEE 80.211n Wi-Fi for wireless communications between remote units. An alternative would be to use custom-built communication devices, but these would require approval and inspections to ensure compliance with regulation constraints imposed by the FCC (FCC, 1993).  None of the COTS equipment or programming used in the BBQ Dash causes the Wi-Fi transmitters to deviate from their original equipment operating characteristics thusly staying within regulation.

The following information should be taken into consideration while discussing compliance standards:

• Due to the nature of the business this to which this product is aimed, it complies with no formal reporting formats.  Currently, there are no formal reporting formats imposed on the BBQ Dash by the customer or any government agency.

• Currently, there are no data naming conventions imposed on the BBQ Dash by the customer or any government agency.

• To date, neither the customer nor any government agency has imposed accounting procedures on DPC for the BBQ Dash.

• Currently, there are no formal audits planned for the BBQ Dash by the customer or any government agency.  Formal audits and audit tracing do not apply to this product.

In contrast to the list of compliance standards, the following self-imposed standards are in place:

• Engineering best practices shall be used in the design of all hardware components of this product.

• Programming best practices shall be used in the design of all software components of this product.

• The American Psychological Association documentation standard shall be applied to all literature developed.    

The system will be used extensively during the regular hours of business operation.  The data provided by BBQ Dash devices shall be used for cooking operation and maintained in the database for specified amount of time. Necessary training shall be provided to the cooking personnel and management team in order to operate the product correctly and efficiently. Instructions of product operation shall be provided in the user manual.

All testing procedures shall meet the testability standards of the development team, and shall be determined and performed by DPC. The customer has no testability requirements. Properly testing specified in the testing plan shall be performed prior the product delivery.

BBQ Dash system shall be highly modifiable, which shall allow for extension of functions and capabilities for future releases. Some portions of the system, such as user interface, might require future modifications as new functionality is added and the changes to the source code are made. Changes can be made to the code or through addition of libraries at compile time. Only a DPC developer can make changes to the system.

User level access shall be available after the BBQ Dash web service is operational. If the service is hosted on a device that is connected to the customer's intranet, it should be available 30 seconds to one minute after being started.

System recovery should take no more than five minutes per piece of DAQ hardware.  Physical replacement of a memory module makes recovery quick and simple.  Recovery time includes rebooting the system.  During this period the system shall not be available.

Rebooting of the system may be conducted as required, but typically shall not be necessary.  The nature of operation for this system includes a fresh start up of bare metal hardware each time it is setup.  In this case, boot time for each piece of DAQ hardware is typically 30 seconds, unless a network interruption occurs.

For the client to receive benefit from the application, BBQ Dash must be highly reliable and available for use when needed. The mean time between failures of the application shall be at least fifty days. The downtime of the application shall not exceed six hours per year.

A User account with admin access to the system shall be required to make changes to operating system configurations.  This is controlled through the account setup routine handled by the OS, and regulated by username and passwords.  

Access to the network where BBQ Dash hardware operates shall be controlled by the use of pre-shared keys.  Pre-shared keys shall only be issued to network clients deemed acceptable by BBQ Dash developers and the staff at Grand Ole BBQ y Asado.

APPs shall be designed to only allow mobile users access to non-critical OS components.  APPs shall operate in a passive nature with no designed intent to make OS changes on the server.

The BBQ Dash shall be a reliable system that is tolerant of intermittent connections between individual components.  The system services shall continue to be provided as long as core DAQ equipment is available to provide the data.

BBQ Dash software shall be used on computers and mobile devices with currently available operating systems at the time of the start of the project. BBQ Dash shall be created so that platform-specific portions of software are contained in as few sections as possible. These sections shall be properly identified in design and maintenance documents.

The product, by design, shall be portable and should require minimal effort to use on any system that meets the specified software and hardware requirements.