Software Requirements Specification

Online Survey App

COP 4331, Fall, 2014

Team Name: Group # 2

Team Members:

Modification history:

Version	Date	Who	Comment
v0.0	9/11/14	Damla Turgut	Template
v0.1	9/12/14	Shawn Morrison	Updated Comments with Team, Names, and Emails
v0.2	9/15/14	Shawn Morrison	Updated Introduction Section
v0.3	9/15/14	Shawn Morrison	Started Event Table, Specific Requirements. Updated Stakeholders
v1.0	9/15/14	Cody Showers	Created Table of Contents, Purpose, Requirements, Product Functions, User Classes and Characteristics, Operator Environment, User Environment, Design/implementation constraints, Assumptions and Dependencies, User Interface, Hardware interfaces, Software interfaces, Communication protocols and interfaces, Description and priority, Action/result, Functional requirements, Performance requirements, Security requirements, and Software quality attributes.
v1.1	9/16/14	Shawn Morrison	Combined Shawn’s and Cody’s SRS Documents into a single document, and set it up like template given in class.
v1.2	9/16/14	Cody Showers	Added Bookmarks for linking, Terms to Definitions Section, Information to User Environment, data requirements and performance requirements.
v1.3	9/16/14	Adam Hollifield	Formatting and links
v1.4	9/16/14	Cody Showers	Added Use Case Diagram
v1.5	9/17/14	Shawn Morrison	Updated internal links, and Contents of Document. → Use case diagram still needs correcting.
v1.6	9/17/14	Shawn Morrison	Corrected some grammar, and added info to sub-sections.
v1.6.1	9/17/14	Cody Showers	Updated Use Case Diagram. Updated Use Case Diagram Descriptions. Added in template for formal definition of requirements. Updated Table of Definitions. Removed Old version of SRS from end of document.
v1.7	9/17/14	Shawn Morrison	Made Changes to Event Table.
v1.8	9/18/14	Shawn Morrison	Added examples to Requirements Sections - Need to finish filling in Requirements Sections.
v1.9	9/18/2014	Adam Hollifield	Formatted requirements into tables
v2.0	9/18/2014	Cody Showers / Shawn Morrison	Final Software Requirement Specification for submission

Contents of this Document:

Section 1: Introduction:

This Section gives a description and an overview of the details of this SRS Document. It describes the Software to be Produced, Reference Documents, Applicable Standards, and any necessary definitions, acronyms or abbreviations that will be used in this document.

1.1 Purpose:

Feedback is an important tool. A simple and mobile solution that can provide, allow for viewing, and give basic analysis of feedback in real time can improve service in many facets. The intention of this software is to provide such a solution at your fingertips, given you have an Android Device.

1.2 Requirements:

This application must maintain:

private user information

Unique ID
Responses
Demographic information

Public Survey information

The question and response formats
The responses
Comments

This application must be able to return accurate information to authorized mobile platforms:

Survey Results
Basic Demographic Analysis
Public information requested

Such as comments

1.3 Reference Documents:

Concept of Operations
Project Management Plan
Test Plan
Textbook: Shari Lawrence Pfleeger and Joanne M. Atlee, "Software Engineering: Theory and Practice", 4th Edition, Prentice Hall, 2010.

1.4 Software to be Produced:

Software to be produced includes a useful mobile app for generating profiles of voters throughout the nation.
The user will have a unique ID.
The user will also create their profile, such as his/her age, gender, education level, and then share his/her opinions about the current issues.
The user will vote for candidates or view the results of the ongoing/completed surveys.
Refer to the reference documents for more information.

1.5 Applicable Standards:

Privacy is extremely important, and, the user information and survey information must be kept private from other viewers.
The system cannot consume an unreasonable amount of battery voltage from the device.
The system must only use data when necessary for survey responses and receiving results.

1.6 Definitions, Acronyms, and Abbreviations:

