Systems Requirement Specifications

Department of Computer Science and Engineering the University of Texas at Arlington Systems Requirement Specifications BehindtheCurtain Enterprises Project Team Members: Kyle Burgess Kyle Crumpton Austen Herbst Bilal Nawaz Jason Sprowl Last Updated: 11/8/2012 6:00pm

Table of Contents Document Revision History...5 List of Figures...6 List of Tables...7 1. Introduction, Scope, and Requirements Definition...8 1.1 Introduction...8 1.2 Scope...8 1.3 Requirements Definition...8 2. Product Concept...10 2.1 Purpose and Use...10 2.2 Intended Audience...10 3. Product Description & Functional Overview...11 3.1 Functions and Features...11 3.2 Product Interfaces...13 4. Customer Requirements...14 4.1 Read Data from CAN BUS...14 4.2 Profile Each Run...14 4.3 Bluetooth Capability...15 4.4 Mobile iphone App...15 4.5 Mobile Android App...16 4.6 Microcontroller Data Acquisition...17 4.7 Microcontroller Packaged Output...17 4.8 Interface to CAN BUS...18 4.9 Configuration Support Page...18 4.10 Multi-Gauge Graphical User Interface...19 4.11 App Consistency...19 4.12 Hardware Identification...20 5. Packaging Requirements...21 November 8, 2012 2 BehindtheCurtain Enterprises

5.1 User Manual...21 5.2 Secured Enclosure...21 5.3 Printed Circuit Board...22 5.4 Server Software...22 5.5 App Store Submissions...23 6. Performance Requirements...24 6.1 Real-Time Output...24 6.2 Reliable Data Transfer...24 6.3 Mobile Cross-Compatibility...25 6.4 Multi-threading...25 7. Safety Requirements...27 7.1 Secured Fastening...27 7.2 Electric Safety...27 8. Maintenance and Support Requirements...29 8.1 Support Future Mobile Operating System...29 8.2 Code Documentation...29 8.3 Testing...30 8.4 Maintenance Cutoff Date...30 9. Other Requirements...32 9.1 Statistics Database...32 9.2 User Accounts...32 9.3 Encryption of Web Traffic...33 9.4 Salt and Hash Passwords...33 9.5 Accurate Gauge Display...34 10. Acceptance Criteria...35 10.1 Verify that the mobile application GUI is user friendly...35 10.2 Verify that the mobile application sensor output is accurate...35 10.3 Verify that the ios and Android application versions are consistent and compatible...35 November 8, 2012 3 BehindtheCurtain Enterprises

10.4 Verify that the hardware enclosure is environmentally durable...36 10.5 Verify that data is carried over to the central server successfully...36 10.6 Verify that hardware module does not interfere with existing gauge...36 10.7 Verify that data is encrypted and decrypted correctly...36 10.8 Verify that user accounts are created correctly...36 10.9 Verify that the user manual meets customer standards...37 11. Use Cases...38 11.1 Start-Up...38 11.2 View Mobile Gauge User Interface...38 11.3 Calibrate Mobile App for Sensors...39 11.4 Start Run Profile Recording...40 11.5 View Recorded Race Profiles...41 11.6 Mobile App Login to Server...41 11.7 Manually Upload Recorded Runs to Server...42 12. Feasibility Assessment...44 12.1 Scope Analysis...44 12.2 Research...44 12.3 Technical Analysis...44 12.4 Cost Analysis...45 12.5 Resource Analysis...45 12.6 Schedule Analysis...46 13. Future Items...51 13.1 App Store Submissions...51 14. Referenced Documents...52 14.1 Internal Documents...52 14.2 Industry Standards...52 Appendix...53 List of Acronyms...53 November 8, 2012 4 BehindtheCurtain Enterprises

Document Revision History Revision Number Revision Date Description Rationale 0.1 10/11/2012 Initial Release Initial Draft of Document 1.0 10/30/2012 Version 1.0 Sponsor Suggestions Drafted 1.1 11/08/2012 Version 1.1 Baseline Draft November 8, 2012 5 BehindtheCurtain Enterprises

List of Figures Figure # Title Page # 3-1 System Overview 12 3-2 Product Interfaces 13 11-1 Start Up 38 11-2 View Mobile Gauge User Interface 39 11-3 Calibrate Mobile App for Sensors 40 11-4 Start Run Profile Recording 40 11-5 View Recorded Race Profiles 41 11-6 Mobile App Login to Server 42 11-7 Manually Upload Recorded Runs to Server 43 November 8, 2012 6 BehindtheCurtain Enterprises

