What’s a Systems Engineer

There is still an active discussion of what Systems Engineering, and the systems engineer is all about. I found an interesting post on the matter here.

The historical roots have created some of the differences in these definitions of “systems engineering.” For example, the INCOSE definition comes from its roots in electrical engineering and its early application in places like Bell Labs, the defense industry, and space programs.[1]

All systems engineering definitions and all industrial engineering programs share a focus on a set of methods and techniques, although the particular methods and techniques vary.

This article here is not meant to totally resolve the matter, but to bring a personal perspective to the profession.

Basics

Wikipedia starts telling us that:

Systems engineering is an interdisciplinary field of engineering focusing on how complex engineering projects should be designed and managed over their life cycles. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more difficult when dealing with large, complex projects. Systems engineering deals with work-processes and tools to manage risks on such projects, and it overlaps with both technical and human-centered disciplines such as control engineering,industrial engineering, organizational studies, and project management.[2]

Yet, there is, among a lot of other definitions (including from NASA[3]), the more succinct definition given by INCOSE, stating that Systems engineering:

An interdisciplinary approach and means to enable the realization of successful systems.[4]

We can already see fuzzy definitions, relying on very abstract ideas. But, however difficult it would be to exactly define, the discipline is starting from the end result, then finding and applying the proper actions and specific methodologies that enable the project to get there.

So, how do the Systems Engineer fit in here? Surely, we are not sales consultant or network maintenance engineers. It’s nothing truer that we have the customer’s needs and interests in the forefront of our minds. From this point of view, one can say that we are the representatives of our company that sells computer equipment.

Then, it’s obvious, the Systems Engineer is the one that performs the systems engineering activities. He should be a generalist, yet technically proficient when coming to interlink all disciplines and components that concur to form a system. That means a solid knowledge (though not an intimate one) is required in all engineering fields, being it software, electronics, mechanical physics or hydraulics, as well as processes and specific methods and tools. In short, she needs to understand how things work, and more, have strong abilities and vision to have them all work together as one. That sometimes means the need to process and cope with a huge amount of data, existing know-how and new requirements to the end of finding the optimum, and ideally simplest, technical solution.

We saw so far Systems Engineering is supposed to be an interdisciplinary approach, integrating product development activities as: Software, Hardware, Mechanical implementation, as well as some other rather not so exact domains as people, the customer interfacing, legislation, quality orientation while still pushing for results at reasonable costs.

One needs to trust and cooperate well with his team, as he will rely on expert knowledge and realization, while he defines the needs for each component, refining their interfaces to ensure that at the end the entire thing will work as a whole.

Yes, we need to understand what our colleagues are explaining, but our job is to balance through cost and performance, through distributing the feature’s implementation over different functional blocks and/or components. This point of view is drawing us closer to complement the project manager activities, but still not having lost the accentuated technical focus. This is one reason why some companies merge the two jobs in one performed by the technical project manager.

Systems engineering is a highly hands-on role. The System Engineer helps a company develop and maintain the many different technical components that make up a system. [5]

Following LinkedIn group discussions, I found one regarding the role of a Systems Engineer. One answer stated as follows:

A good SE, I would expect, also has a wider knowledge base than most. In my current job I am dealing with issues of Pressure Vessels, Vacuum Systems, Explosive Gases and Atmospheres, Bottle Gas Safety, Cryogenics, Electrical, Electronic and Programmable Control Systems (I started in Electronics). I get regular refresher training on the majority of those aspects to keep up with the current state of legislation. Because of the industry I work with we do have to have an eye to the eventual disposal for most of our materials. [6]

A slightly deeper view on the Systems Engineer

As one can differentiate Systems Engineering in two major activities: Requirements Engineering and Architecture (Design – depending on point of view), so a Systems Engineer can play the role of Requirements Engineer or Architect; or both.

Requirements Engineer

Requirements engineering (RE) is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system. [7]

Shortly then, the Requirements Engineer does activities like:

  1. Requirements management: managing changes to the requirements as the system is developed, structure and categorize requirements, prioritize them, and creates traceability.
  2. Requirement development: copes with requirements elicitation (uncovering and documenting requirement from various sources), their analysis and negotiation, specification, and requirements validation.

Architect

The Architect (or designer) is the one who establishes the technical solution for implementing the requirements. A lot more information about the topic, viewing the role in different contexts, may be found here.

