Software Requirements Specifications: Contents List & Representative Content

Contents List & Sample Content


The following indicates the overall content, plus the actual content of section 2, representative of the typical content: 



Contents

1.	INTRODUCTION	3

1.1.	Scope	3

1.2.	Objectives	3

1.3.	References	4

1.4.	Definitions & acronyms	4

1.5.	Responsibilities	5

2.	STANDARD / PROCEDURE DESCRIPTION	6

2.1.	Introduction	6

2.2.	Characteristics of an SRS	6

2.2.1.	Correct	6

2.2.2.	Unambiguous	7

2.2.3.	Complete	7

2.2.4.	Verifiable	7

2.2.5.	Consistent	8

2.2.6.	Modifiable	8

2.2.7.	Traceable	8

2.2.8.	Usable during the operations & maintenance phase	9

2.2.9.	Standards compliant	9

2.3.	Level of abstraction	9

2.3.1.	Problem partitioning	9

2.3.2.	Issues constraining level of abstraction	10

2.4.	Content	11

2.4.1.	Table of contents	13

2.4.2.	Introduction (section 1)	13

2.4.2.1.	Purpose (section 1.1)	13

2.4.2.2.	Scope (section 1.2)	14

2.4.2.3.	Definitions, acronyms and abbreviations (section 1.3)	14

2.4.2.4.	References (section 1.4)	14

2.4.2.5.	Document overview (section 1.5)	14

2.4.3.	General description (section 2)	14

2.4.3.1.	Product perspective (section 2.1)	14

2.4.3.2.	Product functions (section 2.2)	15

2.4.3.3.	User characteristics (section 2.3)	15

2.4.3.4.	General constraints (section 2.4)	16

2.4.3.5.	Assumptions & dependencies (section 2.5)	16

2.4.4.	Specific requirements (section 3)	16

2.4.4.1.	Functional requirement n (section 3.1.n)	17

2.4.4.2.	External interface requirements (section 3.2)	18

2.4.4.3.	Performance requirements (section 3.3)	20

2.4.4.4.	Design constraints (section 3.4)	20

2.4.4.5.	Security requirements (section 3.5)	21

2.4.4.6.	Maintainability requirements (section 3.6)	21

2.4.4.7.	Reliability requirements (section 3.7)	21

2.4.4.8.	Availability requirements (section 3.8)	22

2.4.4.9.	Database requirements (section 3.9)	22

2.4.4.10.	Documentation requirements (section 3.10)	22

2.4.4.11.	Safety requirements (section 3.11)	22

2.4.4.12.	Operational requirements (section 3.12)	22

2.4.4.13.	Site adaptation (section 3.13)	23

2.4.5.	Organising the specific requirements	23

General description (section 2)

This section of the SRS describes the general factors that affect the product and its requirements. It does not state specific requirements, it only makes those requirements easier to understand.
Product perspective (section 2.1)
Include the following points.

Describe (in overview) the business process that the system will support.

State if the product is self contained (stand alone) or a component of a larger system.

If the product is a component of a larger system describe its principal functions.

Identify principal external interfaces.

Provide an overview of computer hardware to be used if already determined.

Provide a block diagram describing major components and interfaces.

This subsection should not prescribe specific design solutions or design constraints on the solution. Rather it needs to explain why certain design constraints are specified in section 3.
Product functions (section 2.2)
This subsection provides a summary of the functions that the software will perform. It will discuss major functional areas without mentioning any of the large amount of detail that goes with those areas. The functions need to be organised so that the customer will understand them.

Include the following points:

A summary of functions to be performed.

A functional model (i.e. data flow diagram) if appropriate.

Reasons why specific requirements are stated in Section 3 (i.e. relate the functions to the business processes they support).

Where applicable, the function summary for this subsection can be taken directly from the higher-level specification.

This subsection should not prescribe specific design solutions or design constraints on the solution. Rather it needs to explain why certain design constraints are specified in section 3.
User characteristics (section 2.3)
This subsection describes the general characteristics of the users that will influence the SRS.

Describe intended system users in terms of the following:

Educational level.

Experience.

Technical expertise.

Describe the following:

The operational environment (i.e. physical location, temperature, humidity, vibration, electrical noise).

Frequency of use (i.e. occasional use, constant use). Provide reasons why specific user-related requirements or design constraints are stated in section 3.
General constraints (section 2.4)
This subsection gives a general description of any other items that will limit the developer's design options.

Define limiting factors in the creation of a design.

Regulatory policies.

Hardware/system software resource limitations (i.e. memory, disk space).

External interfaces.

Audit requirements.

Company financial control policy.

Communications protocols.

Application criticality.

Safety, security.

Operations (i.e. unattended operation).

Provide general descriptions only. Further detail specific to the requirements impacted shall be provided in section 3.
Assumptions & dependencies (section 2.5)
Define assumed factors that would cause the SRS to change should the assumption be incorrect.

The successful operation of the system is dependant upon the following assumptions and dependencies. Acceptance of this specification means acceptance of the risks associated with these issues.

For example.

Hardware availability.

Behaviour of interfacing external systems

Availability of experienced operations staff.

These assumptions and dependencies are verified individually with the customer. This verification is important in that it helps to arrive at a clear understanding between the developer and the customer which will, in turn, avoid potential contract disputes later.