Term	Definition
ID	Numeric or Alpha-numeric characters used to identify and distinguish an individual. (encrypted phone numbers)
Demographic Information	Ancillary information of participants useful for categorizing results.
Profile	Unique information, specific to an ID, consisting of ID and Demographic information.
Survey	A formed question and response template provided to the application.
Response	A message Sent to the Survey Database containing information pertaining to an Application User or Survey.
Results	Representation of responses provided to survey.

Section 2: Product Overview

2.1 Assumptions:

The user interface software will not be able to function outside of the Android Environment and will require an active internet connection to function.
The database will have to work within the scope of the capabilities of SQLite and must also maintain a network connection to function.
The user must have up-to-date firmware and software on their android device.

2.2 Stakeholders:

Developers:

Instructor:

Dr. Damla Turgut - turgut@eecs.ucf.edu

Teacher's Assistant/client:

Gurkan Solmaz - gsolmaz@knights.ucf.edu

2.3 Event Table:

Event Name	External Stimuli	External Responses	Internal Data and state
Create ID	User clicks button to Create ID	User inputs an Id or phone number.	Current State: Create ID - Encrypted and Saved to database - shift state to Create PW after
Create Password	User Clicks button after entering password	User Enters a Password	Current State: Create PW - Save password to database with encryption. - shift state to Create Profile
Create Profile	User clicks create profile button	User enters Age, Gender, and Education Level by entering an integer, or clicking a drop down box.	Current State: Create Profile - After Creating ID and Password, the User must start to enter their profile. The data is saved to the database. Shift State to Encrypt Phone Number.
Vote or insert opinion.	User clicks Vote button	User selects answer to survey through a radio button, or a drop down menu.	Current State: App Home Page - Save answer to database - Shift State to Vote
View Results/Comments	User clicks button to select view results/comments.	none	Current State: App Home Page - Data is calculated and sent to User - shift state to View Results/Comments.
Encrypt Phone Number	User clicks Encrypt Phone Number button.	User enters phone number.	Current State: Encrypt Phone Number - Data is encrypted and stored to database - Shift state to App Home Page
App Home Page	User clicks Home Button or Encrypt Phone Number Button	none	Current State: View Results/Comments, Vote or Insert Opinion, Add Comments. or Encrypt Phone Number - Shift State to App Home Page
Add Comments	User clicks button to insert comment.	User types their comment.	Current State: Vote or insert opinion - Comments must be stored to database - Shift state to Comments

2.4 Use Case Diagram:

UML Diagram.jpg

2.5 Use Case Descriptions:

Use Case ID:	1
Use Case Name:	Secure login
Description	User securely accesses account by logging in using encrypted phone number.
Actors:	Application User
Preconditions:	Application user has downloaded and Installed application.
Postconditions:	Application user will be able to send or request profile specific information, responses, or comments.
Normal Flow:	Open Application Log in to the Application
Exceptions:	Application user must be using a mobile device with phone access or provide a valid phone number.

Use Case ID:	2
Use Case Name:	Update Profile
Description:	User will be able to update profile specific information.
Actors:	Application User
Preconditions:	User must have logged in.
Postconditions:	The updated information will be sent to the Database for later recollection.
Normal Flow:	Open Application Log in to the Application Update Information

Use Case ID:	2a
Use Case Name:	Update Gender
Actors:	Application User
Description:	Extension of Update Profile. Application User can update demographic information related to Gender individually.

Use Case ID:	2b
Use Case Name:	Update Education Level
Actors:	Application User
Description:	Extension of Update Profile. Application User can update demographic information related to Education Level individually.

Use Case ID:	2c
Use Case Name:	Update Age
Actors:	Application User
Description:	Extension of Update Profile. Application User can update demographic information related to Age individually.

Use Case ID:	3
Use Case Name:	Receive Results
Description:	User will be able to request and receive information about a survey.
Actors:	Application User
Preconditions:	User must have logged in. User must have chosen a survey.
Postconditions:	The results of the survey requested will be displayed on the mobile device.
Normal Flow:	Open Application Log in to the Application Choose Survey Request Results Receive Results
Exceptions:	If the survey has not been created or has received no responses then no results can be given.

