King Saud University
College of Computer and Information Sciences
Information Technology Department
GUIDE FOR WRITING A PROJECT SRS
DOCUMENT PREPARED FOR
CAP312: SW ENGINEERI NG PROJECTS- PART 2
Version: 1
Date: November 2009
Prepared by: Maha Al-Yahya and Latifa AlAbdulkarim
Guide for writing a project SRS Document
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.
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
Page 2
Guide for writing a project SRS Document
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
“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?
Page 4
Guide for writing a project SRS Document
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
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]
Page 5
Guide for writing a project SRS Document
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
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:
Page 6
Guide for writing a project SRS Document
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
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 7