Coursify

Software Requirements Specification (SRS): What It Must Not Discuss

Software Requirements Specification (SRS): What It Must Not Discuss

Verified Sources
Nov 1, 2026

A software requirements specification (SRS) should focus on the “what” (the required capabilities and qualities), not the “how” (implementation/design choices). Classic SRS guidance explicitly warns against including design or implementation details—except in rare cases where higher-level needs force a design-level restriction. In other words, the SRS is meant to define requirements, including testable constraints, not to act as a design blueprint or to prematurely lock in architectural/module structure decisions. 2

Key SRS terminology

functional requirements (FR)
non-functional requirements (NFR)
design specification
implementation constraints

Footnotes

  1. IEEE 29148-2018 Standard for Requirements Engineering (IEEE Technology Navigator / summary) - Describes requirements engineering outcomes and the intent that requirements provide reference for verifying designs/solutions without implying specific implementation. ↩

  2. IEEE Std 830-1998 (PDF) - Software Requirements Specifications (SRS) - States SRS should avoid placing design or project requirements; should not describe design/implementation details; and lists design items the SRS should not normally specify. ↩

Answer to the multiple-choice prompt

The SRS should avoid discussing (iii) Design specification.

IEEE-oriented SRS guidance states that the SRS writer(s) should not describe design or implementation details, such as internal partitioning into modules, allocation of functions to modules, control/information flow between modules, or choice of data structures. 2 This corresponds directly to “design specification” (iii), whereas functional and non-functional requirements (i) and (ii) are core SRS content, and “constraints on the implementation” (iv) may be included only insofar as they are actually requirements (e.g., mandated standards, external limitations) rather than discretionary design architecture. 2

Footnotes

  1. IEEE 29148-2018 Standard for Requirements Engineering (IEEE Technology Navigator / summary) - Describes requirements engineering outcomes and the intent that requirements provide reference for verifying designs/solutions without implying specific implementation. ↩

  2. IEEE Std 830-1998 (PDF) - Software Requirements Specifications (SRS) - States SRS should avoid placing design or project requirements; should not describe design/implementation details; and lists design items the SRS should not normally specify. ↩ ↩2

  3. Software Design Specification vs. Software Requirements Specification (Jama Software) - Clarifies that SRS is the “what,” while design specification is the “how.” ↩

Elicit & define the what

Requirements definition

Capture functional requirements (FR) and non-functional requirements (NFR) plus interface/quality expectations."

Write the contract-like document

SRS baseline

Produce an SRS that is verifiable and unambiguous, serving as an input for design and verification planning. "

Footnotes

  1. IEEE 29148-2018 Standard for Requirements Engineering (IEEE Technology Navigator / summary) - Describes requirements engineering outcomes and the intent that requirements provide reference for verifying designs/solutions without implying specific implementation. ↩

Translate requirements into architecture

Design stage

Create architectural/module/integration decisions—i.e., the design specification (design spec)."

Build and test against the SRS

Implementation & verification

Implement and verify that the solution satisfies requirements and constraints specified in the SRS. "

Footnotes

  1. IEEE 29148-2018 Standard for Requirements Engineering (IEEE Technology Navigator / summary) - Describes requirements engineering outcomes and the intent that requirements provide reference for verifying designs/solutions without implying specific implementation. ↩

What belongs in an SRS (and what that implies for the choices)

An SRS typically includes:

  • functional requirements (FR)
  • non-functional requirements (NFR)
  • externally visible behavior and measurable quality attributes
  • (sometimes) constraints such as mandated standards or operating environment conditions (as requirements), rather than internal architecture. 2

A widely cited SRS guideline emphasizes:

  • specify what functions are performed on what data to produce what results, at what location for whom (i.e., required services)
  • and not normally specify design items like module partitioning, function allocation to modules, module-to-module control/data flow, or data structure selection.

This cleanly supports the multiple-choice selection of (iii) Design specification.

Footnotes

  1. IEEE Std 830-1998 (PDF) - Software Requirements Specifications (SRS) - States SRS should avoid placing design or project requirements; should not describe design/implementation details; and lists design items the SRS should not normally specify. ↩ ↩2 ↩3

  2. Software Design Specification vs. Software Requirements Specification (Jama Software) - Clarifies that SRS is the “what,” while design specification is the “how.” ↩

How to decide whether a topic should be in an SRS

  1. 1
    Step 1

    If it says the system must do X or have quality Y (testable), it fits FR/NFR. If it proposes/module-structure/how-to-build details, it belongs to design.

  2. 2
    Step 2

    SRS items should be written so they can be verified/validated. Vague “implementation intent” statements suggest design leakage.

  3. 3
    Step 3

    Words that imply partitioning, allocation to modules, specific control/data flow, or data structure choices are design/implementation details to avoid in SRS.

    Footnotes

    1. IEEE Std 830-1998 (PDF) - Software Requirements Specifications (SRS) - States SRS should avoid placing design or project requirements; should not describe design/implementation details; and lists design items the SRS should not normally specify. ↩

  4. 4
    Step 4

    If the constraint is external/necessary (e.g., regulatory standard, security mandate, required environment), you can record it as a requirement/constraint. If it is just a design preference, exclude it.

  5. 5
    Step 5

    If the statement primarily guides builders on how to implement (architecture/module/integration choices), it belongs in the design specification—not in SRS.

    Footnotes

    1. Software Design Specification vs. Software Requirements Specification (Jama Software) - Clarifies that SRS is the “what,” while design specification is the “how.” ↩

Design leakage is a common SRS failure mode

If your SRS starts describing module partitioning, internal data structures, or information/control flow between components, it’s likely drifting into design specification territory—precisely what SRS guidance discourages.

Footnotes

  1. IEEE Std 830-1998 (PDF) - Software Requirements Specifications (SRS) - States SRS should avoid placing design or project requirements; should not describe design/implementation details; and lists design items the SRS should not normally specify. ↩

Use “constraints” as requirements, not as design decisions

Including implementation constraints is acceptable when they are truly imposed requirements (e.g., required operating environment or mandated standards). Avoid encoding optional architectural choices as if they were mandatory requirements. 2

Footnotes

  1. IEEE Std 830-1998 (PDF) - Software Requirements Specifications (SRS) - States SRS should avoid placing design or project requirements; should not describe design/implementation details; and lists design items the SRS should not normally specify. ↩

  2. Software Design Specification vs. Software Requirements Specification (Jama Software) - Clarifies that SRS is the “what,” while design specification is the “how.” ↩

Mapping the options to typical SRS scope

How strongly each option should appear in an SRS (qualitative).

Common confusions

Knowledge Check

Question 1 of 4
Q1Single choice

Which topic should an SRS avoid discussing?

Explore Related Topics

1

Linear Sequential Model in SDLC: The Waterfall Model

2

Compiler Phases Question: Which Phase Is Optional?

3

Design Metrics and Tight Constraints in Embedded Systems

Embedded system design is governed by three tight constraints—physical footprint, low power/thermal limits, and deterministic real‑time execution—requiring simultaneous hardware‑software co‑optimization. Design metrics such as cost, time‑to‑market, and reliability guide trade‑offs among microcontrollers, SoCs, and FPGAs.

  • Single‑chip integration cuts area and NRE cost but restricts memory and peripherals.
  • Dynamic power = α·C·V²·f; higher frequency improves latency but raises power and heat.
  • Hard real‑time designs require guaranteed deadlines and low jitter; missed deadlines equal failure.
  • Bare‑metal gives minimal power and size; RTOS adds multitasking support with higher overhead.
Browse all research articles