R&D processes

R&D process model

The process landscape in R&D is based on the V model and describes the development activities and their contextual relations. In the graphic representation, we have closed the V model into a circle, in which all main processes or segments are connected to each other. The circle symbolizes a cyclical, iterative process.

Click on a term 
to find out



The customer communicates the requirements of the product in the form of a specification sheet.
The system requirements are then derived from these requirements. The sum of all system requirements is called system specification and is documented in the Polarion system. The system architecture defines, e.g. in the form of a block diagram, what the division into functional blocks should look like, which functions  should be implemented in the hardware and which in the software, and consequently what interfaces to include.

Find out more

A main task of system development is to describe the various possibilities for technical implementation in the form of corresponding architectures and to compare them. The aim is to select the optimal architecture based on comparisons and analyses, and to make it available together with the system specification to the hardware, software and mechanics disciplines.

Find out more

In the various disciplines, also called domains, the respective requirements are then drawn up in a similar process to that at the system level, and architecture variants are derived. As at the system level, the optimal architecture is then determined. This architecture, together with the respective specification, forms the basis for the specific design activities in the respective domains/disciplines. Once a design has been developed, the test process verifies to what extent the design satisfies the requirements according to the formulated specifications. The logical relation between requirements and tests is a central element in the process landscape, because the fulfillment of requirements needs to be demonstrated. Whether and how individual requirements can be tested is already defined and determined when drawing up the specifications, and the respective tests are also assigned then. The requirements are formulated in order to be testable. Consequently, every specification has a corresponding test specification in which the described tests are linked to the respective requirements. Find out more
The developed system is first tested at the domain level. Then the function blocks are gradually integrated according to the system architecture. After every integration step, the tests associated with the respective function blocks and interfaces are run. Find out more
After all function blocks in the overall system have been integrated and tested against specifications, the whole is tested against the customer requirements. These tests are called validations and form the basis for an acceptance of the development results by the customer. Find out more

We will be happy to personally advise you.

Would you like to learn more about our service portfolio or do you have a specific request? Our experts will be happy to help you.