# caBIG Software Requirements Document Template {#cabig-software-requirements-document-template .unnumbered}

DOCUMENT CHANGE HISTORY

  ------------ -------------- -------------------------------------------
  Version      Date           Description
  Number                      

  1.0          April 2004     Initial Document
  ------------ -------------- -------------------------------------------

*\[The Software Requirements Document (SRD) captures the software
requirements for the system, or a portion of the system. The SRD
provides a less detailed documentation of the analysis of the
requirements to present to the client for approval at the end of the
requirements phase. The SRD is to be used primarily for maintenance
releases, in which case a more detailed document like the Software
Requirements Specification would provide more information than
necessary.*

*SRD Template Instructions:*

*Throughout this template there are many italicized text areas
surrounded in brackets \'\[\]\', similar to these instructions. These
areas either prompt for user entry or provide instructions for
completing the section. **Delete** each bracketed text area after
completing the document. If a section title is italicized and surrounded
in brackets '*\[\]*', i.e.* \[*Notes*\]*, this indicates that the entire
section is **optional**.*

*Areas in regular text are standard wording that may not require
modification.*

*The completed draft of the SRD must go through the project\'s
documented review process.\]*

*\[Insert project name/task number\]*

***\[Insert application name and release version\]***

Software Requirements Document

Version 1.0

***\[Insert approval date of document\]***

Document Change Record

  ------------- -------------- -------------------------------------------
  Version       Date           Description
  Number                       

  1.0           *\[Insert      Initial document
                approval date  
                of document\]* 
  ------------- -------------- -------------------------------------------

TABLE OF CONTENTS

HST SE Software Requirements Document Template
[i](#cabig-software-requirements-document-template)

1\. Introduction [1](#introduction)

1.1 Project Description [1](#project-description)

1.2 Release Overview [1](#release-overview)

1.3 Document Overview [1](#document-overview)

1.4 Reference Documents [2](#reference-documents)

2\. Requirements [3](#requirements)

2.1 \[Heading TBD\] [3](#heading-tbd)

3\. \[*Notes*\] [4](#notes)

Appendix A -- Acronym List [5](#appendix-a-acronym-list)

\[*Appendix B -- other AppendiCES*\] [6](#appendix-b-other-appendices)

# Introduction

This Software Requirements Document (SRD) captures the software
requirements for the \[*name of the system or portion of the system and
release version.*\]

*\[The introduction of the SRD should provide an overview of the entire
SRD. It should include the purpose, scope, references, and overview of
the release being documented.\]*

## Project Description

\[This section of the SRD should describe the general factors that
affect the product and its requirements. This section does not state
specific requirements. Instead, it provides a background for those
requirements, which are defined in detail in Section 2, and makes them
easier to understand. Include such items as the background of the
project and the specific system or portion of the system covered by this
release.\]

## Release Overview

\[*This section of the SRD should fully describe the external behavior
of the application or subsystem covered by this release. It also should
describe nonfunctional requirements, design constraints and other
factors necessary to provide a complete and comprehensive description of
the requirements for the software. Include any additional details that
would explain the reasons for this release, if applicable.\]*

## Document Overview

This SRD captures the software requirements for \[name *of the system or
portion of the system and release version*\] as part of the \[*Insert
project name*\] project.

*\[Insert additional summary of the purpose and contents of this
document and describe any security or privacy considerations associated
with its use.*

*Insert any project specific comments and the type of development.\]*

The remaining SRD sections are organized as follows:

-   **Section 2. Requirements:** Describes all 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.

-   \[***Section 3. Notes:** Contains general information that aids in
    the understanding of this document*.\]

-   **Appendix A. Acronym List:** Defines the abbreviations used on the
    project.

-   \[***Appendix B. Other appendices**: Provides any additional
    information published separately for convenience in document
    maintenance.*\]

## Reference Documents

For additional project, and requirement specific information, refer to
the following documents:

-   *\[Project Name\]* Software Development Plan (SDP)

-   *\[Project Name\]* Software Configuration Management (SCM) Plan

```{=html}
<!-- -->
```
-   *\[Add any additional relationships, if any, of the SRD to project
    management plans.\]*

# Requirements

*\[This section should describe the user/system requirement analysis
conducted for the release. Include a high-level diagram, if applicable.
If the project has not identified requirements for a particular area but
must do so before project completion, so state.*

*Describe the requirement categories defined for this project and how
they fit together. This description may include a diagram, if
appropriate.\]*

## \[Heading TBD\]

\[The section heading may be entitled with a ID #, Module, Subsystem, or
however else a project categorizes their requirements.

This section of the SRD should contain all the software requirements to
a level of detail sufficient to enable designers to design a system to
satisfy those requirements, and testers to verify that the system
satisfies those requirements. For this reason, each requirement shall
have a unique identifier to support testing and traceability and shall
be stated in such a way that an objective test can be defined for it.

Remember to defer to design descriptions those characteristics that the
client is willing to leave up to the developer. If a given requirement
fits into more than one category, it may be stated once and referenced
from the other paragraphs.

After a summary of the issues at hand, the following table is to be used
to enter the line item User and System Requirements for each particular
category. A full listing of the requirements can be found in the
separate Requirements Traceability Matrix (RTM).\]

Table 2.1-1: \[Heading TBD\] Requirements

  ---------------------------------------------------------------------------------
  Req   Requirement   Requirement Description      CCR \#       Trace from User
  ID    Type                                       (Optional)   Requirement/\
                                                                Trace to System
                                                                Requirement
                                                                (Optional)
  ----- ------------- ---------------------------- ------------ -------------------
                                                                

                                                                

                                                                

                                                                

                                                                
  ---------------------------------------------------------------------------------

*\[The table above is a representation of a portion of the RTM. This
does not replace the RTM, but merely shows the client the actual line
item requirements for this system. The optional columns can be replaced
with other columns if desired.\]*

# \[*Notes*\]

*\[Insert any general information that aids in understanding this
document (e.g., background information, glossary, and rationale). This
section shall include a list of any terms and definitions needed to
understand this document.\]*

# Appendix A -- Acronym List {#appendix-a-acronym-list .unnumbered}

*\[Insert an alphabetical listing of all acronyms and abbreviations, and
their meanings as used in this document.\]*

  -------------- -----------------------------------------------------------
  Term/\         Description
  Abbreviation   

  \[????\]       \[*Insert Project Name acronym*\]

  \[????\]       \[*Insert Project all other project Test Plan specific
                 acronyms and resort the table*\]

  CCR            Configuration Change Request

  EPG            Engineering Process Group

  PM             Project Manager

  RM             Requirements Manager

  RTM            Requirements Traceability Matrix

  SCM            Software Configuration Management

  SDP            Software Development Plan

  SE             Software Engineering

  SM             Software Manager

  SOP            Standard Operating Procedure

  SPI            Software Process Improvement

  SQA            Software Quality Assurance

  SRD            Software Requirements Document

  SRS            Software Requirements Specification

  SW             Software

  TBD            To Be Determined
  -------------- -----------------------------------------------------------

# \[*Appendix B -- other AppendiCES*\] {#appendix-b-other-appendices .unnumbered}

*\[Use appendices to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As
applicable, the main text of the document should reference each appendix
where the data would logically fit within the document. Appendices may
be bound as separate documents for ease in handling. Appendices shall be
lettered alphabetically (A, B, etc.).\]*