How requirements paralyze today’s product development process

February 24, 2022 – Reading time: 4 minutes

Product development in today’s automotive industry is characterized by one all-influencing factor: complexity. More and more technology for even greater comfort makes more and more software necessary. And it is precisely this complexity, which serves to make everything better for the end user, that makes it increasingly difficult for engineering to produce a technically flawless, high-quality product in a reasonable amount of time.

The major automotive manufacturers seem to be in agreement: Only the narrowest possible scope of action, specified by the most extensive, detailed and standardized requirements for development and their traceability, enable them to check and ensure the product quality of their suppliers.

However, the current flood of requirements (and we are talking about tens of thousands currently!) has a lasting impact on product development: it simply paralyzes it. The requirements have to be read, understood, decomposed, traced, implemented or linked into the standard implementation and tested – and thus generate a huge amount of work on the part of the suppliers. And the biggest surprise in this context certainly is: On average, certainly half of these requirements would be superfluous for the development of a high-quality product. Yes, you have read correctly: By reducing the ridiculous amount of requirements to a reasonable level, it would be possible to develop even better products at equal cost.

Sure, the approach of quality assurance via requirements and their traceability is certainly correct. Traceability as the central demand from ASPICE certainly helps to get a better overview of the projects. The requirements themselves are also correct: They arise because standardized customer specifications exist, which define the framework conditions of the respective OEMs for a project, including all frequently occurring interfaces (e.g. CAN, Lin). This means that requirements are reused that were defined in similar projects for good reason. And the desire for traceability and standardization on the part of OEMs is perfectly understandable. After all, the consequences of a malfunctioning sensor in a driver assistance system, caused by a supposedly insignificant test run that was not carried out, could not only claim human lives, but also shake the safety perception of an entire market and thus entail financial losses that can hardly be quantified.

However, we observe the negative effects of this multitude of requirements every day when we are asked for support by our customers: Resources are tied up that could be used much more effectively for the (further) development of the product. Bottlenecks in development backlogs occur because the OEMs lack the workforce capacity to respond competently and promptly to queries from the development teams that arise during processing. And in the worst case – and this is an approach unfortunately practiced very frequently – the requirements are ignored until there’s no chance to meet any milestone or deadline anymore. Then various requirement task forces are formed, and really important requirements get lost in the chaos. A classic lose-lose situation.

Certainly, agilization of the supplier’s teams could help. However, this does not address the core of the problem: the sheer flood of requirements.

The only thing that can help here is the consistent reduction of requirements that are not urgently needed, so that there is room to breathe again on all sides. We think that 2-5 thousand requirements are sufficient depending on a product’s complexity. This is the only way to ensure that complex products can still be delivered on time and in high quality.

Author

Resources