5 things Systems Engineers should do early and often

Of course, there are more things that systems engineers need to do than those described below. But this is about simple things that deliver tangible results with little effort ("low-hanging fruit"). The things listed here are also of a tactical nature: they can be introduced or drastic changes to processes, methods or tools need to be made.

1. conduct early and frequent reviews

Reviews can drastically reduce development risks and increase quality. The effort involved is very limited, if we are honest.

Admittedly, reviews were annoying in the past. When work was still document-based, they were very inconvenient, time-consuming and annoying: documents were often sent by email and it was difficult to merge the review results. This often resulted in hours of review meetings.

Software development has long shown that consistent reviews are possible and that they work. Version management for code makes this possible. Tools such as Gerrit also enable distributed reviews with an automated process. This works because only the changes are checked.

I was already working in a commercial environment at the end of the 90s, where every new code was consistently reviewed.

However, a systematic review is also possible for other artifacts. Even with Word, even if the limits are quickly reached here (with more than 2-3 pages it becomes critical, the comparison function is simply too poor).

However, database-based systems are normally used for serious systems engineering, and these can also be used to set up a reasonable review process. One of the best Review systems for requirements I know is part of Jama Connectbut other requirements management tools also make it possible to carry out reviews efficiently. There are now even solutions in the area of modeling. With the help of LemonTree you can, for example, compare the status of Enterprise Architect models and focus on the changes during the review.

2. create traceability early and maintain it frequently

Traceability is a powerful tool in systems engineering. But in order to use it, we have to trust it. And to trust it, it must be maintained. As soon as traceability is no longer trustworthy, we stop using it. We must not get into this vicious circle in the first place!

Too often I had seen that traceability was not used during development and then only updated for compliance at the end of the project. What a waste!

Unfortunately, there is no one-size-fits-all solution for demanding this activity. The solution is also partly tool-dependent. Sensible tactics are:

• Ensure that the tools used support the creation, maintenance and use of traceability in a user-friendly way
• Make traceability easy to use, for example via a dashboard that shows gaps in coverage
• Demand up-to-date traceability from the outset and make it clear that an incorrect or missing trace is a serious bug

If employees recognize the value of traceability and it is easy to use, then traceability will also be maintained.

3. integrate early and often

Unfortunately, with complex systems in particular, many problems only arise during integration. The earlier integration takes place, the better. This technique also originates from software development, where Continuous Integration (CI) has been practiced for many years.

Early integration is not quite so easy when hardware is involved, but there are tactics here too:

• Products contain more and more software. Even if it is not possible to integrate at hardware level at an early stage, it is at least possible to integrate at software level
• The production of prototypes becomes cheaper and, above all, faster, which can be used for integration at hardware level.
• Hardware can be emulated or simulated.

Here, too, it helps to ask about the motivation for integration. And that is often to be able to test. Hence the next technique:

4. write tests early and often

Writing tests (to be carried out later) helps to sharpen the content to be tested. When writing the tests, ambiguities or contradictions often become apparent. This approach also comes from software development, where the Test-first approach exists. Of course, this activity also requires testing, which I assume is the case in systems engineering. According to V-model there are tests at every level of development.

Furthermore, writing the tests also helps in planning the integration: if the test expert defines an integration test early on, feedback may be provided that makes the integration easier or even shifts test activities from the integration level to the component level.

5. carry out tests early and frequently

An important task of CI is to carry out tests. After all, it is only by carrying out tests frequently that we get feedback on where we need to make improvements. Testing also has another task: it gives us the self-confidence that the system works as expected even after changes.

In hardware development, it is not quite so easy to test frequently. But here we can take advantage of the fact that hardware changes much more slowly than software. Once there is hardware on which tests can be carried out, it can be used for test runs after software changes. This usually only works if it is automated. How this can work Andreas Willert impressively described in an interview.

Photo by Charlotte Coneybeer on Unsplash