The Systems Engineering (SE) methodology in product development brings together all related disciplines and functions to cover the full system development lifecycle from concept to design, implementation, operation, maintenance, all the way to retirement. While it is broadly used nowadays, Systems Engineering can still mean different things for different types of products, companies, and industries.
Read on to discover a breakdown of the Systems Engineering philosophy, the core principles you should keep in mind, and the different steps you need to take to implement this approach.
Systems Engineering is an interdisciplinary approach that was designed to create efficient and successful systems while staying on budget and schedule. Coined in the 1950s, it was initially meant for large-scale defense systems in the US, but has since evolved to a broader discipline used across industries as a product development guideline. It can be applied to any type of system development, whether you are working on a defense system, vehicle, household appliance, or even building the house itself – Systems Engineering is widely applicable to help manage complexity.
As an approach, it puts a special emphasis on the following procedural aspects: meeting customer needs, defining requirements early on in the development cycle, working closely with stakeholders, and documenting everything meticulously along the way. Using Systems Engineering techniques, you can then proceed to the design synthesis and system validation stage with a full view of the problem and the proposed solution you have in mind.
Before we dive into the various steps of Systems Engineering, it’s worth reviewing the core principles which give shape to this methodology so that you can use them to leverage the benefits of Systems Engineering to the fullest extent possible:
It may sound obvious, but many teams kick off a project with a solution on the table before the problem has even been thoroughly analyzed. And when you start from the perspective of a solution, you may end up defining requirements and risks which match the solution you had in mind, instead of using the Systems Engineering design process to identify the best possible solution for that specific requirement. There may be a whole variety of ways to solve the problem you want to fix: it’s more likely you’ll pick the best one if you define the problem first.
The most successful projects keep their stakeholders close throughout the entire process of product development. This means involving customers, users, operators, technical personnel, and any other relevant stakeholders at regular intervals. For this reason, the Systems Engineering approach includes a series of reviews and decision points that are implemented to ensure visibility, encourage early feedback from everyone involved, and make sure that everyone is on the same page. This applies to the initial requirements definition phase and all the way through systems verification and acceptance. It gives stakeholders many opportunities to give feedback and contribute insights and highly valuable inputs.
Modern systems are vast and complex, and getting more so every year with the advent of technology – not to mention the growing number of product variants. One of the key principles of the Systems Engineering strategy is to break down a big system into many small subsystems and then breaking down the subsystem into its software and hardware components to make development easier to manage. Building the components separately (while still having a picture of the whole system and all its moving parts) is significantly easier to do. Then the components and whatever problems they face can be mastered and recombined into the bigger system.
It’s all about being able to retrace your steps to see what has changed and why. This is why the link between all the items and actions in the Systems Engineering lifecycle process is called traceability. When you move from one step to another, it’s important to be able to connect those steps together and to make them visible to everyone else in the team (as well as auditors).
For example, once you’ve defined a requirement, you can connect that to a user need, which is then connected to risks, tests, and verification steps. Ideally, any and all changes to all these artifacts are also recorded for version control. Making sure that you have traceable steps throughout the process helps everyone stay on top of changes, allowing for effective collaboration and compliance when it comes down to it. This helps having faster and more efficient impact analyses. Change management won’t be the nightmare it used to be without traceability.
Now that we’ve reviewed the core principles of the Systems Engineering approach, it’s time to understand how these can be applied in the product development process.
Systems Engineering is all about trying to manage the system through its entire lifecycle and to manage all the relevant relationships to other related systems. This lifecycle is generally broken down into several stages, where each one has its own characteristics and purpose. The INCOSE Systems Engineering Handbook defines 6 generic lifecycle stages through which a system evolves: Concept, Development, Production, Utilization, Support, and Retirement.
Understanding the needs for each stage from the beginning will help you have a better system definition right from the outset. Let’s take the example of an embedded battery! Such a component has implications for various stakeholders along the lifecycle. You’ll have to consider the use cases and requirements and how they affect the various lifecycle stages and stakeholders:
To support managing the complexity of the lifecycle, standards have been defined and proposed as reference models that help cover all the aspects needed.
For example, ISO/IEC 15288 defines the following process groups:
Let’s see how all this works out in real life!
Step 0: Systems Engineering Process Inputs
To get started with System Engineering management processes, you will first need to analyze what is known as the process inputs. Process inputs are the various customer needs and requirements, as well as project constraints like time, budget, and materials for example. Inputs can include a whole range of information and metrics to help give context to the project you are about to undertake, all the way from goals to measures of success, environments, available tools, etc. The main objective here is to understand the problem or status quo before you get going.
Step 1: Requirements Analysis
Next comes the requirements analysis phase. Using the customer needs outlined in Step 0, you analyze the requirements in order to meet those needs, which allows you to define a concrete set of functional and performance requirements. In other words: what will the system do, and how will it do it. It is vital that the requirements outlined at this stage are clear, easy to understand, and concise. This will also help the team come up with realistic design constraints and evaluate possible risks.
Step 2: System Analysis Control
This is the part of the project where you plan the necessary work and activities that need to be undertaken to carry out the Systems Engineering process in software engineering. It is also the time to come up with scheduling and cost estimates. Finally, you will outline the technical management activities necessary to track the project development process and documentation of the entire project, ensuring traceability at every step of the way.
Step 3: Functional Analysis/Allocation
At this stage, higher level functions are broken down into lower-level functions using requirements analysis. You need to do this in order to provide a description of each product, what it does, what it needs, and how it should perform. This will shape the functional ‘architecture’ of the product or item and allow the team to understand how all the moving parts fit together. It also gives the team and management more visibility and understanding of what to prioritize and where conflicts may arise throughout the process.
Step 4: Design Synthesis
After the functional architecture, you'll need to define the physical architecture. This is the phase in which you outline the product's hardware and software elements. It is important to note that every element needs at least one functional requirement, but can have many on top of that.
There are several other Systems Engineering techniques that repeatedly take place as you go through the development process. These are:
And there you have it: the core steps which form any system engineering management process! While the details may vary from industry to industry and company to company, these are the structural elements that will be consistent across the spectrum of Systems Engineering practices.