(ESWAR KALYAN)

An SRS is basically an organization's understanding 
of a customer or potential client's system
requirements …

The SRS also functions as a
blueprint for completing a project with as little cost 
growth
as possible. 

The SRS is often referred to as the "parent"
document because all subsequent project management 
documents,
such as design specifications, statements of work, software
architecture specifications, testing and validation plans, 
and
documentation plans, are related to it.

It's important to note that an SRS contains functional and
nonfunctional requirements only…
It serves as an input to the design specification

•	Therefore, the SRS
must contain sufficient detail in the functional system
requirements so that a design solution can be devised. 
•	It serves as a product validation check. The SRS 
also
serves as the parent document for testing and validation
strategies that will be applied to the requirements for
verification. 

1. Scope

   1.1 Identification.

Identify the system and the software to which
this document applies, including, as applicable,
identification number(s), title(s),
abbreviation(s), version number(s), and release
number(s).

  1.2 System overview.
State the purpose of the system or subsystem
to which this document applies.
  
  1.3 Document overview.
Summarize the purpose and contents of this
document.
This document comprises six sections:
•	Scope 
•	Referenced documents 
•	Requirements 
•	Qualification provisions 
•	Requirements traceability 
•	Notes 
Describe any security or privacy considerations
associated with its use.

2. Referenced Documents
   2.1 Project documents.
Identify the project management system
documents here.
   2.2 Other documents.
   2.3 Precedence.
   2.4 Source of documents.

 3. Requirements
	This section shall be divided into paragraphs to
specify the Computer Software Configuration Item (CSCI) 
requirements, that is, those characteristics
of the CSCI that are conditions for its acceptance.
CSCI requirements are software requirements
generated to satisfy the system requirements
allocated to this CSCI. Each requirement shall be
assigned a project-unique identifier to support
testing and traceability and shall be stated in
such a way that an objective test can be defined
for it.
  3.1 Required states and modes.
  3.2 CSCI capability requirements.
  3.3 CSCI external interface requirements.
  3.4 CSCI internal interface requirements.
  3.5 CSCI internal data requirements.
  3.6 Adaptation requirements.
  3.7 Safety requirements.
  3.8 Security and privacy requirements.
  3.9 CSCI environment requirements.
  3.10 Computer resource requirements.
  3.11 Software quality factors.
  3.12 Design and implementation constraints.
  3.13 Personnel requirements.
  3.14 Training-related requirements.
  3.15 Logistics-related requirements.
  3.16 Other requirements.
  3.17 Packaging requirements.
  3.18 Precedence and criticality
requirements.

4. Qualification Provisions:To be determined.

5. Requirements Traceability:To be determined.

6. Notes:
	This section contains information of a general
or explanatory nature that may be helpful, but is
not mandatory.
  6.1 Intended use. 
This Software Requirements specification shall
...
  6.2 Definitions used in this document. 
Insert here an alphabetic list of definitions
and their source if different from the declared
sources specified in the "Documentation
standard."
  6.3 Abbreviations used in this
document. 
Insert here an alphabetic list of the
abbreviations and acronyms if not identified in the 
declared sources specified in the "Documentation
Standard."
  6.4 Changes from previous issue. 
Will be "not applicable" for the initial
issue.

Revisions shall identify the method used to
identify changes from the previous issue.