List of Tables Table # Title Page # 3-1 External Inputs and Outputs 12 12-1 Cost Estimate 45 12-2 Function Point Estimation 46 12-3 Influence Multiplier 47 12-4 Size Estimation KLOC 48 12-5 Jones First Order Estimation 49 12-6 CoCoMo Coefficients 49 12-7 CoCoMo Calculations 49 12-8 CoCoMo vs. Jones First Effort Estimation 50 November 8, 2012 7 BehindtheCurtain Enterprises

1. Introduction, Scope, and Requirements Definition This section describes the overall purpose of this Systems Requirements Specification (SRS). 1.1 Introduction The purpose of this System Requirements Specification (SRS) document is to establish the functional requirements of project 1.2 Scope This document will cover both hardware and software requirements that have been designated by both BehindtheCurtain Enterprises and our sponsor, Redline Gauges. 1.3 Requirements Definition The purpose of this section is to outline what BehindtheCurtain Enterprises defines to be a good requirement. 1.3.1 Characteristics of a requirement All requirements should share the following characteristics: Unitary- The requirement should address one and only one thing. Complete- The requirement is fully stated in one place with no missing information. Consistent- The requirement does not contradict any other requirements. Non-Conjugated- The requirement should not be conjugated. Example: The postal code field must validate American and Canadian postal codes should be written in two requirement statements. Traceable- The requirement meets all or part of a business need as stated by the stakeholders and authoritatively documented. Current- The requirement has not been made obscure by the passage of time. Feasible- The requirement can be implemented within the constraints of the project Unambiguous- The requirement is concisely stated without recourse to technical jargon, acronyms, or other esoteric verbiage. November 8, 2012 8 BehindtheCurtain Enterprises

Specify Importance- The requirement must specify a level of importance. Verifiable- The implementation of the requirement can be determined through basic possible methods: Inspection, demonstration, test, or analysis. 1.3.2 Requirements Terminology The purpose of this section is to define the wording that will be used in our requirements document. Shall- The statement is a hard requirement. It is absolutely not negotiable, and the requirement statement must be met by the team. This corresponds to critical and high, levels 1 and 2, priorities. Will- There is intent by our team to meet this statement. This corresponds to medium, level 3, priority. Should- This word, or the adjective Recommended, means that there may be valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. This corresponds to low and future, levels 4 and 5, priorities November 8, 2012 9 BehindtheCurtain Enterprises

2. Product Concept This section describes the overall concept of the by giving a brief and concise description of the purpose, audience, and proper use. 2.1 Purpose and Use The is an add-on module for a pre-existing gauge by CPC/Redline Gauges, a gauge that provides a digital display for all sensors of a racing vehicle. The existing CPC/Redline Gauge is targeted towards snowmobiles, but is useable with any racing vehicle so long as the vehicle has the required sensors installed. will add mobile app functionality to provide racers and maintenance specialists a tool for data logging, vehicle diagnosis, and real time stats feedback, for all existing sensors. 2.2 Intended Audience will be targeted towards snowmobile racers and maintenance specialists who already own or will purchase the CPC/Redline gauge. Since this is a high end accessory it will have a limited audience. November 8, 2012 10 BehindtheCurtain Enterprises

3. Product Description & Functional Overview This section provides the reader an overview of the system. The primary operational aspects of the product, from the perspective of end users, maintainers and administrators, are defined here. The key features and functions found in the product, as well as critical user interactions and user interfaces are described in detail. 3.1 Functions and Features is an add-on module for a pre-existing gauge by CPC/Redline Gauges. The existing gauge provides feedback from a variety of sensors on a racing snowmobile. will provide a mobile user interface with enhanced tools for data logging, vehicle diagnosis, and real time statistics. The interface will be available on both iphone and Android devices display an assortment of customizable gauges and have a configuration page, allowing the user to configure the gauge to his vehicles unique specifications. In order to populate the UI with data, the add-on module retrieves this data from the existing Controller Area Network (CAN) BUS, parses and reformats it. The module will then transmit it over the Bluetooth connection, to the mobile device, in real time. The mobile device will also connect to a remote database server over its wireless data connection (Wi-Fi or Cellular), when available. The device will then upload pre-recorded statistics to the server for storage, further analysis, and manipulation. Figure 3-1 provides a graphical overview of how the system is interfaced with the existing CPC/Redline Gauge. November 8, 2012 11 BehindtheCurtain Enterprises

System Overview Figure 3-1 External Inputs and Outputs Name Description Use CAN BUS Data Stream Data stream between the existing Gauge Display and Remote Sensor Module Read sensor data from the existing stream to be interpreted by the add-on module Bluetooth Link Wireless Data Connection Short range wireless connection on the mobile device and add-on module Wi-Fi/Cellular connection on the mobile device Connects the add-on module to the mobile device for data exchange Connects the mobile device the remote database server to upload statistics User Interface Mobile applications on iphone and Android Will provide the user with options to adjust the UI view and settings Table 3-1 November 8, 2012 12 BehindtheCurtain Enterprises

