The specification describes in concrete form how the contractor the requirements of the client intends to solve - the so-called how and with what . The client describes the totality of the requirements as precisely as possible in advance in the specification sheet - what he would like to have developed or produced. Only when the client accepts the specifications should the actual implementation work begin with the contractor.
Besides the term specification is found in practice imprecise terms such as Business specification , technical specification , specialist detailed concept , target concept , functional specification , overall system specification , implementation specification or English Software Requirements Specification, Scope Statement, Feature Specification, Functional Specification (F-Spec) System Specification . Since these terms are usually not standardized, they can mean documents in the sense of the specification, but also a technical concept , specification sheet or something else.
According to DIN 69901-5 , the specification includes the “implementation specifications drawn up by the contractor based on the implementation of the specifications specified by the client”. The requirements of the previously worked out specifications are now linked with technical specifications of the operating and maintenance environment.
According to VDI guideline 2519 Part 1, the specification is the description of the implementation of all customer requirements that are required in the specification.
In accordance with VDI guideline 3694, the contractor creates the specification sheet, taking into account the requirements for the automation system specified in the specification sheet.
According to VDI guideline 2221, the terms are also used synonymously.
The specification is formulated by the contractor and confirmed by the client at his request. Ideally, the actual development / implementation work should only begin after this confirmation. The contractor has a right to such confirmation determined by the contract (obligation to cooperate according toBGB).
It is good practice to use the principle of inclusion and exclusion when drawing up a functional specification, i.e. to explicitly include or exclude specific cases.
Upon delivery, an acceptance is formally carried out, which resolves the execution of the contract for work or the purchase contract . This acceptance is often carried out via an acceptance test , which determines whether the requirements of the specifications have been met in the understanding of the customer.
In software development , the specification is defined in V-Modell 97 , among other things . In the current V-Modell XT , the designation has been changed to the overall system specification (functional specification) . Nowadays, a software requirements specification is usually created for international projects . This represents the requirement specification and is still the starting point for the traceability of the requirements in the next solution levels such as B. Architecture specifications, SSRS (Subsystem Requirements Specification) and test case specifications.
Requirement specifications used in international space travel are often based on the NASA standard in order to simplify international cooperation. The following principle has emerged:
- The client creates a requirements specification (spec requirements) that contains the mission requirements and conditions (for example, it is a manned laboratory module for. ISS delivered that with the space shuttle to be transported there);
- The contractor replies with an implementation specification (design-to-spec) which specifies the design chosen by the contractor (e.g. a cylindrical printing module with a specific diameter and length);
- The client formally accepts the more detailed implementation specification. However, in the event of a later conflict, the requirements specification takes precedence.
Furthermore, the client demands in a specification / statement of work (SOW) how and by what means the product to be delivered according to the requirements specification is to be developed, manufactured and verified (development logic, checks / reviews, documents to be delivered, etc.).
The contractor replies with various plans (development plan / design to development plan, production plan, EMC control plan, etc.) which describe the implementation of the SOW in detail (e.g. who writes the minutes of a meeting and in what time frame the parties involved must agree) .
Norms and standards
- VDI 2519 sheet 1: Procedure for the creation of requirement specifications
- VDI 2519 Sheet 2: Specification / functional specification for the use of conveyor and storage systems
- VDI 3694: Requirement specification / functional specification for the use of automation systems
- Thomas Fittkau: Holistic IT project management. Knowledge, practice, applications . Oldenbourg, Munich [u. a.] 2008, ISBN 3-486-58567-3 .
- Ina Depp Rich: Praxishandbuch media, IT and copyright law . 2nd Edition. Müller, Heidelberg 2011, ISBN 3-8114-3820-4 .
- Association of German Engineers (publisher): VDI / VDE 3694 - specification sheet / functional specification for the use of automation systems . Beuth, 2014.
- Association of German Engineers (ed.): VDI 2221 - Methodology for developing and designing technical systems and products . Beuth, 1993.
- Columbus Design Spec (COL-RIBER-SPE-0028, iss 10 / F, June 25, 2004).