What is a specification sheet?
In the specifications, a client describes in text form what results he expects from the employee within the scope of an order: the deliveries and services as well as the criteria or requirements that these must fulfill. For complex projects, such as in construction or software development, the specifications are an indispensable part of project management.
The document is primarily aimed at potential clients. They use it as a basis for drawing up the specifications and cost estimates. The requirements specification later becomes part of the contract for work and services. It also serves to document the internal expectations of a project and to coordinate them between all parties involved.
In which areas are specifications required?
The larger or more complex a project is, the more important the specifications are. It is mainly used in technical areas where products have to meet numerous specifications. Some examples:
- Software and hardware development
- Introduction of IT systems in organizations
- Plant and mechanical engineering
- Building construction and civil engineering
- Large marketing and advertising campaigns
- Development of industrial products
What is the purpose of a specification sheet?
The success of a project depends heavily on the quality of the specifications. It fulfills the following purposes during the course of the project:
Collect and coordinate expectations
As a rule, various interest groups are involved in a project. They have different requirements, expectations and goals. All this
In most cases, not all requirements can be met; sometimes they even contradict each other. Such contradictions are already apparent in the specifications. A compromise can then be found. When all parties involved accept the finished specifications, they commit to the joint agreements. This avoids conflicts in the subsequent process as far as possible.
Basis for specifications and offers from suppliers
Potential contractors draw up a specification sheet in which they describe the concrete implementation of the project. The specifications provide them with all the requirements and framework conditions that they need to fulfill. If this information were only communicated verbally or unstructured by the client, there would certainly be numerous misunderstandings and much would be lost.
Evaluate specifications
The client must check the contractor’s specifications before placing the order. To do this, the client assesses whether and how the solution described in the requirements specification matches the requirements from the specifications.
Becomes part of the contract
The specifications and requirements specification are both part of a contract for work between the client and contractor. In principle, the requirements specification serves as a guideline for project implementation. It must describe everything that needs to be delivered and in what quality. Sometimes, however, requirements are forgotten or unclear in the specifications – this should not happen, but it does. In this case, the requirements specification provides information about what the client originally intended.
ERP specification sheet template
Your project, your plan: Use our sample template for your ERP specifications and lay the foundation for a successful ERP implementation!
What is the difference between specifications and functional specifications?
Specifications and functional specifications differ in three aspects: Author, content and purpose.
Specifications
- Author: Is written by the client.
- Content: Describes the general expectations and requirements for the project result. It often remains at a higher, more general level.
- Purpose: Serves as a basis for the preparation of the specifications by potential contractors.
Specifications
- Author: Created by the contractor on the basis of the specifications.
- Content: Describes in detail how the requirements of the specifications are met and what specifications the product will have.
- Purpose: Serves as the basis for the binding project contract and cost calculation as well as a guideline for the implementation and acceptance of the project.
Find out more: The difference between specifications and functional specifications in detail
Content: What belongs in a specification sheet?
Specifications look very different depending on the industry and project. The focus during creation should be on the following two areas:
Initial situation
- What is the situation of the company in which the project is being tackled?
- What problems does the project aim to solve?
- What goals are to be achieved by the project result?
List of services and requirements
- What specifically needs to be delivered or manufactured and in what quality and condition?
- What functions should the solution have? What tasks should it fulfill?
- What technical specifications or characteristic values must the solution have?
- How must the solution fit into the respective context (e.g. interfaces to other systems)?
- What standards and legal requirements must the solution meet?
- What other framework conditions apply to the project?
- What experience or certifications must the contractor have?
- Which methods of project management, controlling, etc. should be used in the project?
- Contractual conditions: How and when are the services to be provided, accepted and paid for? What warranties does the contractor offer?
Functional and non-functional requirements in the specification sheet
| Category | Functional requirements | Non-functional requirements |
| Definition of | Describe what the system should do (functions and features). | Describe how well the system fulfills certain requirements. |
| Goal | Mapping of business processes and specific tasks. | Ensuring quality, safety and performance. |
| Example requirements (ERP system) | Management of customer and supplier data | Response time under 2 seconds for data queries |
| Creation of invoices and delivery bills | Availability: 99.9 % annual average | |
| Automation of warehouse management | Scalability for up to 10,000 users | |
| Reporting and analysis | Compliance with the GDPR regulations | |
| User administration and assignment of rights | Ease of use (usability) | |
| Priority | Is often defined first | Is then added to ensure quality |
| Measurability | Through certain test scenarios | Often more difficult to measure, requires special tests (e.g. load tests) |
| Frequency of change | Changes more frequently with new business processes | More stable, but can be influenced by technical advances |
| Responsibility | Product managers, specialist departments | System architects, IT security officers |
- Functional requirements describe the direct tasks and processes that the ERP system must map.
- Non-functional requirements define quality characteristics and framework conditions that the system should fulfill in order to work efficiently, safely and user-friendly.
A good specification sheet contains both types of requirements to ensure that the ERP system supports the desired business processes as well as working stably and with high performance.
The requirements are described in text form. Visual elements, such as tables, sketches, technical drawings, diagrams and so on, help to better understand the descriptions and correlations: Tables, sketches, technical drawings, diagrams and so on. Supplementary information such as data sheets, test reports or a glossary of technical terms can also be included in the appendix to the specifications.
How detailed should the specifications be?
The right level of detail is one of the decisive factors in the specifications. Possible levels of detail are – with flowing transitions:
- Rough descriptions of situations, problems, goals, systems and environments
- User stories or use cases, functions and tasks
- Description of requirements, features and guidelines
- Detailed description of requirements, more precise specifications
- Precise regulations, technical specifications, performance and quality indicators
The right level of detail must be found for each individual requirement. The basic rule is: as short as possible, as long and detailed as necessary. The authors of the specifications should ask themselves the following questions: Is it absolutely necessary for a requirement to be fulfilled in a very specific way? Or do we want a requirement to be solved in the best possible way?
In case of doubt, the second option is the better one. The clients have experience from many projects and usually know more elegant and efficient solutions. Contractors, on the other hand, often have a limited perspective: they only know how things have worked for them so far. But it is precisely this approach that has led to the problems that now need to be solved.
Levels of detail 2 and 3 are therefore ideal for the majority of functional requirements: describing use cases and functions as well as the general requirements. More precise specifications should only be made where technical or legal framework conditions leave no other choice. In areas that are heavily regulated by law, for example, specifications are therefore more detailed.
Standards and industry-specific guidelines
Some standards provide guidelines on how specifications should be drawn up in general or for specific sectors:
- DIN 69901-5This German standard describes 110 basic project management terms, including the requirements specification.
- ISO/IEC/IEEE 29148This international standard specifies processes for the requirements management of (technical) systems and software. It contains comprehensive instructions for creating requirements documents, including specifications.
- VDI/VDE 3694This guideline from the Association of German Engineers (VDI) and the Association for Electrical Engineering (VDE) provides recommendations for specifications for automation systems (production technology, energy technology, measurement technology).
- IEC 62366This standard describes requirements for the usability of medical devices. It is relevant for specifications in this area.
- ISO 9001 is not a standard for specifications. It sets out the requirements for quality management systems: for example, clearly defined processes, fact-based decisions and trusting cooperation between all those involved. These principles also apply to the creation of specifications.
ERP specification sheet template
Your project, your plan: Use our sample template for your ERP specifications and lay the foundation for a successful ERP implementation!
FAQ zu Lastenheft:
Ist ein Lastenheft sinnvoll?
Ist ein Lastenheft sinnvoll?
Der Auftragnehmer kann bestimmte Ergebnisse vom Auftragnehmer nur einfordern, wenn diese im Lastenheft beschrieben sind. Ist das Ergebnis mangelhaft, muss der Auftragnehmer kostenlos nachbessern. Fehlt eine Anforderung im Lastenheft, müsste der Auftraggeber die Mehrkosten für nachträgliche Anpassungen bezahlen.