3.2 Product Interfaces Figure 3-2 provides a mockup of the user interface on an iphone. There will also be a nearly identical user interface developed for Android devices. These mobile devices will connect to the add-on module via Bluetooth link and to the web server via wireless data connection. Product Interfaces Figure 3-2 November 8, 2012 13 BehindtheCurtain Enterprises

4. Customer Requirements This following section will detail the existing customer requirements. They should clearly define the restrictions and expectations set forward by the customer, and give a clear definition of what the end product will be capable of performing. Some of these requirements are, but not limited to: reading data from a CAN bus line, profiling each racing run, creating a configuration page for the mobile device, and using microcontroller data acquisition and packing. 4.1 Read Data from CAN BUS 4.1.1 Description: Our product shall have a hardware module that will read its data from the existing gauges CAN BUS line. 4.1.2 Source: Redline Gauges 4.1.3 Constraints: 4.1.4 Standards: CAN BUS 2.0B by Bosch 4.1.5 Priority: 1-Critical 4.2 Profile Each Run 4.2.1 Description: Our product shall be able to record all of the data transferred to the cellular device. The gathered data shall be displayed to the user in a very visually satisfying fashion. 4.2.2 Source: Redline Gauges November 8, 2012 14 BehindtheCurtain Enterprises

4.2.3 Constraints: Storage space on phone. 4.2.4 Standards: 4.2.5 Priority: 1-Critical 4.3 Bluetooth Capability 4.3.1 Description: The hardware module shall have Bluetooth capability to transfer the data from the module to the phone. 4.3.2 Source: Redline Gauges 4.3.3 Constraints:. 4.3.4 Standards: Bluetooth V3.0 4.3.5 Priority: 1-Critical 4.4 Mobile iphone App 4.4.1 Description: Since we are using an iphone as one of our supported devices, we shall write an app in objective C that reads the transmitted data from the Bluetooth module, processes the data, and displays the information to the user in a visually stimulating fashion. If there is a cellular connection to the internet at the racing site, the Bluetooth connected phone shall transmit the already packaged data to a centralized server where other November 8, 2012 15 BehindtheCurtain Enterprises

cellular devices with the app installed can also obtain the same data and visuals at a reduced delay time. 4.4.2 Source: Redline Gauges 4.4.3 Constraints: Only writing app for the newest ios version. 4.4.4 Standards: IMT2000/3G, Bluetooth V3.0 4.4.5 Priority: 1-Critical 4.5 Mobile Android App 4.5.1 Description: Since we have an Android as one of our supported devices, we shall write an app in Java that reads the transmitted data from the Bluetooth module, processes the data, and displays the information to the user in a visually stimulating fashion. If there is a cellular connection to the internet at the racing site, the Bluetooth connected phone shall transmit the already packaged data to a centralized server where other cellular devices with the app installed can also obtain the same data and visuals at a reduced delay time. 4.5.2 Source: Redline Gauges 4.5.3 Constraints: Only writing app for Jellybean OS. 4.5.4 Standards: Bluetooth V3.0 4.5.5 Priority: November 8, 2012 16 BehindtheCurtain Enterprises

1-Critical 4.6 Microcontroller Data Acquisition 4.6.1 Description: Our hardware module shall have a microcontroller that reads the data in from the existing CAN BUS line. 4.6.2 Source: Redline Gauges 4.6.3 Constraints: Microcontroller clock speed. 4.6.4 Standards: 4.6.5 Priority: 1-Critical 4.7 Microcontroller Packaged Output 4.7.1 Description: After the microcontroller has received the data from the CAN BUS line, it shall process and put the data into packages that can be sent to the Bluetooth transmitter for data transmission. 4.7.2 Source: Redline Gauges 4.7.3 Constraints: Microcontroller clock speed. 4.7.4 Standards: 4.7.5 Priority: November 8, 2012 17 BehindtheCurtain Enterprises

1-Critical 4.8 Interface to CAN BUS 4.8.1 Description: shall have a hardware interface that can tap into the existing line. 4.8.2 Source: Redline Gauges 4.8.3 Constraints: Can t interfere with current system. 4.8.4 Standards: CAN BUS 2.0B by Bosch 4.8.5 Priority: 1- Critical 4.9 Configuration Support Page 4.9.1 Description: shall have a user configuration page where they can input the same user inputs. 4.9.2 Source: Redline Gauges 4.9.3 Constraints:. 4.9.4 Standards: 4.9.5 Priority: November 8, 2012 18 BehindtheCurtain Enterprises

