Systems Requirement Specifications

Transcription

1 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

2 Table of Contents Document Revision History...5 List of Figures...6 List of Tables Introduction, Scope, and Requirements Definition Introduction Scope Requirements Definition Product Concept Purpose and Use Intended Audience Product Description & Functional Overview Functions and Features Product Interfaces Customer Requirements Read Data from CAN BUS Profile Each Run Bluetooth Capability Mobile iphone App Mobile Android App Microcontroller Data Acquisition Microcontroller Packaged Output Interface to CAN BUS Configuration Support Page Multi-Gauge Graphical User Interface App Consistency Hardware Identification Packaging Requirements...21 November 8, BehindtheCurtain Enterprises

3 5.1 User Manual Secured Enclosure Printed Circuit Board Server Software App Store Submissions Performance Requirements Real-Time Output Reliable Data Transfer Mobile Cross-Compatibility Multi-threading Safety Requirements Secured Fastening Electric Safety Maintenance and Support Requirements Support Future Mobile Operating System Code Documentation Testing Maintenance Cutoff Date Other Requirements Statistics Database User Accounts Encryption of Web Traffic Salt and Hash Passwords Accurate Gauge Display Acceptance Criteria Verify that the mobile application GUI is user friendly Verify that the mobile application sensor output is accurate Verify that the ios and Android application versions are consistent and compatible...35 November 8, BehindtheCurtain Enterprises

4 10.4 Verify that the hardware enclosure is environmentally durable Verify that data is carried over to the central server successfully Verify that hardware module does not interfere with existing gauge Verify that data is encrypted and decrypted correctly Verify that user accounts are created correctly Verify that the user manual meets customer standards Use Cases Start-Up View Mobile Gauge User Interface Calibrate Mobile App for Sensors Start Run Profile Recording View Recorded Race Profiles Mobile App Login to Server Manually Upload Recorded Runs to Server Feasibility Assessment Scope Analysis Research Technical Analysis Cost Analysis Resource Analysis Schedule Analysis Future Items App Store Submissions Referenced Documents Internal Documents Industry Standards...52 Appendix...53 List of Acronyms...53 November 8, BehindtheCurtain Enterprises

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

6 List of Figures Figure # Title Page # 3-1 System Overview Product Interfaces Start Up View Mobile Gauge User Interface Calibrate Mobile App for Sensors Start Run Profile Recording View Recorded Race Profiles Mobile App Login to Server Manually Upload Recorded Runs to Server 43 November 8, BehindtheCurtain Enterprises

7 List of Tables Table # Title Page # 3-1 External Inputs and Outputs Cost Estimate Function Point Estimation Influence Multiplier Size Estimation KLOC Jones First Order Estimation CoCoMo Coefficients CoCoMo Calculations CoCoMo vs. Jones First Effort Estimation 50 November 8, BehindtheCurtain Enterprises

8 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 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, BehindtheCurtain Enterprises

9 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 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, BehindtheCurtain Enterprises

10 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, BehindtheCurtain Enterprises

11 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, BehindtheCurtain Enterprises

12 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, BehindtheCurtain Enterprises

13 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, BehindtheCurtain Enterprises

14 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 Description: Our product shall have a hardware module that will read its data from the existing gauges CAN BUS line Source: Redline Gauges Constraints: Standards: CAN BUS 2.0B by Bosch Priority: 1-Critical 4.2 Profile Each Run 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 Source: Redline Gauges November 8, BehindtheCurtain Enterprises

15 4.2.3 Constraints: Storage space on phone Standards: Priority: 1-Critical 4.3 Bluetooth Capability Description: The hardware module shall have Bluetooth capability to transfer the data from the module to the phone Source: Redline Gauges Constraints: Standards: Bluetooth V Priority: 1-Critical 4.4 Mobile iphone App 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, BehindtheCurtain Enterprises

16 cellular devices with the app installed can also obtain the same data and visuals at a reduced delay time Source: Redline Gauges Constraints: Only writing app for the newest ios version Standards: IMT2000/3G, Bluetooth V Priority: 1-Critical 4.5 Mobile Android App 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 Source: Redline Gauges Constraints: Only writing app for Jellybean OS Standards: Bluetooth V Priority: November 8, BehindtheCurtain Enterprises

17 1-Critical 4.6 Microcontroller Data Acquisition Description: Our hardware module shall have a microcontroller that reads the data in from the existing CAN BUS line Source: Redline Gauges Constraints: Microcontroller clock speed Standards: Priority: 1-Critical 4.7 Microcontroller Packaged Output 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 Source: Redline Gauges Constraints: Microcontroller clock speed Standards: Priority: November 8, BehindtheCurtain Enterprises

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

19 2-High 4.10 Multi-Gauge Graphical User Interface 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 Source: Redline Gauges Constraints: Limited screen space on both phones Standards: Priority: 2- High 4.11 App Consistency Description: The two mobile application displays shall be nearly identical Source: Redline Gauges Constraints: Standards: November 8, BehindtheCurtain Enterprises

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

21 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 Description: The system shall be packaged with a user manual explaining how to use Source: BehindTheCurtain Enterprises Constraints: Standards: Priority: 1 Critical 5.2 Secured Enclosure 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 Source: BehindTheCurtain Enterprises Constraints: Hardware and budget November 8, BehindtheCurtain Enterprises

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

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

