Scribd
Upload
57 views

Software Requirements Specification : Group Number

This document outlines the software requirements specification for a project. It includes sections on introduction, overall description, specific requirements, and use case and data flow diagrams. The introduction provides an overview and defines terms. The overall description covers the product perspective, functions, users, constraints, and assumptions. The specific requirements section lists individual, testable requirements. Diagrams are also included to illustrate the system functionality and data flows.

Uploaded by

MAMTA YADAV
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
57 views

Software Requirements Specification : Group Number

This document outlines the software requirements specification for a project. It includes sections on introduction, overall description, specific requirements, and use case and data flow diagrams. The introduction provides an overview and defines terms. The overall description covers the product perspective, functions, users, constraints, and assumptions. The specific requirements section lists individual, testable requirements. Diagrams are also included to illustrate the system functionality and data flows.

Uploaded by

MAMTA YADAV
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 5

Group Number

AJAY KUMAR GARG ENGINEERING COLLEGE, GHAZIABAD

IT DEPARTMENT

Software Requirements Specification


<Project Name>

<Group Member Name>


<Roll No.>
Submitted to: - Faculty Name
SRS FORMAT
Table of Contents
1. Introduction
The introduction to the Software Requirement Specification (SRS) document should provide
an overview of the complete SRS document. While writing this document please remember
that this document should contain all of the information needed by a software engineer to
adequately design and implement the software product described by the requirements listed
in this document. (Note: the following subsection annotates are largely taken from the
IEEE Guide to SRS).

1.1 Purpose
What is the purpose of this SRS and the (intended) audience for which it is written.

1.2 Scope
This subsection should:
(1) Identify the software product(s) to be produced by name; for example, Host DBMS,
Report Generator, etc
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified. As a portion of this, it should:
(a) Describe all relevant benefits, objectives, and goals as precisely as possible. For example,
to say that one goal is to provide effective reporting capabilities is not as good as saying
parameter-driven, user-definable reports with a 2 h turnaround and on-line entry of user
parameters.
(b) Be consistent with similar statements in higher-level specifications (for example, the
System Requirement Specification) , if they exist.What is the scope of this software product.

1.3 Definition, Acronyms and abbreviations


This subsection should provide the definitions of all terms, acronyms, and abbreviations required
to properly interpret the SRS. This information may be provided by reference to one or more
appendixes in the SRS or by reference to other documents.

1.3 References
This subsection should:
(1) Provide a complete list of all documents referenced elsewhere in the SRS, or in a
separate, specified document.
(2) Identify each document by title, report number - if applicable - date, and publishing
organization.
(3) Specify the sources from which the references can be obtained.
This information may be provided by reference to an appendix or to another document.
1.4 Overview
This subsection should:
(1) Describe what the rest of the SRS contains
(2) Explain how the SRS is organized.

2. The Overall Description

This section of the SRS should describe the general factors that affect 'the product and its
requirements. It should be made clear that this section does not state specific requirements; it
only makes those requirements easier to understand.

2.1 Product Perspective


This subsection of the SRS puts the product into perspective with other related products or
projects. (See the IEEE Guide to SRS for more details).

2.1.1 System Interfaces


2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements

2.2 Product Function


This subsection of the SRS should provide a summary of the functions that the software will
perform.

2.3 User Characteristics


This subsection of the SRS should describe those general characteristics of the eventual
users of the product that will affect the specific requirements. (See the IEEE Guide to SRS
for more details).

2.4 Constraints
This subsection of the SRS should provide a general description of any other items that will
limit the developer’s options for designing the system. (See the IEEE Guide to SRS for a
partial list of possible general constraints).

2.5 Assumptions for dependencies

This subsection of the SRS should list each of the factors that affect the requirements stated in
the SRS. These factors are not design constraints on the software but are, rather, any changes to
them that can affect the requirements in the SRS. For example, an assumption might be that a
specific operating system will be available on the hardware designated for the software product.
If, in fact, the operating system is not available, the SRS would then have to change accordingly.

2.6 Apportioning of requirements

This will be the largest and most important section of the SRS. The customer requirements will
be embodied within Section 2, but this section will give the D-requirements that are used to
guide the project’s software design, implementation, and testing.

3. Specific Requirements
Each requirement in this section should be:
 Correct
 Traceable (both forward and backward to prior/future artifacts)
 Unambiguous
 Verifiable (i.e., testable)
 Prioritized (with respect to importance and/or stability)
 Complete
 Consistent
 Uniquely identifiable (usually via numbering like 3.4.5.6)

Attention should be paid to the carefuly organize the requirements presented in this section so
that they may easily accessed and understood. Furthermore, this SRS is not the software design
document, therefore one should avoid the tendency to over-constrain (and therefore design) the
software project within this SRS.

3.1 External Interfaces


3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
USE CASE DIGRAM OF PROJECT NAME

CONTEXT OR 0 LEVEL DFD OF PROJECT


1 LEVEL DFD
2 LEVEL DFD (IF REQUIRED)

You might also like