I found an interesting thread regarding what an architect is, on the Microsoft forums. A short excerpt from it:

I would expect someone who is expert in problem solving, can see the most effective way forward for a solution, from a business and technology perspective.

I would see an architect as having excellent communication skills, the ability to translate a business strategy into a set of software solutions.  I would expect an architect to be able to see risk and mitigate it.  I would expect an architect to be able to communicate both to the business and the a technical audience.

I would expect an architect to be able to have knowledge of the technical implementation details rather than just a theoretical or paper based view of the solution.  I would expect that architect to, given their knowledge be able to foresee any difficulties in maintainability, implementation, usability, extensibility and so on and be able to come up with the best compromise on these.

I would expect an architect to also be inventive and able to imagine different ways to do things, including those that may not yet have been attempted by any other architects, to be able to step back and look at the problem, and come up with the greatest solution.

There’s more, but I’ll let someone else have a go at this now!

Martin Platt. [8]

So then, Systems Engineering is a multifaceted discipline, involving human, organizational, and various technical variables that work together to create complex systems.

A Systems Engineer is somebody with strong analytical skills, able to grasp the entire problem in its whole, able to see in perspective, mature and goal oriented to get things done, a good communicator with advanced people skills to gain the respect and cooperation of team and customer; all these backed by a high volume of knowledge and experience in his field.


References

[1] Missouri State University – What is systems engineering? Jane M. Fraser, Colorado State University-Pueblo, Abhijit Gosavi, Missouri S & T

[2] Wikipedia – Systems engineering

[3] NASA – Systems Engineering and Integration

[4] INCOSE – What is System Engineering?

[5] About.com – Systems Engineer

[6] LinkedIn – Group discussions

[7] Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons. 1998

[8] MSDN Forums – Call yourself an Architect?

Comments

New comments are not allowed.

Popular posts from this blog

My Action Dashboard so Things Get Done!

Image
We all know the feeling of being overwhelmed by the sheer amount of tasks that land on our desks each day. It can be difficult to keep track of what's most important and to stay on top of everything. That's why I wanted to share with you my experience with Microsoft ToDo. At first, I was hesitant to use ToDo because of its simplicity. But thanks to its integration with Outlook and its ease of use, it quickly became my go-to tool for planning my day and staying on track. I struggled with finding a system that would help me prioritize my tasks and keep my work and personal tasks separate, while still having them in a single view. That's when I discovered the MS ToDo integration with Outlook. With ToDo, I can easily share a list with any user and keep my work and personal tasks separate. Every morning, I review my tasks backlog and choose the most important ones for the day, adding them to 'My Day'. Then, using Outlook's 'Boards' view, I can load my 'M...
Read more

The Power of Good Enough: Why 90% is Perfect

Image
It's easy to fall into the trap of perfectionism in the pursuit of excellence. We set impossible standards for ourselves and try to achieve flawlessness in everything we do. However, the truth is that perfection is an unattainable goal, and even if we try our hardest, there will always be room for improvement. That's where the Pareto principle, also known as the 80/20 rule, comes in. This principle states that roughly 80% of effects come from 20% of causes. In other words, for any given task or project, 80% of the results can be achieved with just 20% of the effort. But what about the remaining 20%? That's where the principle of "good enough" comes in. In most applications, achieving 90% of the desired outcome is sufficient. In fact, striving for more than that can be counterproductive and lead to diminishing returns. For any practical purpose, 90% is perfect! Think about it: If you spend 80% of your time and energy trying to achieve that last 10%, you're only...
Read more

Why Am I Doing This Thinking Online

Image
In the last couple of days, I had some debate with my wife on why writing everything down. This can be an annoying habit sometimes, I admit. Though, there is a long way towards I could say I’m exaggerating. Only trying to get out the best of me, and the situation at hand. Then I took some time for really thinking about it. All my lofty ideas' implementation followed through to completion and all accomplishments came like this. Cause what good is a god given strike of genius that only happens into your head, when it dies being forgotten the second day, never having the chance of being transmuted into reality? This crystallized my vision on approaching problems, and realized all is well confirmed by my previous experiences in life, both by successes and missed opportunities. At the same time, this clarifies (to me for first) my activity here, on this site. Opportunity is missed by most people because it is dressed in overalls and looks like work. – Thomas A. Edison  1. I have an inte...
Read more