2-High 4.10 Multi-Gauge Graphical User Interface 4.10.1 Description: The cellular devices shall have an appealing user interface that supports all existing sensor displays on the existing gauge. The user interface shall be able to display multiple gauges per screen to accommodate for the vast quantity of data we need to display. 4.10.2 Source: Redline Gauges 4.10.3 Constraints: Limited screen space on both phones. 4.10.4 Standards: 4.10.5 Priority: 2- High 4.11 App Consistency 4.11.1 Description: The two mobile application displays shall be nearly identical. 4.11.2 Source: Redline Gauges 4.11.3 Constraints:. 4.11.4 Standards: November 8, 2012 19 BehindtheCurtain Enterprises

4.11.5 Priority: 2- High 4.12 Hardware Identification 4.12.1 Description: Each hardware unit shall have a unique identification number so as to easily recognize a pairing when syncing with the app. 4.12.2 Source: Redline Gauges 4.12.3 Constraints:. 4.12.4 Standards: 4.12.5 Priority: 2- High November 8, 2012 20 BehindtheCurtain Enterprises

5. Packaging Requirements This section describes the packaging requirements for. Packaging requirements include a user manual, secured box to hold the system, server software, printed circuit board, and application store submissions. 5.1 User Manual 5.1.1 Description: The system shall be packaged with a user manual explaining how to use. 5.1.2 Source: BehindTheCurtain Enterprises 5.1.3 Constraints: 5.1.4 Standards: 5.1.5 Priority: 1 Critical 5.2 Secured Enclosure 5.2.1 Description: The system shall be packaged with a secured enclosure which shall connect to the CAN Bus and hold the microcontroller which interfaces with the current standing system. 5.2.2 Source: BehindTheCurtain Enterprises 5.2.3 Constraints: Hardware and budget November 8, 2012 21 BehindtheCurtain Enterprises

5.2.4 Standards: Our product will follow the same standards of enclosure as specified by Redline Gauges: RG-ICD001 rev A 5.2.5 Priority: 2 High 5.3 Printed Circuit Board 5.3.1 Description: System will be delivered with a printed circuit board loaded with the embedded code to run. 5.3.2 Source: BehindTheCurtain Enterprises 5.3.3 Constraints: Budget and customer demand 5.3.4 Standards: 5.3.5 Priority: 3 Medium 5.4 Server Software 5.4.1 Description: will include server software to host documented races, users, and possibly statistics. 5.4.2 Source: BehindTheCurtain Enterprises 5.4.3 Constraints: November 8, 2012 22 BehindtheCurtain Enterprises

5.4.4 Standards: 5.4.5 Priority: 3 Medium 5.5 App Store Submissions 5.5.1 Description: should be made available to both Android market and the Apple ios App Store. 5.5.2 Source: BehindTheCurtain Enterprises 5.5.3 Constraints: Time and licensing requirements 5.5.4 Standards: 5.5.5 Priority: 4 - Low November 8, 2012 23 BehindtheCurtain Enterprises

6. Performance Requirements This section describes the performance requirements for. Performance requirements include real-time output, multi-threading, mobile cross-compatibility, and reliable data transfer. 6.1 Real-Time Output 6.1.1 Description: The system shall be able to transmit data over Bluetooth to be output to the mobile device. 6.1.2 Source: BehindTheCurtain Enterprises 6.1.3 Constraints: Reliable data transfer 6.1.4 Standards: 6.1.5 Priority: 1 Critical 6.2 Reliable Data Transfer 6.2.1 Description: The system shall have a high success rate on packet transfers. System should implement error detection, receiver feedback, and retransmission to the receiver. 6.2.2 Source: BehindTheCurtain Enterprises 6.2.3 Constraints: November 8, 2012 24 BehindtheCurtain Enterprises

6.2.4 Standards: 6.2.5 Priority: 1 Critical 6.3 Mobile Cross-Compatibility 6.3.1 Description: The application shall be cross compatible between multiple mobile devices. The most notable devices shall be the Android and ios. 6.3.2 Source: BehindTheCurtain Enterprises 6.3.3 Constraints: 6.3.4 Standards: 6.3.5 Priority: 2 Critical 6.4 Multi-threading 6.4.1 Description: The system should be multithreaded to insure high speed data acquisition. 6.4.2 Source: BehindTheCurtain Enterprises 6.4.3 Constraints: Limited microcontroller memory. November 8, 2012 25 BehindtheCurtain Enterprises

