1. Minimum Recommended Content

The following section outlines the minimum content for the Software Requirements Specification (SRS), consistent with the latest recommendations and best practices. The SRS provides a clear, detailed, and comprehensive definition of software requirements for a project, a Computer Software Configuration Item (CSCI), or a group of CSCIs. It serves as the foundation for design, implementation, verification, validation, and maintenance. This document reflects the results of decomposing user-defined requirements into detailed, actionable software requirements at a level sufficient for development and testing.

An SRS may be structured into multiple volumes or sections, as appropriate, as long as the documentation collectively addresses the information specified below.

a.    Introduction – The introduction sets the context for the SRS and provides essential background information. It establishes the purpose and scope of the software requirements and introduces the software system being described.

1. Purpose – Define the purpose of the SRS and its intended audience. Explain how the document supports the project lifecycle and stakeholders.
2. Scope – Describe the product or software system under development, including its key objectives, benefits, and intended users. Discuss the problem domain and how the software addresses specific user needs.
3. System Software Overview – Provide an overview of the software system and its major components, including a high-level description of its functionality, context, and relationships with other systems or environments.

b.    Computer Software Configuration Item (CSCI) requirements – The CSCI requirements section is the core of the SRS, encompassing both functional and non-functional requirements for the software product. Each requirement should be specific, testable, and traceable. Provide requirements for each of the following requirement types:

1. Functional requirements – Define the software's behavior and operations in detail, including any specific conditions or constraints. This includes, but is not limited to:
   1. General Functional requirements.
   2. Required states and modes.
   3. Internal and External data requirements.
   4. Safety requirements.
   5. Control System requirements.
   6. Algorithm requirements.
   7. Input/output (I/O) requirements, including data validation and error handling.
   8. Security and privacy requirements.
   9. Fault Management requirements (hardware and software).
   10. Operating system requirements.
   11. Board support package requirements.
   12. Partitioning requirements.
   13. Fault tolerance and common mode requirements.
2. Non-functional requirements – Describe the software characteristics that impact how the software operates and behaves. Include:
   1. Performance and Timing Requirements – Include latency, throughput, response time, and other performance constraints.
   2. Software Quality Attributes – Specify quality characteristics for the -ilities (i.e., reliability, maintainability, availability, scalability, etc.).
   3. Design and Implementation Constraints: Highlight any constraints and limitations imposed by the system, hardware, standards, compliance, regulations, or tools.
   4. Computer Hardware Resource Utilization: Define memory, processor, storage, and other resource requirements.
3. Interface Requirements – Detail the necessary interactions the software will have with systems, users, and devices for the following types of interfaces:
   1. External Software Interfaces – Describe how the software system interacts with external entities.
   2. Internal Software Interfaces – Identify interfaces between software components.
   3. User Interfaces – Specify how end-users will interact with the software, including accessibility considerations.
   4. System Interfaces – Detail interdependencies with system features or configurations.
   5. Hardware Interfaces – Describe how the software system interacts with the hardware components.
   6. Communication Interfaces – Specify protocols, data formats, and network requirements.
   7. Services Interfaces – Include requirements for connections to web services, APIs, or cloud platforms.
4. User Requirements – Define user-specific needs, focusing on usability, personalization, and human-machine interaction.

c.    Qualification provisions – Specify how the software requirements will be verified and validated during the development lifecycle. Include the qualification methods: Demonstration, Testing, Analysis, Inspection.
d.    Rationale and Supporting Information – Provide the rationale, context, and justification for requirements.
e.    Additional Requirements and Information – Include any other information necessary to describe the software requirements in full.

Software requirements specifications need not be textual and may include representations in rigorous specification languages, graphical representations, or specifications suitable for requirements analysis tools or methodologies.

2. Rationale

A Software Requirements Specification (SRS) is a cornerstone document in the software development lifecycle, detailing software performance, interface, operational, and quality requirements for each Computer Software Configuration Item (CSCI). It defines in precise terms the software product to be delivered by a provider to a customer and serves as a contractual and instructional foundation upon which all project stages are built. The SRS is vital not only as a reference document but also as a communication bridge among all stakeholders, ensuring clarity, alignment, and accountability throughout the lifecycle of the project.

The SRS is especially critical because all subsequent project deliverables—such as software architecture, design, implementation, testing, validation, and user documentation—are founded on the requirements outlined in this document. Additional supporting references, like data dictionaries or interface requirements specifications, contribute to the detail and precision captured in the SRS.

The importance of documenting the system and software requirements is reflected in standards such as IEEE 29148, which emphasizes the following benefits: IEEE 29148

