25-06-2014, 02:00 PM
Software Requirements Specification (SRS) Template
Software Requirements.doc (Size: 309.5 KB / Downloads: 252)
. Introduction
The following subsections of the Software Requirements Specifications (SRS) document should provide an overview of the entire SRS.
1.1 Purpose
Identify the purpose of this SRS and its intended audience. In this subsection, describe the purpose of the particular SRS and specify the intended audience for the SRS.
1.2 Scope
In this subsection:
(1) Identify the software product(s) to be produced by name
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified, including relevant benefits, objectives, and goals
(4) Be consistent with similar statements in higher-level specifications if they exist
1.3 Definitions, Acronyms, and Abbreviations.
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 appendices in the SRS or by reference to documents. This information may be provided by reference to an Appendix.
1.4 References
In this subsection:
(1) Provide a complete list of all documents referenced elsewhere in the SRS
(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 can be provided by reference to an appendix or to another document.
1.5 Overview
In this subsection:
(1) Describe what the rest of the SRS contains
(2) Explain how the SRS is organized
1 Product Perspective
Put the product into perspective with other related products. If the product is independent and totally self-contained, it should be so stated here. If the SRS defines a product that is a component of a larger system, as frequently occurs, then this subsection relates the requirements of the larger system to functionality of the software and identifies interfaces between that system and the software.
A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful.
The following subsections describe how the software operates inside various constraints.
2.1.1 System Interfaces
List each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system.
2.1.2 Interfaces
Specify:
(1) The logical characteristics of each interface between the software product and its users
(2) All the aspects of optimizing the interface with the person who must use the system
2.1.3 Hardware Interfaces
Specify the logical characteristics of each interface between the software product and the hardware components of the system. This includes configuration characteristics. It also covers such matters as what devices are to be supported, how they are to be supported and protocols.
3.7.4 Feature
A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result. Each feature is generally described in as sequence eof stimulus-response pairs.
3.7.5 Stimulus
Some systems can be best organized by describing their functions in terms of stimuli.
3. 7.6 Response
Some systems can be best organized by describing their functions in support of the generation of a response.
3.7.7 Functional Hierarchy
When none of he above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by either common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be use dot show the relationships between and among the functions and data.
3.8 Additional Comments
Whenever a new SRS is contemplated, more than one of the organizational techniques given in 3.7 may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification.
Three are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful.
In any of the outlines below, those sections called “Functional Requirement i” may be described in native language, in pseudocode, in a system definition language, or in four subsections titled: Introduction, Inputs, Processing, Outputs.