6.4.4 Standards: 6.4.5 Priority: 4 Low November 8, 2012 26 BehindtheCurtain Enterprises

7.1 Secured Fastening 7.1.1 Description: 7. Safety Requirements The system shall be securely fastened to the vehicle. 7.1.2 Source: BehindTheCurtain Enterprises 7.1.3 Constraints: Budget. 7.1.4 Standards: 7.1.5 Priority: 2- High 7.2 Electric Safety 7.2.1 Description: The system shall be packaged in such a way that there is no risk of electrical shock to the user. 7.2.2 Source: BehindTheCurtain Enterprises 7.2.3 Constraints:. 7.2.4 Standards: November 8, 2012 27 BehindtheCurtain Enterprises

Our product will follow the same standards of enclosure as specified by Redline Gauges: RG-ICD001 rev A 7.2.5 Priority: 2- High November 8, 2012 28 BehindtheCurtain Enterprises

8. Maintenance and Support Requirements This section describes the management and support requirements for the RG. It basically explains how the product will be maintained over the course of time and what type of support will be provided to ensure complete customer satisfaction. It also explains what measures will be taken to ensure that the product is still functional in the long run and that it can be modified and improved with ease in future. Once we are done with the final product, our next task will not be to add new features but to improve the existing features and make sure the existing program is error-free before moving on to advanced functionalities. 8.1 Support Future Mobile Operating System 8.1.1 Description: The mobile applications will be able to support future mobile OS. 8.1.2 Source: BehindtheCurtain Enterprises 8.1.3 Constraints: No knowledge of future mobile operating systems. 8.1.4 Standards:. 8.1.5 Priority: 3 Medium 8.2 Code Documentation 8.2.1 Description: Code shall be well documented with UML, use-cases, and comments detailing information regarding variables and methods. 8.2.2 Source: BehindtheCurtain Enterprises 8.2.3 Constraints: November 8, 2012 29 BehindtheCurtain Enterprises

. 8.2.4 Standards:. 8.2.5 Priority: 8.3 Testing 1 Very high 8.3.1 Description: Verification process shall include detailed unit and module tests covering every aspect of implementation. 8.3.2 Source: BehindtheCurtain Enterprises 8.3.3 Constraints:. 8.3.4 Standards:. 8.3.5 Priority: 1 Very high 8.4 Maintenance Cutoff Date 8.4.1 Description: Project shall be maintained through 05/2012. 8.4.2 Source: BehindtheCurtain Enterprises 8.4.3 Constraints: November 8, 2012 30 BehindtheCurtain Enterprises

8.4.4 Standards:. 8.4.5 Priority: 1 Very high November 8, 2012 31 BehindtheCurtain Enterprises

9. Other Requirements This section will basically specify anything else that is required for the product to be considered complete. It will contain requirements related to customer setup, configuration and accounts as they are not identified in a previous requirement. Requirements related to product architecture and design, such as modularity, extensibility, or alteration for a specific programming language will also be explained. Requirements such as portability of our source code to various platforms and how database will be used to in this project will also be addressed. 9.1 Statistics Database 9.1.1 Description: A remote server database will store the data gathered from the gauge sensors for later use. Driver will be able to look back at the mobile application and go through the statistics of race. 9.1.2 Source: BehindtheCurtain Enterprises 9.1.3 Constraints: 9.1.4 Standards: 9.1.5 Priority: 3 Medium 9.2 User Accounts 9.2.1 Description: The mobile application will allow users to create accounts and access race statistics and information. November 8, 2012 32 BehindtheCurtain Enterprises

9.2.2 Source: BehindtheCurtain Enterprises 9.2.3 Constraints: 9.2.4 Standards: 9.2.5 Priority: 3 Medium 9.3 Encryption of Web Traffic 9.3.1 Description: All web traffic between the mobile apps and central server should be encrypted. 9.3.2 Source: BehindtheCurtain Enterprises 9.3.3 Constraints: 9.3.4 Standards: RSA 1024 bit encryption will be used for the public key encryption algorithm. AES 128 bit will be used for the symmetric key encryption algorithm. 9.3.5 Priority: 4 - Low 9.4 Salt and Hash Passwords 9.4.1 Description: User passwords and sensitive details should be salted and hashed before being stored in server database. November 8, 2012 33 BehindtheCurtain Enterprises

9.4.2 Source: BehindtheCurtain Enterprises 9.4.3 Constraints: The server database needs to be configured to store user passwords. 9.4.4 Standards: SHA-2 should be the hash algorithm. 9.4.5 Priority: 4 - Low 9.5 Accurate Gauge Display 9.5.1 Description: Any gauge data being displayed shall be as accurate as existing gauge. 9.5.2 Source: BehindtheCurtain Enterprises 9.5.3 Constraints: 9.5.4 Standards: 9.5.5 Priority: 2 - High November 8, 2012 34 BehindtheCurtain Enterprises