Use Case ID:	4
Use Case Name:	View Survey Demographics
Description:	User will be able to request demographic information about survey results.
Actors:	Application User
Preconditions:	User must have logged in. User must have chosen a survey. Survey must have received responses.
Postconditions:	The updated basic demographic information tallied will be sent to the mobile device.
Normal Flow:	Open Application Log in to the Application Choose Survey Request Results Receive Results Request Survey Demographics Receive Survey Demographics
Alternate Flow:	Open Application Log in to the Application Choose Survey Request Survey Demographics Receive Survey Demographics
Exceptions:	If the survey has not been created or has received no responses then no results can be given. If the survey responders have not accurately updated their profile, demographic information will be incorrect.

Use Case ID:	5
Use Case Name:	Send Response
Description:	User will be able to Respond to Created Surveys. This includes sending a designated response and basic comments related to survey.
Actors:	Application User
Preconditions:	User must have logged in. User must have picked a survey. User must have select a response to send.
Postconditions:	The updated information will be sent to the Database for later recollection.
Normal Flow:	Open Application Log in to the Application Choose a survey Prepare a response Send Response
Exceptions:	If the survey does not exist or is closed then the response cannot be sent.

Use Case ID:	6
Use Case Name:	Create Survey
Description:	User will be able to create a survey to display to other Application Users
Actors:	Application User
Preconditions:	User must have logged in.
Postconditions:	The survey will be published for other Application Users to respond to.
Normal Flow:	Open Application Log in to the Application Enter specific question and responses for survey. Create Survey.
Exceptions:	Only Application users successfully logged in will be able to create surveys.

Use Case ID:	7
Use Case Name:	Receive Response
Description:	The Survey Database will have to take in Responses from the application, dictating Application User profile information, survey responses, survey creation, and Login information.
Actors:	Survey Database
Preconditions:	Survey Database must exist. Survey Database must be online. Survey Database must have additional space for Responses
Postconditions:	The information contained in the Response will be received and cataloged to the Database for later recollection.
Normal Flow:	Database Receives valid response Database updates appropriately for later recollection.
Alternate Flow:	Database Receives invalid response Database purges response and awaits next response.
Exceptions:	If Survey Database loses connection or runs out of available space, responses will not be able to be recorded.

Use Case ID:	8
Use Case Name:	Calculate Results
Description:	Database will make basic calculations based off the Survey Responses upon receiving a Response. These will include basic arithmetic such as counts and averages.
Actors:	Survey Database
Preconditions:	Survey Database must have received a Survey and Responses to that Survey.
Postconditions:	The updated information will be stored to the Database for later recollection.
Normal Flow:	Receive Survey Response Make Calculation
Exceptions:	If the survey has not been created or has received no responses then no results can be given.

Use Case ID:	9
Use Case Name:	Send Results
Description:	The Survey Database will send results that have been calculated in response to a request.
Actors:	Survey Database
Preconditions:	Survey must exist. Responses must have been sent for this Survey. Calculations must have been completed before they can be sent.
Postconditions:	The updated information will be sent to the Database for later recollection.
Normal Flow:	Receive Survey Response Update Survey in database Calculate Results Receive Results Request Send Results to Requestor.
Alternate Flow:	Receive Results Request Send Precalculated Results to Requestor.
Exceptions:	If Survey Database loses connection or runs out of available space, results will not be reported. If the survey has not been created or has received no responses then no results can be given.

SECTION 3: Specific Requirements

3.1 Functional Requirements:

No: 1

Statement: The program user interface shall read information about survey questions, take in responses, and return valid results and demographic information.

Source: Stake Holders

Dependency: Functional Requirement 3

Conflicts: None

Supporting Materials: None

Evaluation Method: The application should properly allow the user to read information, take a survey, and submit responses and demographic data.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 2

Statement: The program shall encrypt the user's phone number and use it as their ID.