• it establishes the basis for agreement between the acquirers or suppliers on what the product is to do (in market driven projects, the user input may be provided by marketing.
• it forces a rigorous assessment of requirements before design can begin and reduces later redesign.
• it provides a realistic basis for estimating product costs, risks and schedules.
• organizations can use the specifications to develop validation and verification plans.
• it provides an informed basis for deploying a product to new users or new operational environments.
• it provides a basis for product enhancement.

2.1    Rationale Behind Writing an SRS

The rationale behind developing an SRS can be further elaborated in terms of its high-impact benefits across multiple dimensions of software development:

1. 1. Clarity and Agreement
   An SRS ensures that all stakeholders—ranging from developers and testers to customers, end-users, and project managers—have a clear, consistent, and shared understanding of the system’s requirements. This is critical to avoiding misinterpretations or misalignments during development. By explicitly documenting requirements, it creates a single source of truth that bridges the gap between technical and non-technical stakeholders.
2. Foundation for Design and Development
   The SRS serves as a blueprint for the system’s architecture, guiding key design decisions, implementation strategies, and the development of subsystem components. By decomposing high-level user needs into actionable and measurable software requirements, the SRS connects user expectations with technical design solutions. This ensures that the end product fulfills its intended purpose.
3. Basis for Validation, Verification, and Testing
   A properly documented SRS provides a definitive set of measurable criteria for evaluation. It enables validation (ensuring the system meets user needs) and verification (ensuring the product satisfies its specifications). Well-defined requirements make it easier to perform robust testing and confirm that the software meets all expectations before deployment.
4. Scope Management
   The SRS clearly defines what features, functionality, and constraints are in scope and explicitly states what is out of scope for the project. By doing so, it helps manage scope creep—unsanctioned changes to the project that can lead to extended timelines, unforeseen costs, and resource misallocation—ensuring that the project stays aligned with agreed objectives.
5. Improved Communication
   The SRS acts as a communication bridge, especially between technical stakeholders (e.g., developers, testers, architects) and non-technical stakeholders (e.g., customers, end-users, business analysts). By documenting every requirement with precision and clarity, the SRS minimizes ambiguities and assumptions, fostering collaborative discussions about project goals, trade-offs, and priorities.
6. Risk Identification and Reduction
   An SRS helps identify potential technical, operational, and business risks early in the development lifecycle by exposing incomplete, infeasible, or conflicting requirements. Uncovering these risks before system design and development begins reduces the likelihood of introducing costly changes at later stages. The early identification of dependencies, constraints, and performance bottlenecks improves overall risk management.
7. Realistic Project Planning and Execution
   The SRS provides a solid basis for project planning regarding resources, cost, and scheduling. Clear and detailed requirements allow project teams to more accurately allocate resources, estimate effort for different components, and identify critical path activities. This leads to better management of budgets and timelines.
8. Basis for Product Evolution and Maintenance
   As users interact with the software and new requirements emerge, the SRS serves as a historical reference point for understanding how current features align with previously documented requirements. This informed basis enables smoother product updates, future enhancements, and scaling to new users or environments.
9. Compliance with Standards and Regulations
   For projects in regulated industries (e.g., healthcare, aerospace), the SRS is instrumental in demonstrating compliance with applicable legal, regulatory, and safety standards. It ensures that requirements related to privacy, security, and functionality are explicitly defined and adequately addressed during development.
10. Long-Term Knowledge Retention
    The SRS acts as a living document that retains organizational knowledge about the software product and its requirements. This is particularly valuable for long-term maintenance, support, and onboarding of new team members, ensuring continuity even as personnel or business needs change.

By documenting software requirements comprehensively, an SRS ultimately acts as both a technical guide and a strategic asset, aligning stakeholders, optimizing development efforts, minimizing risks, and ensuring the delivery of high-quality software that meets user needs effectively.

3. Guidance

When writing the SRS, it is important to capture specific, key information. Basic guidance for capturing that information is provided below. Other sections, not listed below, that may be included in an SRS are:

• Overview, purpose, audience, organization of the SRS.
• Definitions, acronyms, abbreviations specific to the SRS.
• Summary of history of system development, operation, maintenance.
• Project sponsor, acquirer, user, developer, and support agencies.
• Current and planned operating sites.
• References.
• Appendices.

Because requirements change and evolve over the life of the project, the SRS is typically revised as the project progresses. Guidance for managing these changes can be found in SWE-053 - Manage Requirements Changes of this Handbook. Guidance for baselining and updating the SRS in preparation for life cycle milestone reviews can be found in Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews in this Handbook. Data on requirements volatility is tracked in the Software Metrics Report.

3.1 System Overview

The SRS introduces the product whose requirements are captured in the SRS, including:

• Name or other identifier.
• General functionality, benefits, purpose, objectives, goals of the software.
• Background for the requirements, e.g., users, assumptions, constraints, functions, dependencies.
• Major components of the system and their interfaces.
• User interfaces, hardware interfaces, software interfaces, communication interfaces. (Note that software design interface descriptions will be captured in a separate Interface Design Description.

3.2 CSCI Requirements

For purposes including, but not limited to, planning work, assigning resources, and understanding the size of the software, it is helpful to organize requirements by CSCIs. For each CSCI, include:

Functional requirements

Functional requirements cover the basic actions that the software should perform, "the functions that need to be done to accomplish the objectives" . The following questions may be helpful when identifying functional requirements:

• What functions need to be performed?
• Where do they need to be performed?
• How often? (also useful for performance and timing requirements)
• Under what operational and environmental conditions? (also useful for environmental requirements)

Consider the following when capturing functional requirements:

• Validity checks on the inputs.
• Exact sequence of operations.
• Responses to abnormal situations, including:
  
  • Overflow.
  • Communication facilities.
  • Error handling and recovery.
• Effect of parameters.
• Relationship of outputs to inputs, including:
  
  • Input/output sequences.
  • Formulas for input to output conversion.
• Relevant operational modes (nominal, critical, contingency).

Because functional requirements tend to be large in number, it may be helpful to organize them into groups or subsections appropriate for the software project. Suggested groupings include functionality, performance, or coupling.

Additionally, it is helpful to understand the rationale behind a requirement to understand its intent; therefore, consider co-locating with the functional requirements the "supporting requirements rationale" described later in this guidance.

3.3 Required States and Modes

If the software "is required to operate in more than one state or mode having requirements distinct from other states or modes ... identify and define each state and mode. Examples of states and modes include idle, ready, active, post-use analysis, training, degraded, emergency, backup, launch, testing, and deployment. ... If states and/or modes are required, each requirement or group of requirements in this specification should be correlated to the states and modes. The correlation may be indicated by a table ... an appendix ... or by annotation of the requirements ..."

3.4 External Interface Requirements

External interface requirements cover all inputs and outputs for the software system and expand on the interfaces generally described in the system overview. When capturing requirements for external interfaces, consider including interfaces to items such as test equipment or transportation systems. Note that interface specifications may be captured in a separate interface requirements document; in that case, reference to the separate document needs to be included in the SRS.

Information such as the following is included, as applicable to the system:

• Identifier (name).
• Description.
• Source (input) or destination (output).
• Valid range.
• Units of measure.
• Timing.
• Window or screen layouts and relationships.
• Data formats.
• Command formats.
• Type of interface, e.g., real-time data transfer, storage-and-retrieval of data.
• Characteristics, e.g., data type, size, format, security, frequency, of data elements that the software must provide, store, send, access, receive.
• Characteristics of communication methods, e.g., message format, communication bands, transfer rate.

See also Topic 5.02 - IDD - Interface Design Description, 

3.5 Internal Interface Requirements

Internal interface requirements can cover interfaces internal to the software (i.e., interfaces between functions), if those are not left to the design phase. Note that software design interface specifications are captured in an Interface Design Description, which needs to be referenced in the SRS.

When capturing internal interface requirements, information such as that noted above for external interface requirements applies, as appropriate.

3.6 Internal Data Requirements

Internal data requirements define the data and data structures, e.g., files, databases, that are part of the software. Internal data requirements include information such as:

• Data types.
• Modes of access, e.g., random, sequential.
• Size and format.
• Units of measure.

If a database is used, consider capturing the following requirements :

• Types of information used by various functions.
• Frequency of use.
• Accessing capabilities.
• Data entities and their relationships.
• Integrity constraints.
• Data retention requirements.

3.7 Adaptation Requirements

Adaptation requirements describe data used to adapt a program to a given installation site or to given conditions in its operational environment. These requirements address topics such as "installation-dependent data to be provided by the [software] (e.g., site-dependent latitude and longitude or [communication dependencies such as local access codes]) and operational parameters that the [software] is required to use that may vary according to operational needs (e.g., parameters indicating operation-dependent targeting constants or data recording)."

3.8 Safety Requirements

While the SRS is not required to have a specific section that addresses the safety requirements, safety requirements are to be included in the SRS and designated (marked) as safety requirements.

“Software safety requirements are required to carry a unique identification or tag for traceability purposes. A way to mark and trace these requirements throughout the development and operational phases is needed in order to enable assessment of impacts and changes to the requirements. The unique identification or tag can be a special section in the requirements document, or a flag beside the requirement, or within a database. The method of identification is not important as long as it can be used for traceability and assessment.”  

Software safety requirements “are derived from the system safety requirements, standards, program specification, vehicle or facility requirements, and interface requirements." , See also Topic 8.10 - Facility Software with Safety Considerations

“The valid and invalid modes or states of operation [are documented] within the software safety requirements."   

“All software related safety constraints between the hardware, operator, and software [are included] in the software requirements documentation... When the software, hardware or operator performs a safety critical function, document the hardware, software, and operator roles in that function, the precedence, and the failure modes as well as any known constraints, controls, mitigations, conditions, timing constraints, limits, and wear-out factors that impact how software needs to respond.”

3.9 Performance and Timing Requirements

Performance and timing requirements specify measurable capacities and manageable volumes of activities for the system. Consider the following when capturing these requirements:

• Number of simultaneous users to be supported.
• Number of concurrent transactions and/or tasks to be supported.
• Amount of data to be processed within a specified time period (normal and peak loads).
• System response times.
• Failure recovery times.
• Output data availability.
• External hardware interface timing.
• Command execution timing.
• Maximum bandwidth throughput or capacity.

Performance requirements need to be defined in terms of a "minimum acceptable value needed for the system to carry out its mission"   and "the baseline level of performance desired."   This gives the design team a set of parameters in which to design the software solution.

3.10 Security and Privacy Requirements

Security and privacy requirements "specify the factors that protect the software from accidental or malicious access, use, modification, destruction, or disclosure. Specific requirements in this area could include the need to:

1. Utilize certain cryptographical techniques;
2. Keep specific log or history data sets;
3. Assign certain functions to different modules;
4. Restrict communications between some areas of the program;
5. Check data integrity for critical variables."

3.11 Environmental Requirements

Environmental requirements address environmental conditions that the system may encounter and/or in which the software must operate including "ground test, storage, transportation, launch, deployment, [target processors,] and normal operations from beginning of life to end of life."

3.12 Computer Resource Requirements

Computer resource requirements include hardware resource requirements (including utilization requirements), computer software requirements, and computer communications requirements.

Computer hardware resource utilization includes items such as "maximum allowable use of processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, and communications or network equipment capacity. The requirements (e.g., stated as percentages of the capacity of each computer hardware resource) include the conditions, if any, under which the resource utilization is to be measured."

Computer software requirements include items such as "operating systems, database management systems, communications and network software, utility software, input and equipment simulators, test software, ... The correct nomenclature, version, and documentation references of each such software item should be provided."

Computer communications requirements include items such as "geographic locations to be linked, configuration and network topology, transmission technique, data transfer rates, gateways, required system use times, type and volume of data to be transmitted or received, time boundaries for transmission, reception, and response, peak volumes of data, and diagnostic features."

3.13 Software Quality Characteristics

Software quality characteristic requirements include requirements that specify software system attributes such as :

• Reliability (the ability to perform with correct, consistent results).
• Maintainability (the ability to be easily corrected).
• Availability (the ability to be accessed and operated when needed).
• Flexibility (the ability to be easily adapted to changing requirements).
• Portability (the ability to be easily modified for a new environment).
• Reusability (the ability to be used in multiple applications).
• Testability (the ability to be easily and thoroughly tested).
• Usability (the ability to be easily learned and used).
• Other attributes.

See also 8.02 - Software Quality

3.14 Design and Implementation Constraints

Design and implementation constraint requirements address constraints that "can be imposed by other standards, hardware limitations, etc."

"Examples include requirements concerning

a) Use of a particular [Computer Software Configuration Item] CSCI architecture or requirements on the architecture, such as required databases or other software units, use of standard, military, or existing components, or use of Government- or acquirer-furnished property (equipment, information, or software)
b) Use of particular design or implementation standards, use of particular data standards, and use of a particular programming language
c) Flexibility and expandability that must be provided to support anticipated areas of growth or changes in technology, threat, or mission."

