Getting better in Systems Engineering - Part 2

An Additional 5 Ideas to Enhance Your Systems Engineering Projects

Following up on my previous post, here are five additional tips to enhance your Systems Engineering. These suggestions may be more technical than the previous ones, but they should be beneficial for any project:

1. Maintain Consistent Terminology: Ensure everyone uses the same project-specific language, referring to the terms and concepts unique to the project, rather than natural languages like English or German.
2. Conduct Requirements Analysis: Don't overlook this crucial step. Many projects fail to thoroughly analyze stakeholder requirements, leading to inconsistent, incomplete, and ambiguous system requirements. Poor requirements significantly impact the project's success or failure.
3. Opt for Modeling Over Narration: Abandon the use of text, prose, and natural language for specifying systems. Instead, employ a formal or semi-formal language, like SysML, to design and specify systems, as prose can be ambiguous and problematic.
4. Welcome Refactoring: Embrace change and understand that perfection is not always achievable on the first try. Organize processes, methods, and tools to expect, support, and accommodate change as part of everyday engineering tasks.
5. Foster Education, Learning, and Communication: Continually adapt to a changing world by learning new things. Encourage communication, teaching, listening, and learning to ensure everyone is on the same page and well-informed.

Remember, consistent terminology is crucial. For example, terms like "Power Supply," "Power Source," "Power Supply Module," and "PMIC" (Power Management Integrated Circuit) might refer to the same thing, but it's unclear without consistency. While using varied terms may make storytelling more interesting, it's essential to be precise and consistent in Systems Engineering.

Humans are very good at automatically interpreting terms in a story or when talking to people. However, this automatic interpretation is based on context, individual experience and assumptions, often leading to misunderstandings.

The problem is of course compounded as projects become international and involve many people who do not natively speak the same natural language.

Human communication has a verbal aspect, but is backed but by many other factors. As discussed here, common ground, non-verbal queues, context and environment, all play a part in face-to-face communication. However, when somebody reads what you have written down, none of that additional information is present. In particular when considering Stakeholders, Systems Team, External Assessors, International Boundaries, or a domains such as Software or Hardware, the common ground is simply not present.

When reading something, the words, the terms in use, (and their context) are the only things available for communication. The importance of a common understanding of what they mean is vastly increased.

In an engineering context, multiple words for the same thing just leads to ambiguity, confusion and misunderstanding. Don’t do it!

A common solution is to put in place a glossary for the project, but there is a tendency for it to be unmaintained and incomplete. Ultimately is is up to the the team as a whole to agree what different terms refer to and down to each individual engineer to be consistent regarding usage of those terms.

You might disagree with the decision made by the team — but please, for the good of the project, to avoid misunderstandings — use the agreed terms.

Initially the glossary can be populated using a technique such as Domain Analysis. Though in large/long project, such a glossary of terms can get large and terms may evolve to have different meanings a the project progresses (all languages evolve). Maintaining the glossary is important if you want to reduce ambiguity and misunderstandings.

In particular, try to keep the same meaning for terms across team boundaries. I.e. make sure that the Stakeholders, the System team, the Software team, the Hardware team, etc all use the same term for the same thing.

Requirements Analysis

The Requirements Analysis part of the engineering process is normally described in most good books on the topic. (If not, I argue that it is not a ‘good’ book!) However, making provision for good/thorough requirements analysis beginning of a project is often undervalued. Insufficient time/budget is allocated and it is rushed or even skipped entirely.

There are multiple stakeholders, many providing multiple documents, providing hundreds or thousands of requirements. Nearly all written in natural language (prose), with a few (probably informal) diagrams if you are lucky.

This is very short sighted of the stakeholders. If they provided quality, precise, consistent, formal, requirements then they would get far better (faster, cheaper, higher-quality) delivery of what they want!

We cannot change what the customer (and other stakeholders) provide. Thus we need to analyse what we are given and provide a quality, precise, consistent, formal requirement specification for ourselves.

It is very well known and documented that poor requirements are the primary reason for project failures. According to the Project Management Institute, 47% of project failures are due to inaccurate requirements management.

Furthermore, the cost of poor requirements increases more and more the later in a project the issues are detected. The following graph, although consisting of purely fictitious data, illustrates the point.

How do we avoid this?

Just spend the time/effort/cost at the start of a project to properly analyse the stakeholder requirements and update that analysis as the stakeholder requirements change.