24 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 Description: The system shall be able to transmit data over Bluetooth to be output to the mobile device Source: BehindTheCurtain Enterprises Constraints: Reliable data transfer Standards: Priority: 1 Critical 6.2 Reliable Data Transfer Description: The system shall have a high success rate on packet transfers. System should implement error detection, receiver feedback, and retransmission to the receiver Source: BehindTheCurtain Enterprises Constraints: November 8, BehindtheCurtain Enterprises

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

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

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

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

29 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 Description: The mobile applications will be able to support future mobile OS Source: BehindtheCurtain Enterprises Constraints: No knowledge of future mobile operating systems Standards: Priority: 3 Medium 8.2 Code Documentation Description: Code shall be well documented with UML, use-cases, and comments detailing information regarding variables and methods Source: BehindtheCurtain Enterprises Constraints: November 8, BehindtheCurtain Enterprises

30 Standards: Priority: 8.3 Testing 1 Very high Description: Verification process shall include detailed unit and module tests covering every aspect of implementation Source: BehindtheCurtain Enterprises Constraints: Standards: Priority: 1 Very high 8.4 Maintenance Cutoff Date Description: Project shall be maintained through 05/ Source: BehindtheCurtain Enterprises Constraints: November 8, BehindtheCurtain Enterprises

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

32 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 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 Source: BehindtheCurtain Enterprises Constraints: Standards: Priority: 3 Medium 9.2 User Accounts Description: The mobile application will allow users to create accounts and access race statistics and information. November 8, BehindtheCurtain Enterprises

33 9.2.2 Source: BehindtheCurtain Enterprises Constraints: Standards: Priority: 3 Medium 9.3 Encryption of Web Traffic Description: All web traffic between the mobile apps and central server should be encrypted Source: BehindtheCurtain Enterprises Constraints: 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 Priority: 4 - Low 9.4 Salt and Hash Passwords Description: User passwords and sensitive details should be salted and hashed before being stored in server database. November 8, BehindtheCurtain Enterprises

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

35 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 Verify that the mobile application GUI is user friendly Requirement(s) addressed: Multi Gauge Graphical User Interface Verification Procedure: The GUI of the mobile application will be approved by the sponsor to verify user friendliness Verify that the mobile application sensor output is accurate Requirement(s) addressed: 9.5- Accurate Gauge Display, 6.2- Reliable Data Transfer, 6.1- Real-time Output Verification Procedure: The output displayed by the mobile application will be compared against the output of the existing gauge Verify that the ios and Android application versions are consistent and compatible Requirement(s) addressed: 6.3- Mobile Cross Compatibility, Application Consistency Verification Procedure: The sponsor will compare both applications for consistency. November 8, BehindtheCurtain Enterprises

36 10.4 Verify that the hardware enclosure is environmentally durable Requirement(s) addressed: 5.2- Secured Enclosure Verification Procedure: The hardware enclosure will be subjected to shock, heat, and water exposure tests Verify that data is carried over to the central server successfully Requirement(s) addressed: 6.2- Reliable Data Transfer Verification Procedure: The profiling data stored in the server will be compared against the profiling data saved in the mobile applications Verify that hardware module does not interfere with existing gauge Requirement(s) addressed: 4.8- Interface with CAN Bus 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 Verify that data is encrypted and decrypted correctly Requirement(s) addressed: 9.3- Encryption of Web Traffic 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 Verify that user accounts are created correctly November 8, BehindtheCurtain Enterprises

37 Requirement(s) addressed: 9.2- User Accounts 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 Verify that the user manual meets customer standards Requirement(s) addressed: 5.1- User Manual 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, BehindtheCurtain Enterprises

38 11.1 Start-Up Scenario Actors: The user starts up the app User 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 Scenario November 8, BehindtheCurtain Enterprises

39 The app syncs with the hardware module, or with the server Actors User and Server 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 Scenario The user opens the settings panel or registers for the first time Actors User Case Action They will be presented with a series of options to precisely adjust the sensors. November 8, BehindtheCurtain Enterprises

40 Figure 11-3: Calibrate Mobile App for Sensors 11.4 Start Run Profile Recording Scenario Actors The user will select Start Run within the mobile app prior to racing. User 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, BehindtheCurtain Enterprises

41 11.5 View Recorded Race Profiles Scenario Actors The user will be select Race Profiles within the app. User and Server 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 Scenario The device detects wireless connection Actors User and Server Case Action November 8, BehindtheCurtain Enterprises

42 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 Scenario User The user will open the run profiles panel within the mobile UI. User and Server 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, BehindtheCurtain Enterprises

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

44 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 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 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 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, BehindtheCurtain Enterprises

45 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 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 $ 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, BehindtheCurtain Enterprises

46 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 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 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* *5 0*7 0*10 5 Unadjusted Function Points (UAF) 77 Adjustment Factor.99 Total 76 Table 12-2 November 8, BehindtheCurtain Enterprises

47 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, BehindtheCurtain Enterprises

48 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) ios Application Android Application Server Software Total Table 12-4 November 8, BehindtheCurtain Enterprises

49 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 Calendar Months 7.02 Calendar Months 6.44 Calendar Months Table 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 Semi-detached Embedded 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, BehindtheCurtain Enterprises

50 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, BehindtheCurtain Enterprises

51 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 App Store Submissions Description: will be made available to both Android market and the Apple ios App Store Source: BehindTheCurtain Enterprises Constraints: Time and licensing requirements Standards: Priority: 5 - Future November 8, BehindtheCurtain Enterprises

52 14.1 Internal Documents CPC/REDLINE GUAGES: RG-ICD001 rev A 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 CAN BUS 2.0B by Bosch Bluetooth V G Wireless Connection November 8, BehindtheCurtain Enterprises

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