ABSTRACT

I would like to express my special thanks to our mentor Mr. Anand

Sharma for his time and efforts, he provided throughout the year.
Your useful advice and suggestions were really helpful to me during
the project’s completion. In this aspect, I am eternally grateful to you.
I would like to acknowledge that this project was completed entirely by
me and not by someone else.

Signature:
 INDEX

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
1.4 Intended Audience
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Product constraints
2.5 Usecase Diagram
2.6 E-R Diagram
2.7 Sequence Diagram
2.8 UML Diagram
3. System Features
3.1 User Interface
3.2 Features and Functions
3.3 Hardware Interface
3.4 Software Interface
4. Functional and Non-functional Interface
4.1 Functional Requirement
4.2 Non-functional Requirement
5. Testing methodologies
5.1 Usability Testing
5.2 Functional Testing
5.3 System Testing
1. INTRODUCTION
1.1 PURPOSE
Musify is a digital music streaming service that allows you access to millions of songs and other
entertaining content from creators worldwide. Thus, one can listen to their favorite music online
comfortably without downloading songs to their devices and overloading the memory.
With free Spotify, users can access functions like playing music for free. Also, it offers
personalized services like recommending music based on your music history, builds collections of
music and podcasts, and so on.

1.2 SCOPE
The product musify is an imaginery product that will support listening to streamed music and
handle playlists in the mobile phone , even in the offline mode.

1.3 OVERVIEW
With free musify, users can access functions like playing music for free. Also, it offers
personalized services like recommending music based on your music history, builds collections of
music and podcasts, and so on.

1.4 INTENDED AUDIENCE

Anyone with some basic knowledge of programming can understand this document. The
document is intended for Developers, Software architects, Testers, Project managers and
Documentation Writers. But anyone with programming background and some experience with
UML can understand this document.
This Software Requirement Specification also includes:

• Overall description of the product

• External interface requirements
• System Features
• Other non functional requirements

2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
It is a music streaming webpage which provide a free platform to listen music without
downloading it.
This webpage is user-friendly from login to listening music. With the various features, users can
enjoy listening to their favourite songs with ease.
Some music player are only available in online . So musify clone will provide the offline platform
for users. Users will use the offline option to stream the album and listen without using the
internet.
The software application will be used to play music and store playlists. Since this is a data-centric
product it will need
storage space to store information of artists, music, playlists, etc.

The musify system provides an interface to the end-user . The major logical components are:
• List of playlist
• Playlist of music
• Music player
• Search screen

2.2 PRODUCT FUNCTIONS

• Create a Profile
Users can create and edit their profile through the efficient web, including uploading their
profile picture, details, etc.

• Music List
Users can view the active music list to get status updates like which songs they have recently
listened to, most trendy, etc.

• Select Playlist
Browse for new songs to make smart choices from the available music list on the website;
they can choose to play any as per their need.

• Add Favourite
Choose to share details over social media platforms by adding single or multiple kinds of
music to your favourite list.

2.3 USER CLASSES AND CHARACTERISTICS

The software can be used by the following user categories:

• Almost any user will be able to easily get going with this application as it is perfectly
meant for an average music lover. Music lovers especially interested in playing various
genres of music in a playlist for background music playing for instance will be benefited
more than ever by this application as it does not require the internet for playing the
music.

• Simple users that intend to hear a song. These users could be of any age, with no special
knowledge. Knowing how to use a computer is essential.
• Users with poor internet connectivity will benefit even more because the only place we
require internet connection is where we are required to update the metadata of the
music for giving correct suggestions.
 • Programmers - Software Developers – Open Source project participants of any age that
could understand the program’s source code and expand or improve it. Must have
knowledge of the programming language that thesoftware is written in, in order to be
able to understand exactly what it does and how it does it. Also some experience in
programming will most certainly help in extending or improving the project.
• There is no restriction in user’s categories and everyone using a computer can use this
program.
This is an Open Source project and anyone who desires to distribute to the project is
welcome

2.4 PRODUCT CONSTRAINTS

Software application needs to have an operating system that has enough performance. If the
operating system does not have enough hardware resources available for the application. Then,
there may be scenarios where the application does not work as intended or even at all.

2.5 USECASE DIAGRAM

Following is the use case diagram of our system.

Musify being an online player is independent of any admin. The user can and does manages the
entire system by themselves. Broadly, the user has three component to run:

• Control Music: Using this functionality, the user can play music, seek to a part of the song,
stop the playing song, control the volume, pause the song, and change the tracks.
• Edit Metadata: Metadata of the albums, songs, playlists, etc. This then works together with
Local Storage to modify the metadata.
• Manage Songs: Add songs and remove songs from the system. we are planning to
implement a system where the player automatically detects files that can played with out
system. Until that, the user has to manually add and delete songs into the system.
Usecase description table:

Usecase title Usecase description

Manage Songs generalization of Manage songs

