King Saud University

College of Computer and Information Sciences

Information Technology Department

GUIDE FOR WRITING A PROJECT

SRS

D O C U M E N T PR E P A R E D F O R

C A P 3 1 2 : S W E N G I N E E R I N G PR O J E C T S - P A R T 2

Version: 1
Date: November 2009
 Guide for writing a project SRS Document

Prepared by: Maha Al-Yahya and Latifa AlAbdulkarim

INTRODUCTION
“The SRS document describes recommended approaches for the specification
of software requirements. It is based on a model in which the result of the
software requirements specification process is an unambiguous, correct, and
complete specification document.

Since the SRS has a specific role to play in the software development
process, the SRS writer(s) should be careful not to go beyond the bounds of
that role. This means the SRS

a) Should correctly define all of the software requirements. A software

requirement may exist because of the nature of the task to be solved
or because of a special characteristic of the project.

b) Should not describe any design or implementation details. These

should be described in the design stage of the project.

The basic issues that the SRS writer(s) shall address are the following:
a) Functionality.
What is the software supposed to do?
b) External interfaces.
How does the software interact with people, the system’s hardware, other
hardware, and other software?
c) Performance.
What is the speed, availability, response time, recovery time of various
software functions etc.?
d) Attributes.
What are the portability, correctness, maintainability, security, etc.
considerations?
e) Design constraints imposed on an implementation.
Are there any required standards in effect, implementation language, policies
for database integrity, resource limits, operating environment(s) etc.?”[1]

STYLE CONVENTIONS

FORMAT
The SRS document should be typed. All text, Figures and Tables should
appear on only one side of each sheet of paper. All pages other than the
cover sheet should have page numbers that begin with “1” on the first page
after the title page, and should continue through the last page of the
reference page, but not the appendices.

Page 2
 Guide for writing a project SRS Document

The right-hand margin should be 1.5 cm and the upper and lower margins 2 -
2.5 cm. The left-hand margin must be 4 cm on each page of the document
because of the binding. The margin instructions should be followed in the
appendices as well.

The font size in the text should be in 12, in subsections 12 and in the main
headings 14. The main headings are to be written in capitals and placed at
the beginning of a new page. All headings are to be in bold letters. Leave two
empty lines under the main heading, two empty lines above the subsection
and one empty line under it. The headings should not have more than three
numbers. A line spacing of 1.5 should be used in the text, 1 on the title page
and in the abstract. The font to be used is Times New Roman. The page
number is placed in the lower right corner.

The text should not be indented and both margins on the page should be
justified. When a paragraph continues on the next page, at least two lines of
the paragraph should be left on the upper or lower end of the page. The
paragraphs are separated from each other and from the headings with one
empty line. A new chapter is started on a new page. One empty line is
needed to separate two paragraphs.

TEXT
The text of the report should be written in complete sentences. The style
should be formal. Formal style means to avoid slang, clichés, abbreviations
that are common in spoken English or advertising. It is convention that formal
reports are written in the third person.

FIGURES AND TABLES

All Figures and Tables should have a number and a caption. If a figure or
table is extracted from a source, the source should be cited in the references.

Page 3
 Guide for writing a project SRS Document

SRS REPORT CONTENTS

A template for the project SRS report is attached. A project SRS should
include the following components:

TITLE PAGE
The title page should include:

• University, College, and Department centered

• University logo on right hand side

• Project logo just above the title

• Project title: The title should be a stand-alone statement that can fully
describe the project by summarizing the main idea of the project. The
title is supremely important. A successful title will attract readers while
an unsuccessful one will discourage readers. Compose trial versions of
the title as early as you can.

• Student names in alphabetical order, along with the IDs.

• Supervisor name

• Year and semester in HIjrii and Gregorian

TABLE OF CONTENTS
A table of contents should list each of the main sections of the SRS report,
and the beginning page numbers for each section.

INTRODUCTION

Page 4
 Guide for writing a project SRS Document

“The introduction of the SRS should provide an overview of the entire SRS. It
should answer the following:
a) Describe what the rest of the SRS contains.
b) Explain how the SRS is organized.”[1]

PROJECT SCOPE
Project scope is the boundary of the project. Think of the “project scope” as
an imaginary box you are describing that will enclose all the activities for the
team’s activities. It not only defines what you are doing, but it sets the
boundaries on what the team will not be doing. Scope answers what’s inside
the box? What’s outside the box? What is the project going to look like? How
much is your project going to contain?

