Requirements Specification

Updated 22 Jul 2026

•
def
- •
  the process of formally documenting user and system requirements in a structured format that is understandable by all stakeholders
- •
  the most common output is the Software Requirement Specification (SRS)
- •
  "A requirement not written down is a requirement that does not exist."
•
purpose
- •
  serves as a single reference point for users, analysts, developers, and testers
- •
  prevents miscommunication and dual interpretation
- •
  provides a basis for estimating cost, time, and quality
•
types of specification notation
- •
  natural language — numbered sentences; each sentence states one requirement; universally understandable but prone to ambiguity
- •
  structured natural language — requirements written on standard forms or templates; each field covers one aspect
- •
  design description languages — programming-language-like notation defining an operational model of the system
- •
  graphical notations — UML use cases, sequence diagrams, activity diagrams
- •
  mathematical specifications — formal notations based on finite-state machines or sets; unambiguous but difficult for customers to validate
•
writing guidelines
- •
  invent and use a standard format for all requirements
- •
  use language consistently — "shall" for mandatory requirements, "should" for desirable ones
- •
  use text highlighting to identify key parts of requirements
- •
  avoid computer jargon where possible
- •
  include rationale for each requirement
•
common problems with natural language specifications
- •
  lack of clarity — precision is difficult without making the document hard to read
- •
  requirements confusion — functional and non-functional requirements get mixed together
- •
  requirements amalgamation — multiple distinct requirements expressed as a single statement
•
structured (form-based) specification includes
- •
  definition of the function or entity being described
- •
  inputs and their sources
- •
  outputs and their destinations
- •
  required information and other used entities
- •
  description of the action to be taken
- •
  pre- and post-conditions
- •
  side effects
•
principles for good specification writing
- •
  unambiguous — one possible interpretation
- •
  complete — all necessary information is present
- •
  consistent — no internal contradictions
- •
  verifiable — can be tested by objective means
- •
  understandable — readable by the intended audience
•
software documentation standards evolution
- •
  DOD-STD-2167 / 2167A (1985, 1988) — early U.S. defense documentation standards for mission-critical systems
- •
  MIL-STD-498 (1994) — military standard for software development and documentation
- •
  IEEE Std 830-1993 / 1998 — Recommended Practice for Software Requirements Specifications
- •
  ISO/IEC 12207:1995, 2008, 2017 — evolving international standard for software lifecycle processes, with SRS increasingly aligned to ISO/IEC/IEEE 29148
•
related

Linked references 7

◌ Explore connections in Graph view