Software Requirement Specifications

for
iMMS (Internet Music Management System)

Version 1.0

Prepared by Imran Ahmed, Safi Mustafa, Usman Aslam and Neelofur

TABLE OF CONTENTS:
1). Introduction
1.1 Purpose of document 1.2 Scope of Project 1.3. Intended audience and reading suggestion 1.4 Definitions, Acronyms, and Abbreviations 1.5 References

2) General Description
2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies

3) Specific Requirements
3.1 External Interface Requirements 3.1.1 User Interfaces

5)Non functional requirements 1.1Safety requirements 1 Security requirement 2 Reliability requirements 3 Software quality attributes 4 Business rules

5) Appendix

Appendix A Images 5.1 Use Case Diagram 5.2 Data Flow Diagram 5.2.1 Level 0 Data Flow Diagram 5.2.2 Level 1 Data Flow Diagram 5.3 Sequence Diagram 5.4 State Diagram 5.5 Class Diagram 5.6 Interface (Unregistered Users) 5.6.1 Interface (Registered Users)

1)

Introduction:

1.1. Purpose :
The iMMS is a unique application that is synchronizing both user experience and copyrights while providing services like online music management, legal downloads, artists management. There are several other applications available in the market that either provides some specific services or large scale integrated solutions. Our product differs from the rest in a way that we give more power to the users remaining within the copyrights circle.

1.2. Scope :
iMMS is a unique web application that is basically a community based website. It will have two types of users i.e. registered users and unregistered users. Unregistered users can get access to very limited features. On the other hand, registered users can login to the application so that they can get access to the dashboard. The dashboard will be interactive options panel that will show users activity and the major functionality of the application. These registered users can also search information about music. Search can be of three types i.e. search by album; search by year and search by artist name. The application will pull data from the database servers accordingly. Registered users will have the capability to edit any information voluntarily if they think that information is inaccurate. The information will be published once it is verified by the artist himself of his manager. There will be a community feature that will enable multiple users to interact with each other in a specific group. Users can also interact through applications internal messaging system. Users can create their own music streams that can be available for other registered members. These streams can either private or public depending on the users applied settings. Once logged in, the manager will upload music, videos and pictures. He will have the ability to set the copyright license. The manager can also create events on Facebook and put the link on the website. Our application will pull data from Facebook and feature the event on the artists Facepage. The registered users will get access to the content uploaded by the mangers. The users can create playlists, stream music, download music and take part in community discussions. Before downloading, the user will be asked to pay for the music if its not free. The administrative panel consists of the global administrators, the artist/managers and the general users. Independent developers can also get access to our API (application programming interface) that will enable them to integrate our resources in their own custom applications

1.3

Intended Audience and Reading Suggestions:

Intended audiences for this SRS document are developers, users, testers, documentation writers and project manager. Chapter 4 will be helpful for developers and test cases developers as they will be able to understand what the product will do by looking into DFD, Use case diagrams and other diagrams. Interface developers can have a look at chapter 3 to have a rough Idea what the interface should look like. Stake holders can have a look at section 4.1 so that they can get to know what will be products major functionality. Project manager should look at the whole document so that he/she understands well where are we going and then devise a strategy accordingly.

1.4. Definitions, Acronyms and Abbreviations:

Term
iMMS Global Administrator

Definition
Internet Music Management System The supreme user of iMMS who has access to the source code, the databases and almost everything, except personal inboxes and other info, that runs on the application. A person who creates his own music. A person who has the ability to upload content for his artist. The manager can be an artist. An unregistered user who has yet to login or will just surf free content. A person who is registered with the application and can get access to exclusive content and buy music. A place within the iMMS that will feature all the content of a specific artist. This includes all the

Artist Manager Guest User Facepage

1.5. References:
www.w3schools.com/ www.php.net/ www.mysql.com/ docs.jquery.com/
en.wikipedia.org

2) General description:
2.1. Product perspective:
IMMS (internet Music Management System) is a system designed for the users from all over the world. There are so many other web sites already providing us music of all kind such as beeMp3.com, songs.pk and many more but the major problem with all of them is that they dont ensure copyrights and they dont give us accurate information. For example if you search for any song on those websites, it will give you 1000s of links to listen a particular song and download it so, what our website is going to do is that it will provide accurate information upon search. It will also provide us with features such as groups, messaging, chatting and many more.

2.2. Product function:

The overview of major function of product are given below they will be discussed in more details in section 4. Open Source Search Music Buy Music Interact with users having similar taste Accuracy of information Compatibility

2.3. User classes and characteristics:

The major user classes will be users and IMMS system and they will have their unique attributes and operations .This will be discussed in detail in section 3.4

2.4. General Constraints:

Search operation should give result in maximum 2 seconds. The application will only work well on major browsers such as Mozilla Firefox, Google Chrome and Safari. The application will not bear load of more than 10,000 users at a specific time. The application will work well on Pentium 4 or its upgrades.

2.5. Operating Environment:

