Software Requirement Specification

Table of Contents
I. Project Report.....................................................................................................................................3
1. Status Report.................................................................................................................................3
2. Team Involvements........................................................................................................................3
3. Issues/Suggestions.........................................................................................................................3
II. System Requirement Specification.....................................................................................................4

1|Page
1. Overall Description.........................................................................................................................4
1.1 Product Overview.....................................................................................................................4
1.2 Business Rules..........................................................................................................................5
2. User Requirements........................................................................................................................6
2.1 Overview..................................................................................................................................6
2.2 <<Feature Name 1 – i.e Order Meals>>...................................................................................7
2.3 <<Feature name 2 – i.e: Meal Subscriptions>>......................................................................10
2.4 <<Next Feature Name..>>......................................................................................................11
3. Functional Requirements.............................................................................................................12
3.1 System Functional Overview..................................................................................................12
3.2 <<Feature Name 1>>..............................................................................................................14
3.3 <<Feature Name 2>>..............................................................................................................14
4. Non-Functional Requirements.....................................................................................................15
4.1 External Interfaces.................................................................................................................15
4.2 Quality Attributes...................................................................................................................16
5. Other Requirements.....................................................................................................................18
5.1 Appendix1 - Messages List.....................................................................................................18
5.2 Appendix2 - …........................................................................................................................18
5.3 ….............................................................................................................................................18

2|Page
I. Project Report
1. Status Report
# Work Item Status Notes (Work Item in Details)
 1   Pending  
 2   In Progress  
 3   Completed  

2. Team Involvements
# Task Member Notes (Task Details, etc.)
 1    
 2    
 3    

3. Issues/Suggestions
# Issue Status Notes (Solution, Suggestion, etc.)
 1   Pending  
 2   In Progress  
 3   Completed  

3|Page
II. Software Requirement Specification
1. Overall Description
1.1 Product Overview
This is a high-level design document of Spotify Clone Application, which is developed by TechGod
team, to provide an overview for the implementation and migration of a web-based music
application.
This document provides a professional and detail of the functionalities of the web app for users,
in which users can login by Spotify account and freely interact with some of the features
presented by the developers of team, for example :
- Login with spotify API
- Play music by clicking any song displayed on screen
- Choose songs from random/categoried playlist on Home Screen.
- Real-time audio player at the bottom of website
- Users can create new playlist, access to any play list, add/remove song from playlist.
- Users can like any song( also add to likedsong list)
- Search songs by name or genre
The design of the system described in this document bases on an assumption that the Spotify
Clone App is a music website application that implement local streaming playback of Spotify
content, stream and control audio tracks from Spotify, and get metadata about the current
playback.
The application after deployed, only support below browsers:
 Google Chrome latest version on PC
 Web responsive

4|Page
>>

1.2 Business Rules

ID Rule Definition
BR-01 Use but not allowed to interfere with 3rd party software if it is allowed in the whitelist
BR-02 Do not post inflammatory, politically or ethnically sensitive content
BR-03 We always try to bring the best foreign camp but always have to be alert if we detect
fraudulent content
BR-04 Comply with other provisions stated in the contract
BR-05 Any errors or problems please contact us immediately

2. User Requirements
(This is optional part)

2.1 Overview
a. Use Case Diagram
[Provide your use case diagram(s) which is something like the sample below]

b. System Actors
# Actor Description
1 Administrator responsible for various administrative duties surrounding a project.

5|Page
 These duties may include documentation, meeting management,
handling the project budget, and using time management skills to
help the team stay on track. 

The Menu Manager provides a graphical interface for customizing

2 Menu Manager pop-up menus for projects, subprojects, data sets, and files.

c. Use Cases List

