Department of Computer Science and Engineering the...

Department of Computer Science and Engineering

the University of Texas at Arlington

Systems Requirement Specifications

BehindtheCurtain Enterprises

Project AVALANCHE

Team Members: Kyle Burgess

Kyle Crumpton Austen Herbst

Bilal Nawaz Jason Sprowl

Last Updated: 11/8/2012 6:00pm

System Requirements Specification – v1.1 AVALANCHE

November 8, 2012 2 BehindtheCurtain Enterprises

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



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



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 AVALANCHE 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



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



List of Figures

Figure # Title Page #

3-1 System Overview 12

3-2 Product Interfaces 13

11-1 AVALANCHE 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



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



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 AVALANCHE

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.



• 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



2. Product Concept

This section describes the overall concept of the AVALANCHE by giving a brief and concise description of the purpose, audience, and proper use.

2.1 Purpose and Use The AVALANCHE 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. AVALANCHE 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 AVALANCHE 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.



3. Product Description & Functional Overview

This section provides the reader an overview of the AVALANCHE 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

AVALANCHE 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. AVALANCHE 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 AVALANCHE system is interfaced with the existing CPC/Redline Gauge.



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 Short range wireless connection on the mobile device and add-on module

Connects the add-on module to the mobile device for data exchange

Wireless Data Connection Wi-Fi/Cellular connection on the mobile device

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



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



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:

None

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



4.2.3 Constraints:

Storage space on phone.

4.2.4 Standards:

None

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:

None.

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



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:



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:

None

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:

None

4.7.5 Priority:



1-Critical

4.8 Interface to CAN BUS

4.8.1 Description:

AVALANCHE 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:

AVALANCHE shall have a user configuration page where they can input the same user

inputs.

4.9.2 Source:

Redline Gauges

4.9.3 Constraints:

None.

4.9.4 Standards:

None

4.9.5 Priority:



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:

None

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:

None.

4.11.4 Standards:

None



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:

None.

4.12.4 Standards:

None

4.12.5 Priority:

2- High



5. Packaging Requirements

This section describes the packaging requirements for AVALANCHE. 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 AVALANCHE.

5.1.2 Source:

BehindTheCurtain Enterprises

5.1.3 Constraints:

None

5.1.4 Standards:

None

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:


5.2.3 Constraints:

Hardware and budget



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 AVALANCHE.

5.3.2 Source:


5.3.3 Constraints:

Budget and customer demand

5.3.4 Standards:

None

5.3.5 Priority:

3 – Medium

5.4 Server Software

5.4.1 Description:

AVALANCHE will include server software to host documented races, users, and

possibly statistics.

5.4.2 Source:


5.4.3 Constraints:

None



5.4.4 Standards:

None

5.4.5 Priority:

3 – Medium

5.5 App Store Submissions

5.5.1 Description:

AVALANCHE should be made available to both Android market and the Apple iOS App

Store.

5.5.2 Source:


5.5.3 Constraints:

Time and licensing requirements

5.5.4 Standards:

None

5.5.5 Priority:

4 - Low



6. Performance Requirements

This section describes the performance requirements for AVALANCHE. 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:


6.1.3 Constraints:

Reliable data transfer

6.1.4 Standards:

None

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:


6.2.3 Constraints:



None

6.2.4 Standards:

None

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:


6.3.3 Constraints:

None

6.3.4 Standards:

None

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:


6.4.3 Constraints:

Limited microcontroller memory.



6.4.4 Standards:

None

6.4.5 Priority:

4 – Low



7. Safety Requirements

7.1 Secured Fastening

7.1.1 Description:

The system shall be securely fastened to the vehicle.

7.1.2 Source:


7.1.3 Constraints:

Budget.

7.1.4 Standards:

None

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:


7.2.3 Constraints:

None.

7.2.4 Standards:



Our product will follow the same standards of enclosure as specified by Redline Gauges:

RG-ICD001 rev A

7.2.5 Priority:

2- High



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:


8.1.3 Constraints:

No knowledge of future mobile operating systems.

8.1.4 Standards:

