SYSTEMS ENGINEERING

ABSTRACT

Since its inception, INCOSE (INTERNATIONAL COUNCIL ON SYSTEMS

ENGINEERING) has been attempting to resolve the question of what, exactly, is systems
engineering. Several dualities have been explored, including whether systems engineers are
specialists or generalists, and whether systems engineering is a set of life-cycle roles, such as
the generation of specifications and verification programs, or an overall program
management discipline. There has even been a discussion on whether systems
engineering is a discipline or an attitude. Worthy and wise arguments have been put forth
on both sides of each issue, leaving some to despair of ever being able to pin down
definitions that all can agree on.

INTRODUCTION
Different roles of system engineering are defined in detail here. First, the meaning of
“systems engineering roles” is discussed. Next, twelve systems engineering roles are
defined. These roles are then considered in relation to “life- cycle” and “program
management” roles, the two major paradigms of systems engineering responsibility.
Then the whole process is explained with one small case study.

DEFINITION OF SYSTEM ENGINEERING

A Consensus of the International Council on System Engineering (INCOSE) Fellows
defines it as “System Engineering is an engineering discipline whose responsibility is
creating and executing an interdisciplinary process to ensure that the customer and
stakeholder’s needs are satisfied in a high quality, trustworthy, cost efficient and schedule
compliant manner throughout a system life cycle.”

SYSTEMS ENGINEERING ROLES

1. Requirement Owner

2. System Designer

3. System Analyst
4. Validation/Verification Engg.

5. Logistics/Ops Engineer
6. Glue Among Subsystems

7. Customer Interface

8. Technical Manager
 9. Information Manager

10. Process Engineer

11. Coordinator
12. Classified Ads SE
1. Requirements Owner (RO) Role.
Requirements Owner/ requirements manager, allocator, and maintainer / specifications
writer or owner / developer of functional architecture / developer of system and subsystem
requirements from customer needs.
This role groups several requirements-related tasks together. The first is translating
customer needs into specific, well-written requirements to which systems and
subsystems (sub elements, pieces, software and hardware, control items, etc.) can be
architected and designed. Requirements duties include understanding all external
interfaces and ensuring the functional architecture correctly captures the need.
2. System Designer (SD) Role.
System Designer / owner of “system” product / chief engineer / system architect /
developer of design architecture / specialty engineer (some, such as human-computer
interface designers) / “keepers of the holy vision” [Boehm 94].
An engineer in this role creates the high-level system architecture and design and
selects major components. Possible ways of building the system from pieces are
investigated and compared to the system requirements, the system design is selected
and fine tuned, needs for the next lower subsystems are described in detail, and it
is confirmed that subsystems that can meet the specifications are available or can be
developed. Because of the complexity of projects employing systems engineers, the
emphasis tends to be on architecture, high-level design, integration, and verification,
rather than on low-level development.

3. System Analyst (SA) Role.

System Analyst / performance modeller / keeper of technical budgets / system modeller
and simulator / risk modeller / specialty engineer (some, such as electromagnetic
compatibility analysts).
System analysts confirm that the designed system will meet requirements. Typical
analyses include system weight, power, throughput, and output predictions for
hardware systems, and memory usage, interface traffic, and response times for
software systems. Usually the more complex parts of the system need to be modelled in
order to demonstrate that they will work properly and interface properly with the
external world. Modelling also helps the systems engineer and others understand
how the system will be operated.

4. Validation and Verification (VV) Role.

Validation and Verification engineer / test engineer / test planner / owner of system test
program / system selloff engineer. VV engineers plan and implement the system
verification program to ensure the system, as designed and built, will meet the specified
 requirements. In some organizations, systems engineers also write the detailed system test
plans and test procedures. During the system verification process, questions usually
arise as to what was supposed to have happened during a scenario. VV engineers are
responsible for answering these questions in real time and, to the extent possible, for
predicting such behaviour in advance. VV engineers also are required to respond to
anomalies with the best possible understanding of the system design. They must
also know which experts to call when needed.
5. Logistics and Operations (LO) Role
Logistics, Operations/ maintenance, and disposal engineer / developer of users ‘manuals
and operator / training materials.
This role captures the back end of the “cradle-to- grave” or “lust-to-dust” system life
cycle. During the operational phase, systems engineers sometimes operate the
system for the customer; more often, they serve “on call” to answer questions and
resolve anomalies.
In addition to owning primary responsibility in the later phases of programs, LO
engineers are usually expected to bring maintenance, operation, logistics, and disposal
concerns to the requirements, design, and development phases. As creators of
users’ manuals, they need to understand most design aspects and all operational aspects
of the system, and determine what users do and do not need to know about the system.
6. Glue (G) Role.
Owner of “Glue” among subsystems/ system integrator / owner of internal interfaces /
Seeker of issues that fall “in the cracks” / risk identifier/ “technical conscience of the
program”
In this role, the systems engineer serves as a proactive trouble shooter, looking
for problems and arranging to prevent them. Since many problems happen at
interfaces, this role involves a very close scrutiny of interfaces, particularly internal,
subsystem- to-subsystem interfaces. While the designers of the subsystems struggle to
make their subsystems do what they are supposed to, the G systems engineer is
watching to ensure that each subsystem is not going to interfere with the others.
In hardware system negative effects such as electromagnetic incompatibility and
passive intermediation products can be caused by designers of structural subsystems
inadvertently employing materials that adversely affect the system electronics.
Incorrect software module interfaces can result in out- of-bounds conditions, race
conditions, or inappropriate failure recovery sequences. In the G role, systems engineers
need wide experience, meaningful domain knowledge, and an interest in continuous
learning to stay a step ahead of problems like these.

