Embed Size (px)
Citation preview
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 References2) General Description
2.1 Product Perspective2.2 Product Functions2.3 User Characteristics2.4 General Constraints2.5 Assumptions and Dependencies
3) Specific Requirements3.1 External Interface Requirements
3.1.1 User Interfaces
5)Non functional requirements1.1Safety requirements1 Security requirement2 Reliability requirements3 Software quality attributes4 Business rules
5) Appendix Appendix A Images
5.1 Use Case Diagram5.2 Data Flow Diagram5.2.1 Level 0 Data Flow Diagram5.2.2 Level 1 Data Flow Diagram5.3 Sequence Diagram5.4 State Diagram5.5 Class Diagram5.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 application’s 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 user’s 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 artist’s 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 it’s 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 Definition
iMMS Internet Music Management System
Global Administrator 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.
Artist A person who creates his own music.
Manager A person who has the ability to upload content for his artist. The manager can be an artist.
Guest An unregistered user who has yet to login or will just surf free content.
User A person who is registered with the application and can get access to exclusive content and buy music.
Facepage A place within the iMMS that will feature all the content of a specific artist. This includes all the
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 don’t ensure copyrights and they don’t 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 don’t 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 it’s 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 can’t 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 it’s very easy to use for the people who don’t really know how to use a computer. We are also going to provide tutorial and help menu so that if they don’t 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 don’t 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
Browser
Events
Unregistered user
«uses»
«uses»
Feature Content«extends»
Free Content
«extends»
browsing
Events
Registered user
«uses»
«uses»
Featured Content«extends»
Free Content«extends»
login dashboard inbox
read
write
delete
«extends»«extends»«extends»
«extends»
«extends»
groups
join
leave
create
edit
delete
«extends»
«extends»
«extends»
«extends»
«extends»
«extends»
search
album
artist
track
«extends»
«extends»
«extends»
«extends»
«uses»
playlist
create
edit
stream
«extends»
«extends»
«extends»
«extends»
manage friends
add friends
remove friends
«extends»
«extends»
«extends»
buy
album
track
video
«extends»
«extends»
«extends»
«extends»
logout«extends»
iMMS Use case for Registered Users
browsing
View Events
artist/manager
«uses»
«uses»
Featured Content
Free Content
login dashboard1 inbox
read
write
delete
«extends»«extends»«extends»
«extends»
«extends»
groups
join
leave
create
edit
delete
«extends»
«extends»
«extends»
«extends»
«extends»
«extends»
search
album
artist
track
«extends»
«extends»
«extends»
«extends»
«uses»
playlist
create
edit
stream
«extends»
«extends»
«extends»
«extends»
manage friends
add friends
remove friends
«extends»
«extends»
«extends»
buy
album
track
video
«extends»
«extends»
«extends»
«extends»
logout
«extends»
iMMS Use case for Artists/Managers
upload
«extends»
video audio pictures
«extends»
«extends» «extends»
event
create edit delete
«extends»
«extends»
«extends»
«extends»
«extends»
«extends»
browsing
View Events
global administrator
«uses»
«uses»
Featured Content
Free Content
login dashboard1 inbox
read
write
delete
«extends»«extends»«extends»
«extends»
«extends»
groups
join
leave
create
edit
delete
«extends»
«extends»
«extends»
«extends»
«extends»
«extends»
search
album
artist
track
«extends»
«extends»
«extends»
«extends»
«uses»
playlist
create
edit
stream
«extends»
«extends»
«extends»
«extends»
manage friends
add friends
remove friends
«extends»
«extends»
«extends»
buy
album
track
video
«extends»
«extends»
«extends»
«extends»
logout
«extends»
iMMS Use case for global admin
upload
«extends»
video audio pictures
«extends»
«extends» «extends»
event
create edit delete
«extends»
«extends»
«extends»
«extends»
«extends»
«extends»
iPanel
«extends»
database
access code
«extends»
«extends»
edit
edit«extends»
«extends»
5.2. Data Flow Diagram:
Sequence Diagram:
Main view (Interface)
User Database
Disp_events(): Message1
User_infor(): Message2
Verify()
admin_info(): Message 4
verify()
Dashboard
download()
Edit()
conformation()
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
