1 Introduction
2 Related work
2.1 RE in the embedded domain
2.2 Modelling in industry
2.3 Modelling in the embedded domain and during RE
2.4 Frameworks for using models during RE
2.5 TwinPeaks and architecture models
2.6 Summary
3 Research methodology
3.1 Study design
Nr. | Description | RQs | References |
---|---|---|---|
H1
| Requirements are mainly specified in natural language | 1 | [45] |
H2
| Models are already used in automotive RE | 1 | |
H3
| Using models during Requirements Engineering could significantly improve requirements validation and verification | 2 | [50] |
H4
| There is insufficient tool support for modelling requirements | 3 | |
H5
| Using UML for modelling requirements is deficient and frustrating | 3 | |
H6
| Requirements Engineers lack guidance on how to use models within Requirements Engineering | 3 | |
H7
| The main problem in automotive RE is finding the right level of abstraction | 3 | [45] |
3.2 Data collection
Area | Interviewees |
---|---|
Embedded software engineering | A1(15), A2(4), A3(15), A4(3.5), A5(3, 10), A6(7), A7(10), A8(\(<1\)) |
Systems engineering | B1(3.5), B2(1.5), B6(4.5) |
Application software engineering | B3(36), B4(27), B5(4) |
3.3 Data analysis
3.4 Validity threats
3.4.1 Construct validity
3.4.2 Internal validity
3.4.3 External validity
3.4.4 Reliability
4 Case companies
4.1 Company A
4.2 Company B
5 Results
5.1 RQ1: How and why are models currently used in automotive RE?
5.1.1 Nature of models in RE
ID | Model Nature | EmbSys | SysE | AppSE |
---|---|---|---|---|
T1.1.1 | Mainly textual requirements | 5/8 | 2/3 | 3/3 |
T1.1.2 | Emerging specification structure | 5/8 | 1/3 | 1/3 |
T1.1.3 | Templates | 2/8 | 1/3 | 3/3 |
T1.1.4 | Sketches of behaviour | 5/8 | 1/3 | 3/3 |
T1.1.5 | Formal structural models | 3/8 | 2/3 | 0/3 |
ID | Purpose | EmbSys | SysE | AppSE |
---|---|---|---|---|
T1.2.1 | V&V | 5/8 | 0/3 | 0/3 |
T1.2.2 | Communication | 1/8 | 1/3 | 1/3 |
T1.2.3 | Guidance and streamlining | 3/8 | 2/3 | 3/3 |
T1.2.4 | Handling complexity | 5/8 | 0/3 | 2/3 |
In both companies, interviewees mentioned that sketches of behaviour are common (T1.1.4). For example, one interviewee at Company A stated:[..] there were a couple of terms specified that were not followed and, due to that, (it) has broken down in what it actually means, [..] it has broken down in principle.—A7, EmbSE
And sometimes when we have pictures, it’s mostly like state diagrams and so on. So you say ’OK, A, B, C, and what are the transitions between that?’.—A4 EmbSE
An exception is SysE, in which formal diagrams are commonly drawn for safety-critical applications.But it (the model) is not fully used. This is here the problem. Some use it, some gurus.—B4, AppSE
5.1.2 Purpose of models in RE
For semi-formal and informal notations, interviewees mentioned models as a tool to support communication (T1.2.2).[..] it’s used for test and verification. I mean those pictures, it’s not just for writing down a specification and have it for later use when we do a new model, it’s used later on also to verify that we have gotten the right things.—A5, EmbSE
Additionally, several interviewees brought up formalisation as a tool to guide and streamline RE (T1.2.3). For example, in Company B one interviewee mentioned a defined vocabulary and process as a way to guide engineers.Our focus is clearly on cross-domain communication. Definitely.—B2, SysE
Finally, several interviewees mentioned that different kinds of models are currently used as a way to handle increasing complexity (T1.2.4). This is especially true for the structural models close to architecture, e.g. interface and signal descriptions that can be used to generate skeleton code or documentation. However, also tracing was mentioned several times as a means to understand changes, support product variants, or support verification activities. On higher levels of abstraction, use case models were brought up specifically in Company B as a way to understand the existing system functionality and allow for easier impact analysis when new feature or change requests are incoming from customers.[..] it helps [..] that you concentrate on ’What is the function I want to fulfil? What is the behaviour [..]?’ And that contributes to a lot of thoughts that you would never have if you would simply write it down in a Word document.—B1, SysE
5.2 RQ2: What is the perceived potential of models in automotive RE?
ID | Potential | EmbSys | SysE | AppSE |
---|---|---|---|---|
T2.1 | Analyses/execution | 3/8 | 1/3 | 2/3 |
T2.2 | Communication | 0/8 | 2/3 | 3/3 |
T2.3 | Manage evolution | 3/8 | 1/3 | 1/3 |
T2.4 | Provide context | 2/8 | 0/3 | 0/3 |
T2.5 | Standardisation | 1/8 | 3/3 | 2/3 |
5.2.1 Formal analysis and execution (T2.1)
In Company A, the importance of models for early validation with customers and other stakeholders was raised repeatedly. Three interviewees stated that they would like to use executable models to simulate parts of the system behaviour. This could then be used to demonstrate early concepts or to establish a common understanding in a group of engineers or stakeholders.What does the product contain already? What do we need to develop newly? Here it would be cool if we had the existing products as a model.—B3, AppSE
One interviewee expressed the belief that the company should go directly from high-level textual requirements to executable models.I think information management is key. [..] I do believe in using models for testing. To have things that you can show people, that you can work with. That you can already try the specification or the model.—A2, EmbSE
One of the reasons for having executable requirements models is, according to another interviewee at Company A, that faults can easily be injected and the resulting behaviour assessed.I think we should have (high-level requirements) in whatever Word document that is needed and then we go directly to a model where we can execute the model and simulate the behaviour and the functionality.—A3, EmbSE
5.2.2 Communication (T2.2)
While models that are used for communication could possibly also be reused for formal analyses, one interviewee stressed the importance of informal models for communication.On cross-discipline level. [..] There I think it makes most sense, as more and more experts and disciplines emerge [..], but the connections, that’s the point.—B2, SysE
Interestingly, none of the interviewees in Company A pointed out models as a means to communicate only.Well, models. When you say you work with pictures, with sketches, graphics, that definitely helps. But flow diagrams, when you are that far then usually everybody understood it already. The problems come before that.—B5, AppSE
5.2.3 Manage system evolution (T2.3)
Finally, one interviewee mentioned that requirements models could be used in areas where computer tools are still missing and repeated work is necessary. In these areas, it could be useful to build a library of reusable model elements that can be used by engineers to reduce the effort and errors.[..] there is the work in progress and there is the product as it is. [..] we created a functional model of natural language use cases. This means the product is structured into its main functions [..], a tree with use cases in the leaves. And this represents the current state of the product. Which use cases are there? And I have to maintain that, because the work in progress [..] extends the tree, it changes the tree. But if there is no tree [..], then I don’t know how you do that.—B3, AppSE
[..] we plan to use MBE not as a individual method in small islands, but using synergies and reuse. On the long term we would like to build up a library of standard elements that can be reused.—B2, SysE
5.2.4 Provide context (T2.4)
5.2.5 Standardisation (T2.5)
In a similar direction, one more interviewee from Company B suggested to use defined terms or model elements as a means of standardisation. This would allow to check for consistency on syntax level, have a uniform (graphical) representation, and create different views of the model for different stakeholders.Often, the problem is not the existence of a requirements documents, but the method to create this document. [..] That is, every specification looks slightly different [..]. And model-based means in this case a strong use of SysML as a language, which brings the advantage that people are more aware of the fact that they express something in a more formal way that before.—B1, SysE.
5.3 RQ3: Why are models not used during automotive RE?
ID | Challenge | EmbSys | SysE | AppSE |
---|---|---|---|---|
T3.1 | Interoperability or single tool | 3/8 | 0/3 | 1/3 |
T3.2 | Need for customisation | 3/8 | 2/3 | 0/3 |
T3.3 | Information extraction from tools | 2/8 | 2/3 | 2/3 |
T3.4 | High effort | 2/8 | 2/3 | 2/3 |
T3.5 | High complexity | 3/8 | 0/3 | 0/3 |
T3.6 | Accidental design/detail | 6/8 | 2/3 | 0/3 |
T3.7 | Insufficient maturity | 3/8 | 3/3 | 1/3 |
T3.8 | Organisation resistance | 2/8 | 2/3 | 1/3 |
5.3.1 Shortcomings of modelling tools
Similarly, interviewees in Company A refused the idea to use Simulink as a general purpose tool for requirements modelling, as other interviewees in the same company proposed.One size fits all won’t work for Company B. Definitely not. [..] as I already said in systems engineering we are in the mechatronic world...we wouldn’t be interested to re-build existing UML models for software for SysML. It also wouldn’t help us.—B2, SysE
Similarly, tools need to be customisable (T3.2) to fit existing processes. However, according to the interviewees, the possibility to customise existing modelling tools is currently limited.I think Simulink is really good for some parts. It’s absolutely, really wrong for HMI parts. And it’s not really quite super good for state machines. So the thing is that this modelling has to be very flexible —A6, EmbSE
Finally, six interviewees in both companies stressed the need to be able to make information stored in models more accessible (T3.3). In this context, one interviewee stated:[..] they are all in their core 10, 15 years old, or older. [..] that means you have big problems customising these tools in an easy way. That is, directly highlighting certain menus, hiding certain features.—B2, SysE
Concretely, interviewees expressed the need for tables, layouting, easy model navigation, and tracing capabilities in modelling tools.Most users don’t care about diagrams. They are concretely interested in ’I’m responsible for this component, and this requirements, or this function. I’d simply like to have a list, whatever, a matrix view, which tells me what the function is, what attributes it has, [..], which interfaces [..].’ [..] I’m not interested in the whole model. That is, the gap between the expert who creates the model and the group [..] which interacts or works with the model later.—B1, SysE
[..] most of the functionality that we have today in (Requirements tool) is good enough...I see few tooling problems, very few tooling problems. There is a lack of information thinking. But that’s very much linked to the key concept of how the product is documented.—A6, EmbSE
5.3.2 Complexity and effort of modelling
In particular, interviewees in Company A saw the risk that there is a large amount of domain and modelling knowledge needed to understand existing models, meaning that recipients of the requirements models would need additional explanations in natural language.I think you still need to write what the purpose of the function would be. But probably not like the exact logical behaviour.—A2, EmbSE
5.3.3 Organisation and process aspects of modelling
Another interviewee added that this level of detail would require requirements engineers to have detailed development knowledge to be able to create requirements models.It should be on higher level. [..] usually if you do a model and you want simulate it and so on, then you go into too much detail. [..] So to avoid these kind of problems, for the high-level requirements I think it is enough with textual requirements.—A3, EmbSE
What we have now is sort of a merge of the analysis and the design. It’s more towards the design, but it’s sort of a mix. Because it was too complex for users to grasp how to distinguish between analysis and design.—A5, EmbSE
In addition to more technical concerns, several interviewees stated that their organisations are not mature enough (T3.7) to introduce modelling during RE. This was stated both with respect to the necessary skills to actually create and understand models, and with respect to the process currently used in the companies. Three interviewees stated that engineers would currently lack the necessary skills for modelling.In the first step, it will always end up wrong. Either too little or too much or something else. [..] You will approximate this iteratively. What is needed? What is meaningful?—B1, SysE
On an organisation level, several interviewees stated that there would either be a lack of support from management, or a lack of understanding of the actual problem that requirements models would aim to solve.I mean because the persons that write requirements for (vehicles) know about (vehicles). [..] So how many (domain experts) know Simulink? I don’t know.—A8, EmbSE
Technically, everything works. It’s only that companies like Company B [..] have to figure out ’What do we want to fix?’. [..] Sometimes, they don’t even have a real understanding of their problem, leave alone a solution.—B2, SysE
I think a lot is simply a human factor. There are for example also those who have the overview. They sometimes don’t want it (the change), as they realise that the privilege they’re having, what defines their role, is in danger.—B2, SysE
6 Discussion
Nr. | Description | Support |
---|---|---|
H1
| Requirements are mainly specified in natural language | Yes |
H2
| Models are already used in automotive RE | Yes, but restricted to experts |
H3
| Using models during Requirements Engineering could significantly improve requirements validation and verification | Yes |
H4
| There is insufficient tool support for modelling requirements | Yes |
H5
| Using UML for modelling requirements is deficient and frustrating | Not enough evidence |
H6
| Requirements Engineers lack guidance on how to use models within Requirements Engineering | Yes, on organisation level |
H7
| The main problem in automotive RE is finding the right level of abstraction | Yes, when modelling requirements |