3.15 Personnel Requirements

Personnel requirements include requirements for the way users interact with the system (e.g., responsibilities, activities, modes of operation) as well as qualifications (e.g., skill level, education, background) of each user role. Interactions among user roles and permissible activities for those roles are also considered, as well as "requirements for [the] number of simultaneous users and for built-in help or training features. Also included should be the human factors engineering requirements, if any, imposed on the CSCI. These requirements should include, as applicable, considerations for the capabilities and limitations of humans, foreseeable human errors under both normal and extreme conditions, and specific areas where the effects of human error would be particularly serious. Examples include requirements for color and duration of error messages, physical placement of critical indicators or keys, and use of auditory signals."

3.16 Training Requirements

Training requirements may be part of personnel-related requirements if they describe the training required before users can properly and safely interact and use the system. Training requirements may also describe training software to be included in the software system. 

3.17 Logistics requirements

Logistics-related requirements "may include system maintenance, software support, system transportation modes, supply system requirements, impact on existing facilities, and impact on existing equipment."

3.18 Packaging Requirements

Packaging requirements address packaging, labeling, preparing, and handling the software for delivery, e.g., delivery on DVDs that are labeled and packaged a certain way.

3.19 Precedence and Criticality Of Requirements

Precedence of requirements, linking them to safety, criticality, performance, or prioritizing them based on cost, dependency, or importance facilitates selection of existing software to fulfill the requirements, allows selection of the most important requirements to implement, and can be used to define the capabilities of each software release or build.   "Having prioritized customer requirements ... ensures that functional and quality attribute requirements critical to the customer and other stakeholders are addressed quickly."   Setting precedence and criticality of requirements also facilitates planning for potential schedule or budget shortfalls. Interviewing stakeholders can help facilitate prioritization of requirements, particularly for development life cycle models that focus on addressing high-priority requirements as defined by the customer.