Control Music generalization of control songs
Edit Metadata user edits metadata
Play user can play music
Pause user can pause music
Seek user can seek into timeline of playing track
Stop user can stop the playing track
Next Track Track user can change to next track
Previous Track Track user can go to previous track
Add songs user can add songs
Remove Songs user can remove songs from list
Access Local Storage components can access local storage for persistence
Read from local Storage components can read from local storage
Write into local Storage components can write into local storage
Update into local components can update data into local storage
Storage
Delete from local components can delete items from local storage
Storage
 2.6 E-R DIAGRAM:

Creating a complete Entity-Relationship Diagram (ERD) for a musify would be quite complex and
beyond the scope of a text-based response.

In a musify, you would typically have entities such as User, Song, Album, Artist, Playlist, and
among others. Here's a basic representation:

Entities:
 1. User
2. Artist
3. Album
4. Song
5. Playlist

"User" is an actor representing the end-users of the Music player.

"Admin" is another actor who may have special privileges, such as managing content, users, or
settings.

Relationships:

➢ User can create many Playlists (One-to-Many relationship between User and Playlist)
➢ Playlist can contain many Songs (Many-to-Many relationship between Playlist and Song)
➢ User can follow many Artists (Many-to-Many relationship between User and Artist)
➢ Artist can have many Albums (One-to-Many relationship between Artist and Album)
➢ Album can contain many Songs (One-to-Many relationship between Album and Song)
➢ Song can belong to many Playlists (Many-to-Many relationship between Song and Playlist)
Attributes:

➢ User: UserID, Username, Email, Password, etc.

➢ Artist: ArtistID, Name etc.
➢ Album: AlbumID, Title, ReleaseDate, etc.
➢ Song: SongID, Title, Duration, etc.
➢ Playlist: PlaylistID, Title, Description, etc.

This is a simplified representation, and a real-world system like Spotify would have many more
entities and relationships to capture all its features and functionality.

2.7 SEQUENCE DIAGRAM:

A sequence diagram consists of a group of objects that are represented by lifelines, and the
messages that they exchange over time during the interaction. A sequence diagram shows the
sequence of messages passed between objects. Sequence diagrams can also show the control
structures between objects.
A sequence diagram for a Music player would illustrate the interactions and communication
between various components or objects in the system. Here's a high-level description of what
you might find in such a diagram:
User: The diagram would typically start with a user object, representing an individual interacting
with the Music Player.

Client Interface: This object represents the user interface of the Music Player (e.g., a mobile app or
a web app).
Authentication: The user would initiate the authentication process to log in or sign up. This would
involve interactions with an authentication service, which might include checking credentials and
providing access tokens.

Search and Playback: Users can search for songs, playlists, or albums. The sequence diagram
would show the flow of user requests, including interactions with the search and playback
functionalities.

Music Database: There would be interactions with a music database or server that stores
information about songs, playlists, and albums. Queries for song data and streaming requests
would be included.

User Profile: Users can view and update their profiles. The diagram would show interactions
related to profile management.

Playlists and Library: Users can create, edit, and manage playlists. Interactions with playlist and
library management components would be shown.

In a sequence diagram, we represent these components as objects and show the order and nature
of their interactions using arrows and lifelines. Each step in a user's action would trigger a
sequence of events and communication between these objects, which the diagram would depict.

2.6 UML DIAGRAM:

"User" is an actor representing the end-users of the Spotify clone.

"Admin" is another actor who may have special privileges, such as managing content, users, or
settings.
"Musify" is the system itself, representing the core functionality of the application.
Use cases for the "User" actor might include:

• Browse Music: The user can view and explore the available music catalog.
• Search Music: Users can search for specific songs, artists, or albums.
• Create Playlist: Users can create custom playlists by adding songs from the catalog.
• Play Music: Users can listen to music by selecting songs, playlists, or albums.

The "Admin" actor's use cases might involve tasks like managing user accounts, adding or
removing music from the catalog, or configuring system settings.
2.7 CLASS DIAGRAM
A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations
(or methods), and the relationships among objects.

The class diagram is the main building block of object-oriented modeling. It is used for general
conceptual modeling of the structure of the application, and for detailed modeling, translating
the models into programming code. Class diagrams can also be used for data modeling. The
classes in a class diagram represent both the main elements, interactions in the application, and
the classes to be programmed.

In the diagram, classes are represented with boxes that contain three compartments:

The top compartment contains the name of the class. It is printed in bold and centered, and the
first letter is capitalized.
The middle compartment contains the attributes of the class. They are left-aligned and the first
letter is lowercase.
The bottom compartment contains the operations the class can execute. They are also left-
aligned and the first letter is lowercase.

3. SYSTEM FEATURES
The system features and functional requirements are described in detail, to help the reader
understand the application better and developers and testers in their future work in Music
Player.

3.1 USER INTERFACE

➢ Title Bar – shows song length and position.
➢ Menu Bar - contains “File”, “View”, “Tools” and “Help”.
➢ Left Progress Bar - shows volume on the left speaker.
➢ Right Progress Bar - shows the volume on the right speaker.
➢ Previous Button - switch to the previous song in the playlist
➢ Pause Button - temporarily stops the current playing audio.
➢ Play Button - plays and resumes the paused audio.
➢ Next Button - switch to the next song in the playlist.
3.2FEATURES / FUNCTIONS

