Companies that want to have custom embedded systems developed often face the same question: How do you describe the requirements for a new device or board so that a development service provider can work with them? In many cases, a technical idea already exists, such as a sensor board, a controller, or a special embedded platform. However, what is missing is a structured description of this idea – for this, an embedded systems requirements specification is needed.
The classic tool for this is the requirements specification document. It describes the requirements a customer has for a product and forms the basis for collaboration with the development partner. In practice, two different approaches have become established: a text-based requirements specification and a graphic or block-based requirements specification. Both forms pursue the same purpose but differ significantly in their approach.
Content
What is a requirements specification?
A requirements specification document (Lastenheft) is a document that describes the requirements for custom electronics. It defines the functions, features, and general conditions that a product must meet. The requirements specification document is typically created by the client and serves as the starting point for quotations, project planning, and technical implementation.
The most important principle is: the requirements specification describes the „What“, not that „How“. The specific implementation will be described later in the requirements specification, which is typically created by the development service provider. This document will define the architecture, components, and development processes that will be used to implement the requirements.
In practice, however, a requirements specification is not a rigid document. Many projects also begin with a brief description or a discussion. Nevertheless, a structured specification helps to avoid misunderstandings and to clearly define the development framework.
Two typical forms of requirements specifications
When it comes to electronics projects, two fundamental types of specifications can be observed. Which one is used depends heavily on the client's environment and organization.
The text-based requirements specification
The classic approach is a structured document with textually formulated requirements. This format is particularly common in regulated industries, such as aviation, in Railway sector, I'm Automotive industry or in safety-critical applications.
In such projects, not only the function but also the process is the focus. Requirements are formally described, versioned, and comprehensibly documented. Typically, such a requirements specification contains:
- a project description and objective
- a list of functional requirements
- Non-functional requirements (e.g., lifespan, environmental conditions, safety)
- Interface descriptions
- Standards and regulatory requirements
- Boundary conditions such as deadlines or budget
- Documentation and Proof Requirements
The advantage of this approach lies in its traceability. Requirements can later be clearly traced back to tests, validation, and documentation.
The block and graphical requirements specification
In many industrial projects, especially in mechanical engineering, electrical engineering, sensor technology, or the tool industry, the specification is developed differently. Here, the technical solution is more of a focus than the formal process.
Instead of a long text document, block diagrams, sketches, or architectural designs are often created. These describe, for example:
- the functional assemblies of a board
- Signal flows between components
- Communication interfaces
- integration into a machine or system
- a possible software structure
A typical example is a block diagram of an embedded system with Microcontroller, Sensors, actuators, communication interfaces, and power supply. Mechanical installation situations or existing hardware platforms are also often graphically depicted.
This approach is more pragmatic and technology-driven. It is particularly suitable when the central question is: What function is the board intended to serve, and how does it integrate into the overall system?
How extensive does a requirements specification need to be?
There is no fixed rule for the scope of a requirements specification. In some projects, it comprises several hundred pages; in others, it consists of a few pages or even just a presentation.
The most important thing is that central questions are answered:
- What function should the electronics serve?
- In what system is it used?
- What interfaces exist?
- What environmental conditions are relevant?
- Which norms or standards must be complied with?
An embedded systems requirements specification should be precise enough to define the scope of development. At the same time, it should not be so detailed that it fully dictates the technical solution. The concrete architecture often emerges through dialogue between the customer and the development service provider.
In Five Steps to an Embedded Systems Requirements Specification
Regardless of whether a text-based or graphical approach is chosen, the creation of a requirements specification can be broken down into a few basic steps.
Define purpose and objective
At the beginning is the question of why the electronics should be developed. Is it about a new product, an extension of an existing system, or the replacement of an outdated platform? The objective significantly determines the later requirements.
2. Gather Requirements
In the next step, all system requirements will be gathered. This includes both functional requirements (e.g., measurement functions, control algorithms, communication interfaces) and non-functional requirements such as:
- Temperature range
- Lifespan
- Vibration resistance
- Security Requirements
- Update or maintenance mechanisms
The operating environment also plays an important role, especially with electronics.
3. Structure Requirements
The collected requirements are then structured. Typical categories include:
- electrical properties
- mechanical boundary conditions
- Software features
- Communication interfaces
- Standards and Certifications
Prioritizing requirements can also be useful for better managing the scope of development.
4. Create Document
Now, the actual requirements specification will be created from the collected information. This can either be in the form of a structured document or as a combination of text, tables, and diagrams.
A possible setup includes:
- Project Overview
- Objective
- System Description
- Functional Requirements
- non-functional requirements
- Boundary conditions
- Attachments with drawings, block diagrams, or data sheets
Companies often get bogged down in questions about tools or exports. They work with software such as Polarion or IBM DOORS. In this regard, any form of document is fundamentally valid. What is crucial is the clear communication of the framework of expectations. We therefore recommend documenting system requirements in Word or Confluence.
5. Review and Approval
Before the document is handed over to the development partner, it should be coordinated internally. Often, several departments participate, such as development, product management, or system engineering.
After release, the embedded systems requirements specification serves as the basis for further project planning and for the creation of the functional specification.
Requirements specification or dialogue?
Even though a requirements specification is a helpful tool, it is not a mandatory prerequisite for an inquiry. Many projects begin with an idea, a sketch, or a brief description.
In such cases, the specification often arises collaboratively through discussion. The client describes their requirements, and the development service provider adds technical perspectives and possible architectures. Only after this is a structured specification created.
Whether a text-based document or a technical block diagram: The crucial thing is that the fundamental idea is clearly described. On this basis, an electronics project can be systematically planned and implemented.