10. Acceptance Criteria These acceptance criteria will be verified in the verification stage of project. These items are critical to the success to the project. The sponsor has requested verification for each of the following. 10.1 Verify that the mobile application GUI is user friendly 10.1.1 Requirement(s) addressed: 4.10- Multi Gauge Graphical User Interface 10.1.2 Verification Procedure: The GUI of the mobile application will be approved by the sponsor to verify user friendliness. 10.2 Verify that the mobile application sensor output is accurate 10.2.1 Requirement(s) addressed: 9.5- Accurate Gauge Display, 6.2- Reliable Data Transfer, 6.1- Real-time Output 10.2.2 Verification Procedure: The output displayed by the mobile application will be compared against the output of the existing gauge. 10.3 Verify that the ios and Android application versions are consistent and compatible. 10.3.1 Requirement(s) addressed: 6.3- Mobile Cross Compatibility, 4.11- Application Consistency 10.2.2 Verification Procedure: The sponsor will compare both applications for consistency. November 8, 2012 35 BehindtheCurtain Enterprises

10.4 Verify that the hardware enclosure is environmentally durable 10.4.1 Requirement(s) addressed: 5.2- Secured Enclosure 10.4.2 Verification Procedure: The hardware enclosure will be subjected to shock, heat, and water exposure tests. 10.5 Verify that data is carried over to the central server successfully 10.5.1 Requirement(s) addressed: 6.2- Reliable Data Transfer 10.5.2 Verification Procedure: The profiling data stored in the server will be compared against the profiling data saved in the mobile applications. 10.6 Verify that hardware module does not interfere with existing gauge 10.6.1 Requirement(s) addressed: 4.8- Interface with CAN Bus 10.6.2 Verification Procedure: The gauge will be tested with and without the hardware module to insure that output and function is not affected by the added hardware. 10.7 Verify that data is encrypted and decrypted correctly 10.7.1 Requirement(s) addressed: 9.3- Encryption of Web Traffic 10.7.2 Verification Procedure: The packets will be tested to make sure that they are the same before and after encryption. The encryption packets will also be tested to make sure that the data cannot be read from the encrypted data. 10.8 Verify that user accounts are created correctly November 8, 2012 36 BehindtheCurtain Enterprises

10.7.1 Requirement(s) addressed: 9.2- User Accounts 10.7.2 Verification Procedure: Test user accounts will be created and dummy data will be uploaded to each account. Then, the accounts will be tested to insure that the account can be accessed correctly and that the data is stored to the correct user account. 10.9 Verify that the user manual meets customer standards 10.9.1 Requirement(s) addressed: 5.1- User Manual 10.9.2 Verification Procedure: The sponsor will review the user manual and give feedback about whether the user manual is clear and easy to use. November 8, 2012 37 BehindtheCurtain Enterprises

11.1 Start-Up 11.1.1 Scenario 11.1.2 Actors: The user starts up the app User 11.1.3 Case Action 11. Use Cases Upon power up, the mobile device will search for existing hardware connection. If the connection exists, the mobile app will sync with the hardware module. If no connection exists, it will offer the user the option to setup a new device. Figure 11-1: AVALANCE Start-Up 11.2 View Mobile Gauge User Interface 11.2.1 Scenario November 8, 2012 38 BehindtheCurtain Enterprises

The app syncs with the hardware module, or with the server. 11.2.2 Actors User and Server 11.2.3 Case Action The app will display the main screen showing all applicable gauges. Figure 11-2: View Mobile Gauge User Interface 11.3 Calibrate Mobile App for Sensors 11.3.1 Scenario The user opens the settings panel or registers for the first time. 11.3.2 Actors User 11.3.3 Case Action They will be presented with a series of options to precisely adjust the sensors. November 8, 2012 39 BehindtheCurtain Enterprises

Figure 11-3: Calibrate Mobile App for Sensors 11.4 Start Run Profile Recording 11.4.1 Scenario 11.4.2 Actors The user will select Start Run within the mobile app prior to racing. User 11.4.3 Case Action The app will begin data logging and will store inputs at a rate of 8Hz. It will also store a time stamp for every logged entry so as to obtain a meaningful sense of time. Figure 11-4: Start Run Profile Recording November 8, 2012 40 BehindtheCurtain Enterprises

