Being a systems engineer is a weird job for many as it’s both specific (technical expert) and broad (product manager). Finding the boundaries for the a system engineer’s role can be tricky as there are lots of overlap with other skilled workers such as business analysts, product managers, architects, and project managers to name but a few. Here I will look to explain where the system engineer works on and how they work with other people.

What does a System Engineer do?

The best way to know what a system engineer does (or should do) is to have a look at two key sources of informations: 1) Systems Engineers Handbook (SEHB) from International Council of Systems Engineering (INCOSE) and the Systems Engineering Book of Knowledge (SEBoK) which is overseen by three groups: 1) INCOSE, 2) International Electrical and Electronics Engineers (IEEE) Systems Council, and 3) Stevens Institute of Technology (private research university in New Jersey, USA). All the fundamentals of doing (being) systems engineering are in these two sources.

Understanding the product, the platform, the people – the system

The primary role of the SE is to own the system or solution of something else depending on how the business/enterprise/corporation describes its things. This is a fundamental of the SE – they are accountable for the system. Yep – accountable. The buck should stop with them when the system doesn’t perform. Now, that sounds like a lot of pressure but it’s not a bad as it seems as the SE is there to bring everyone else’s work together, check that it works before it’s used in the public domain in terms of the of the litres (securityility, dependability, usability etc) and that the business gets the value out of it. We describe these two types as non-functional (the ilities) and functional (the function). The SE ensures there are defined standards for the ilities or records they have been ignored and the number of functions the system has and what those functions do. With functionality we need to be precise. A function is something that takes a defined input, does something to that input, and produces a defined output. What a function is not is a component where a component has multiple functions to create a feature. The structure is non-functional requirement > functions (inputs, processes, outputs) > components > features. When describing and designing the system this is a common way of breaking it down but I’ll get to that later when I talk about modelling.

Both the SE handbook (SEHB) and the SE Book of Knowledge (SEBoK) have around 6 parts to them

SEBoK

1. SEBoK introduction
2. Foundations of Systems Engineering
3. SE and Management
4. Applications of Systems Engineering
5. Enabling Systems Engineering
6. Related Disciplines
7. SE Implementation Examples
8. Emerging Knowledge

SE Handbook (INCOSE)

Process Groups

There are four process groups that explain where systems engineering skills can be used. These four groups take the SE from start to finish as the product is developed to decommissioned. The process groups have defined processes in them (as you would expect). Each process has an input, activity, and output

1. Agreement Processes (2) – getting an SE in the building: 1) acquisition of SE skill, 2) supplier providing SE skill. This group is largely about contracting.
2. Organisational Project Enabling Processes (6) – having the infrastructure to develop products and an enterprise: 1) lifecycle management of products, 2) infrastructure (the environments and technologies to enable the organisation), 3) portfolio management, 4) human resources, 5) quality processes, and 6) knowledge management.
3. Technical Management Processes (8) – managing development of a product: 1) project planning, 2) project assessment and controls, 3) decision making, 4) risk management, 5) configuration management (change control), 6) information management (communication), 7) measurement, and 8) quality assurance (QA)
4. Technical Processes (14) – what the SE can do to manage product development: 1) Business/Mission analysis (the big problem), 2) stakeholder requirements (the detail of the problem and possible solution), 3) system requirements (how and where the solution would work), 4) system design (high level view/model of the solution, 5) detailed design (more detail), 6) systems analysis (checking if the design still fits and could work), 7) implementation (building the solution), 8) integration (bring together all the working), 9) verification (does it operate), 10) transition (move to real life), 11) validation (does it solve the problem), 12) operation (working in real life), 13) maintenance (keeping it working in real life) and, lastly, 14) decommission (turning it off and throwing away.

You may be able to recognise that the first two processes the SE doesn’t get too involved in and the third looks like what a project manager would have responsibility over. This would be true but it is possible that the SE has project management responsibilities as the project delivery approach. The key take away is that the SE’s role sits in the 14 technical processes.

SEBoK – SE and Management

SEBok layouts a very similar structure in part 3 SE and Management. In this section of the SEBoK (the real heart of SE) it first goes into the how science and technology is coming together in more complicated ways and how a method (systems engineering) is needed to coordinate how they work. After this background we go into the main approach of engineering – drawing stuff out – modelling! There’s a lot here so I’ll come back to it.

In the SE Engineering Management we see the same subjects as in the SEHB

SEHB Process Groups > Technical Management Processes	SEBoK – Part 3: SE and Management > Systems Engineering Management
Project Planning	Technical Planning
Project Assessment and Control	Assessment and Control
Decision Management	Decision Management
Risk Management	Risk Management
Configuration Management	Configuration Management
Information Management	Information Management
Quality Assurance	Quality Management
Measurement	Measurement

Again, these are largely project management tasks but it shows the total match up between the two sources. The other sub-parts in SE and Management are what the SE does to complement the technical management side of things. These are the things that need to be done to the system to build it correctly. These processes are pretty much the same in the SE handbook and the SE Book of Knowledge as you would expect. Below is a comparison between the two sources layouts.

SEHB	SEBoK
Business or Mission Analysis Process	Business and Mission Analysis
Stakeholder needs and Requirements Definition Process	Stakeholder Needs Definition
System Requirements Definition Process	System Architecture Definition
Architecture Definition Process
Design Definition Process	Detailed Design Definition
System Analysis Process	System Analysis
	System Realization
Implementation Process	System Implementation
Integration Process	System Integration
Verification Process	System Verification
Transition Process	System Transition
Validation Process	System Validation
Operation Process	System Operation
Maintenance Process	System Maintenance
Disposal	Logistics

These processes are the instruction manual on what to do when you’re an SE. You don’t have to do all of them, you don’t have to spend the same amount of time on each process, you don’t (and shouldn’t) have to do them once, you can add more processes between these processes. Whatever you decide to do these are the 12-15 processes that should be on the To Do List.