As a part of my research in model-based requirements engineering, we conducted a case study a while ago to investigate how models are/can be used in automotive requirements engineering. While running the interviews at two automotive companies, we discovered that interviewees regularly talked about problems that occur during everyday work. What stood out to us was that they all mentioned communication issues frequently.
We decided to first investigate these issues further, instead of prioritising the original analysis regarding modelling. From our interviews, enhanced with an online survey among practitioners in the automotive industry, we extracted a list of seven problems in automotive RE – all related to communication and coordination:

• P1: Lack of Product Knowledge: the lack of sufficient knowledge about
  the product in early stages.
• P2: Lack of Context Knowledge: the lack of context information regarding
  requirements on low levels of abstraction.
• P3: Unconnected Abstraction Levels: a mismatch between requirements
  on different abstraction levels.
• P4: Insufficient Communication and Feedback Channels: lacking communication
  with other people within or across the organisation.
• P5: Lack of Common Interdisciplinary Understanding: the lack of common
  understanding across multiple disciplines.
• P6: Unclear Responsibilities and Borders: the lack of clear and communicated
  responsibilities between different parts of the organisation.
• P7: Insufficient Resources for Understanding and Maintaining Requirements:
  to lack enough resources in early phases to get an understanding
  of the needs and to maintain requirements later on.

We found that these problems were the main issues mentioned by multiple interviewees in both our case companies and in the survey we conducted.

Clearly, some of these issues are related to a cost-benefit trade-off. For instance, P7, how to deal with a limited amount of time and money, is omnipresent in daily life and can only be solved by lowering the expectations towards certain quality aspects in parts of the requirements specification. Similarly, P3, abstraction gaps between requirements abstraction levels, can only be reduced by extra effort in both specification and maintenance of requirements (which would then inevitably lead to P7 again).

However, we also find a number of issues that are strongly related to the automotive reality. For example, both the lack of product knowledge (P1) and lack of context knowledge (P2) are related to the large number of sub-contractors in automotive engineering. Sub-contractors are typically very specialised to certain parts of the automobile (their specific expertise), leading to a lack of product knowledge in other areas. Similarly, the lack of context knowledge is typically related to this issue and to concerns regarding intellectual property (i.e., only making very limited parts of the requirements specification available to sub-contractors).

Based on these findings, there are a number of issues that, we believe, should be addressed in future work. First, there is a need for a process that allows for sufficient levels of uncertainty during early phases of RE. This is certainly not a new finding, but increasing speed of technological change makes this more and more important. Also, while I personally come from the ‘formal world’ and, ideally, would like to specify everything so that you can verify it for correctness (or what ever else comes to mind), it is important to accept reality, i.e., that not everything is certain and can be specified. Secondly, there is a need for an organisation structure that effectively supports interdisciplinary RE, taking into account the central role of software. While automotive companies are often ‘traditional’ and have a purely mechatronic background, software is becoming increasingly important. The companies need to be aware of this and adapt. In contrast, the software engineering community would be strongly advised to not ignore other disciplines. Hardware and mechatronic components in automobiles still have long lead times and do often not adhere to agile practices. This already causes frictions between the two worlds (see also our recent Paper on challenges in large-scale, agile requirements engineering: Kasauli et al., 2017, “Requirements Engineering Challenges in Large-Scale Agile System Development”, Proceedings of 25th International Requirements Engineering Conference).

(This is a summary of the article published at Requirements Engineering Journal. If you want to know details, plus more numbers and figures, you can read it here, free of charge!)