Team HandiApp. utdallas.edu/~srb Samuel Becker, Andrew Stein, Chris Hauptli, and Blake Barnhill. World Requirements Specification Evolution

Transcription

1 Team HandiApp utdallas.edu/~srb Samuel Becker, Andrew Stein, Chris Hauptli, and Blake Barnhill World Requirements Specification Evolution Submitted July 30 th, 2015 Version 1.1

2 Revision History Date Version Change(s) Author(s) 6/30/ Assignment Page Cover Page Revision History Table of Contents 7/1/ Revision History Table of Contents Process Issues 7/1/2015 7/2/ WRS Prototype Traceability Index Sam Becker Sam Becker Sam Becker Chris Hauptli Blake Barnhill 7/2/ Introduction Sam Becker 7/29/ Fixes to Intro Fixes to Issues Fixes to FR and NFR Fixes to Traceability Sam Becker 1

3 Table of Contents 1. Cover 2. Change History 3. Table of Contents 4. Process 1. Team Members 2. Team Leaders 3. Meetings 4. Resources 5. Input 6. Output 7. Activities 5. Introduction 1. Purpose 2. Scope 3. Objectives and Success Criteria 4. Definitions, Acronyms, and Abbreviations 6. Issues 1. Domain Issues 1. DI1 2. DI2 2. Functional Requirements Issues 1. FRI1 2. FRI2 3. FRI3 3. Non Functional Requirements Issues 1. NFRI1 2. NFRI2 3. NFRI3 4. NFRI4 5. NFRI5 7. WRS 1. W 1. Problem 2. Goal 2. RS 1. Functional RS 2. Non Functional RS 8. Prototype 9. Traceability 10. Reference 11. Index 1. Scope Creep 2. Quality of Work Statement 2

4 4. Process 4.1 Team Members Sam Becker Andrew Stein Chris Hauptli Blake Barnhill 4.2 Team Leaders Sam Becker June July 1 July 23 July 30 Andrew Stein July 2 July 8 Chris Hauptli July 9 July 15 Blake Barnhill July 16 July Meetings June 16 (2 hrs) Sam Becker Chris Hauptli Blake Barnhill June 30 (10 mins) Sam Becker Blake Barnhill Andrew Stein Future Meetings TBD 4.4 Resources (Expected to Use) Individual Laptops Developement Google Drive Document Sharing Google Doc/Excel Document Editing/Creation and Project Planning Text Messaging Communication GitHub Code Repository Xamarin Application Prototyping Tool EasyBacklog User Story Tracking Visio Modeling and Diagrams Website 3

5 4.5 Input Sam Becker Andrew Stein Chris Hauptli Blake Barnhill Professor Lawrence Chung 4.6 Output WRS Presentation Slides Prototype Mock up Prototype Project Plan (Evolving) 4

6 5. Introduction 5.1 Purpose This project is intended to assist handicapped individuals, specifically those with hearing impairment. The application will be an inexpensive alternative to traditional hearing aids. Users will be able to hear family, friends, co workers, and their surroundings as though they were no longer hearing impaired. 5.2 Scope The application will take input audio, increase the volume, and then output the louder audio. Audio input will only be taken from the normal frequency range that humans can hear. The application will also be able to isolated human speech, and amplify it, in order to make it easier for users to follow and participate in a conversation. 1.3 Success Criteria 1. Users of the application feel that they were able to hear others easier with the application than without. 2. Users can detect a wider range of sounds while using the application. 3. The application can target and output amplified Human speech. 1.4 Definitions, Acronyms, and Abbreviations D FR NFR RS DI FRI NFRI Domain Functional Requirement Non Functional Requirement Requirements Specification Domain Issue Functional Requirements Issue Non Functional Requirements Issue 5

7 6.1 Domain Issues Issues DI1 Domain Issues ID DI1 Hearing Impaired is ambiguous. Option 2 Hearing Impaired refers to those with hearing loss that can hear at least 70dB or more. Hearing Impaired refers to the deaf and those with hearing loss. Choice The application is basically a hearing aid. The deaf would require a form of implant. Hardware limitations also affect the number of people that the application can serve, so a volume level must be specified as well. Domain Issues ID DI2 Noise is ambiguous. Option 2 Any non targeted speech to be isolated. Any non speech to be isolated. Choice Option 2 Removing noise can be done, but differentiating one person s speech from another (or from music, movies, etc.) is too difficult for our team. 6

8 6.2 Functional Requirements Issues FRI1 FR Issues ID FRI1 The term amplify is ambiguous. Option 2 The input audio will all be output at 70 db. The input audio will be amplified to be within the volume range of 70dB to the maximum volume of the phone. Choice Option 2 Differences in volume need to be preserved, and volumes lower than 70dB need to be amplified. FR Issues ID FRI2 The term isolate is ambiguous. Option 2 Human Speech will be separated from the audio input, amplified, and output. English Speech will be separated from the audio input, amplified, and output. Choice Option 2 We do not have any non English speakers, and speech in general is already very difficult to detect from an audio sample. 7

