What is a customer specification, how is it drawn up and what content should be included?
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.
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.
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.
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.
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.
The structure of a Customer Specification
Below you will find a description of an alternative structure:
- General description
- Defaults and restrictions
- Attachments and supplements
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.
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 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:
- 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.
Tips for drawing up Customer Specifications
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 Template for free now.
With the customer specification template you document the following contents:
- Initial situation, objectives and expected benefits
- Stakeholder and product perspective
- Scope of the desired solution and performance of the contractor
- System description, system context, scope of delivery
- functional and non-functional requirements
- Guidelines and constraints
Knowledge on 10 pages to take away.
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 in the context of Customer Specifications and requirements
There is a long list of questions in the context of Customer Specifications and requirements. You can find answers to some of the questions in our blog:
- What is a good process in requirements management?
- How can a customer specification be done within 14 days?
- What to do when there are too many requirements?
- What tips are there for conducting requirements workshops?
- How can contradictions, gaps and errors be found in specifications?
- Does it make sense to manage requirements with MS Excel?
- How can the completeness of specifications be verified?
We are sure you can think of more questions. Feel free to contact us and we will try to answer your questions or publish relevant articles.
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?
 Helmut Balzert: Lehrbuch der Softwaretechnik: Softwaremanagement
Here you can find more types and examples of specifications.
And here you can find additional information from our Smartpedia section: