Frank Houdek: Requirements management at Mercedes-Benz
How does a company like Mercedes-Benz deal with requirements? Dr. Frank Houdek gave a public lecture on this topic last Monday. Here are some interesting insights on the topic from the presentation, filled with hard facts and figures.
Dr. Frank Houdek is not only "Manager Basic Technology Assurance, Test Methodology, Requirements Engineering" at Mercedes-Benz; he is also a founding member of the IREB e.V. and with decades of experience are highly qualified to speak on the subject.
When developing complex systems, thousands of engineers have to be coordinated in the development process. Requirements engineering plays a dominant role and is one of the most critical phases in system development.
Huge amounts of data
A modern vehicle is a highly complex system consisting of hundreds of components. For this reason, no specification at Mercedes is smaller than 25 pages; some consist of up to 1,500 pages. Or expressed in DOORS objects, we are dealing with 1,000-50,000 elements, the majority of which are requirements.
But not all elements are requirements. Specifications also contain information, predefinitions, headings and much more. At Mercedes, around 70% of all elements are requirements. Testing was also mentioned in the presentation. Only approx. 60% of the requirements are test-relevant.
Approx. 70% of all elements are requirements. Approx. 60% of all requirements are test-relevant.
But that's not all: not all requirements are in the specifications. Suppliers still have to consider 30-300 other applicable documents. Mercedes carried out a study on this topic in 2013. The result was that the documents, including all references, accumulate to up to 50,000 pages. Just under a third of this is specific to Mercedes-Benz, the rest comes from standards and other sources.
No specifications
Typically, a supplier responds with a Specifications to the customer's requirements, which are set out in the specifications. However, with such a flood of requirements, Mercedes does not consider this approach to be practicable. Instead, the supplier must evaluate Mercedes' specifications. To do this, the supplier simply sets a status, supplemented with comments if necessary.
Data exchange with the supplier is now also carried out using the Requirements Interchange Format (ReqIF) which I also helped to standardize. Incidentally, the use case of requirement specification evaluation was explicitly taken into account in the development of the ReqIF standard.
Tools
I found it interesting that Mercedes works with the proprietary DOORS Exchange instead of ReqIF for suppliers who use the "classic" DOORS. This is quite understandable, as this is more performant compared to a DOORS-to-DOORS ReqIF exchange. I was more surprised that DOORS (classic) is still so widespread, apparently also among suppliers.
The introduction of tool-supported requirements engineering at Mercedes-Benz ran for 12 years
The introduction of tools in corporate groups is a lengthy process. Mr. Houdek demonstrated this using the example of tool-supported Requriements Engineering with Classic DOORS. The first pilot projects began in 2000, with widespread use starting in 2004, followed by the rollout in mechanical engineering in 2007. Mercedes did not have full penetration until 2012. Mercedes is currently introducing DOORS Next as its successor.
Only selective modeling
It goes without saying that Mercedes also Modeling but the majority of requirements are still formulated in natural language. The basis for this is a comprehensive specification template. A large proportion of the specifications are written in German. One reason for this is that German is often the binding contract language. On the other hand, this is also intended to relieve the German-speaking colleagues. An automatically translated English, non-binding specification sheet often accompanies the German one.
Mercedes takes a pragmatic approach to the requirement texts: On Text templates tables, illustrations, etc. are permitted where it makes sense.
Mercedes has, for obvious reasons, investigated the potential for automation when working with textual requirements. The analysis of 130,000 requirements showed where NLP (Natural Language Processing) can recognize problems automatically (NLP is a Sub-discipline of AI). These techniques are effective when it comes to specifying requirements, for example by identifying weak words or improving grammar. However, when checking the passive voice or ambiguous relationships, they are not, at least not yet.
Exploding diversity of variants
Mr. Houdek also had some interesting figures on the subject of variants. As an example, he cited an analysis of almost 200,000 vehicles. Around a third of them had a wiring harness that no other vehicle had: they were unique.
A third of the wiring harnesses in 200,000 vehicles were unique
The main reasons for this type of optimization are cost and weight. After all, a cable that is installed but not used increases both. But only a manufacturer who masters this diversity can afford to do so.
The example just given was about variants in production. Fortunately, we don't have to specify every possible wiring harness in development. To rule out possible variant conflicts and to be able to handle variants safely, Mercedes uses the Pure Variants in.
Conclusion
It is not always easy to think outside the box to find out how things are done elsewhere. And even then, presentations and reports are often vague and general. So it's all the more refreshing to hear a presentation filled with as many hard facts and figures as Mr. Houdek's.