ID Use Case Primary Actors Secondary Actors
01 Follow the interface
02 Song Search
03 Manage playlists
04 Recommend music by theme
05 Collect user habits data
06 Check contracts with music sellers
07 Check out the products purchased by customers
08 Check the product expiration date
09 Support customer inquiries
10 Filter and check divided products
11 Follow the interface
12 Song Search
13 Manage playlists
14 Recommend music by theme
15 Collect user habits data
2.2 <<Feature Name 1 >>
a. <<Use Case Name 1.1>>
[Provide the specification for the related use case following the table format as below.
UC ID and Name: UC-01 Register an account

Created By: Trần Đình Hoằng Date Created: 15/5/2022

Primary Actor: teenager Secondary Actors: Older people

Trigger: A Patron indicates that he wants to register an account

Description: User need to use email account or facebook account to register. and then
the user just needs to enter the username and password

Preconditions: PRE-1. Patron is logged into COS.

PRE-2. Patrons are registered to listen to music in a free way.
Post-conditions: POST-1. SUCCESSFUL REGISTRATION is stored in COS with a status of
“Okela”.
POST-2. Update the latest playlists all over the world
POST-3. Listen to a certain number of songs every day
Normal Flow:

Alternative Flows:

Exceptions:

6|Page
 Priority: High

Frequency of Use: Approximately 1.500.000 users, average of one usage per day. Peak usage
load for this use case is between 8:00 p.M. and 12:00 p.M. local time.

Business Rules: BR-1, BR-2, BR-3, BR-4, BR-11, BR-12, BR-33

Other Information:

Assumptions: Assume that 30 percent of Patrons will be update our VIP account.

UC ID and Name: UC -001

Created By: HGP Date Created: 27/03/2022

Primary Actor: Patron Secondary Actors: founder

Trigger: A Patron indicates that he wants to listen a song offline

Description:  A Patron accesses the application from the website or mobile app, choose
a song and look for the download icon, which looks like a downward-facing
arrow. When you see a green arrow next to the track, album, or podcast,
that means your download is complete and ready for offline playback

Preconditions: PRE-1. Patron is logged into App.

PRE-2. Patron have premium account

Post-conditions: POST-1. The account is check premium or not

POST-2. Check the internet connection of device
POST-3. Started to download the song
Normal Flow: 1. patron access a song
2. app display feature Patron wants to use
3. Patron choose the Download button
4. App check the account is premium or not

5. Started to download
Alternative Flows: 1.1 The Patron want to update to premium account
Give Patron an access to buy premium account page
Return step 4 of normal flow
1.2 The Patron want to download playlist that have this song

Access to that playlist and return step 2 of normal flow

Exceptions: The Patron account is not premium

Priority: High

Frequency of Use: has 300 downloads per day

Business Rules: BR-01 BR-02

Other Information: Expect high frequency of executing this use case within first 2 weeks after
system is released.

7|Page
 Assumptions: Assume that 70% premium account want to download new release album
of famous singer

3. Functional Requirements
3.1 System Functional Overview
a. Screen Flow
[This part show the system screens and the relationship among screens. You can draw the Screens
Flow for the system in the form of diagram as below]

b. Screen Details
[Provide the descriptions for the screens in the Screens Flow above]
# Feature Screen Description
1 Search song Create Order
2 Search song Change Order  
3 Play song Play Order
4 Play song Stop Order
5 Play song Skip Order
6 Play song Back order
7 Play song Repeat order
8 Search singer Create Order
9 Add playlist Create Order
1
0 Add playlist Change Order
1
1 Delete playlist Change Order

8|Page
c. Screen Authorization
[Provide the system roles authorization to the system features (down to screens, and event to the
screen activities if applicable) in the table form as below – replace Role1, Role2,… with the specific
system user role names]

Screen Role1 Role2 Role3 Role4 RoleX

<<Screen Name1>> X X X
<<Screen Activity>> X X
<<Screen Name2>> X X
Query All Data X
Query Own Data X
Query Managed Data X
Add New Data X X
Update All Data X
Update Own Data X
Update Managed Data X
Delete Data
…
In which:
 Role1: <<role1 description>>
 Role2: <<role2 description>>
 …

d. Non-Screen Functions
[Provide the descriptions for the non-screen system functions, i.e batch/cron job, service, API, etc.]
# Feature System Function Description

<<Feature <<Function
1 <<Function Name1 Description>>
Name>> Name1>>

2 …

e. Entity Relationship Diagram

Authentication Module:

9|Page
 o Sign in Component will request authorization to access access data and controls by
register the user’s Spotify account and password to the Spotify Account Service then
redirect user to Main page.
a. User module:

o Authentication Service controls the range of what User can do to User Service and
Library Service using validation based on the Spotify Accounts Service.
o User after authenticated is freely access to User’s Playlist and User/Library Services
o User’s Playlist handle event related to user like: update user’s playlist, … then update
playlists to Library Service

b. Player module:

10 | P a g e
 o Play/Pause selected any single song or song from a playlist
o Next/Previous song from a playlist
o Like/Unlike the playing song to add/remove from User’s Playlist
o Adjusting volume of song

c. Library Module

d. Search Module

11 | P a g e
12 | P a g e
Entities List

# Entity Description
1 Search module
2 User module
3 Player module
4 Library module

Software and licenses

o The following table describes the third-party technical libraries and applications that are
used to build this Blog App

# Libraries/Applications Purpose Version Need license?

1 ReactJS For front end 17.0.1 No

implementations

2 React-router-dom For front end 5.2.0 No

implementations

3 Css-module For front end No

implementations

4 Redux For front end 4.0.5 No

implementations

5 Material UI For front end 1.7.1 No

implementations

6 Redux-saga For front end 1.1.3 No

13 | P a g e
 implementations

Component Interactions
a. Login & Logout:

In Login Component, these are the interactions:

At the Homepage, user clicks the Login Button on Navbar, redirect to the Spotify
Login Page. User fills out his/her username and password in the provided Form and submit.
A request is sent to authenticate the data of the user, if something is mistaken
(wrong password, wrong username), authentication fails and the Form shows the error.
If the Spotify Authentication Service validates the data matched with user’s data on
server, then it will return the Access token and the application can grant access to data &
control then redirect User to the Main Page.

14 | P a g e
In Logout Component, these are the interactions:

 After clicking the Sign out button, a request is made to the Authentication Service, then the
Authentication Service update the the token status by CLEAR_TOKEN of the user
 After that, user is redirected to Home page and is restricted to some functionalities that
interacts with the App

b. Show Playlist
Updating..

c. Player
Updating…

15 | P a g e
 d. Creat/Delete Playlist/Add Song to Playlist
Updating…

e. Search songs by name or genre

Updating…

1. Additional Features
a. Share to Social media:
 Updating…
b. Dark-Light Mode:

2. Deployment architecture
a. DEV/MASTER environment:
 DEV: for developer can code and test feature function.
 MASTER: for users to run system with real data

Each environment is contained in a separate resource group. This helps administrator easy to
control the environment state as well as analyze and resolve issues.

The figure below describes how a web application stands up on FireBase.

b. Deployment Process
1. Developers need to implement and run the application to DEV environment and do
Test feature first.
2. If any test case false, the leader will log bugs and assign to member to vertify and
resolve. Then team member will re-test function.
3. When all UT test case are passed, leader will merge from dev branch to master branch.
4. Developers deploy app into the server using CICD.

16 | P a g e
5. Developers re-test all function in server app.
6. If any test case false, the leader will log bugs and assign to member to vertify and
resolve. Then team member will re-test function.
7. When all UT test case are passed the app has complete.

17 | P a g e