Introduction

Commented [Instr1]: See IEEE 830 section 5.1 for a

discussion of this section and its subsections.

Purpose Commented [Instr2]: This section is about the SRS, not about
the product.

This is a partial training specification that can

be used by students in the course in Software
Engineering theory at Lovely Professional
University.
Scope 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

The product Spotify is an imaginary product that not apply for student projects.

will support listening to streamed music and

handle playlists on mobile phones, even in off-line
mode.
Overview Commented [Instr4]: This section is about the rest of the SRS,
not about the product.

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.
Overall Description
Commented [Instr5]: See IEEE 830 section 5.2 for a
discussion of this section and its subsections.

For student projects this section is relatively short. The most

important part is section 2.3

Product Perspective Commented [Instr6]: Most student products are self-contained,

so this section should simply indicate that. In this case, the sub-
sections specified in IEEE 830 are not needed.

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.
Mobile phone

Format MP3
SOL Streaming service
converter player

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 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

The product functions are described in use-cases. Scope description, but the intent is not that you repeat all the
detailed requirements from section 3.

Use-case 1: Listen to music

Description:
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

Synchornize with *
1 service
1
Streaming service
User Characteristics 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

User group 1: Kids 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

Kids are consumers in the age 7-17 are very active

would buy or use the product.

For example, for a sales tracking system, the groups might include

in building and sharing playlists. They might “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…
have difficulty understanding English, so default Include key use cases for your product, including both diagrams(s)

settings and visual interaction is a must.

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
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
System features According to the standard you normally split Data interfaces into
Software, Hardware, and Communication interfaces

Feature 1: Selecting and listening to streamed Focus on capturing all the concepts of your system, but doing so
without being repetitious.

music 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).

Introduction/Purpose of the feature Section 3.3, and 3.5-7 are optional and not used for most student
products.

The user shall be able to select and listen to music

in on-line mode. Spotify accesses the music via
lists of playlists.
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.