Source: Stake Holders and security requirement

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: The database should be investigated to ensure that the user’s phone number is encrypted and not stored in clear text.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 3

Statement: The backend of the system will be able to interact with the application to provide and receive the necessary information to perform these tasks.

Source: Stake Holders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: All backend functions of the application must work as expected. This should including test database and web server functionality.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 4

Statement: The server should validate all input from the application

Source: Stakeholders

Dependency: Functional Requirement 3

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should check for input errors and alert the user to try again.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 5

Statement: Sequence of operations should be: Login, Create Profile, Take Survey, Insert Comments, View Results/View Comments.

Source: Stakeholders

Dependency: Functional Requirement 2, Functional Requirement 3

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should follow the sequence of operations outlined above. If more steps are necessary than included in this requirement they must be justified or eliminated.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 6

Statement: Formula from input to output should be: divide the number of votes per topic by the total number of votes.

Source: Stakeholders

Dependency: Functional Requirement 4

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should properly divide the votes when calculating results and properly the output the result of the survey as a percentage.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 7

Statement: The administrator should be able to create a survey definition in the system.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should allow an administrative user to create survey for other application users to take. The administrator should be able to create radio buttons or checkboxes within the survey.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 8

Statement: Each survey consists of a set of questions. There should be web pages that allow for the addition/modification/deletion of questions and their possible choices.

Source: Stakeholders

Dependency: Functional Requirement 7

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should allow the survey creating user to select, modify, and delete specific questions from a survey.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 9

Statement: Depending on the answer type, the end user should be presented with radio buttons or checkboxes at the time of taking the survey.df

Source: Stakeholders

Dependency: Functional Requirement 7

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should only present the end user with the appropriate input buttons and methods. Other input buttons should not be present.

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.2 Interface Requirements:

No: 10

Statement: The user should be able to click radio buttons or drop down fields to select an answer to the survey.

Source: Stakeholders

Dependency: Functional Requirement 8

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the process of clicking buttons and drop down fields.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 11

Statement: The user should be able to input their comments.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the process of entering a comment.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 12

Statement: User should be able to view comments and survey results.

Source: Stakeholders

Dependency: Interface Requirement 11

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the process of viewing a comment.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 13

Statement: User should be restricted to only one vote per issue.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the process of trying to enter more than one vote.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 14

Statement: Data must calculate accurately to the 1/10th of a percent - (example 25.3% voted this way).

Source: Stakeholders

Dependency: Functional Requirement 6

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the calculations to see if the results round and calculate properly.

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.3 Physical Environment Requirements:

No: 15

Statement: Android device is required to access application.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: None

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 16

Statement: Internet connection must be present for voting and viewing results.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: None

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 17

Statement: The back end of this application will need to be a database system. SQLite, to which the mobile device can send and receive data from.

Source: Stakeholders

Dependency: Functional Requirement 3

Conflicts: None

Supporting Materials: None

Evaluation Method: None

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.4 Users and Human Factors Requirements:

No: 18

Statement: All users that have no problems with vision, and the ability to interact with the touch screen of the android device should be able to use the system.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Allow multiple users to try the application.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 19

Statement: Any person that is familiar with android devices should be able to use the application without special training.

Source: Stakeholders

Dependency: Users and Human Factors 18

Conflicts: None

Supporting Materials: None

Evaluation Method: Allow multiple users to try the application.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 20

Statement: System should not allow multiple responses to questions in survey.

Source: Stakeholders

Dependency: Interface Requirement 13

Conflicts: None

Supporting Materials: None

Evaluation Method: Try to enter more than one response.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 21

Statement: The system must not allow unauthorized access to another person’s profile.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Try to access someone else’s profile and see if it is possible.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 22

Statement: Users will have a key associated with their phone number unique to them. It will also contain demographic information about the users.

Source: Stakeholders

Dependency: Functional Requirement 2

Conflicts: None

Supporting Materials: None

Evaluation Method: The database should be investigated to ensure that the user’s phone number is encrypted and not stored in clear text.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 23

