What is a Specification?

The use of specification in standards

There are several standards in project management, product development or system building that very actively use the term specification. Here you will find a selection:

• ISO/UEC/IEEE 24765:2017 uses the term, among other things, to mathematically prove the validity of an implementation, to mathematically derive the implementation or as a formal notation for a proof of correctness.⁷
• The “Allgemeine Umdruck 250″ (AU 250) of the V-Modell 97 requires both in the project manual and in the QA plan the definition of standards or guidelines for the formats and contents of a specification, as well as the official approval of software requirements specifications by responsible bodies.
• For V-Modell XT – the successor to V-Modell 97 – specifications provide the overview of system elements with their functional and non-functional requirements. In total, the term is mentioned 700 times in the German standard for planning and implementing system development projects.
• The Guide to the Software Engineering Body of Knowledge (SWEBOK) explains that in most technical professions the term refers to the assignment of numerical values or limits to design goals of products, but in software engineering it is typically understood as documentation of requirements that can be systematically reviewed, evaluated and approved.
• The Project Management Body of Knowledge (PMBOK) considers systems, components, products, results, procedures or even services as objects of specifications whose requirements, design and behaviour are defined.
• In the course of product-based planning, PRINCE2 defines the specification as a product description that contains all quality aspects such as quality criteria, quality tolerances, creators of the product, testers, authorised acceptors and test methods of the product.⁸
• The Business Analysis Body of Knowledge (BABOK) describes a high quality specification as being easy to read and understand for the intended audience.
• And the International Requirements Engineering Board (IREB) recommends that when specifying requirements for a function, the function should be refined if the description exceeds half a page.

Types and examples of specifications

In the practice of system, product or software development, there are many different types and examples of specification documents:

• A customer specification is a document from a customer that describes requirements for a system and expected deliverables from a contractor. There are several alternative names for the it including user or tender specification, contract document, specification sheet, or requirement catalogue.
• Although requirements catalogues and customer specifications are used synonymously, it would be more correct to understand the requirements catalogue as input for a customer specification. A requirements catalogue is a list of requirements through which a desired project goal is to be achieved.
• The requirements specification is based on the customer specification, but is formulated from the contractor’s point of view and describes the “how” and thus the plan for implementing the “what” from the customer specification. In many cooperations, it forms the basis for the conclusion of the contract between the client and the contractor.
• In business practice, requirements lists and requirements catalogues are also often used synonymously. From a formal point of view, a requirements list is created at the beginning of the development activity, is based on the requirements specification and is a tool for searching for and evaluating solutions that fulfil requirements.
• The Systems and Software Requirements Specification (SRS) is an IEEE standard (IEEE 29148-2018) and includes both customer and requirements specification. In addition to customer requirements – also called C-requirements – it also defines development requirements – correspondingly called D-requirements.
• The use case concept comprises two approaches that can be used together: use case specifications contain natural language information on the systematics of the interactions of a use case (so-called “narratives”). Use case diagrams visualise use cases and actors with their respective relationships. They provide a good overview of the overall system, but unlike specifications, they do not describe processes, but rather the relationships between a set of use cases and the actors involved in them.
• Service descriptions contain specified services from suppliers, required services from clients (in the form of invitations to tender) or the agreed services in contracts between client and contractor.

Opinions vary in practice as to whether backlogs – well-known and popular in agile projects and developments – also represent a “modern” form of specification, or supplement or replace specifications. The same applies to notations such as UML, SysML or BPMN, which support the description of technical contexts, requirements, data flows, etc. by means of numerous diagrams.

Questions in the context of specifications

There is a long list of questions in the context of specifications. You can find answers to some of the questions in our blog:

How can requirements be specified within 14 days?
What is the best process in requirements management?
What to do when the mountain of requirements becomes too big?
What are typical misunderstandings in requirements engineering?
How can the completeness of specifications be ensured?
How can requirements be collected destructively?
How does requirements analysis work remotely?
How can requirements be exchanged without loss?

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.

In some publications you may read that specifications can be defined informally, semi-formally and formally. In informal specifying the definition is verbal, in semi-formal specifying it is partly verbal and partly formalised. How likely is it in your company that an informal or semi-formal description will contribute to a successful implementation?

Notes (in German):

[1] Algebraische Spezifikation von Datenstrukturen
[2] Spezifikationskauf bzw. Handelskauf
[3] Vereinbarte Beschaffenheit
[4] Technische Spezifikationen in der Vergabe- und Vertragsordnung für Bauleistungen
[5] Lebensmittelsicherheit – Vorschriften und Regelungen
[6] Ökonometrie
[7] ISO/IEC/IEEE 24765:2017
[8] PRINCE2

Here you will find additional information from our Smartpedia section:

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