Requirements Specification: From Zero to Hero with Templates!

1. What Is a Requirements Specification?

A requirements specification (also known as a statement of work, or in German: Lastenheft) is a key element in traditional project documentation. It describes the client’s requirements for the deliverables to be produced within a project and thereby defines the “Scope” cornerstone of the Magic Triangle. Writing the requirements specification is typically the responsibility of the client. It serves as a specification and the basis for requests for proposals and tenders. Requirements specifications are usually created during the project management phase “Initiation.” They are a prerequisite for being able to create a project plan and define a significant portion of the project scope.

After receiving the requirements specification, a potential contractor translates the deliverables (requirements) into the necessary activities (obligations) and creates the so-called functional specification. This forms part of the proposal to the client. In the simplest case, the functional specification consists of a reference to the requirements specification along with a deadline and a price.

The requirements specification and functional specification should be part of the contract between client and contractor. They should be prepared before the project begins, which may require a separate project for larger undertakings.

2. How Is a Requirements Specification Structured?

Based on the V-Model XT, a requirements specification should be structured as follows:

• Introduction
• Description of the Current Situation and Objectives
• Functional Requirements
• Non-Functional Requirements
• Overall System Architecture
• Functional Safety Requirements
• Scope of Delivery
• Acceptance Criteria and Acceptance Testing Procedures
• Glossary

In the following sections, we will go through each section in order. For a quick start, we have created a requirements specification template.

Introduction

In the introduction, we provide an overview of the motivation for the project and give a brief summary of the expected benefits.

Current Situation and Objectives

In the second section of the requirements specification, the current situation and the reason for carrying out the project are clearly presented. The benefit or added value compared to existing solutions — and thus the motivation for carrying out the project — is described in generally understandable terms.

Additionally, all relevant stakeholders of the project are named, and the technical and domain-specific integration of the system to be developed into its environment is outlined. This also defines the system boundary and highlights the interfaces to other systems. Initial framework conditions for development are identified and described, such as the specific development process defined in the project manual, technical specifications, or safety requirements.

Functional Requirements

Functional requirements describe the capabilities of the system that enable a user to solve a domain-specific problem. The requirements are derived from the business processes to be supported and the usage workflow descriptions.

There are many methods for representing functional requirements. Examples include:

• Use Cases. On their own, these are often too coarse-grained to derive concrete behavior and are therefore frequently combined with other modeling approaches.
• Goal-Scenario with emphasis on the scenario. The desired behavior is described in scenarios. This method is particularly suitable for systems that expose a large part of their functionality through the user interface.
• Block diagrams are well suited for technical systems and control systems.
• Data models are helpful for data-centric systems. A data model serves as the foundation for the subsequent database design.

Functional requirements are the central specifications for system development. They are carried over into the functional specification and refined as needed.

Non-Functional Requirements

Non-functional requirements are system requirements that contribute to the usability of the system but are not domain-specific in nature. These include, for example, requirements for usability, performance, or scalability of the system.

The properties defined by non-functional requirements must already be considered during the design phase and often contribute to development costs. Requirements that do not clearly belong to the functional requirements are assigned to the non-functional requirements.

Overall System Architecture

It is practically impossible to define user requirements solely in the problem space without considering the solution space. It therefore makes sense to outline an overall system architecture from the user’s perspective already during the creation of the requirements specification. This functional system architecture also defines the interfaces to any adjacent systems.

If the use of off-the-shelf products is planned, these should be identified and documented in the overall system architecture. The system architecture also includes a description of the deployment environment and, where applicable, the definition of security requirements.

Functional Safety Requirements

If the requirements specification concerns safety-critical systems, this section defines the requirements for handling functional safety. The risks associated with system operation are identified, classified by severity, and assigned an estimated probability of occurrence. For each identified damage scenario, a risk acceptance matrix specifies which risk class is tolerated for which severity class and probability of occurrence.

Scope of Delivery

In this section of the requirements specification, all items and services that are to be delivered during or at the conclusion of the project by the contractor are listed. The scope of delivery may include an entire system, parts thereof, documents, and services.

Acceptance Criteria and Acceptance Testing Procedures

Acceptance criteria define the properties and behavior that a delivery must fulfill in order to meet the requirements. The criteria should be presented in a measurable way and can be structured by initial situation, action(s), and expected result. Acceptance criteria can relate both to individual requirements (“Under what conditions is the requirement considered fulfilled?”) and to the scope of delivery (“What conditions must be met for a specific delivery to be accepted?”). The acceptance criteria form the basis of the acceptance test.

It is advisable to describe acceptance criteria in the form of concrete acceptance scenarios that the system must pass upon delivery.

The acceptance criteria can be further detailed after the contract is awarded, which can also help to refine the requirements. The expected results of the acceptance and the procedure for the acceptance test for each delivery should in any case be defined in detail before the acceptance and agreed upon between client and contractor.