Statement: Surveys will contain the information about the question, response types, registered responses, and comments they are associated with.

Source: Stakeholders

Dependency: Functional Requirement 3

Conflicts: None

Supporting Materials: None

Evaluation Method: Each survey should contain and properly display all elements referenced above.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 24

Statement: Results will be able to display information about the survey and demographic analysis of the survey.

Source: Stakeholders

Dependency: Users and Human Factors 22

Conflicts: None

Supporting Materials: None

Evaluation Method: A user should be able to run reporting on the results of any particular survey and gain analytical information from the results.

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.5 Documentation Requirements:

No: 25

Statement: Documentation will need to outline the basics of registration and operation of application.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: The documentation should be compared to this RSR document to confirm that each requirement and functionality has properly been documented

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 26

Statement: Documentation will be provided on line.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: The documentation should be publicly available and downloadable online. Anyone with an internet connection and a PDF viewer should be able to view the documentation

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 27

Statement: It is assumed that the audience will have the ability to read and has experience with basic android applications. Most expected users will have knowledge of using intuitive touch interfaces. These users will need a brief summary of requirements to use such as secure login and required information for profile creation. However, the users who are not familiar with the technology will require clear and specific instructions for navigation in an unfamiliar interface

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: A focus group will be created to read the documentation and ensure that users with the experience mentioned in the statement can properly follow the documentation. Multiple focus groups may be conducted for both users with touch screen experience and those without.

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.6 Data Requirements:

No: 28

Statement: Data must calculate accurately to the 1/10th of a percent - (example 25.3% voted this way). This also includes performing other basic arithmetic operations

Source: Stakeholders

Dependency: Functional Requirement 6, Interface Requirement 14

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the calculations to see if the results round and calculate properly. Ensure basic arithmetic operations are computed correctly.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 29

Statement: User profile information, comment, and survey answers as well as a running tally of the totals of specific votes and number of votes per topic must be retained on the database.

Source: Stakeholders

Dependency: Functional Requirement 3, Physical Environment Requirement 17

Conflicts: None

Supporting Materials: None

Evaluation Method: Check the database after a survey action or comment and ensure the data is indeed present in the database.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 30

Statement: This system must have efficient methods for retrieval of database information.

Source: Stakeholders

Dependency: Functional Requirement 3, Physical Environment Requirement 17

Conflicts: None

Supporting Materials: None

Evaluation Method: Ensure that database retrieval is fast and data received does not have any errors.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 31

Statement: This system must retain an ID hashed for each user profile to access this information. This module should also retain the demographic (age, gender, and education level) for each user’s profile.

Source: Stakeholders

Dependency: Functional Requirement 3, Physical Environment Requirement 17

Conflicts: None

Supporting Materials: None

Evaluation Method: Ensure that database properly stores the hashed ID as well as the additional account information.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 32

Statement: This system must retain the questions and responses associated with the survey

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Ensure that web server maintains the questions and the database contains the responses to the questions.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 33

Statement: This system must be able to tally results.

Source: Stakeholders

Dependency: Interface Requirement 14, Data Requirement 28

Conflicts: None

Supporting Materials: None

Evaluation Method: Ensure that the application properly counts and tallies the responses to various survey questions

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.7 Resource Requirements:

No: 34

Statement: The developers will be required to build, use, and maintain the system.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Ensure that all development tools and communication protocols are working properly so developers may build, use, and maintain the system

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 35

Statement: All web server data will be stored on an Amazon AWS EC2 Instance

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement confirms that all related login, access, and firewalling are configured to allow administrative access to the system as well as HTTP access for the application itself.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 36

Statement: Project schedule is outlined in the Project Management Plan. See Dependency section

Source: Stakeholders

Dependency: Project Management Plan

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement is validated when the development stays on schedule and continually reviews the schedule for any problems or delays

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 37

Statement: Project funding should be zero. Since all of the resources we are using to design this project are open source, no funding is needed (with the exception of our tuition).

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement is validated when no funding is spent on developing this application.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 38