7. Customer Interface (CI) Role.

Customer Interface / customer advocate / customer surrogate / customer contact.
In a pivotal work in the field of
systems engineering defines the Systems
Architect role as a combination of the SD (System Designer) role and this role.3 Systems
engineers can be asked to represent the point of view of the customer, and to see that it
is properly respected throughout the program. They can also serve as the interface to
customer technical personnel in this role, striving to ensure the “right” system is built,
and that the details are as customer-friendly as possible.
The CI (Customer Interface) role includes only the role of the engineers building a
customer-deliverable product, not the full marketing process of a business or organization.
The CI role is handled quite differently by different organizations and businesses. Some
prohibit engineers from talking to the customer, either because they believe that a
customer would want to talk to someone at a higher level, i.e., a manager, or because
they fear that technical people will “give it all away for free,” promising a more
thorough interpretation of contract requirements without negotiating additional funding.
These organizations do not consider CI to be a systems engineering role.

8. Technical Manager (TM) Role.

Technical Manager / planner, scheduler, and tracker of technical tasks / owner of risk
management plan / product manager / product engineer.
Technical management is one part of program management, which also includes
controlling cost, scheduling resources, and maintaining support groups such as
configuration management, computer network staff, and finance. The technical
management part is sometimes assigned to a program systems engineering manager or
to engineers responsible for the customer- deliverable system.
As the reach of systems engineering extends to commercial companies, a type of
systems engineer called the Product Manager or Product Engineer appears. This
role is similar to a Systems Engineering Manager role, with authority over a much
smaller group of engineers, maybe only one. On a small project, the Product
Manager or Product Engineer may wear more of a marketing hat and more of a cost and
schedule hat than technical managers on large programs wear.
9. Information Manager (IM) Role.
Information Manager (including configuration management, data management, and
metrics).
Historically, some authorities have considered configuration management to be systems
engineering role. These are generally the authorities who lean toward he “program
management” view of the systems engineering task. As information systems become more
complex and more pervasive, it becomes more
Important for someone to view the overall information needs of the system, and even of the
business. Thus, this role may grow to include data management and process asset
management.
Organizations attempting to improve their capability maturity begin to define
and capture metrics. The organizational set of program metrics can be considered
information to be managed, preferably by someone with an enterprise-wide viewpoint.
10.Process Engineer (PE) Role
Process engineer / business process reengineer / business analyst / owner of the systems
engineering process.
This is a fairly recent systems engineering role. Those who do systems engineering are
also expected to document, follow, own, and improve the project’s and the organization’s
systems engineering processes. This role also calls for defining and capturing systems
engineering metrics.
Recently the “reengineering” of industry has called for a cadre of “reengineers” to be
developed, and those trained in systems engineering have sometimes been asked to
participate, because the skills of designing a complex product can be applied to
designing business processes as well.
11. Coordinator (CO) Role.
Coordinator of the disciplines / tiger team head / head of integrated product teams
(IPTs) / system issue resolver.
Because systems engineers have a broad viewpoint, they are sometimes
asked to coordinate groups and resolve system issues, at least to the point of seeking
consensus, or making recommendations, when consensus cannot be achieved among the
participants. Even if there are no “systems engineers,” coordination can be considered vital
to the engineering of a complete system. This role may be permanent, defined in terms of
team or discipline coordination, or transitory, established to solve a specific
problem and then dissolved. Team leadership and the ability to facilitate groups in
developing their own leadership skills and working norms are skills that are more
necessary for this role than for others.
12. “Classified Ads Systems Engineering” (CA) Role.
This role was added to the first eleven in response to frustration encountered when
scanning the classified ads, looking for the INCOSE-type of systems engineering
jobs. Approximately half of the advertisements for “systems engineers” in a
recent newspaper seemed to be asking for other things. For example, note the words in
selected ads:
“Skills must include shell scripting, SQL, performance analysis, and network
integration.”