The Requirements Specification: From Zero to Hero, with a Template

1. What Is a Requirements Specification?

The requirements specification (scope of work, statement of work, requirements document) is an important element in classical project documentation. It describes the client’s requirements for the deliverables to be produced within a project, and thereby defines the “scope” corner of the project management triangle. Creating the requirements specification is normally the responsibility of the client. It serves as a specification and as the basis for requests for proposals and tenders. Requirements specifications are usually created during the project management phase of “Initiation.” They are a prerequisite for being able to create a project plan and define a large part of the project scope.

After receiving the requirements specification, a potential contractor translates the required results (requirements) into the necessary activities (obligations) and creates what is known as the functional specification. This forms part of the contractor’s offer to the client. In the simplest case, the functional specification consists of a reference to the requirements specification along with a delivery date and a price.

The requirements specification and functional specification should both form part of the contract between client and contractor. They should be produced before the project begins — for larger undertakings, this may require a dedicated sub-project of its own.

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 procedure
• Glossary

In what follows we work through each section in order. For a quick start, we have created a requirements specification template.

Introduction

In the introduction, we provide a high-level overview of the motivation for the project and a brief summary of the expected benefits.

Current Situation and Objectives

In the second section, when creating the requirements specification, the current situation and the reason for undertaking the project are presented clearly. The benefits or added value compared to existing solutions — and therefore the motivation for carrying out the project — are described in terms that any reader can understand.

All relevant stakeholders in the project are also named here, and the technical and functional embedding of the system to be developed within its environment is outlined. This also defines the system boundary and identifies the interfaces to other systems. Initial constraints for development are identified and described — for example, the specific development process set out in the project manual, technical specifications, or security requirements.

Functional Requirements

Functional requirements describe the capabilities of the system that enable a user to solve a business problem. When creating the requirements specification, the requirements are derived from the business processes to be supported and from the usage descriptions for the system.

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

• Use cases. These are often too coarse on their own to derive concrete behavior from, and are therefore frequently combined with other modeling approaches.
• Goal-scenario with an emphasis on scenario. The desired behavior is described in scenarios. This method is particularly well suited to systems that expose a large part of their functionality at the user interface.
• Block diagrams are well suited to technical systems and control systems.
• Data models are useful for data-centric systems. A data model serves as the basis for the later 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 requirements imposed on the system that contribute to its usability but are non-functional in nature. These include, for example, requirements relating to usability, performance, or scalability.

The properties of a system defined by non-functional requirements must be taken into account as early as the design phase, and they frequently contribute to development costs. Requirements that cannot clearly be assigned to the functional requirements are allocated to the non-functional requirements.

Overall System Architecture

It is practically impossible to define user requirements solely within the problem space without also considering the solution space. It therefore makes sense, even when creating the requirements specification, to sketch out an overall system architecture from the user’s perspective. 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 within the overall system architecture. The system architecture further includes a description of the deployment environment and, where applicable, the specification of security requirements.

Functional Safety Requirements

Where the requirements specification concerns safety-critical systems, this section defines the requirements for handling functional safety. The risks arising during system operation are identified, classified by severity, and assigned an estimated probability of occurrence. For each identified damage scenario, a risk acceptance matrix (for example) is used to specify which risk class is tolerated for each damage category and probability of occurrence.

Scope of Delivery

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

Acceptance Criteria and Acceptance Testing Procedure

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

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

Acceptance criteria may be refined further after the contract has been awarded; this can also serve to sharpen the requirements themselves. The expected outcomes of the acceptance test and the procedure for the acceptance testing of each deliverable should in any case be specified in detail and agreed between client and contractor before the acceptance test takes place.

3. What Should You Watch Out for When Creating a Requirements Specification?

Level of Detail

Unfortunately, there is no single “correct” level of detail. If the document is superficial and vague, there is a high risk that the delivered product will not match the client’s expectations — and disputes over additional demands or legal conflicts are not uncommon. On the other hand, a highly detailed specification can unnecessarily restrict the solution space and thus inhibit innovation. It can also take a great deal of time to produce a robust requirements specification.

A reliable recipe for identifying the “essential” requirements for a requirements specification remains systems analysis, which has lost none of its effectiveness in the agile age. And it is precisely those essential requirements that a requirements specification is primarily concerned with.

Structure and Content

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

Requirements Specification Style

1	Use established sentence patterns such as those shown in the examples below.
2	Write requirements in complete sentences, not as bullet points or keywords.
3	Use active sentences and avoid passive constructions.
4	Write short sentences and avoid nested clauses.
5	Avoid "weak words" (but, too, absolute, other, extremely, also, accordingly — see the more extensive list below).
6	Avoid qualitative adjectives such as slow, fast, beautiful, hot, cold, cyclical, etc.

Sentence Patterns

Use established sentence patterns such as the following:

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

For formulating requirements 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”

The use of words from the following list indicates vague or imprecise ideas about the requirements. When you create a requirements specification, these expressions must not appear in any finalized requirement text (after Dreher, Marion).

A	about, absolutely, accordingly, adequate, additionally, almost, also, alternatively, although, another, apparently, approximately, around, as applicable, as needed, as well
B	basically, best, best possible, better, briefly
C	ca., certain, clearly, close, common, completely, considerably, convenient
D	detailed, different
E	easy, effectively, especially, etc., eventually, exactly, extremely
F	fairly, feasible, few, flexible, frequently, fully, fundamental
G	general, generally, good, great
H	hardly, high, hopefully
I	if applicable, if necessary, in general, in some cases, intuitive
J–K	just, kind of
L	large, largely, late, later, little, long
M	mainly, many, maximum, might, minimal, minor, modern, more, more or less, mostly, multiple
N	nearly, never, numerous
O	obviously, occasionally, often, only, optimal, or so
P	partially, perhaps, plausible, possibly, primarily, probably
Q	quickly, quite
R	rarely, rather, really, recent, recently, regularly, roughly
S	self-explanatory, should, significant, similar, simple, slow, small, so-called, some, sometimes, somewhat, soon, special
T	thorough, typical
U–V	ultimately, unclear, unique, usually, various, very
W	well, where applicable, while, wide

4. Requirements Specification and PM Standards

DIN 69901-5:2009-1 “Project management — Project management systems — Part 5: Terms” defines the concept of the 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 work to be performed. This covers only the specification of the product or service.

The ICB 3.0 dispenses with the explicit naming of a requirements specification. Instead, it refers only to “project scope” and “deliverables.” The German Competence Baseline NCB 3.0 does at least supplement this by naming the pair of terms “requirements specification/functional specification” under the technical competency element “Scope and deliverables.”

PRINCE2 dispenses entirely with the system of requirements specification and functional specification, since it does not describe procurement processes. In content terms, PRINCE2 substitutes the project mandate and the project product description for the overall project. In place of requirements specifications to be produced within the project, PRINCE2 uses the work breakdown structure (WBS), product descriptions, and management strategies.

5. Requirements Specification Templates

Creating a requirements specification can be significantly accelerated. You can download a requirements specification template here. The templates are available in Microsoft Word format as well as for the Allegra project management software.

6. Further Information

Read more about how to easily create a functional specification and how to properly define project scope. Tips on formulating clear requirements can be found in our article on writing a requirements specification.