Statement: Hardware for testing and deployment will be an Android based mobile phone.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement is validated when an Android based phone, running a recent version of Android is used for both testing and deployment.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 39

Statement: Software (free, or free for students) used for this project consists of Android Studio with Android SDK, SQLite, Amazon AWS, RHEL, GitHub, Apache, Google Docs, and Microsoft Visio Professional.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement is validated when the freely available software mentioned in the statement is used.

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.8 Security Requirements:

No: 40

Statement: The system must not allow unauthorized access to another person’s profile.

Source: Stakeholders

Dependency: Users and Human Factors 21

Conflicts: None

Supporting Materials: None

Evaluation Method: Try to access someone else’s profile and see if it is possible.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 41

Statement: The application must be sandboxed from the rest of the applications running on the Android device as well as the rest of the phone’s operating system.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement will be satisfied when the application is developed in such a way that complies with Android security guidelines and application sandboxing

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 42

Statement: The database must be backed up once per week on a separate cloud-based storage location.

Source: Stakeholders

Dependency: Resource Requirement 35

Conflicts: None

Supporting Materials: None

Evaluation Method: Keep track of dates and verify that backups are performed.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 43

Statement: The web server and any other cloud services will be stored on an Amazon EC2 instance. Amazon, under the AWS terms and conditions are responsible for water damage, fire, and theft. The developers will also maintain will have a backup on a different online drive.

Source: Stakeholders

Dependency: Security Requirement 42

Conflicts: None

Supporting Materials: None

Evaluation Method:By using the Amazon AWS service, the first portion of this requirement is automatically satisfied. The second half of this requirement is satisfied by Security Requirement 42.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 44

Statement: The recovery process would include the copying and pasting of database information from one cloud-based system to another.

Source: Stakeholders

Dependency: Security Requirement 43

Conflicts: None

Supporting Materials: None

Evaluation Method: None

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 45

Statement: The system should implement a secure login process that transmits and stores login credentials in a secure fashion.

Source: Stakeholders

Dependency: Functional Requirement 2, Users and Human Factors 22

Conflicts: None

Supporting Materials: None

Evaluation Method: This requirement is satisfied when the user’s phone number is securely transmitted and stored in the database.

Revision History: Shawn Morrison, 9/16/2014, created requirement

3.9 Quality Assurance Requirements:

No: 46

Statement: The application must have a font that is readable by a person with reasonable vision.

Source: Stakeholders

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: None

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 47

Statement: The database must remain available for the application to work.

Source: Stakeholders

Dependency: Functional Requirement 3

Conflicts: None

Supporting Materials: None

Evaluation Method: Periodically check for the database availability.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 48

Statement: The device should be able to receive the information from the Database within 60 seconds or less.

Source: Stakeholders

Dependency: Data Requirement 30

Conflicts: None

Supporting Materials: None

Evaluation Method: Periodically check the speed of information received.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 49

Statement: The Application should be able to verify within 60 seconds or less.

Source: Stakeholders

Dependency: Data Requirement 30, Physical Environment Requirement 13

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the verification time multiple times.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 50

Statement: The system must be able to detect a lack of internet connection.

Source: Stakeholders

Dependency:Physical Environment Requirement 13

Conflicts: None

Supporting Materials: None

Evaluation Method: Disconnect the device from the internet and see if the application detects.

Revision History: Shawn Morrison, 9/16/2014, created requirement

No: 51

Statement: The system must be able to detect for missing information.

Source: Stakeholders

Dependency: Functional Requirement 4

Conflicts: None

Supporting Materials: None

Evaluation Method: The completed system should check for input errors and alert the user to try again.

Revision History: Shawn Morrison, 9/16/2014, created requirement

SECTION 4: Supporting Material

Reference Material used with researching this project as well as creating this document::

http://devproconnections.com/visual-studio/develop-survey-application-part-i

http://www.se.rit.edu/~team6g/documents/FACETS_SRS.doc