Software requirements specification (SRS): template and example

A practical SRS outline

This is a starting outline for a software component, not an official ISO or NASA template. Add the sections your project and governing obligations require.

Use this plain-text template in your existing documents or issue tracker. No signup needed.

Download the template (.txt)

1. Purpose and scope
   Users, problem, component boundary and exclusions.
2. Context and interfaces
   External systems, inputs, outputs and interface contracts.
3. Functional requirements
   Stable ID, trigger, required behavior and exceptional cases.
4. Quality requirements and constraints
   Performance, safety, security, reliability and resource limits.
5. Assumptions and dependencies
   Operating conditions, external guarantees and open decisions.
6. Verification and acceptance
   Observable criteria, planned methods and evidence references.
7. Governance and change history
   Sources, owners, approval state, revisions and superseded intent.

A product brief explains the problem and value. The SRS makes the software obligations specific. The design explains how to fulfill them. Keeping these roles distinct helps expose a requirement that was quietly rewritten to suit the implementation.

Example: a resumable import

The following requirements are illustrative candidates. They require review against the product’s actual recovery and data-integrity promises.

• IMP-01, replay identity: after an interrupted import resumes, a previously committed source record must not create a second destination record. Check a restart immediately after commit and before checkpoint acknowledgment.
• IMP-02, rejected input: an invalid source record must be reported with its identity and reason; it must not be reported as successfully imported. Check malformed and unsupported records.
• IMP-03, changed source: if the source revision differs from the recorded checkpoint basis, the importer must refuse to resume that checkpoint and report the mismatch. Check a modified source before restart.

The planned checks above are not results. Record their execution separately. Also decide what happens to later valid records after a rejected one, how long identities are retained and which storage guarantees the importer relies on. Those unresolved decisions prevent this small example from being mistaken for a complete SRS.

Use a traceability matrix to connect these requirements to implementation and reported results.

Organize around responsibilities

For an import subsystem, describe accepted inputs, transformation rules, rejected records, persistence, restart behavior, and reporting. Identify boundaries with storage and downstream consumers. State resource limits and environment assumptions where they affect the promise.

Keep the stakeholder rationale visible through the hierarchy. Lower-level detail should refine the promise, not quietly change it to match the implementation.

Give every statement enough context to review

Use stable identifiers, explicit lifecycle and approval state, rationale or parent links, measurable acceptance expectations, and ownership. Separate environmental assumptions from system guarantees. Record constraints deliberately rather than embedding unexplained implementation preferences in every sentence.

Sources can include existing contracts, designs, tests, code, and incidents. Recovered statements remain candidate intent until reviewed under the applicable authority policy. Existing behavior may include defects that the specification should expose rather than canonize.

Generate a document without mistaking it for evidence

proof doc list-templates
proof doc generate npr7150-srs --format html \
  --output docs/srs.html

Proof includes this SRS template and renders it from repository data. The template name does not establish NASA compliance or approval. Generation does not run tests, refresh model results, or resolve missing requirements.

Review the document's scope, assumptions, trace links, and evidence freshness before sharing it for a decision. A polished export can faithfully contain incomplete or stale records.

Maintain the specification through change

1. Record why the proposed change is needed and which requirements it affects.
2. Review any change to the governing promise through the correct authority.
3. Update derived requirements, interface agreements, and implementation links.
4. Rerun the affected evidence and retain its versions and limitations.
5. Regenerate the document as a view of that current state.

A defect may reveal missing intent, a weak refinement, or an implementation violation. Preserve that distinction in the record. The specification then becomes useful for the next change instead of a document that is only accurate on publication day.

Continue from here

Create a scoped summary. Refine responsibilities through the hierarchy.

Bring one software component and the requirements document that should govern its next change. Bring a change to Proof.