SOFTWARE REQUIREMENTS

SPECIFICATION
(SRS DOCUMENT)

for

MUSIC RADIO STATION

Contents
1. Introduction ................................................................................................................................... 3
1.1. Purpose.......................................................................................................................................... 3
2. User Stories ................................................................................................................................... 3
3. Wireframe ..................................................................................................................................... 4
4. Use Case Diagram......................................................................................................................... 9
5. Detail Use Case ............................................................................................................................. 9
5.1. Select music………………………………………………………………….………………..….5
5.2. Record Music…………..……………………………………………….………………………...5
5.3. Save Music………………..………………………………………………………………….…...5
5.4. Stop Music………………………………………………….………………………………..…...5
5.5. Change Volume…………………………………………………….………………..……….…...5
5.6. Change Gain……………………………………………………….……………………………...5
6. Functional Requirement ................................................................................................................ 8
7. Non-Functional Requirement ........................................................................................................ 9
8. Implementation and Reflection ..................................................................................................... 9
 1. Introduction
This document represents the requirements specifications of the Music Radio Station
software GUI. In the document details related to functional and non-functional requirement
are mentioned as well as user cases and wireframes and user stories as well. In the first
section of the document we have mentioned the user stories, which gives us insight on what
we have to develop and what is the requirement from the user end for our software. In the
second section of the document , the overall system use case diagram are present which
represent all the basic functionalities within our software and give an overall view of
interaction between actor and the system. In next section of this document, the use cases
mentioned within the use case diagrams are elaborated in detailed tabular form and every
use case contains the flow with which they will be used. In the next section of this document
functional requirements related to our system are written in detail, these functional
requirements represent all the functionalities that the software will contain. Finally, this
document contains non-functional requirements, these requirements ensure the quality of
the system related to how well the system should perform under different conditions. In
the last we have mentioned the implementation and reflection, we have mentioned in this
section generally how we designed and developed it.

1.1. Purpose
In our music radio station you just choose sounds from a collection of quality beats, tunes
and vocals. Combine sounds and record beats/tunes in the entire library and apply sound
effects and modify them. You can save your creative music into your computers. It is
time to focus on your creative ideas. Just create music.

2. User Stories
Following are the main user stories of our system.

User Story Acceptance Criteria Priority

As a potential user, I want to record
the music that I made.
As a user, I want to save the music
that I have recorded, so I can use
listen to it whenever I want.
As a user, I shall be able to choose
and alter different beats and mix
different music tunes together as
per my liking so I can create creative
music.
 User shall be able to record the High
music he/she made.
 System shall have a record button
 System shall have a save button High
 User shall be able to download
his/her music audio file
 System shall provide user with High
different music beats and tunes.
 System shall allow user to play
and mix multiple tunes and beats
together

As a user I shall be able to stop the
music recording whenever I want.
 User shall be able to edit the
volume, pan, gain, frequency etc.
of the music he/she made.
 System shall have a stop button High

3. Wireframe
Following is the wireframe schematic page for our software that we made using
app.moqups.com. It represents the basic functionality of the software.

Figure 1: Wireframe
 4. Use Case Diagram
Following is the use case diagram of our software which shows the user interaction with
the system.

Figure 2: Use Case Diagram

5. Detailed Use Cases

5.1. UC-01: Select Music Tunes

Use Case Name: Select music tunes
Actors: User (primary actor)
Description: User shall be able to select music tunes by clicking a specific tune button from music collection
available and the particular music beat start playing
Trigger: User clicks the “music tune/beat ” button from the collection

Preconditions: PRE-1. System is available to the user

Postconditions: POST-1. User successfully selected the beat he/she wants to play.

Normal Flow: 1. User navigates to the dashboard.

2. Collection of all music tunes/ user
3. User clicks on music button
 4. System starts playing the music that the user selected
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A

5.2. UC-02: Record Music

Use Case Name: Record music
Actors: User (primary actor)
Description: User shall be able to record music tunes by clicking record button

Trigger: User clicks the “record” button from the menu.

Preconditions: PRE-1. System is available to the user

Postconditions: POST-1. User successfully record the beat that he/she made.

Normal Flow: 1. User navigates to the dashboard.

2. Collection of all music tunes/ user
3. User plays the music tunes/beats.
4. User clicks on the record button
5. System starts recording
6. User records the music he/she made.
Alternative Flows: N/A
Exceptions: User clicks the record button but doesn’t play any music.
Business Rules N/A

5.3. UC-03: Save Recording

Use Case Name: Save Recording
Actors: User (primary actor)
Description: User shall be able to save his/her recording by clicking save button

Trigger: User clicks the “save button” from the menu available.

Preconditions: PRE-1. System is available to the user

Postconditions: POST-1. User successfully saved the recording that he/she made.

Normal Flow: 1. User navigates to the dashboard.