11.5 View Recorded Race Profiles 11.5.1 Scenario 11.5.2 Actors The user will be select Race Profiles within the app. User and Server 11.5.3 Case Action The user will be presented with a list of recorded profiles. The selected profile will either be loaded from the local device memory or downloaded the database server. Figure 11-5: View Recorded Race Profiles 11.6 Mobile App Login to Server 11.6.1 Scenario The device detects wireless connection. 11.6.2 Actors User and Server 11.6.3 Case Action November 8, 2012 41 BehindtheCurtain Enterprises

Upon hardware connection and detecting wireless signal, the mobile device will attempt to connect to the internet. The phone will be connected to the server where it will proceed to download/upload information. Figure 11-6: Mobile App Login to Server 11.7 Manually Upload Recorded Runs to Server 11.7.1 Scenario 11.7.2 User The user will open the run profiles panel within the mobile UI. User and Server 11.7.3 Case Action The user will then have the option to manually upload recorded runs to server. A connection will established with the server and data will be transmitted. November 8, 2012 42 BehindtheCurtain Enterprises

Figure 11-7: Manually Upload Recorded Runs to Server November 8, 2012 43 BehindtheCurtain Enterprises

12. Feasibility Assessment Feasibility assessment plays a critical role in assessing the probability of success for a given project. We at BehindtheCurtain Enterprises believe all stakeholders are entitled to know the risk involved in proceeding with the project. Therefore the critical analysis on the feasibility of each component of the project plays an important role in project planning. Feasibility involves an assessment of the following six components: scope analysis, research completed/remaining; technical analysis; cost analysis, resource analysis; and schedule analysis. 12.1 Scope Analysis We at BehindtheCurtain Enterprises feel that we will be able to fulfill all priority 1 and 2 requirements as specified in this SRS document. The more complex non-critical requirements surrounding the central server will require a more in depth understanding of the infrastructure of modern computer networks. We do not yet know if the requirements surrounding this aspect of the project will be feasibly accomplished during the given time period. Therefore all priority 3, and to a lesser extent, priority 4 requirements are planned to be developed after the critical and high priority components have been integrated into the system. 12.2 Research Because of the meetings with our sponsor so far, we have a working knowledge of the high level functions of the existing gauge. We also have researched into how the data will be transferred using Bluetooth. We also have researched into the development of both Android and ios applications. With the knowledge we have gained from our research and sponsor so far, we feel the basic concept of our project is entirely feasible. As a team we will need to research further into Bluetooth, embedded systems development, and GUI development. We will also need to look further into the networking challenges associated with the central server implementation. We also need to look into the finer functionality and workings of the gauge in order to plan how to interface our own embedded system with the existing gauge. 12.3 Technical Analysis There are several discrete technological aspects involved with the development of this racing gauge interface. Hardware design, embedded system development, mobile application November 8, 2012 44 BehindtheCurtain Enterprises

development, graphical interface design, computer network architecture, server software design, and database development. Managing the design and development of all disparate aspects of the projects will be a major hurdle for moving forward. The only feasible way to manage this is to make sure that the different aspects are split evenly between team members and roles. Our team has a diverse skill set and should be able to manage all the different technical challenges associated with the project including those listed above, and any challenges that may develop. 12.4 Cost Analysis The main cost associated with this project will have to deal with the hardware which we will interface with existing technology. The current plan is to actually design and develop a printed circuit board to integrate into an existing system. If budget does not allow for a full printed circuit board, a bread boarded prototype will be produced. Other costs are associated with licensing ios application development. All other costs should be considered to be time related instead of monetary-based. The following table gives a bare bones initial estimate of the potential costs associated with the project. This estimate is broken down into a both a low and high end cost estimate. Cost Estimates Component Low End Cost High End Cost Microcontrollers $60 $200 Bluetooth chip $80 $200 Hardware Enclosure $25 $100 Wiring and Connections $10 $20 Circuit Board $15 $100 App Store License $0 $100 Total $190 $720 12.5 Resource Analysis Table 12-1 BehindtheCurtain Enterprises team composition consists of two computer engineers (Kyle B, and Kyle C), two computer scientists (Austen, and Jason), and a single software engineer (Bilal). Hardware design and embedded system development will be designated to the two November 8, 2012 45 BehindtheCurtain Enterprises