USER CHARCTARISTICS
“This subsection of the SRS should describe those general characteristics of
the intended users of the product including educational level, experience,
and technical expertise. It should not be used to state specific requirements,
but rather should provide the reasons why certain specific requirements are
later specified in Section 4 of the SRS.”[1]

SPECIFIC REQUIREMENTS
“This section of the SRS should contain all of the software requirements to a
level of detail sufficient to enable designers to design a system to satisfy
those requirements, and testers to test that the system satisfies those
requirements. Throughout this section, every stated requirement should be
externally perceivable by users, operators, or other external systems. These
requirements should include at a minimum a description of every input
(stimulus) into the system, every output (response) from the system, and all
functions performed by the system in response to an input or in support of an
output. As this is often the largest and most important part of the SRS, the
following principles apply:
a) Specific requirements should be stated in conformance with all of
the requirements characteristics.
b) All requirements should be uniquely identifiable.
c) Careful attention should be given to organizing the requirements to
maximize readability.”[1]

USER REQUIREMENTS AND SYSTEM REQUIREMENTS

Page 5
 Guide for writing a project SRS Document

User requirements should determine the different software services required

by the customer, in a high level natural language.

Then for each user requirement, system requirements should define the
fundamental actions that must take place in the software in accepting and
processing the inputs and in processing and generating the outputs. These
are generally listed as “shall” statements starting with “The system shall”
“These include
a) Validity checks on the inputs
b) Exact sequence of operations
c) Responses to abnormal situations, including
1) Overflow
2) Communication facilities
3) Error handling and recovery
e) Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion

It may be appropriate to partition the functional requirements into sub

functions or sub processes.” [1]

Specific requirements format :

1. User requirement
1.1. System requirement 1
1.2. System requirement 2
1.3. System requirement 3
1.4. …..and so on.

You may also define the system requirements as use cases, if you are going
to deal with the system as objects:

Use case: <Usecase name>

Actor stimulus System response

Priority
Precondition(s)
Postcondition(s
)

NON FUNCTIONAL REQUIREMENTS

Page 6
 Guide for writing a project SRS Document

This section should answer all the special constraints and considerations in
the project, i.e.:

a) What are the factors required to establish the required reliability of the
software system at time of delivery?
b) What are the factors required to guarantee a defined availability level
for the entire system such as checkpoint, recovery, and restart. ?
c) What are the factors required to protect the software from accidental
or malicious access, use, modification, destruction, or disclosure?
d) What are the different attributes of software that relate to the ease of
maintenance of the software?
e) What is the speed, availability, response time, recovery time of various
software functions, etc.?

SYSTEM MODELS
This section should illustrate the system models that reflect the overall
system processes from different perspectives according to the software type.
Either as:

1-Behavioural Models: Data processing models that show how data is

processed as it moves through the system (Data Flow Diagram and
Entity Relation diagram).

2- OR Object Models: Use case diagrams and Class diagram.

These models should be illustrated by data dictionaries that lists all of the
names (entities, relationships, and attributes) used in the system models as
in the table below:

Name Description Type

REFERENCES
Always give complete citations for material on other sources. A proper
reference involves two components: the citation in the text and the complete
bibliographic entry in the References section. Use the Institute of Electrical
and Electronics Engineers (IEEE) style for referencing. For more information
see
http://wwwlib.murdoch.edu.au/find/citation/ieee.html

APPENDICES

Page 7
 Guide for writing a project SRS Document

An appendix is included at the end of the report. It contains information

referred to in the report that's too large to fit in the body of the report.
Provide any appendices you have in this section.

Appendices include the material needed for the report but which is
unnecessary to include in the text itself (sample agreement form with client,
graphs, and interview forms). The appendices must be referred to in the text
and they must have all the necessary information needed for interpretation.
Appendices are situated at the end of the thesis and numbered
consecutively. The written form for reference to appendices within the text is:
Appendix 1, Appendix 2, etc. In the References it is: APPENDIX 1, APPENDIX
2, etc.

REFERENCES FOR THIS GUIDE

[1] IEEE (1998) IEEE Recommended Practice for Software Requirements
Specifications.IEEE Std 830-1998 (Revision of IEEE Std 830-1993)
The Institute of Electrical and Electronics Engineers, Inc

Page 8