3. What to Consider When Writing a Requirements Specification?

Level of Detail

Unfortunately, there is no “right” level of detail. If the document is superficial and vague, there is a high risk that the delivered product will not meet the client’s expectations, often leading to additional claims or legal disputes. An overly detailed specification, on the other hand, can unnecessarily restrict the solution space and thus inhibit innovation. It can also be very time-consuming to develop a robust requirements specification.

A reliable approach for identifying the “essential” requirements for a requirements specification remains systems analysis, which has lost none of its effectiveness even in the agile era. And it is these essential requirements that the requirements specification is primarily about.

Structure and Content

1	Clearly identify the requirements in the specification as such and separate them from contextual information.
2	Give each requirement a unique identifier.
3	Formulate mandatory requirements with "shall."
4	Use the same terminology consistently throughout the specification for the same concept, even if the term is frequently repeated.
5	Define an acceptance criterion or verification method for each requirement from the start.
6	Prefer tables and graphical representations over text descriptions.
7	Formulate exactly one requirement per paragraph or sentence, never multiple.
8	Document the source of a requirement where it is known, or reference it.
9	Define potentially ambiguous terms and designations in a glossary.
10	Do not use "/" or "resp." without clearly indicating whether you mean "and," "or," or "and/or."

Writing Style for Requirements

1	Use proven sentence patterns as shown in the examples further below.
2	Formulate requirements in complete sentences, not as bullet points.
3	Use active voice and avoid passive constructions.
4	Write short sentences and avoid nested clauses.
5	Avoid "weak words" (e.g., but, overly, absolutely, other, extremely, also, accordingly — see extended list below).
6	Avoid qualitative adjectives such as slow, fast, beautiful, hot, cold, cyclic, etc.

Sentence Patterns

Use proven sentence patterns such as the following:

• [Condition] “When the pressure exceeds 1 bar,”
• [Requirement keyword] “shall”
• [Subject] “the controller”
• [Object] “the relief valve”
• [Action] “open”

For formulations in agile project management, the following sentence pattern is commonly used:

• [As a {Role}] As an administrative user
• [I want to {do something}] I want to import a column from an Excel spreadsheet
• [in order to {Goal}] in order to populate a selection list

Avoid “Weak Words”

Using words from the following list indicates vague ideas regarding the requirements. When writing a requirements specification, these expressions must not appear in the finalized requirement texts (adapted from Dreher, Marion).

A	about, absolutely, actually, almost, also, always, apparently, approximately, as if, at all
B	basically, best, better, broadly
C	ca., clearly, completely, considerably
D	definitely, deliberately, distinctly
E	easily, elementary, enough, especially, essentially, even, eventually, evidently, exactly, exceptionally, extremely
F	fabulous, fairly, fast, few, formerly, frequently
G	generally, good, great, greatly
H	hardly, hopefully, however, hugely
I	ideally, if possible, immediately, in the meantime, intuitively
J	just
K–L	largely, likely, little, long
M	mainly, many, maybe, moderate, more, more or less, most, mostly, much
N	naturally, nearly, normally, nothing
O	obviously, occasionally, often, only, optimal
P	partly, perhaps, plausible, possibly, presumably, probably, properly
Q	quasi, quite
R	rather, really, reasonable, regularly, roughly
S	seemingly, seldom, self-explanatory, several, should, simply, slowly, some, somehow, sometimes, soon, special, strongly, supposedly, surely
T	temporarily, terribly, thoroughly, too, typically
U	under certain circumstances, undoubtedly, unfortunately, unless, unlikely, usually
V	various, very, virtually
W	well, widely, without doubt

4. Requirements Specification and PM Standards

DIN 69901-5:2009-1 “Project Management — Project Management Systems — Part 5: Terms” defines the term Lastenheft (requirements specification) in the sense described above. The PMBOK Guide 2008 defines the Statement of Work (SOW) somewhat more narrowly. There, the SOW is defined as a description of the services or works to be provided. This only covers the specification of the product or service.

ICB 3.0 does not explicitly name a requirements specification. Instead, it only refers to “project scope” and “deliverables.” In the German Competence Baseline NCB 3.0, the term pair Lastenheft/Pflichtenheft (requirements specification/functional specification) is additionally mentioned under the technical competence “Scope and Deliverables.”

PRINCE2 completely dispenses with the concept of requirements specification and functional specification, as it does not describe procurement processes. In terms of content, PRINCE2 uses the project mandate and the project product description for the overall project instead. In place of requirements specifications to be created within the project, PRINCE2 uses the work breakdown structure, product descriptions, and management strategies.

5. Requirements Specification Templates

You can significantly speed up writing your requirements specification. Download a requirements specification template here. Templates are available in Microsoft Word format as well as for the Allegra project management software.

6. Further Reading

Read more about how to easily create a functional specification.