• Add Song To Playlist

With this choice, users can choose a song from the hard disk and add it to the playlist. When a
user chooses the file then this will start playing automatically.
• Play

With this operation the chosen song starts playing. If there are no registered records in the
playlist when users
choose Play, then the user has the opportunity to choose songs from the disk automatically.

• Pause
This choice interrupts the song and if the user chooses Play then the song starts playing from the
same point.

• Stop

With this choice the song stops playing. If the user chooses the choice Play the file will start to
play from the beginning.

• Previous on Playlist

With this choice the previous song on the playlist is chosen automatically and starts playing.

• Next on Playlist
With this choice the next song on the playlist is chosen automatically and starts playing.
• Playlist
This choice pops up a new window where songs are to be played.

3.3 HARDWARE INTERFACE

Musify needs playback device for sound output.

3.4 SOFTWARE INTERFACE

These are minimum requirements to run and build Musify :

• OS – Window XP with server pack 3 installed.
• .Net framework - .Net framework 3.5
• DirectX- DirectX 3 for audio
• RAM- 512 MB
• DISK SPACE – 10 MB free space
4.FUNCTIONAL AND NON-FUNCTIONAL INTERFACE
Built into the Musify is a music player that can play music with a number of controls including
play, pause, stop, play next or previous track, seek and volume control .
•The user will be able to import music from his offline music collection which may simply refer
to a hard-drive or a flash memory
•In Import stage software will build an Internal Local Store with Information about added
tracks.
•User can remove a track from imported music and that will remove the corresponding entry
from Local Store

Functional Description
requirement
Name
Pause music The user will be able to pause the track being able to play it again
from the same timeline.

Seek track The user will be able to move anywhere in the timeline of the
track

Stop music The user will be able to stop the track which will close the track,
in order for the user to play another track or exit software

Go to next track The user will be able to play the next track

Go to previous The user will be able to play the previous track

track
Add songs The user will be able to import music from his external music
collection, to the application

Local Store is persistence layer of application, it will be implemented as SQLite Database. It will
store all the information required for software to work.

The user will be able to essentially cache data into a local store while importing a track into the
application.

• On adding a track or importing a track from the offline music library of the user to the
application the track will be added into the local store.
• On removing the track from the application the track will also be removed from the Local
store. In short the Local store maintains the library of the application.
• It will not be available for user to direct interaction, This component will be used by other
components internally.

User actions

This section will state all the use cases of the application and what the user will be able to do
with the application.

Music management

A music manager is an industry professional who works closely with artists to help them meet
their goals. Music managers help with all aspects of a music career, including music production,
performance and promotion of the artist

Control music

The user can control music in the music player component by the following actions:

• play music
• pause music
• control volume
• go to the next track
• go to the previous track
• seek a playing track

User Interactions

The following are the use cases and how the actor: user interacts with them

Use case: Manage tracks

Brief Description

The user manages tracks, can import and remove them from the application

User interaction

• Import tracks from offline music collection

• Add directories, sub directories and files to the music player.
• The user can remove the track from the application
 • The local store updates itself deleting the track

Use case: Control Music

Brief Description

The user can control music which means he/she can play, pause, stop, go to the next track, go to
the previous track, control the volume

User interaction

Click events trigger all controlling of music operations.

Use case: Edit metadata

Brief Description

The user can also manually edit his/her track’s metadata

User interaction

The user defined metadata of a track is going to be updated in the local area.

4.2 NON-FUNCTIONAL REQUIREMENTS

The non-functional requirements of the system are explained below.

4.2.1 Performance Requirements

Musify requires a small amount of disk space for installation-10MB. It is characterized by fast
loading and executing times. It‘s not a heavy program and it can work while other programs are
running.

• Quickness-- System should be fast enough to play music and respond to any of the user
action in any Way Without any shattering and buffering , else it will be not a good experience

• Robustness – System should be robust to deal and act accordingly with common errors
scenarios Unsupportable metadata, unsupportable file type etc.

• Failure Handling -- In case of failure it should be able to fail or recover quickly.

4.2.2 Safety Requirements

Exception Handling

The software should be able to restrict or warn(in the first place) the user from doing things not
suitable, like, increasing volume beyond threshold, or exiting the software without saving the
changed data.

4.2.3 Software Quality Attributes

Musify is easy to use because it is a small program. Users can easily learn to use it. The
software’s interface is quite friendly, simple, easily understood, it works fast and is organized. RC
Music Player is a very fast and efficient program and users can easily change its options to satisfy
their needs. Some Software Quality Attributes of RC Music Player are:

Memory Management - System should not leak memory.

Compatibility - System should peacefully co-exist with other software

Error Handling - System should not cause or trigger any events that will leave Operating System
in unrecoverable state

5. TESTING METHODOLOGIES

Usability testing – It is performed to the perceptive of the client to evaluate how the GUI is
user- friendly ? How easily client learn?

Functional testing – It a testing to ensure that specified functionality required in SRS . It involves
observation of output for certain input values.

System testing - System testing test the system as a whole .once all components are integrated,
the complete integration is tested to see that it needs the specific quality standards