IEEE Standard SRS Template IEEE 830-1998
Table of content
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms & abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.1.1. System interfaces
2.1.2. User interfaces
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications interfaces
2.1.6. Memory constraints
2.1.7. Operations
2.1.8. Site adaptation requirements
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and dependencies
2.6. Apportioning of requirements
3. Specific Requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Specific requirements
3.2.1 Sequence diagrams
3.2.2 Classes for classification of specific requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.6 Other requirements
4. Supporting information
4.1 Table of contents and index
4.2 Appendixes
Note: History of versions of this document with author/contributor info may be included before the main sections of the document.

1. Introduction
This section illustrates a scope description and overview of everything included in this SRS document. Also, the purpose for this document described the requirements for Android file finder
1.1 Purpose
The purpose of this document is to give a detailed description of the requirements for the “Android File Finder” (AFF) software. It will illustrate the purpose and complete declaration for the development of system. It will also explain system interface and how it works. Today every user wants to keep their files for ex PDF, images and every other data in their mobiles. Users find it difficult to sort this data or find the files whenever they need.
1.2 Scope
Our application “Android file finder” is a software which helps Android device users to find any kind of saved or downloaded files on their devices, This files includes documents, images, audios or videos. The application is not web-based and thus can be accessed from anywhere without the internet.
The Application can be downloaded on any Android device. The Home page appears when app is opened by users
The project deliverable a non-web file finder system on Android devices needs to fulfil these requirements for it to be accepted:
- Search Bar
- Category wise search
- Sort search result
This project will not include following aspects:
- Users will not be able to add or remove codes
- Users cannot perform more than one task at a time
Assumptions for this project are mobile android phones or android tablets . Another important assumption is that users can type in keywords of files on search bar and get results without going through stress.
1.3 Definitions, acronyms and abbreviations
a) Android – Operating system, developed by Google, made to run on mobile phones.
b) Graphical User Interface – The part of the application that the user sees and interacts with.
c) PC (Personal Computer) - A desktop or laptop running the Microsoft windows operating system.
d) Software Development Kit (SDK) – Set of tools that makes it possible to create software for a particular piece of software or hardware.
e) Extensible Mark up Language (XML) – A widely used type of text data organization and storage language that use ‘ ’and ‘ ’ to label and distinguish sections of data or instructions from each other.
1.4 References
1.5 Overview
2. Overall Description
This section will help in understanding the entire application. It describes about the product functionality, characteristics that a user expect and requirements of the project. Here contains an application. This section will show how the system interacts with other components. The system’s functions, its user’s characteristics and requirements are also explained in this section
.
2.1 Product perspective:
The application has different icons on the home page when its opened, which are Search Bar, Images, Audios, Videos, Document and a Menu bar which include Home, Search and Bookmark.
Users can make use of the search bar for easy access to files by inputting some keywords. User can as well click on the Image, video, doc or audio icons depending on the file. The application will conduct a deep, fast and efficient search on keywords to get the results. The app will also advise if keywords typed does not match.
Here the files are found and can be viewed from the mobile. These records can also be downloaded and renamed for easy identification and as well as several other purposes.
2.1.1. System interfaces
2.1.2. User interfaces

Figure 1 Homepage

Figure 2 Keywords in Search bar

Figure 3 Menu Icon
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications interface.
2.1.6. Memory constraints.
2.1.7. Operations
2.1.8. Site adaptation requirements
2.2 Product functions
With this non-web application, the users with android device can download the application and view any files that is hidden on the device using the sort size or type.
2.3 User Characteristics
2.4 Constraints
2.5. Assumptions and dependencies
2.6. Apportioning of requirements
3. Specific requirements
The requirement from the user are classified in different category as following:
a) Functional Requirement:
- cross platform
- high level authentication
- fast performance algorithm
- XXS attack proof
b) Non-functional Requirement:
- should be accessible from mobile device.
- should be user friendly
3. Requirement Prioritization and Negotiation
- We only had every week meeting with the client where we gathered the requirement about the project for further studies. So, the requirement that we developed would be put forward for prioritization and negotiation in our next meeting with the client.
4. Requirements Specification
- The requirements have not been finalized yet, this will be finalized in the next meeting.
3.1 External interface requirements
3.1.1 User interfaces.
3.1.1 User interfaces
Figure 1 Homepage

Figure 2 Keywords in Search bar

Figure 3 Menu Icon
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Specific Requirements
3.2.1 Sequence Diagrams
The Use case Diagram

Figure 1 Use case Diagram
3.2.2. Classes for classification of specific requirements
3.3 Performance requirements
The requirements in this section provide a detailed specification of the user interaction with the software and measurements placed on the system performance.
3.4 Design Constraints

3.3.3 Class Diagram
3.3.5 Entity relationship Diagram
3.5 Software system attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.6 Other requirements
4. Supporting Information
For effective management and easy development of the application requirements we have prioritized requirements based on their importance in the project. This section will provide detailed insight into the selection of prioritization method we used and provides suggestion of how the sprint will products each week and effectively with the whole application.
4.1 Table of contents and index
Discussion and client meetings were main methods we used to prioritize our main requirements we had. We implemented a system that used numbers from 1 to 5, 1 being least important and 5 being the most important task on the list. From the discussion and client meetings, the numbers were summed up for each requirement. The results are in appendix 2 for this SRS document.
We followed yes-no vote method, this method is simple to implement for this process, the range is too narrow but because of the nature of the project, this method of prioritization was best suited for our project. Also, client felt easy to work with this method than other method like five-way priority scheme, which we tried but did not work.

4.2 Appendices.
Appendix 2: Prioritization of requirements
Req. No. Requirements Priority (0-5) Projected week to be completed
1 The app should be downloadable on any android device
5 Week 6 -12
2 The app should be able search for files using keywords
5 Week 5-8
3 App should be able to display file when found
5 Week 6-8
4 App should be able to sort file by either type or size 4 Week 8
5 App should be able to display error message if searched files are not found 4 Week 8
6 App should be flexible and easy to use 4 Week 8
7 Way to update and delete system details 4 Week 8
8 App should meet consistency increasing search of users 4 Week 9
9 App should be fast and easy to use
3 Week 9
10 Sufficient feedback should be given to the user of task being performed or in case or errors or success.
3 Week 9
11 Database needs to be secure. (XXS proof.)
2 Week 9 -10