2. Collection of all music tunes/ user
3. User plays the music tunes/beats.
4. User clicks on the record button
 5. System starts recording
6. User clicks on the save button after recording the music
7. System allows the user to download the audio file to his/her PC.
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A

5.4. UC-04: Stop Recording

Use Case Name: Stop Recording
Actors: User (primary actor)
Description: User shall be able to stop recording and music playing in the background altogether by clicking the
stop button
Trigger: User clicks the “stop button” from the menu available.

Preconditions: PRE-1. System is available to the user.

Postconditions: POST-1. User successfully stop the recording and the music playing in the background altogether.

Normal Flow: 1. User navigates to the dashboard.

2. Collection of all music tunes/ user.
3. User plays the music tunes/beats.
4. User clicks on the record button.
5. User clicks on the stop button from the menu.
6. System stops the recording and music playing altogether.
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A

5.5. UC-05: Change Volume

Use Case Name: Change Volume
Actors: User (primary actor)
Description: User shall be able to change the volume of the music output.

Trigger: User slide the “volume” slider up and down from the menu available.

Preconditions: PRE-1. System is available to the user.

Postconditions: POST-1. User successfully change the volume of music output.

Normal Flow: 1. User navigates to the dashboard.

2. Collection of all music tunes/ user.
3. User plays the music tunes/beats.
 4. User slide the volume slider up or down.
5. System changes the music output accordingly
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A

5.6. UC-06: Change Gain

Use Case Name: Change Gain
Actors: User (primary actor)
Description: User shall be able to change the gain of the music output.

Trigger: User slide the “gain” slider up and down from the menu available.

Preconditions: PRE-1. System is available to the user.

Postconditions: POST-1. User successfully change the gain of music output.

Normal Flow: 1. User navigates to the dashboard.

2. Collection of all music tunes/ user.
3. User plays the music tunes/beats.
4. User slide the gain slider up or down.
5. System changes the music output accordingly
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A

6. Functional Requirements
Following are the main functional requirements of our software.

ID Requirement Dependencies
FR-01 The user shall be able to record the music by clicking the N/A
record button
FR-02 The user shall be able to save his/her recording by FR-01
clicking the save button
FR-03 The user shall be able to stop playing recording by FR-01, FR-07
clicking the stop button
FR-04 The system shall be able to stop music playing by FR-01, FR-07
clicking the stop button
FR-05 User shall be to change volume of the recording by FR-01, FR-07
dragging (up & down) volume slider
FR-05 User shall be able to change pan of the recording by FR-01, FR-07
dragging (up & down) pan slider
 FR-06 The user shall be able to change the gain of the recording FR-01, FR-07
by dragging (up & down) gain slider from the menu.
FR-07 The user shall be able to play different music beats and FR-01
tunes from the collection available in the system
FR-08 System shall combine and merge the music sounds that FR-07
users clicks from the collection while recording.
FR-09 User shall be able to change frequency of the recording FR-01,FR-07
(mid, high low) by dragging (up & down) frequency
slider

Note: Dependencies represent on which other FR’s does a particular FR depends on.

7. Non- Functional Requirement

a. Performance
PER-1: The average response time per every user click shall be less than 5 seconds. And the
maximum average time per every click shall be less than 7 seconds.

b. Usability
USE-1: The user interface shall be user friendly i.e. the minimum amount of time taken by novice
user to learn the system shall be 10 minutes.

8. Implementation and Reflection

The design specifications were first thought out and written in the form of flow chart so we
had the basic idea to what we basic functionality we wanted to implement. We have
included the basic flowchart (Figure 3) that we made initially for our better understanding
of software at the end of this section.

After this we used wireframe to layout the structure and the basic functionality of the
software keeping in account the user needs and his/her journey using the software. The
wireframe diagram (Figure 1) is mentioned in the earlier section of this document.

Also we worked on the use case diagram to represent user interaction with the system.
From the use cases we then had a clear idea about the software functionality. We then listed
out the FR’s and NFr’s for the software.

We then listed out the arrays and buttons and different functionalities that were required in
the implementation of the software. Given below is the list of them. After this we started
working on the software and with after different errors and trials we made the music radio
station software.

buttonArray : reperesent array of class soundFile : represent the downloading file

MusicButton panSlider : control pan value for output
songArray : preload all the assets into gainSlider : control gain value for output
canvas masterGain : adjust the gain value in output
songGain : gain modulator for assets by gainSlider
 lowFilter : filter low frequency volSlider : adjust volume of the output
midFilter : filter mid frequency lowFreq : filter low frequency
highFilter : filter high frequency midFreq : filter mid frequency
recordButton : record the system sound highFreq : filter high frequency
stopButton : stop the recoding and all sound
playing in the background
saveButton : download the recording
locally to system
recorder : reference for the
p5.SoundRecorder() to start and stop
recording

 Flow-chart:

Figure 3: Flow chart