[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
Revision History
|
Date |
Version |
Description |
Author |
|
|
1.0 |
Creation |
Isaac Sanchez |
|
|
1.1 |
Update from review comments |
Isaac Sanchez |
|
|
1.2 |
Updates for FR5, FR6, FR7, DC2, CI1 |
|
|
|
1.3 |
Updates for FR3, SI1 |
Srini Kattragadda |
|
|
|
|
|
Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Definitions, Acronyms, and
Abbreviations 5
1.4 References 6
1.5 Overview 6
2.
Overall Description 6
3.
Specific Requirements 6
3.1 Functionality 6
3.1.1 {FR1} 6
3.1.2 {FR2} 6
3.1.3 {FR3} 6
3.1.4 {FR4} 6
3.1.5 {FR5} 6
3.1.6 {FR6} 6
3.1.7 {FR7} 7
3.1.8 {FR8} 7
3.1.9 {FR9} 7
3.1.10 {FR10} 7
3.1.11 {FR11} 7
3.1.12 {FR12} 7
3.1.13 {FR13} 7
3.1.14 {FR14} 7
3.1.15 {FR15} 7
3.1.16 {FR16} 7
3.2 Usability 7
3.3 Reliability 7
3.4 Performance 7
3.5 Supportability 7
3.6 Design Constraints 7
3.7 On-line User Documentation
and Help System Requirements 8
3.8 Purchased Components 8
3.9 Interfaces 8
3.9.1.1 {UI1} 8
3.9.1.2 {SI1} 8
3.9.1.3 {CI1} 8
3.10 Licensing Requirements 8
3.11 Legal, Copyright, and
Other Notices 8
3.12 Applicable Standards 8
4.
Supporting Information 8
Software Requirements Specification
Purpose of this SRS is to describe all of the requirements of the Linux-WiFi-P2P-AudioFileSharing application.
This document covers the complete software application requirements.
Linux: Operating system.
P2P: Peer-to-peer network
Software: In this document, refers to the application under development.
Wifi: Wireless fidelity.
None.
The rest of the document states the individual requirements of the software. If a requirement is not stated, it is not a requirement and may be defined as the development team feels fit.
The software is to implement an audio file sharing application between computers running the application. The software is targeted to systems running the Linux operating system and connected using Wifi and/or Ethernet network connections. The computers running the software shall be logically connected using a P2P network architecture over the above mentioned Wifi and/or Ethernet links.
The software is to support the following major features: searching for audio files across the network, downloading audio files from the network, and sharing audio files on the network.
Functional Requirements shall be indicated by the following notation: {FR#}, where # is the functional requirement number.
Software shall automatically detect the presence of the network.
Software shall automatically detect the presence of other computers running the application that are connected to the network.
Software shall allow searching
for mp3 audio files on the p2p network based on the user-defined criteria.
Software shall allow following criteria to be defined by the user for searches: artist name, song title, song genre, artist, preferred user, audio file format, file size.
Software shall allow user to
modify user configuration statically stored in an XML file.
Software shall allow user to
save user configuration to an XML file.
3.1.6-5
The software shall allow the user to run in either Autodrive or Manual mode. The application shall allow the user to download files automatically based on a set of criteria in the Autodrive mode. Once in autodrive mode, the application shall search for files based on a user-defined criteria and download it. In Manual mode, the user shall be able to interactively put in searches for individual audio files and shall be able to download one or more files based on the search result. (com,bines 7, 8, 9, 10 and talks about the two modes that we have)
Software shall allow user to
download selected audio files over the same pipes that are discovered using the
peer discovery addressed in FR1.
Software shall allow users to selected files, either individually or as a group, from the results of a search.
Software shall allow users to allow software to download files automatically without user intervention.(3.1.6-5 Autodrive mode)
Software shall allow user to selected files either individually or as a group.
Software shall allow user to select preferred users for search criteria.
Software shall allow user to see file download while in progress.
Software shall display, to user, files queued to be downloaded.
Software shall allow user to cancel the download of files while download is in progress.
Software shall allow user to resume the download of a file that was previously cancelled.
Software shall allow user to remove files from list of scheduled files to be downloaded.
No specific usability requirements.
No specific reliability requirements.
No specific performance requirements.
No specific supportability requirements.
Design Constraints shall be indicated by the following notation: {DC #}, where # is the functional requirement number.
{DC1}
Software shall be developed in the Java programming language.
{DC2}
Software shall be developed to
operate in the Java environment constrained only by the Java implementation
availability on a specific platform.
{DC3}
Software shall be developed to operate with Wifi 802.11b standard.
{DC4}
Software shall be developed using Rational Unified Prcoess (RUP)
No specific online user documentation or help system requirements.
No purchased components shall be required
User Interfaces
User Interfaces shall be indicated by the following notation: {UI#}, where # is the functional requirement number.
Software shall be run through a JAVA graphical user interface (GUI).
Hardware Interfaces
No specific hardware interfaces.
Software Interfaces
Software Interfaces shall be indicated by the following notation: {SI #}, where # is the functional requirement number.
Software shall operate on any
operating system that can run the Java application.
Communications Interfaces
Communications Interfaces shall be indicated by the following notation: {CI #}, where # is the functional requirement number.
Software shall support Wifi 802.11b standard only by the fact that it is an extension of wired Ethernet.
Software is ‘as-is’ and developed under the GPL License.
Software is ‘as-is’, with no warranties either expressed or implied.
[This section describes by reference any applicable standard and the specific sections of any such standards which apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.]
[The supporting information makes the SRS easier to use. It includes:
·Table of contents
·Index
·Appendices
These may include use-case storyboards or user-interface prototypes. When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements.]