Home
Smartpedia
Customer Specification

What is a Customer Specification?

Table of Contents: Definition – Content – Structure – Advantages and disadvantages – Download – Notes

Smartpedia: A customer specification is a document issued by a customer that describes the requirements of a system and the expected services of a contractor.

Customer Specification Definition

DIN 69901-5 defines a customer specification as “the totality of the demands made on the deliveries and services of a contractor within an order as specified by the client”. It is therefore a document of the client with the results of the requirements analysis and thus a wish list that a contractor is to realise.

There are several alternative names for the customer specification:

user specification,
tender specification,
contract document,
specification sheet, or
requirement catalogue.

Ideally, the wording in a customer specification should be as general as possible and as restrictive as necessary, so that contractors can develop solutions without being too restricted in their competences. Requirements are usually formulated in natural language without going into the technical implementation; this is documented by the contractor in the so-called requirements specification, performance specification or functional specification.

What Content belongs in a Customer Specification?

There are different structure proposals for Customer Specifications. For example, the VDI (Verein deutscher Ingenieure e.V. – Association of German Engineers) defines different templates for the use of conveyor and storage systems or the use of automation systems. Companies should therefore be guided by templates that have been specifically defined for their industry.

In software development, the structure described by Helmut Balzert in the “Lehrbuch der Softwaretechnik: Softwaremanagement”¹ (Textbook of Software Engineering: Software Management) is widespread:

Goal definition: Goals to be achieved with the software
Product application: application areas and target groups
Product overview: environment or context of the software
Product functions: main features of the product from the point of view of the client
Product data: (permanently stored) main data of the product
Product performance: special demands on features (time, data scope or accuracy), target conditions
Quality requirements such as reliability, user-friendliness, performance, etc.
Supplements

The Structure of a Customer Specification

Below you will find a description of a structure²:

Introduction
General description
Requirements
Defaults and restrictions
Attachments and supplements

Introduction

At the beginning of the specification it is important to build a common understanding. Explanations about the purpose and structure of the document, the terms used and the scope of the desired solution will help here:

Cover sheet with project name, project manager, responsibility, creation and modification date, storage location, version and modification directory, creator and contributors, document status (e.g. initial, finished) and verification directory.
Purpose of the document
Overview of the structure of the document
Initial situation and objectives
Scope of the desired product, software, system or service of the contractor
References to other sources and resources
Definitions and explanations of terms

In addition, it can be very useful to record the system’s benefit proposition at an early stage. A system only makes sense if it promises users a benefit and fulfils a purpose.

General description

The general description is about the classification of the desired product into the existing infrastructure of the enterprise and the description of essential characteristics:

User characteristics with the description of the target group of the product, the motifs and settings
Product perspective with the description of the relationship of the product to other products
Summary of the features that the system should provide
Restrictions and limits for development, e.g. legal rules, standards or internal specifications
Assumptions and dependencies that influence, but not hinder development, such as the use of defined databases or programming languages
Description of the system including system context, system architecture, interfaces, data model, etc.
Scope of delivery with description of the supplier’s performance, commissioning of the solution, etc.

Requirements

Requirements are the central element in a Customer Specification. In practice, they are not always as easy to collect as they might appear at first glance. Potential conflicts of interest among stakeholders, unclear underlying conditions or changing priorities at such an early stage are not uncommon. The following requirements structure is frequently encountered:

functional requirements
non-functional requirements with statements on performance, quality, usability, ergonomics, etc.
external interfaces
design limits or constraints
other requirements such as logical database requirements
supporting information such as examples, models, sketches or graphics

If other outlines are more suitable, appropriate adjustments should be made here.

Defaults and restrictions

It is possible to document defaults and restrictions that the system has to fulfil in the chapter “Requirements” or in a separate chapter. This may include the following aspects:

usability
dependability
effectiveness
changeability
transmissibility
maintainability
risk assessment
acceptance criteria

Attachments and supplements

In the last chapter, attachments and directories should be clearly managed. This includes

the sources and resources already mentioned in the chapter “Introduction”. References e.g. to the project application or the project manual with the specified requirements can also be displayed here.
List of abbreviations, list of tables, list of images.
other additions such as notes or a list of requirements to be implemented at a later date.

Advantages and disadvantages of the Customer Specification

Customer Specifications promote communication between the client and potential contractors. By documenting the wishes of users and explaining goals and challenges, it forms a good basis for the description and subsequent development of suitable solutions.

