Introduction
Commented [Instr1]: See IEEE 830 section 5.1 for a
discussion of this section and its subsections.
Purpose
This is a partial training specification that can
be used by students in the course in Software
Engineering theory at Lovely Professional
University.
Commented [Instr2]: This section is about the SRS, not about
the product.
Scope
The product Spotify is an imaginary product that
will support listening to streamed music and
handle playlists on mobile phones, even in off-line
mode.
Commented [Instr3]: This should be a short overview of your
product. Remember that the audience is people who will purchase
and use the product. Note that IEEE 830, 5.1.2 (d) generally does
not apply for student projects.
Overview
This SRS will contain an overall description and some
functionally oriented features and a few functional
requirements for parts of the software. This document
includes all the functions and specifications with their
explanations to solve related problems and Comments
with some guidelines are included. As a project of
Lovely Professional University Computer Science
Engineering (CSE) Department.
Commented [Instr4]: This section is about the rest of the SRS,
not about the product.
Overall Description
Commented [Instr5]: See IEEE 830 section 5.2 for a
discussion of this section and its subsections.
Product Perspective
The Spotify system runs on a java-enabled mobile
phone with an built-in MP3 player. The system
shall download and synchronize material from a
music steaming service, either by a cable
connection to a computer or directly over GPRS
or 3G connection to the service.
Commented [Instr6]: Most student products are self-contained,
so this section should simply indicate that. In this case, the subsections specified in IEEE 830 are not needed.
For student projects this section is relatively short. The most
important part is section 2.3
Mobile phone
Format
converter
MP3
player
SOL
Streaming service
Java platform
The Spotify system provides an end-user
interface. The major logical components are:
 List of playlist
 Playlist of music
 Music player
 Search screen
Product Functions
The product functions are described in use-cases.
Use-case 1: Listen to music
Description:
Commented [Instr7]: This section should provide a summary
description of the key functions of the product. Bulleted lists work
well for this. Note that you should be a bit more specific than the
Scope description, but the intent is not that you repeat all the
detailed requirements from section 3.
The user turns on the phone and opens the
Spotify. The preferred playlist is selected from the
list of playlists. The preferred track is selected
from the playlist. The track is played, and there
are options for controlling the play. When the
user is satisfied he or she stops the music and step
back 2 times in the menu.
Use-case 2: Synchronize with service
Description:
The user turns on the phone in on-line mode.
When the user opens Spotify, the playlists and
music are automatically synchronized with the
account on the on-line service. If synchronization
conflicts are detected, the user is prompted with a
question of how to solve them. The user continues
listening to the music in on-line mode. Whenever
SOL is left, the user is prompted with a question
about preparing for off-line listening if this is not
in the default settings of Spotify.
SOL
Listen to music
1
1
1
End-user
1
Synchornize with
service
*
1
Streaming service
User Characteristics
User group 1: Kids
Kids are consumers in the age 7-17 are very active
in building and sharing playlists. They might
have difficulty understanding English, so default
settings and visual interaction is a must.
Commented [Instr8]: Identify groups of people who will use
the product and describe how each would use it.
Name each group and use these names wherever possible throughout
the product documents, and especially in the detailed requirements.
If one group will perform all the functions of another group, explain
this here. Try to choose names that are meaningful to people who
would buy or use the product.
For example, for a sales tracking system, the groups might include
“sales rep”, sales manager, financial analyst, general manager, and
customer. Your description might note that sales managers can
perform all the functions of a sales rep, plus…
Include key use cases for your product, including both diagrams(s)
and explanatory text.
User group 2: Adults
Adults are in the ages 18-upwards and have well
organized playlists for different modes and
occasions. Whenever new features are released
these groups need to be notified, they will not
enjoy discovering things by curiosity.
Specific Requirements
System features
Feature 1: Selecting and listening to streamed
music
Introduction/Purpose of the feature
The user shall be able to select and listen to music
in on-line mode. Spotify accesses the music via
lists of playlists.
Commented [Instr9]: See IEEE 830 section 5.3 for a
discussion of this section and its subsections. (You should also
consult the examples in Appendix A.)
There is some flexibility in how you organize the material in this
section. However, in all cases, you should address external
interfaces, functional requirements, and internal data requirements
(shown here as 3.1, 3.2, and 3.4
According to the standard you normally split Data interfaces into
Software, Hardware, and Communication interfaces
Focus on capturing all the concepts of your system, but doing so
without being repetitious.
You should include some diagrams (with accompanying text) in this
section to capture some of the basic features of your system. You
should consider a preliminary class diagram (emphasizing classes
that embody external concepts of the product).
Section 3.3, and 3.5-7 are optional and not used for most student
products.
Stimulus/response sequence
The user starts the phone and Spotify and
navigates to the preferred track.
The currently selected track is played using the
audio ports. Visual information about the track is
shown on the screen.
Performance Requirements
The upper limit for connection to the service is 2
seconds.
The upper limit of the time from clicking on the
icon representing play to the time when the first
sound can be heard is 2 seconds.
Software System Attributes
Reliability
The failure density shall not exceed 1 failure per
100 hours usage time.
Availability
The average availability over a year shall exceed
167 hours per week.