Customer Specification

What is a customer specification, what is the difference to a requirement specification, what is the structure and what are the advantages and disadvantages?

Customer Specification Definition

A Customer Specification is a document that describes the requirements of a desired system from the customer’s or user’s point of view. It contains the results of the customer’s requirements analysis and is therefore a wish list that a contractor should implement. DIN 69901-5 defines a customer specification as “the totality of the requirements specified by the customer for the supplies and services of a contractor within an order”.

Alternative designations are user specification, tender specification, contract document, specification sheet, or requirement catalogue.

In most cases, the requirements are formulated in the Customer Specification in natural language without going into the technical implementation. Ideally, the wording should be as general as possible and as restrictive as necessary, so that contractors can develop solutions without being too restricted in their competences. The technical implementation is documented by the contractor in the so-called requirements specification, performance specification or functional specification.

​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 provides the basis for implementation by one or more contractors.

In contrast to a Customer Specification, 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” from the customer specification,
  • 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.

Customer Specification - an example

Advantages and disadvantages of the Tender 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.

 

The Customer Specification in practice

What 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 an alternative structure.

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.

 

Creating Customer Specifications

Scenarios of the Customer Specification creation

There are three typical scenarios for the creation of specifications:

  1. the classic scenario with one or more external suppliers
  2. the internal scenario with requirements from a user department
  3. 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.

Degree of detail in the Customer Specification

Anyone who draws up a specification is faced with the challenge of finding the right level of detail. On the one hand, the wording should not be too detailed, on the other hand no essential aspects should be missing. If, for example, requirements are incomplete, this should be easy to recognise. Unnecessary contents and comprehensive prose texts generate effort – both in the description and in the subsequent discussion in the course of finding a solution by the contractor. Missing aspects increase the project risk, provoke inquiries and lead to delays; in practice, this dilemma often leads to more comprehensive specifications.

The use of a well-proven template can help in the preparation of specifications. It defines the structure, helps to ensure that the requirements are recorded uniformly, and ideally offers hints on drafting by means of short comments and examples. At the same time, the description of a solution is excluded from the outset – the description of the solution belongs in the Requirement Specification – so that the scope of the document is naturally limited. In addition, the clarity can be increased by the use of tables, because these can be easily extended or commented. The use of sketches, drawings or graphics also increases understanding without using too many unnecessary words.

Drawing up Customer Specifications is generally regarded as a demanding craft that needs to be learned and experienced. It can therefore make sense to have access to experienced partners or service providers when drawing up the specifications.

Error when creating Customer Specifications

When drawing up specifications, some mistakes are made again and again:

  • Existing tools such as MS Excel are used instead of specialised requirements management tools.
  • A clear structure facilitates both the creation and the comprehension of the described contents. Without a meaningful structure – this can arise, for example, by 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. The use of supplementary levels is recommended here, because otherwise nobody reads the document completely.
  • The prioritisation of the task to create the specifications and the time factor are underestimated. Often the formulation takes too much time, because efforts are underestimated or insufficient capacities are provided. The effects can lead to delays in delivery or even to missed market opportunities.

 

Challenges for companies

Efficiency in the preparation of Customer Specifications

The description of requirements from the user’s perspective for the development of software, systems, products or services is not as easy as it may sound at first glance. It is therefore advisable to use a specification template that is adapted to the concrete challenges. This facilitates the wording of the content, but also requires experience. There are various partners on the market who specialise in drawing up specifications. Of course, working with external partners causes costs, but inaccurately or contradictorily expressed requirements probably cost more. Anyone who deals with the definition of specifications should always take a look at profitability. If the preparation takes too much time, opportunities may be missed. If not enough capacities are available, the creation is delayed. Here, only early prioritisation and an agreed procedure can help. And experience.

Here you can find additional information from our blog:

t2informatik Blog: Inspection of the specification

Inspection of the specification

t2informatik Blog: In 14 days to the customer specification

In 14 days to the customer specification

t2informatik Blog: The best process in requirements management

The best process in requirements management