What is Systems Engineering?

In this article I’m going to briefly outline the role and purpose of a Systems Engineer. This should hopefully come in useful for either Project Manager’s in industries such as the Defence Materiel Organisation or Defence Industry who seek to hire one, or engineers who seek to become one. Although it’s a bit of a niche, the renumeration can be good due to the variety of different skills and technical background required, as well as the fact that there’s typically more demand than supply. For employer’s seeking one, it can be useful to understand their role better in order to determine whether the person is really suitable, or whether you could train a regular engineer into a systems engineer. In my mind, a potential systems engineer would want a strong technical background, the ability to read and understand mountains of documentation and turn that information into actionable tasks, and the ability to think big picture.

What is Systems Engineering?
Systems Engineering is fundamentally a tool for dealing with complexity in large systems.

It’s not necessarily suitable for all systems, but when projects get large, suddenly the things that seemed easy get more and more complicated. It can be hard to keep track of the scope of the problem, which can span multiple disciplines and have many, many stakeholders, all of which need to be satisfied before the project can be declared a success.

Even worse, when projects get large, mistakes can become very, very expensive to fix. Suddenly any hours spent on Systems Engineering are dwarfed by the magnitude of the costs to fix problems that could have been averted if detected early. For example, if a particular stakeholder (one of many) is stating that they need a multicast capability when building a large computer network, when using ad-hoc processes (or no processes) it’s very possible for the system designers to simply forget or misunderstand the requirement. The architecture of the system will then probably be designed without this capability, and then implemented at full cost. During testing, that particular stakeholder will attempt to test multicast only to find it has not been built into this system. The two options are then to either proceed without the required functionality, or go back to the design phase and attempt to redesign and then re-implement the entire system, potentially costing millions or even billions of dollars.

How could this have been avoided? If someone had simply validated that the architecture and design adequately met the original requirements, the missing functionality could have been built in. Or, if the cost was too great or the design too adversely influenced, the stakeholder(s) could have been consulted before it was too late to make a decision.

And what about the original requirements themselves? Systems Engineering also covers the elicitation of requirements. At first meetings are held with all stakeholders (a stakeholder is anyone with enough influence to declare the project a failure, for example the users, management, security analysts who can say it’s not secure enough) to determine their needs. Then needs are broken out into specific requirements eg ‘The system should be accessible from a web browser’. Generally it’s important to remain as design agnostic as possible, but the more requirements are designed the more you are actually architecting the system. In the above example you’ve made the design decision based on the fact that many users won’t have the admin rights to install new software on their computer, that the system will be a web based application.

From here detailed designs are now drawn up that attempt to satisfy all of the requirements, within the context of the Operational Concept Document which is simply a high level view of the project. The design activity is often outsourced. In the Systems Engineering process it’s very important that each requirement be linked to exactly where in the design it will be satisfied, and how that satisfaction will be measured.

For example a requirement may state that a system requires 99.9% up time. Somewhere in the design documentation it should mention uptime and a more specific plan for how it will be achieved. If there is a gap and uptime has not been considered, then who’s to say it will be implemented? It’s very easy for the implementers of a design to have tunnel vision and simply forget (hey, I’ve been there!). Suddenly your uptime requirement simply disappears, potentially making the project a catastrophic failure if it was a critical requirement. It would have been far better to simply check that it was being implemented, update the design if it had been an oversight, or if it had been specifically omitted by the designers find out why and consult with the relevant stakeholder to see just how badly they need that in the system. Either way, large amounts of work won’t have to be undone later, because the project won’t continue until it’s figured out.

For small, agile business’ this can seem like a nightmare because the schedule is king. They ship early and iterate until it works. For larger project’s this just isn’t an option, because making even minor changes to projects can have major ramifications in other areas. And changing or reimplementing the requirements is really changing the architecture, something even the small projects try to avoid.

It’s bad with software since programmers can be expensive to hire and suddenly they’re undoing old work and rewriting it, which is an expensive waste. But imagine if the design wasn’t software but something physical, like a Battleship? A stakeholder (for example the Navy) have said they absolutely need a mode of operation where zero electromagnetic signals are emitted, but the networks still work internally. If the designers miss this or simply pay lip service, when it comes time to do TEMPEST testing the design is going to fail miserably, and without proper electromagnetic control the ship is a dud. Rework has to begin and the schedule goes 6 months to the right. Not only are the vendor annoyed because they’re losing millions of dollars, the government buying the ship are annoyed because they have to make do without the ship they thought they’d have, and they also need to keep staff on their side of the project, which strains their budget also.

So basically so far we’ve seen that a Systems Engineer (or a team of them) will:
–  Elicit requirements from stakeholders
– Produce a Functional Performance Specification (aka ‘the requirements’) which is a very high level architecture of the project, which also specifies how these requirements will be tested and often becomes an important contractual interface with the designer.
– Design the system from the requirements – However this step is often outsourced
– Once the design is complete, verify the design satisfies the requirements, sending it back for redesign where it does not.
– Test the physical implementation once it is complete to ensure it satisfies the original needs of the user.

 Systems Engineers also perform:
– Tradeoff Analysis between different architectural and design options
– Safety Management
– Risk Management (Project Management overlap)
– Security Management (due to the technical nature of it)
–  Maintain and Engineering Decision Log to aide in communication across teams and over time (as new staff arrive and old staff leave)
– Integrated Logistics Support – How will the system be maintained after it has been procured and the project closed? This details finding and establishing relationships with component suppliers (including the original supplier), writing the training documentation and detailing how it will be disseminated / used, and writing the maintenance manuals that technicians will use.

This, along with a variety of other considerations that come into play when projects get bigger than just a close-knit group, are the process of Systems Engineering.

There are a few different places to go for more information on the activities, outputs and structure of the actual process. There are actually competing standards, here are a few of them:

MIL-STD-499C. A US DoD standard, 499 was the first SE standard. Things have moved on since then, and 499C is the draft copy of the latest version.
– ANSI/EIA 632
– ISO/IEC 15288
– SEBOK: http://g2sebok.incose.org/

I hope this has given you a brief overview into what the Systems Engineering profession is all about. If you’re looking for Systems Engineers in Victoria, Australia, feel free to contact nick.cooper@coopersystems.com.au for advice or referrals.

Did you like this article? Check out the free task management tool I’m developing at teamsgo.com. You’ll love the simplicity, and your colleagues will love how much more orgnised you are. http://www.teamsgo.com

Comments are closed.