3.20 Qualification Provisions, e.g., Demonstration, Test, Analysis, Inspection

In addition to the requirements themselves, their verification methods "should be included in the software requirements document, either when the requirement is stated or in a separate verification matrix at the end of the document."   Verification methods include test, inspection, analysis, demonstration. 

See also Topic 5.14 - Test - Software Test Procedures

3.21 Bidirectional Requirements Traceability

Guidance for bidirectional requirements traceability is found in SWE-052 - Bidirectional Traceability of this Handbook.

3.22 Requirements Partitioning For Phased Delivery

"If the software will be developed and released in increments (phased delivery), define which requirements ... will be met for each release."

3.23 Testing Requirements That Drive Software Design Decisions

Systems may have special testing requirements, such as special system-level timing requirements, checkpoint restart requirements, or built-in self tests that must be considered when making software design decisions or when the testing may not be feasible or possible. When those situations occur, requirements reflecting those conditions need to be captured and included in the SRS.

See also SWE-055 - Requirements Validation, SWE-058 - Detailed Design, SWE-184 - Software-related Constraints and Assumptions

3.24 Supporting Requirements Rationale

Supporting rationale "Provides additional information to help clarify the intent of the requirements at the time they were written."    The supporting rationale may be located with the requirements to which it applies. Consider including the following in the requirements rationale:

