Improve your systems engineering projects with five additional techniques:
Following on from our previous discussion, here are five more strategies for improving your systems engineering projects. These ideas may be more technical than the previous ones, but they are valuable for any project:
- Emphasise consistent terminology: Ensure that everyone uses a consistent, project-specific language to refer to terms and concepts unique to the project, rather than relying on natural languages such as English or German.
- Prioritise requirements analysis: Never underestimate the importance of this critical step. Many projects suffer from inadequate stakeholder requirements analysis, resulting in inconsistent, incomplete and unclear system requirements. Inadequate requirements can make or break a project.
- Choose modelling over narration: Avoid using text, prose and natural language to define systems. Instead, choose a formal or semi-formal language such as SysML, which helps to design and specify systems more accurately and eliminates the ambiguity often found in prose.
- Be open to refactoring: Accept that change is inevitable, and that perfection may not be achievable on the first try. Establish processes, methods and tools that anticipate, support and accommodate change as a routine part of engineering tasks.
- Encourage education, learning and communication: Continually adapt to an ever-changing world by acquiring new knowledge. Encourage communication, teaching, listening and learning to ensure everyone is on the same page and well informed.
Consistent terminology
Remember that consistent terminology is essential. For example, terms such as "power supply", "power source", "power supply module" and "PMIC" (power management integrated circuit) may refer to the same thing, but without consistency it's unclear. While using different 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, and often leads to misunderstandings.
The problem is compounded, of course, when projects become international and involve many people who do not speak the same natural language.
Human communication has a verbal aspect, but is underpinned by many other factors. As discussed here, common ground, non-verbal cues, context and environment all play a role in face-to-face communication. However, when someone reads what you have written down, none of this additional information is present. In particular, when considering stakeholders, system team, external reviewers, international boundaries or a domain such as software or hardware, the common ground is simply not there.
When reading something, the words, the terms used, (and their context) are the only things available for communication. The importance of a common understanding of what they mean is greatly increased.
In a technical context, using multiple words for the same thing only leads to ambiguity, confusion and misunderstanding. Don't do it!
A common solution is to create a glossary for the project, but this tends to be unmaintained and incomplete. Ultimately, it is up to the team as a whole to agree what different terms mean, and up to each individual engineer to be consistent in their use of those terms.
You may disagree with the team's decision - but please, for the good of the project and to avoid misunderstandings, use the agreed terms.
Initially, the glossary can be populated using a technique such as domain analysis. However, in a large/long project, such a glossary can become large and terms can evolve to have different meanings as the project progresses (all languages evolve). Maintaining the glossary is important if you want to reduce ambiguity and misunderstandings.
In particular, try to maintain the same meaning for terms across team boundaries. I.e. make sure that the stakeholders, the systems 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 usually covered in most good books on the subject. (If it is not, I would argue that it is not a 'good' book!) However, the importance of a good/thorough requirements analysis at the beginning of a project is often underestimated. Insufficient time/budget is allocated and it is rushed through or even skipped altogether.
There are multiple stakeholders, many of whom provide multiple documents containing hundreds or thousands of requirements. Almost 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 high quality, precise, consistent, formal requirements, they would get a much better (faster, cheaper, higher quality) delivery of what they want!
We cannot change what the customer (and other stakeholders) deliver. So we need to analyse what we are given and produce a high quality, precise, consistent, formal requirement specification for ourselves.
It is well known and documented that poor requirements are the number one cause of project failure. According to the Project Management Institute, 47% of project failures are due to poor requirements management.
Furthermore, the cost of poor requirements increases the later in a project the problems are discovered. The following chart, although based on purely fictitious data, illustrates the point.
Cost of issues due to poor requirements
How do we avoid this?
Simply spend the time/effort/cost at the start of a project to properly analyse stakeholder requirements and update this analysis as stakeholder requirements change.
A good system analysis should cover things like
- System context: specifying the things in the environment that interact with the system of interest (the system).
- Characteristics: 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 context of the system. Including the information communicated through these interfaces
- Interactions: the expected sequence of interactions between the system and things in its context, including constraints on those interactions (i.e. time 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.
Modelling rather than telling
Given the nature of today's 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.
Analysing and architecting today's complex systems requires tool support and a formal (or at least semi-formal) model of the requirements.
The idea of using models to support 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 launched.
SysML contains appropriate concepts (syntax and diagram types) for capturing the essential things that make up a good system analysis model and system architecture.
Good system analysis and architecture models will not completely eliminate the need for natural language (text) based system requirements - but they will
- reduce the number of textual requirements required
- greatly improve the quality of the system specification
- increase the ability to detect inconsistencies, gaps and ambiguities.
A good tip is to keep analysis and architecture models separate. You need to have traceability between them, but several smaller models are easier to manage than one huge one. In particular, (today's) commonly used modelling tools struggle with large models.
Embrace refactoring
As a project progresses, the understanding of the problems becomes clearer (with any luck!), and so the decisions made at the start can be adjusted on the basis of the experience gained.
Initial decisions are based on guesses and past experience with similar problems. Over time, as knowledge of a particular 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 used in a project should be designed to accommodate such changes.
There are different types of change:
- A change in requirements coming from one of the stakeholders (i.e. the customer). This type of change is usually already accommodated and expected.
- A change in architectural/design decisions, which produces a better solution. This type of change is also normally already accommodated and expected.
- Changes in structure, documentation, terminology. In my experience, these kinds of changes are often necessary, but teams often don't make them.
Refactoring refers to the kind of changes in point (3). It may seem that these kinds of changes are pointless. They may not change the actual solution or affect the final 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 for reducing technical debt.
The same applies to system requirements and architecture. In particular, as you move from natural language requirements to more formal specifications, accepting refactoring as a necessary change will improve the quality, clarity and understanding of the system specifications.
Don't resist change - embrace it!
Train, 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). Projects also tend to last several years. During this time, the people involved change. The new people don't know the history, they don't know why certain things were decided. Even people who have been involved in the project from the beginning sometimes forget or were not present at the 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 might help the project.
Actively learn
All team members, especially team leaders (and I don't mean managers - I mean leaders, which can include managers), communicate constantly. Educate the people in your sphere of influence with information they may have missed. Don't assume that everyone knows something just because you do.
Never assume! Always communicate.
Make every day a learning day and never think you have communicated enough. Remember an aspect of Brook's Law:
"The communication overhead increases with the number of people".
So in a large team, you need to communicate excessively 😄
Conclusion
To conclude:
- Use consistent terminology - this has huge benefits over time.
- Do an effective requirements analysis - it is worth the cost.
- Use models (formal or semi-formal languages) - rather than (ambiguous) natural language.
- Embrace refactoring - it improves quality and saves money in the long run.
Train, learn and communicate - all the time.
Comments