9 FR Issues ID FRI3 Isolating speech cannot be done perfectly, so an amount of noise must be accepted. How much noise is acceptable? Option 2 Any sound that is not related to the target speaker s speech. Any human speech is allowed, and 2% of the output sound may be from non human speech. Choice Option 2 Human speech can be isolated, but not from multiple speakers. 2% non human noise seems reasonable, and going much higher may keep us from reaching success criteria. 6.3 Non Functional Requirements Issues NFRI1 NFR Issues ID NFRI1 Audible is ambiguous. Option 2 The output volume will be between the user s set minimum, and the phone s maximum output. The output will be a minimum of 70 db. Choice The application will include a minimum volume control. Phones only have a maximum output that is safe for human ears anyway. 8

10 6.3.2 NFRI2 NFR Issues ID NFRI2 Security is ambiguous. Option 2 The application will not interface with other applications. The application will only store audio input in the system memory; never in storage. Choice Options 2 The OS should already protect the application s input audio from other applications. Keeping audio out of storage prevents that audio from being accessed in the future by others NFRI3 NFR Issues ID NFRI3 Safety is ambiguous. Option 2 Never amplify the output audio beyond the phone s maximum audio, regardless of the output device. Never amplify the audio beyond the minimum audio output setting. Choice Differences in volume must be preserved so option 2 is unhelpful. Phone s typically have a maximum output volume that is well below the volume that can damage human hearing. 9

11 6.3.4 NFRI4 NFR Issues ID NFRI4 Performance is ambiguous. Make audio amplification instantaneous. Option 2 Enforce an average latency between input and output at 30 ms. Choice Option 2 30 ms is fast enough as not to hamper communication, and instantaneous amplification is impossible NFRI5 NFR Issues ID NFRI5 Usability is ambiguous. Option 2 Have only a single screen with all necessary buttons and information. Have at minimum two buttons, two sliders, and a main, loading/title, and help screen Choice Option 2 Multiple screens are necessary, and the current mock up is already useable enough to be the definition. 10

12 7. WRS 7.1 W Problem: Problem ID P1 P2 P3 Problem The hearing impaired cannot hear what is happening around them. Also, they cannot hear others easily enough to communicate with others. While hearing aids exist for this purpose, they are too expensive for many hearing impaired people to afford Goal: Goal ID G1 G2 G3 Goal Create a free hearing aid application that can work with any smartphone. Create a hearing aid application that will allow the hearing impaired to hear what is happening around them. The application should also make communicating with others easier by allowing them to hear the person they are conversing with more easily. 11

13 7.2 RS Functional RS: FR ID FR1 FR2 FR3 FR The system shall amplify all sound that can be received by the phone microphone (20Hz 20kHz) to 70+ db through headphones. The system shall isolate and then amplify human speech. The system shall dynamically adjust minimum volume levels from 0 db output to 70+ db output independently for each headphone (left and right) Non Functional RS: NFR ID NFR1 NFR2 NFR3 NFR4 NFR Audio amplification and isolation will run outside of the application, and within it. Amplification of input audio will have a maximum latency of 30ms. Audio will only be stored in the phone s memory, never on disk. Audio output will not cause more harm to the user s hearing. 12

14 8. Prototype GUI Mock Up of End Product and in app How to Use guide [Load Screen] [Main App Screen] [How to Use] [Microhpone Error Message] 13

15 9. Traceability NFR1 NFR2 NFR3 NFR4 FR1 X X X X FR2 X X X FR3 X G1 G2 G3 FR1 X X FR2 X X FR3 X X G1 G2 G3 P1 X P2 X P3 X 14

16 10. Reference Chung, Lawrence. WRS template.pdf. Chung, Lawrence. Sample.pdf. 15

17 12. Index 12.1 Scope Creep We anticipate a reasonable amount scope creep (this is why we are using an agile method for prototype development). To meet our 7/30/2015 prototype go live date, we estimate that we can handle a 10% change in requirements between 06/24/2015 and 07/30/2015. Our team is using story points to assign difficulty to each of the programming tasks required. Our baseline is 8 story points. 8 story points is reflective of a development task that one developer could complete in a single day. The ability to include additional functionality created by a 10% change in requirements is qualified with the fact that the amount of effort required to complete the new features in scope will determine the % change in requirements that is feasible. Story Points Features that can be accommodated (per sprint) 0 No limitation 1/ inf 0 16

18 12.2 Quality of Work Statement Our team has experience in both IOS and Android mobile application development, including development in native environments (XCode for ios, Eclipse for Android), and app development frameworks such as Unity and Xamarin. Collectively, we have 15 years of combined experience with software development. Our iterative and incremental approach to development allows us to focus our development effort on customer feedback. The only things we spend time developing are those that the customer believes to be the most important based on their direct input into the development process. Additionally, one of our team members has a vested interest in the development of hearing aid technology as he is a veteran with hearing damage as a result of being in the military. By employing individuals who are representative of our customer base, we provide ourselves with a unique perspective and development edge that other competitors do not possess. 17