Seven questions for choosing the right tool for systems engineering

To get straight to the point: The choice of a tool for system engineering should not come first. Tools should provide support, and in order to choose the right tool, we must first decide which activities the tool should support.

The V-model is a good "map" to discuss in which areas of development tools should be used. As a reminder: In the V-model, the requirements are at the "top left" of the V, which lead through several steps (architecture, design...) to the implementation at the "bottom tip" of the V. On the right-hand branch of the V are the V&V elements, for example tests, which check the elements on the left-hand branch at the same levels.

A tool alone is rarely the solution. But the wrong tool in systems engineering can lead to failure

The following questions should help you make a decision:

1. what kind of project is it?

Possible answers to this question are:

• Academic project or "game project"
• Completely new development without existing tool environment
• Complete new development with existing tool environment
• Further development (apparently with existing tool environment)

If a tool environment already exists, it should be carefully considered whether something should be changed here. In particular, changing a tool can generate significant costs and problems, even if it should theoretically not be a problem. An example of this would be changing the UML tool. Even if there is a standard for UML models (XMI), this does not mean that UML models can be easily transferred from one tool to another.

For academic or learning projects, the learning objective should be clearly defined. Here it can be useful to use tools that are open source (or at least support a powerful scripting language) so that the aspects relevant to the learning objective can be developed.

2. what is the scope of the tool support?

The V-model provides a good overview of the areas that could be covered by a tool. These range from requirements and design to hardware and software code. The first step is to decide for which of these areas a tool should be selected. It is quite possible that the decision has already been made for some areas (e.g. the choice of programming language and compiler).

Furthermore, although there are integrated tools that cover many areas, this is not a fundamental requirement. On the contrary: with an integrated tool, you can quickly become dependent on a single manufacturer ("vendor lock-in"), which can lead to many other problems. Examples of integrated tools include Scade Systems or IBM Jazz (although Jazz can also be used via OSLC). other tools integrated can be used).

However, the advantage of an integrated tool is that the development artifacts can be closely interlinked. This results in powerful traceability. However, there are also powerful external tools for traceability that bring together a wide variety of tools, such as Reqtify.

3. what does the tool architecture look like?

Even if only a small area of system development is to be covered with tools, these tools must fit into the overall context of system development. A tool architecture must therefore be selected. This is not complicated and the architecture description should be able to be summarized in a few sentences. Possible architectures could be

• File-based working with manually assigned IDs
• Linking all tools via OSLC
• Working with an integrated environment

Of course, this is only an exemplary list, there are many other architectures that all influence the choice of tool.

4. are there any important requirements that need to be taken into account?

As with many things in systems engineering, requirements are important. There's no need to pull out the big guns here: For a small project, the requirements can be safely recorded on half a page.

Regulations must be taken into account, especially for safety-critical developments. But users must also be involved. It is important to remain pragmatic here and not go overboard.

5 How high must the degree of automation be?

Tools are powerful because they take work off our hands, i.e. they allow automation, among other things. However, two things should always be borne in mind:

• Automation must be understood. Incorrectly configured (or misunderstood) automation can do more harm than good under certain circumstances. A classic example is code generation, i.e. the creation of software code from models. It works, but is time-consuming. And if this is not understood correctly, dead code may remain in the software, causing faulty behavior.
• Manual processes may be part of the tool chain. If there is no clean interface between two tools, then it may be necessary to work manually. This is sometimes seen as negative, but can be easily managed with clearly described processes. It should also be noted that manual processes do not necessarily have to be carried out by a specialist. Checklists are an example of effective manual support.

6. is there a budget for support and customization?

This question is often forgotten, but it is very important: the best tool is useless if the users cannot handle it. The following statement may seem controversial: But Word may be more suitable for the requirements than Rational DOORSif the users have never worked with DOORS before and there is no budget for training and support.

Customization is also an important topic. All serious systems engineering tools have customization options, from document templates to script engines. If there is no budget for customization, then a great added value of the tools can simply fizzle out.

7. does it feel right?

And finally: even if one or more tools have been found rationally, all relevant stakeholders should be asked whether the choice of tool seems right to them, i.e. really from the gut. If this is not the case, then an attempt should at least be made to understand the reason for this feeling of discomfort. Of course, the decision can still be made in favor of the tool, but it should be understood why this is the case.