• Reason for the requirement.
• Assumptions, e.g., requirement assumes availability of new technology development.
• Relationships, e.g., requirement is based on expectation for how users will interact with the software.
• Design constraints, e.g., requirements written based on decisions made during design phase.

Guidance for SWE-050 - Software Requirements also provides information on requirements rationale.

3.25 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the  in the Resources tab.

4. Small Projects

Software requirements documents are typically created from a template with the information filled in as the document grows throughout the requirements engineering activities. This is the simplest method but can be time-consuming and error-prone. Automating all or part of the requirements document creation can help with both issues. Some requirements management tools (from a previous project or owned by the Center or Agency if costs are an issue) may be able to export requirements in a format that can be included in the requirements document. Another option is to use an appropriate scripting language to write a script to pull the requirements from the tool and import them into the requirements document in an automated fashion.

For projects with a relatively small number of requirements to document, it may be helpful to use a simple spreadsheet to document and maintain the requirements. Software requirements need not be textual and may include representations in rigorous specification languages, graphical representations, or specifications suitable for requirements analysis tools or methodologies.

5. Resources

5.1 References

Enter necessary modifications to be made in the table below: SWEREFs to be added SWEREFS to be deleted SWEREFs called out in text: 061, 157, 214, 271, 273, 276, 511, 529 SWEREFs NOT called out in text but listed as germane: 001, 282, 381 Related Links Pages Refstable Topic

5.2 Tools

5.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

5.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

6. Lessons Learned

6.1 NASA Lessons Learned

• Probable Scenario for Mars Polar Lander Mission Loss (1998) (Affects of an incomplete software requirements specification). Lesson Number 0938: "All known hardware operational characteristics, including transients and spurious signals, must be reflected in the software requirements documents and verified by test."
• Consider Language Differences When Conveying Requirements to Foreign Partners (1997) (Diagrams may be useful in requirements specifications). Lesson Number 0608: "It is especially important when working with foreign partners to document requirements in terms that describe the intent very clearly; include graphics where possible."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.