The application can run on all kinds of operating system that support internet browsing. This product will work well on the Pentium 4 and later systems. The application can also be accessed from hand held devices, PDAs, Tablets and major mobiles like iPhone and other Android compatibility. There will be an independent application for such devices but there is always be the option to get access to the application through mobile web browsers like Mini Opera etc.

2.5. Assumptions and Dependencies:

I personally dont think anything will affect requirements if the points discussed above will be kept in mind while designing but requirements will change if the customer come and ask for something new. The main dependence will be the database, if it fails the system will no more remain operate able but we have a backup of the database which will obviously take time to link with the system. Similarly the server can be busy if too many users are logged in at a same time. We do not have any plans for using components from other product so its not dependent on any other product.

3) Specific Requirements:
3.1 Functional Requirements :The requirements will be implemented before the system is deemed satisfactorily completed. 1. The Systems shall use the tabs for displaying the specified request from the user. 2. The User must be logged in for the facility of dashboard. 3. Administrative features will allow of manipulation of underlying database system. 4. The system will provide functionality to allow the user to log in to the system with a username and password. 3.1.1 Unit Registration :1. The unregister user only see the main interface of the website. 2. Register will first login(having user name and password) to enter in the privileged mode . 3. For admin login he/she should given a special id with the login . 4. In Dashboard a user can search and download the song or album by entering artist or song name.

5. Registered user can make his/her own playlsit by selecting the option of Create playlist, in the user can save his/her favourate song as well as delete them. 3.1.2 Retrieving and Displaying Unit information :-

The main interface will prompt the user for the latest events check,notifications,contact us and for user login.When the user entered as a registered user he/her will be able to access his own dashboard.

4) Other Nonfunctional Requirements:

Safety Requirements
Admins cant access personal information of users such as messages so this will insure safety of users.

Reliability Requirements
We will use cloud server and back data base for reliability .It will be 70% reliable then other applications

Software Quality Attributes

This application will be very user friendly and we will insure it by making the application in that way that its very easy to use for the people who dont really know how to use a computer. We are also going to provide tutorial and help menu so that if they dont understand any thing the can see tutorial or use help menu. This application will be available to the user all around the world. We try to make it as flexible as we can so that changes at any time will be easy to manage and this will be done by making applications in module so that if we make changes in one module it dont effect other modules of the system. By making application in module it will be easy to reuse application and portability will also be achieved. We are also going to test this software with the worst possible inputs to ensure correctness of software.

Business Rules
Unregistered user can only use limited resources of product such as browsing and viewing events Registered users will have to login and after they are logged in the can get access to their dash board so that they can manage their friend chat with friends listen and buy songs and many other features Artist/manager should also log in to get access to their dashboard but their dashboard will have two additional feature then registered user i.e.(upload, creating and editing events) Global admin can do what ever he/she wants to do access source code edit it access database and stuff like that. If at any time global admin wants to leave he/she will decide from user who will be the next global admin and give admin privileges to that user

5)Appendix:

5.1. Use Case Diagram:

iMMS Use Case for Unregistered Users

uses Browser

extends Feature Content

extends

Unregistered user uses Events Free Content

iMMS Use case for Registered Users

uses Events extends Featured Content uses browsing extends Free Content

extends logout extends read uses extends login dashboard extends inbox extends write

Registered user extends delete extends create extends extends extends edit playlist extends extends stream extends extends add friends extends delete groups extends leave extends join

extends create

manage friends extends remove friends

extends edit

extends album

extends album

extends track buy search

extends artist

extends video

extends track

iMMS Use case for Artists/Managers

View Events extends Featured Content browsing uses extends Free Content uses logout extends uses extends login dashboard1 extends inbox extends write extends read

artist/manager extends delete extends create extends extends extends edit playlist extends extends stream extends extends add friends extends delete groups extends leave extends join

extends create

manage friends extends remove friends extends extends album

extends edit

extends album

extends track buy search

extends artist

extends video extends

extends track

extends upload extends

extends

extends event extends

extends

video

audio

pictures

create

edit

delete

iMMS Use case for global admin

View Events extends Featured Content browsing uses extends Free Content uses extends logout extends uses extends login dashboard1 extends inbox extends write extends read extends iPanel access code extends edit extends database extends edit

global administrator extends delete extends create extends extends extends edit playlist extends extends stream extends extends add friends extends delete groups extends leave extends join

extends create

manage friends extends remove friends extends extends album

extends edit

extends album

extends track buy search

extends artist

extends video extends

extends track

extends upload extends

extends

extends event extends

extends

video

audio

pictures

create

edit

delete

5.2. Data Flow Diagram:

Sequence Diagram:

Main view (Interface) User Database

Dashboard

Disp_events(): Message1

User_infor(): Message2 Verify()

admin_info(): Message 4 verify() Edit()

conformation()

download()

Interface screenshots:

This is roughly how user interface will look like when the user will not be logged in. User at that time can only use limited resources such as he/she can see the events coming ahead or the featured and free contents.

This is roughly how the system will look like after user has logged in .Dashboard will have all the activities a user can perform such as interaction with member checking messages and chatting stuff .user can also make their own play list and listen to it or buy it