Here are five tips to boost your systems engineering projects:
- Get the right people on board: Make sure leaders have excellent leadership skills and engineers possess the necessary technical know-how.
- Treat all requirements equally: Whether they're customer, stakeholder, or system-related, focus on building a unified team that includes software, hardware, and mechanical experts to prevent internal divisions.
- Focus on system behavior: Break down the system into functional components that integrate multiple disciplines, rather than separating them by mechanical parts. Understand the difference between features and parts.
- Use the right tools for the job: Steer clear of tool misuse and use independent traceability tools. Keep in mind that no single tool can meet every need.
- Adopt practical, automated, and accurate methods: Track progress and evaluate other project metrics with these methods.
It's easier said than done, but this is really my number one suggestion. Having the right people in the right roles greatly increases the likelihood of a successful project.
When you find talented people, treat them well - they're your greatest asset. Trust skilled engineers to excel at their jobs without micromanaging them. A good engineer is passionate about their work, takes pride in it and wants to create a great product. They're often constrained by time and budget, but the best engineers understand this and work within these limits. Encouraging a good engineer to improve isn't usually necessary; instead, you often have to persuade them to scale back their ambitions to fit the budget.
Allow engineers to take pride in their work.
Avoid burdening them with inefficient processes, inadequate tools or unrealistic expectations. Listen to their input and create an environment where they can perform at their best. Recognise that a one-size-fits-all approach won't work - people are different, so establish working standards and processes that allow for individual variation while maintaining consistent quality. This can be challenging and may require some compromise.
Leadership, particularly in technical roles, is an often overlooked skill. Many people end up in leadership positions without adequate knowledge of how to be an effective leader. It's important to understand the difference between management and leadership. While this article won't focus on leadership skills, it's worth noting that good leadership can have a huge impact on a team's motivation and effectiveness.
The only requirements
Create a well-written system design based on all other stakeholder requirements combined. Customers (for example) provide requirements. There are no other requirements, i.e. no discipline (SW, HW, etc) specific requirements.
Requirements are part of a contract between two parties who want to be able to prove that something is or is not fulfilled for financial, security, etc. purposes. The two parties are not on the same team, one is providing something to the other and it is necessary to clearly define what is required.
Within the same company this should never be necessary, it is the SAME company, therefore the same team. There should be no need for contracts within the company, everyone should feel that they are on the same team and contributing to customer satisfaction.
From a technical perspective, the system design team must include the lead domain (SW, HW, etc) architects. The system can only be designed correctly if these people are involved. The system is the combination of what the different domains produce. The systems team is there to make sure it all fits together, to provide a bridge and communication path between the different domains.
Stakeholder requirements come in all shapes and sizes. Sometimes good, sometimes bad, the systems team has little control over customer requirements. However, the team should always be prepared to push back on a customer and tell them where their requirements are problematic, inconsistent, ambiguous, etc. - garbage in means garbage out, you can't produce a product that satisfies unclear requirements.There are stakeholder requirements. There is a system design and there are software (SW), hardware (HW), mechanical (Mech), etc designs that implement and contribute to the system design.
Behaviour is king
Why do I say that behaviour is king? Well, because if I just want to buy a box or a brick, I don’t need a system. Systems exist because of the behaviour they exhibit, not because of their size or their weight.
Most modern systems (certainly in the field I work in) include a lot of software. It would be nice and easy, if the systems team could simply delegate behaviour to software — “That is a behavioural requirement or issue, therefore it’s a software problem not ours.” — I have heard that said!
Maybe systems engineering can get away with that approach under certain restricted circumstances, i.e. one processor and the hardware and mechanical parts are just there to support the processor. However, interesting, modern day systems are rarely like that. Most include multiple processors, and involve hardware, firmware, mechanical, and maybe even other domains such as optical, security, etc.
The behaviour of the system as a whole is provided by the interaction of multiple parts from multiple domains.The system team needs and must take ownership of this distributed behaviour. They must design it and understand it and it has to be tested at a system level.
This is not a trivial task. Designing and modelling (writing down, describing, specifying) behaviour is not easy for complex systems, and simple text is a really bad (in particular ambiguous) way to do it.
To do it well systems engineering must take ownership of three things:
- The required system behaviour as a black box.
- Functional breakdown. How the behaviour is broken down and provided by parts within the system.
- The mapping between these two.
Black box system behaviour.
The system generally has complex behaviour and it can be broken down into sub behaviours. These are referred to by different names: Features, Use Cases, Scenarios, System functions, etc. The important thing is that they sub-divide overall system behaviour, but still treat the system as a black box. The sub-behaviours (I will use the term feature from here on) are still behaviours of the system as a whole.
Functional breakdown
How the behaviour is broken down and provided by parts within the system. This is probably the most important aspect of “system design”. This should be done in collaboration with the other domain leads, as it result in the definition of the parts (some people name these Functional Blocks) that are ultimately realised by specific domain parts. The breakdown at system level should be sufficient that one Functional-Block is implemented by one domain. i.e. a Functional-Block is realised by either HW or SW, not both.
Mapping
The mapping between behaviour and structure is a matrix. Features (behaviour) go on one axis, parts (structure) goes on the other axis.
The matrix content shows which parts of the system are used to provide which features.Use the correct tools
There may be “One Ring” but there is no one tool that rules them all. There is no single tool that can be used for every task involved in engineering projects.
The best approach is, in collaboration with the engineers who use the tools, to define the tasks that need doing, and look for tools that support that task. A tool that is design to support a single task is probably much better at supporting that task than a general purpose tool, or a tool that was designed for something else.
What is the best tool for opening a tin of food? A Swiss army knife, a tin opener or a screw driver?Let’s start with IBM DOORS. This tool is “the” tool in most System Engineering projects I have worked with. I could imagine a sales slogan from IBM along the line of “if you are not using DOORS then you are not doing System Engineering”!
As is says on the product website, IBM DOORS is “is a requirements management application”. Whether you think it is a good requirements tool or not (there are many other options, e.g. Jama or one of the others from this list), it is a tool that is designed for managing requirements.
DO NOT use it for something else!I have seen several miss-uses (or abuses) of DOORS and it pains me greatly. Why? because:
- DOORS was not designed for the task, thus does it quite badly or inefficiently.
- It frustrates the users (engineers) and reduces moral. Any poorly functioning equipment reduces moral in a team, this ultimately leads to a drop in quality and reduction of effort applied to the project.
- Wastes budget, raises costs. The right tool should speed up development, and help an engineer do the job, rather than get in the way and slow down progress.
Some of the abuses of DOORS I have seen include:
- As an issue tracking tool. Try one of these alternatives, personally I like JIRA or YouTrack.
- As a review management tool.
- As a design capture tool. This is possibly my favourite one to hate. DOORS is predominantly a tool that manages snippets of text. You cannot sensibly capture a product design in text! Use a design tool and understand the difference between requirements and design (e.g. learn SysML).
Traceability is of course important and it can be easy to get tempted into misusing one tool for the wrong task simply because it enables easy traceability.
DO NOT do this!There are many independent traceability tools, that enable traceability tracking between multiple different 3rd party tools, often with no need for additional manual involvement. If your favourite tool is not connectable, I know a Traceability tool vendor who is more than happy to add a custom connector on-demand.
The following, of course, applies to all tools in your tools chain:
Use the right tool for the right task, and do not abuse a tool by using it for something it was not designed.Oh, and before you get tempted, an Excel sheet on a shared drive is NOT a good solution for anything! Although it is quick and easy to set up, in general there is a better, purpose built tool, to do the job.
Automate and explain metrics
I have seen such a lot of time spent by engineers on counting and collecting data for metrics, rather than on engineering work. This really is such a waste of company resources.
In this day and age of IT based work, if you can’t collect the data automatically, then there is a big problem with the way you are working. Collect the metrics automatically, or don’t collect them at all. Aside from the fact that it is a waste of time for the engineer doing the counting, people make mistakes when counting things, machines don’t. The metrics will be far more reliable and give more accurate information if automatically collected.
Secondly, make sure the metrics are a true indication of what you want to know. Explain fully how a metric is computed, do involve the engineers in setting up the calculations, so that they agree that the metric is a correct representation of whatever is being measured.
Ensure that part of the explanation of a metric, includes a range for where the value is OK, what it means if the metric is out of range and what should be done to bring it back in range. Basically, don’t measure something without knowing what to do with the result of the measurement.
Conclusion
To conclude, I will simply repeat how I started, though more briefly:
- Employ the right people.
- Customer/Stakeholder requirements are the only requirements.
- Behaviour is king.
- Use appropriate tools, appropriately.
- Automate and explain metrics.
Comments