A software requirements specification (SRS) document should avoid discussing…

Answer: Design specification

Why:

The SRS should describe what the system must do and the constraints it must meet, not how the system will be implemented. Detailed architecture, module-level designs, algorithms, data structures, and code-level decisions are implementation details and belong in design documentation.

• What to include in the SRS:

• Functional requirements — clear, testable statements of system behavior.

• Non-functional requirements — performance, security, reliability, usability, etc.

• External interface requirements — protocols, data formats, and interaction contracts with other systems.

• Constraints and acceptance criteria that the solution must satisfy.

• What to avoid in the SRS:

• Detailed design and architecture decisions such as module decomposition, algorithms, and data structures.

• Low-level UI designs (pixel layouts, final mockups) and implementation-specific instructions.

• Technology- or code-level mandates that limit implementation choices without necessity.

Keep requirements implementation-independent and testable so design and implementation teams can choose the best solution while meeting specified needs.