Working with Tender Specifications offers the following advantages:

Structured and well-founded description of requirements and expected deliveries and services of the contractor.
Systematic evaluation of defined requirements is made possible.
Increase of the comparability of the Requirement Specifications, since these are based on the structure of the Customer Specification.

The following disadvantages arise when working with Customer Specifications:

The expenditure for the production is high also with use of a template.
The scope increases rapidly when many details are documented.
The more comprehensive and detailed the documentation, the more difficult it becomes to understand.
Subsequent changes due to new findings are difficult to integrate.

Questions from the field

Here you will find some questions and answers from practice:

What is the difference between Customer and Requirement Specification?

Frequently there are questions as to what the difference is between a Customer Specification and a Requirement Specification.

A Customer Specification has the following characteristics:

it is drafted from the client’s point of view,
it focuses on the user and his requirements,
it describes the “what” and calls the “why” (e.g. in the form of goals),
it serves as a basis for tenders, offers or contracts,
It provides the basis for implementation by one or more contractors.

A Requirement Specification has the following characteristics:

it is expressed from the point of view of the contractor,
it addresses the system level,
it describes the “how” and thus the plan for implementing the “what”,
it serves as the basis for the conclusion of the contract between the client and the contractor,
it represents the basis for the conclusion of the contract between the customer and the contractor.

The Customer Specification is thus the basis for the Requirement Specification. Without a Customer Specification there is no Requirement Specification.

What are Scenarios of the Customer Specification Creation?

There are three typical scenarios for the creation of specifications:

the classic scenario with one or more external suppliers
the internal scenario with requirements from a user department
the competitive scenario with various potential customers

In the classic scenario, a client wants to receive a service from a client – a supplier. It is the client’s task to draft the specifications with the requirements. This task often falls within the scope of product management or marketing. Subsequently, the contractor delivers the Requirements Specification.

With the internal scenario the department is responsible for creating the Customer Specification. Since the requirements are implemented by an internal department such as IT, the boundaries between the Customer Specification and the Requirements Specification are often blurred, so that a specification document is created that includes solution descriptions in addition to the requirements.

In a competitive scenario, a company develops products for a market. However, the market participants do not produce specifications; this task is also performed by product management or marketing. Good market knowledge is important here and the requirements are ideally determined using a defined process. With the help of the Kano Model, competitiveness can possibly be increased and the use of a minimum viable product can enable early customer feedback.

What Tips for drawing up Customer Specifications are useful?

There are some tips for creating Customer Specifications:

There are various tools that are specialised for the collection and management of requirements. In many cases, these are much better suited than generally available tools such as MS Excel or MS Word.
A clear structure facilitates both the creation and the comprehension of the described content. Without a sensible structure – which can result, for example, from simply copying content from different documents – the overview is quickly lost. Without an overview, contradictory statements are overlooked, aspects are repeated and gaps are not identified.
Despite the use of templates, the number of requirements for complex systems can quickly grow into the five-digit range. Here, the use of supplementary layers is recommended, because otherwise no one will read the document in its entirety.
Prioritising the task of creating the Customer Specification and the time factor are underestimated. Often the formulation takes too much time because efforts are underestimated or too little capacity is provided. The consequences can lead to delivery delays or even missed market opportunities.
Describing requirements from a user perspective for the development of software, systems, products or services is not as easy as it may sound at first. It is therefore advisable to use a template that is adapted to the concrete challenges. This makes it easier to formulate the content, but also requires experience.

Download the Customer Specification Guide for free now.

Everything important about customer specifications at a glance.

What is a customer specification and what are the differences to a requirements specification?
What content and in particular requirements belong in the document?
What are the advantages and disadvantages?
What challenges must companies master?

Knowledge on 10 pages to take away.

Download the Guide

Impulse to discuss:

Does the backlog replace the customer specification in agile product development? And how difficult is it to find the right level of detail in specifications?

Notes:

[1] Helmut Balzert: Lehrbuch der Softwaretechnik: Softwaremanagement
[2] Here you can find a Customer Specification Template to download for free.

Other sources:

Here you can find more types and examples of specifications.

And here you can find additional information from our Smartpedia section:

What is a Minimum Viable Product?

How does Prioritisation work?

What is the Kano-Model?

t2informatik develops and modernises software as a service provider. Click here to learn more.