Requirements Specification: User and System Requirements, Writing Methods, and Documentation

Requirements Specification

Requirements specification is the process of writing user and system requirements into a document; the requirements should be clear, understandable, complete, and consistent.

In practice this is difficult because stakeholders interpret requirements differently and inherent conflicts and inconsistencies often exist.

The requirements‑engineering process is iterative: the first iteration defines user requirements, followed by more detailed system requirements.

User Requirements

User requirements describe functional and non‑functional needs in natural language that non‑technical users can understand.

They should be written with simple tables, forms, and intuitive diagrams, avoiding system design details, software jargon, or formal symbols.

System Requirements

System requirements are an expanded version of user requirements used by software engineers as the basis for system design.

They add detail and explain how the system should fulfill user needs, without describing implementation or design.

System requirements can also be written in natural language, but are often expressed using structured forms or graphical notations.

Methods for Writing Requirements

The two most common approaches are natural‑language specifications and structured‑language specifications.

Natural‑Language Specification

This approach uses plain text without a predefined format, which can lead to ambiguity.

Guidelines to reduce ambiguity include creating a personal format, defining the system component that handles each requirement, highlighting key words, and avoiding unexplained abbreviations (or providing an appendix).

"(Actor) shall (do something) by (how the user triggers the feature) in order to (why – the benefit or purpose)." Example: "The system shall allow a user to register by entering a username and password in order to access the system."

Structured‑Language Specification

This method uses a more formal, structured format, often based on standard templates that describe functions or events.

Templates help ensure consistency and completeness across requirements.

Software Requirements Document (SRS)

The SRS (also called the Software Requirements Specification) is the official document describing what should be implemented; it serves as a contract between the system buyer and the developers.

It should contain both user and system requirements, typically with user requirements defined in the system‑requirements section.

When the number of requirements is large, detailed system requirements may be placed in a separate document.

The SRS must address a diverse audience—from customers to system engineers—balancing communication, detailed developer/tester guidance, and flexibility for future changes.

In agile environments, delivering a complete document up front is wasteful; instead, requirements are collected incrementally as user stories on cards, each with an estimated effort and priority, and grouped by related functionality.

The final pillar of requirements engineering is requirements validation.