A good system analysis should cover things such as:

• System Context: specifying the things in the environment that interact with the system-of-interest (the system).
• Features: the required behaviours of the system. Each feature is a subset of the externally visible behaviour of the system.
• Interfaces: to external things, defined/identified in the system context. Including the information communicated over those interfaces
• Interactions: the expected sequence of interactions between the system and things in its context, including constraints on those interactions (i.e. timing constraints)
• Other constraints on the system

Time invested in Requirements Analysis at the start of a project will be more than recovered by the end of the project.

Model rather than narrate

Given the nature of todays and future systems, the analysis of stakeholder requirements and the architecture of a large and complex system cannot be done in the heads of engineers or using informal natural language sentences.

The analysis and architecting of todays complex systems requires tool support and a formal (or at least semi-formal) model of the requirements.

The idea of using models to assist in requirements analysis has been around since (at least) the 1980s. In the 1990s UML was standardised, and in 2001 the SysML (System engineering version of UML) initiative was started.

SysML contains suitable concepts (syntax and diagram types) for capturing the essential things that form a good System Analysis model and a System Architecture.

Good system analysis and architecture models will not totally eliminate the need for natural language (text) based System Requirements — but it will:

1. reduce the number of necessary textual requirements
2. vastly improve the quality of the system specification
3. increase the ability to spot inconsistencies, gaps and ambiguities.

A good tip, is to keep analysis and architecture models separate. They need to have traceability between them, but multiple smaller models are easier to manage than one huge one. In particular, (todays) commonly used modelling tools struggle to handle large models.

Embrace refactoring

As a project progresses, the understanding of the problems becomes clearer (with any luck!), and thus, due to experience gained, the decisions made at the start can be adjusted.

Initial decisions are based on guesses and past experience of similar problems. Over time, as the knowledge about a specific project increases, better decisions can be made.

This is normal and should be expected as part of the development process. The processes, methods and tools in use on a project should be set up to accommodate such changes.

There are different kinds of change:

1. A change in requirements, coming from the one of the stakeholders (i.e. the customer). These kinds of change are normally already accommodated and expected.
2. A change in architectural/design decisions that produces a better solution. These kinds of change are also normally already accommodated and expected.
3. Structural, documentation, terminology changes. In my experience, these kind of changes are often necessary, but teams often don’t do them.

Refactoring refers to the kind of changes in point (3). It may seem that these kind of changes are pointless. However, they are really important. they may not change the actual solution, or affect the end product, but they do improve understanding, clarity and communication.

In the software world, refactoring is accepted as necessary and is supported by most software tools. Refactoring is a key process to reduce Technical Debt.

The same thing is true in system requirements and architecture. In particular, as you move from natural language requirements into more formal specifications, the acceptance of refactoring as a necessary change will improve the quality, clarity, understanding of the system specifications.

Don’t resist change — Embrace it!

Educate, learn and communicate

Communication is the key to human success. Just google it (or click on the link, I did it for you ??).

A systems engineering project tends to involve many people (hundreds of them). The projects also tends to last several years. Over this time, the involved people change. The new people don’t know the history, they don’t know why certain things were decided. Even people who have been on the project from the start, sometimes forget, or were not present at meetings where decisions were made.

As a member of the team (and I mean the whole project team, not just a specific domain team) you have to actively seek out knowledge, actively learn. Learn about this particular project, and learn new things that could help the project.

Actively learn

All team members, in particular leaders in the team (and I don’t mean managers — I mean leaders, which may include managers), constantly communicate. Educate the people in your sphere of influence with information they may have missed. Don’t assume everyone knows something just because you do.

Never assume! Always communicate.

Make every day a learning day, and never think that you have communicated enough. Remember one of the aspects of Brook’s Law:

“Communication overhead increases as the number of people increases”

Hence, in a large team, you need to communicate excessively ??

Conclusion

To conclude:

1. Use Consistent Terminology — over time this has huge benefits.
2. Do an effective Requirements Analysis — it is worth the cost.
3. Use Models (formal or semi-formal languages) — rather than (ambiguous) natural language.
4. Embrace refactoring — it improves quality and saves cost in the long term.
5. Educate, learn and communicate — all the time.

Visit the itemis MBSE blog!

#systemsengineering?#engineering?#mbse #uml #sysml