computer engineers. Network architecture design and mobile application development will be handled by the two computer scientists. We have designated server software development to our software engineer. We have designated the task of coordinating information between us and the sponsor to Kyle Burgess, as the sponsor is his father. 12.6 Schedule Analysis Before agreeing to undertake this project, it is imperative that BehindtheCurtain Enterprises takes sufficient time to analyze the feasibility of our schedule given the high, middle, and low level priorities that have been established for this project. The three methods that we will use to demonstrate our projects feasibility are Functional Points, the COCOMO model, and Jones First Order Estimation. 12.6.1 Size Estimate Function Points The following table gives our estimation of the function points of the project. These will be used to estimate the length of the project. Function Point Estimation Program Characteristic Low Complexity Moderate Complexity High Complexity Function Point Totals Number of Inputs 2*3 4*4 0*6 24 Number of Outputs 1*4 0*5 3*7 25 Inquiries 2*3 2*4 0*6 14 Logical Internal Files External Interface Files 0*7 1*10 0*15 10 1*5 0*7 0*10 5 Unadjusted Function Points (UAF) 77 Adjustment Factor.99 Total 76 Table 12-2 November 8, 2012 46 BehindtheCurtain Enterprises

Influence Multipliers Characteristics Effort (1-5) Data Communications 5 Distributed Data Processing 1 Performance 5 Heavily Used Configuration 1 Transaction Rate 3 Online Data Entry 1 End User Efficiency 4 Online Update 1 Complex Processing 2 Reusability 2 Installation Ease 2 Operation Ease 3 Multiple Sites 1 Facilitate Change 3 Total 34 Value Adjustment Factor: 0.99 Adjusted Function Point: 77 *.99 = 76 Table 12-3 November 8, 2012 47 BehindtheCurtain Enterprises

12.6.2 Size Estimate Thousand Lines of Code (KLOC) To estimate the size of the project based on thousand lines of code (KLOC), we first broke down and estimated the size of each individual aspect of the project. The following table 12-4 gives a rundown of the size estimation for each component. Size Estimation KLOC Component Low Estimate High Estimate Microcontroller Software 2000 2500 (including hardware design effort) ios Application 2500 3000 Android Application 2500 3000 Server Software 1000 1500 Total 8000 10000 Table 12-4 November 8, 2012 48 BehindtheCurtain Enterprises

12.6.2 Effort Estimation Jones First Order Estimation The following table uses the function point from Table 11-1 to approximate the calendar month length of our project based on Jones First Order Estimation. We are basing our schedule on the best in class estimation and expect our project to take 6.44 calendar months. Jones First Order Estimation Worst In Class Average Best in Class 76.48 76.45 76.43 7.99 Calendar Months 7.02 Calendar Months 6.44 Calendar Months Table 12-5 12.6.3 Effort Estimation CoCoMo Table 12-5 gives a rundown in the coefficients used in CoCoMo calculations, while Table 12-6 gives our CoCoMo estimations for the project CoCoMo Coefficients Coefficient a b b b c b d b Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.2 2.5 0.32 CoCoMo Calculations Table 12-6 Effort PM [ E = a b (SLOC) b b ] Duration Months [ D = c b (E) d b ] Low Estimate E = 3.0 (8) 1.12 E = 30.8 PM D = 2.5(30.8) 0.35 D = 8.30 months High Estimate E = 3.0 (10) 1.12 E = 39.5 PM D = 2.5(39.5) 0.35 D = 9.05 months Final Estimate 8 months 9 months Table 12-7 November 8, 2012 49 BehindtheCurtain Enterprises

12.6.4 Effort Comparison CoCoMo vs. Jones First Order Effort Estimation Estimation Technique Low End High End Jones First Order 6.44 calendar months 7.99 months CoCoMo 8.30 months 9.05 months Average 7.37 months 8.52 months Table 12-8 November 8, 2012 50 BehindtheCurtain Enterprises

13. Future Items This section describes the future items for. Future requirements include a user manual, secured box to hold the system, server software, printed circuit board, and application store submissions. 13.1 App Store Submissions 13.1.1 Description: will be made available to both Android market and the Apple ios App Store. 13.1.2 Source: BehindTheCurtain Enterprises 13.1.3 Constraints: Time and licensing requirements 13.1.4 Standards: 13.1.5 Priority: 5 - Future November 8, 2012 51 BehindtheCurtain Enterprises

14.1 Internal Documents 14.1.1 CPC/REDLINE GUAGES: RG-ICD001 rev A. 14.2 Industry Standards 14. Referenced Documents In the event of a conflict between a referenced document and this document, the requirements in this document shall take precedent. 14.2.1 CAN BUS 2.0B by Bosch. http://hem.bredband.net/stafni/developer/can.htm 14.2.2 Bluetooth V3.0 http://en.wikipedia.org/wiki/bluetooth#bluetooth_v3.0_.2b_hs 14.2.3 3G Wireless Connection http://en.wikipedia.org/wiki/3g November 8, 2012 52 BehindtheCurtain Enterprises

Appendix List of Acronyms CAN Bus- Controller Area Network bus SRS- Systems Requirement Specification November 8, 2012 53 BehindtheCurtain Enterprises