None.

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:


8.2.3 Constraints:



None.

8.2.4 Standards:

None.

8.2.5 Priority:

1– Very high

8.3 Testing

8.3.1 Description:

Verification process shall include detailed unit and module tests covering every aspect of

implementation.

8.3.2 Source:


8.3.3 Constraints:

None.

8.3.4 Standards:

None.

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:


8.4.3 Constraints:

None



8.4.4 Standards:

None.

8.4.5 Priority:

1 – Very high



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:


9.1.3 Constraints:

None

9.1.4 Standards:

None

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.



9.2.2 Source:


9.2.3 Constraints:

None

9.2.4 Standards:

None

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:


9.3.3 Constraints:

None

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.



9.4.2 Source:


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:


9.5.3 Constraints:

None

9.5.4 Standards:

None

9.5.5 Priority:

2 - High



10. Acceptance Criteria

These acceptance criteria will be verified in the verification stage of AVALANCHE project. These

items are critical to the success to the AVALANCHE 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


9.5- Accurate Gauge Display, 6.2- Reliable Data Transfer, 6.1- Real-time Output


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.


6.3- Mobile Cross Compatibility, 4.11- Application Consistency


The sponsor will compare both applications for consistency.



10.4 Verify that the hardware enclosure is environmentally durable


5.2- Secured Enclosure


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


6.2- Reliable Data Transfer


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


4.8- Interface with CAN Bus


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


9.3- Encryption of Web Traffic


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




9.2- User Accounts


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


5.1- User Manual


The sponsor will review the user manual and give feedback about whether the user manual

is clear and easy to use.



11. Use Cases

11.1 AVALANCHE Start-Up

11.1.1 Scenario

The user starts up the app

11.1.2 Actors:

User

11.1.3 Case Action

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



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 AVALANCHE 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.



Figure 11-3: Calibrate Mobile App for Sensors

11.4 Start Run Profile Recording

11.4.1 Scenario

The user will select “Start Run” within the mobile app prior to racing.

11.4.2 Actors

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



11.5 View Recorded Race Profiles

11.5.1 Scenario

The user will be select “Race Profiles” within the app.

11.5.2 Actors

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



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

The user will open the run profiles panel within the mobile UI.

11.7.2 User

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.



Figure 11-7: Manually Upload Recorded Runs to Server



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



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

Table 12-1

12.5 Resource Analysis

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



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 AVALANCHE 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

0*7 1*10 0*15 10

External Interface

Files

1*5 0*7 0*10 5

Unadjusted Function Points (UAF) 77

Adjustment Factor .99

Total 76

Table 12-2



Table 12-3

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



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

(including hardware design

effort)

2000 2500

iOS Application 2500 3000

Android Application 2500 3000

Server Software 1000 1500

Total 8000 10000

Table 12-4



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 ab bb cb db

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

Table 12-6

CoCoMo Calculations

Low Estimate High Estimate

Effort – PM

[ E = ab(SLOC)bb ]

E = 3.0 (8)1.12

E = 30.8 PM

E = 3.0 (10)1.12

E = 39.5 PM

Duration – Months

[ D = cb(E)db ]

D = 2.5(30.8)0.35

D = 8.30 months

D = 2.5(39.5)0.35

D = 9.05 months

Final Estimate ≈ 8 months ≈ 9 months

Table 12-7



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



13. Future Items

This section describes the future items for AVALANCHE. 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:

AVALANCHE will be made available to both Android market and the Apple iOS App

Store.

13.1.2 Source:


13.1.3 Constraints:

Time and licensing requirements

13.1.4 Standards:

None

13.1.5 Priority:

5 - Future



14. Referenced Documents

14.1 Internal Documents

14.1.1 CPC/REDLINE GUAGES:

RG-ICD001 rev A.

14.2 Industry Standards

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



Appendix

List of Acronyms

CAN Bus- Controller Area Network bus

SRS- Systems Requirement Specification

Date post:	01-Apr-2018
Category:	Documents
Upload:	lephuc
View:	219 times
Download:	2 times