Teaching Systems Engineering to Software Engineering Students

Richard E. (Dick) Fairley, PhD

Mary Jane Willshire, PhD
Software and Systems Engineering Associates (S2EA)

Abstract
This paper describes the relationships between systems engineering and software
engineering and indicates ways in which systems engineering concepts can be integrated into
the SE2004 curriculum guidelines for software engineering to produce software engineers
who can effectively participate in systems engineering endeavors. This paper is a companion
to “Teaching Software Engineering Concepts to Systems Engineers” which appears in the
proceedings of the 2011 ASEE conference.
1. Introduction
It is widely recognized that software is the element that binds together the diverse
components of modern technological systems and provides much of the functionality in
those systems. However, many undergraduate software engineering students are not
sufficiently exposed to system-level thinking or the methods and techniques of systems
engineering. Some software engineering students may take some embedded systems
classes but those classes are usually at the bit and byte level of hardware-software
interfaces. Some software engineering students may receive an introduction to systems
thinking in their senior project classes but many do not and for those who do, the exposure
is often superficial. Software engineers who graduate from these programs are not taught
to think of software as components of more complex systems that include hardware,
software, and people. As a result, software engineers are often delegated to the “second
level” of systems engineering endeavors because they are not qualified to participate as first
class members of systems engineering teams, which are typically led by and include
engineers from traditional disciplines such as electrical, mechanical, or aerospace
engineering who have received training and/or accumulated experience in systems
engineering.
It is somewhat ironic that software engineering students should need to be educated in
systems engineering because many of the concepts of software engineering have been
adapted and tailored from systems engineering; they include stakeholder analysis,
requirements engineering, functional decomposition, design constraints, architectural
design, design criteria, design tradeoffs, interface specification, traceability, configuration
management, and systematic verification and validation. Systems engineers are also
concerned with the entire lifecycle of a product, or family of products, from concept
through development and sustainment to disposal. Software engineering students are
seldom shown how the methods and techniques inherited from systems engineering are
applied at the system level.
Also, software engineering students are seldom shown how the methods developed by
software engineers (model-driven development, UML-SYSML, use cases, object-oriented
design, iterative development, agile methods, continuous integration, incremental V&V,
and process modeling and improvement) can be, and are being used by systems engineers.

219
978-1-4577-0348-5/11/$26.00
c 2011 IEEE CSEE&T 2011, Waikiki, Honolulu, HI, USA
Table 1. Systems Engineering Methods adapted to Software Engineering (SE to SwE)
and Software Engineering Methods adapted to Systems Engineering (SwE to SE)

1a. SE to SwE 1b. SwE to SE

stakeholder analysis model-driven development
requirements engineering UML-SYSML
functional decomposition use cases
design constraints object-oriented design
architectural design iterative development
design criteria agile methods
design tradeoffs continuous integration
interface specification incremental V&V
traceability process modeling
configuration management process improvement
systematic verification and
validation

In addition, the malleable nature of software and the methods used to develop software
have resulted in different uses of terminology and emphasis on different aspects of the
artifacts produced by systems engineers and by software engineers. Some examples: the
term “performance” is often used by software engineers in the narrow sense of throughput
and response time, whereas systems engineers often take performance to mean satisfaction
of all the non-functional requirements for a system. Version control and configuration
management are typically more fluid for software than for physical components. Safety
and dependability are sometimes addressed in software engineering curricula but software
engineering students need to understand how these issues are best addressed at the system
level. In addition, software engineering students need to understand how to quantify non-
functional considerations such as cost/benefit tradeoffs, reliability, and MTTF at the system
level.
The following sections of this paper provide some background information on systems
engineering and then address ways to introduce systems thinking and systems engineering
into software engineering curricula based on the SE2004 guidelines for software
engineering curricula [1].
2. The interdisciplinary nature of systems engineering
Systems engineering, as defined by the International Council of Systems Engineering,
is:
“. . . an interdisciplinary approach and means to enable the realization of successful
systems. It focuses on defining customer needs and required functionality early in the
development cycle, documenting requirements, then proceeding with design synthesis
and system validation while considering the complete problem:
Operations, performance, test, manufacturing, cost & schedule,
training & support, and disposal.

Systems engineering integrates all the disciplines and specialty groups into a team effort
forming a structured development process that proceeds from concept to production to
operation. Systems engineering considers both the business and the technical needs of
all customers with the goal of providing a quality product that meets the user needs.”
[2]
220
 Systems engineering can be regarded as the discipline that coordinates the activities and
work products of other disciplines to produce and sustain complex systems that are
composed of diverse components. Systems engineers, by the above definition, do not
engage in development of system components. Instead, systems engineers coordinate the
development of system components by component specialists.
The primary activities of systems engineering include analysis, design synthesis,
allocation of requirements, integration and verification, and system validation. Systems
engineers may also oversee delivery, installation, and life cycle sustainment of systems.
Systems engineers, like software engineers, develop options that involve tradeoffs among
technology, cost, schedule, and risk; and then present those options to decision makers and
other stakeholders.
From the viewpoint of a systems engineer engaged in developing a complex system,
software is one of many system components that may include diverse kinds of hardware
(computers, analog and digital devices, other machines and structures), natural resources,
software to be developed, existing components to be incorporated, interfaces to be
provided, and human elements (operators, service personnel, and maintainers).
3. Software systems engineering
At the software level, the systems engineering framework can be applied to development
of software-intensive systems for which software is the primary element to be developed.
A software systems engineer may be called a software architect or lead software designer.
Like the systems engineer, a software architect engages in “documenting requirements,
then proceeding with design synthesis and system validation” [2]. Software architects
coordinate the work activities and work products of software component specialists who
may include, for example (depending on the nature of the software to be developed) user
interface, database, computational, communication, and security specialists.
Software requirements, interfaces, and design constraints are derived from the system
requirements when software is part of a larger system. Requirements, interfaces, and
design constraints are developed through interactions with customers and users for
standalone software applications.
4. Bodies of Knowledge
An underlying body of knowledge (BOK) is a foundation element of a mature
discipline. A primary purpose of a BOK is to provide the basis for curriculum
development. The Software Engineering Body of Knowledge (SWEBOK) contains 10
knowledge areas in Chapters 2 through 11 of the SWEBOK Guide [3]. Chapter 12 of the
SWEBOK Guide describes related disciplines. The SWEBOK Guide is currently under
revision (as of early 2011) but the structure of the Guide is not expected to change
significantly.
A Systems Engineering Body of Knowledge (SEBoK) is currently under development
by an international author team of approximately 40 participants; it is anticipated that
SEBoK, v0.5 will be available for public review in Summer 2011. The 14 knowledge areas
(KAs) of SEBoK are contained in Chapters 3 through 15 of the current draft of SEBoK.

221
 Table 2. Comparing SEBoK KAs and SWEBOK KAs

SEBoK KAs (v0.25) SWEBOK KAs (2004)

Systems Engineering Overview Chapter 1, SWEBOK Guide
Generic Life Cycle Stages Software Engineering Process
System Life Management
Enabling Systems Engineering in the
Organization
Service Systems Engineering
Enterprise Systems Engineering
Systems Engineering Agreement Software Engineering Management
Systems Engineering Management
System Definition Software Requirements
Software Design
System Realization Software Construction
Software Testing
System Deployment and Use Software Maintenance
Cross-Cutting Disciplines Configuration Management Software Quality
Related Disciplines
System Engineering Competency Software Engineering Tools and Methods
System Engineering
Applications/Case Studies

As is evident in Table 2, the SEBoK KAs cover a broader range of topics than covered
by the SWEBOK KAs, but the 10 KAs of SWEBOK are in reasonable agreement with the
corresponding SEBoK KAs. This provides a strong foundation for integrating systems
engineering concepts in software engineering curricula.
5. Integrating Systems Engineering Concepts into Software Engineering
Curricula based on SE2004
This section provides some thoughts on how topics in systems engineering can be
integrated into undergraduate software engineering curricula based on SE2004, which is a
framework for software engineering curricula developed by a joint committee of the ACM
and the IEEE with participation of several international computing societies [1].
The various chapters of SE2004 cover:
• 10 Software Engineering Education Knowledge Areas (SEEK Areas)
• Guidelines for SE Curriculum Design and Delivery,
• Courses and Course Sequences,
• Adaptation to Alternative Environments, and
• Program Implementation and Assessment plus
• An appendix that provides Detailed Descriptions of Proposed Courses.
The 10 SEEK areas provide the foundation for design, implementation, and delivery of
the educational units that make up a software engineering curriculum. The SE2004 Volume
provides guidance on how to use the SEEK areas to develop a curriculum and includes two
example implementations.
Table 3 indicates modifications of SEEK areas that can be made to introduce systems
engineering into a SE2004-based software engineering curriculum. The modified SEEK
areas are referred to as SEEK+SE.

222
 Table 3. SE2004 SEEK Areas and SEEK+SE Areas

SE2004 SEEK Areas SEEK+SE Areas

Computing Essentials Computing Essentials
Add Fundamentals of Systems Engineering
Mathematical & Engineering Fundamentals Add Continuous Mathematics with
Engineering Applications
Professional Practice Augmented
Software Modeling & Analysis Software & Systems Modeling & Analysis
Software Design Software & Systems Design
Software V&V Software & Systems V&V
Software Evolution Software & Systems Evolution
Software Process Software & Systems Process
Software Quality Software & Systems Quality
Software Management Software & Systems Management
System and Application Specialties Systems Engineering Specialties

As can been seen from Table 3, SEEK+SE augments the SEEK Areas and adds two
courses to SE2004-based curricula: Fundamentals of Systems Engineering and Continuous
Mathematics with Engineering Applications.
A basic tenet of SE2004 is that software engineering is based on several foundation
disciplines and, in particular, relies heavily on Computing Essentials (i.e., computer science
topics) and Mathematical & Engineering Fundamentals. Professional Practice (SEEK area
3) is equally applicable to software engineering and to systems engineering. SEEK areas 4
through 10 can be easily modified to include systems engineering topics and “Software”
can be replaced with “Software & Systems” in the title of each area. Each of the
modifications to SEEK areas indicates what is common to both systems engineering and
software engineering and what is different.
The following sections of this paper provide comments on the SEEK+SE areas.
6. Computing Essentials and Systems Engineering Essentials
This modification to SEEK involves two changes: adding Fundamentals of Systems
Engineering for software engineers and emphasizing engineering applications in the
Computing Essentials courses.
Topics to be addressed in fundamentals of systems engineering include the following.
• The nature of systems
o natural, man-made, technological
• Systems theory, systems thinking, and systems engineering
• Systems engineering and software engineering life cycle models
• Paths to systems engineering
o traditional engineering disciplines, decision science, industrial
engineering, software engineering
• Systems engineering terminology
• Structure of the systems engineering body of knowledge
• Systems engineering specialties
• Systems engineering standards and guidelines
• Case studies in systems engineering (both software-intensive and other)
• Lots of examples
• A term project

223
 The latter topics to be addressed (case studies, examples, a term project) are
particularly important because undergraduate software engineering students may not have
the work experience and professional maturity to appreciate the importance of a systems
approach to solving complex problems.
Most engineering schools require a first Introduction to Engineering course for all
engineering students. These courses could be modified to incorporate systems engineering
essentials, which would be of benefit to both traditional engineering students and software
engineering students in engineering schools. An alternative for software engineering
students would be an Introduction to Systems Engineering course if such course was
available. Software engineering students could take one of these courses, regardless of
whether the software engineering program is in a school of engineering or a different
school. A third alternative would be to integrate the systems engineering topics itemized
above into an Introduction to Software Engineering course.
With regard to Computing Essentials, Section 6.2 of the SE2004 Volume discusses
alternative approaches to introducing software engineering to students in the first year-and-
a-half of a bachelors degree program. As discussed in SE2004, one alternative is to start
with courses that immediately introduce software engineering concepts; another alternative
is to follow a traditional computer science curriculum during the first year with software
engineering being introduced in the second year.
It is recommended that the first alternative to teaching Computing Essentials (starting
immediately with software/systems engineering concepts) be pursued and that introductory
topics in software engineering and systems engineering be presented in the first year of a
software engineering program, perhaps as a single course, so that students will start to think
as engineers from the beginning and will realize that programming, although an essential
element of software engineering, is only one elements of software and systems engineering,
and, in addition, that software development is considered to be “component
implementation” by systems engineers.
7. Mathematical and Engineering Fundamentals
Most systems engineering educators are careful to point out that systems engineers are
firstly engineers and secondly systems engineers. This is taken to mean that systems
engineering students should pursue a core program of traditional engineering and
continuous mathematics during their freshman and sophomore years and to then study
systems engineering during their junior and senior years. Many systems engineers with
whom software engineering graduates will work will have been educated as traditional
engineers in a discipline such as mechanical, electrical, or aerospace engineering.
The primary issue to be resolved in the core elements of an undergraduate program in
software engineering is how to best prepare software engineering students to engage in
engineering problem solving in ways comparable to the methods learned and practiced by
systems engineers who follow a traditional core program in engineering.
Courses in mathematical and engineering fundamentals are typically offered in different
formats depending on whether a software engineering program resides in a school of
engineering, or in a computer science or software engineering program that is not in a
school of engineering. Mathematical Fundamentals required of all engineering students in
a school of engineering concentrates on continuous mathematics and typically includes a
sequence of calculus courses, differential equations, and other courses such as linear
algebra. Engineering fundamentals typically include science courses such as physics and
chemistry plus introductory courses in mechanical, civil, and electrical engineering.
Engineering students then pursue programs of study in specific engineering disciplines
during their junior and senior years.

224
 The upper division classes for students in traditional engineering disciplines largely
consist of applications of continuous mathematics presented in lectures and laboratories.
The upper division courses for software engineering students largely consist of topics based
in discrete mathematics. Thus, software engineering students are never exposed to the
various ways in which continuous mathematics is applied to real engineering problems.
The arguments for requiring calculus and other continuous mathematics courses in
software engineering programs are: 1) the study of mathematics develops students’
analytical reasoning ability and abstract thinking skills, and 2) students learn the
terminology and viewpoints of engineers who are trained in continuous mathematics.
Analytical reasoning and abstract thinking for software engineering students can be
developed (and will be more applicable) with a sequence of discrete mathematics courses
plus courses in formal methods and statistics and probability rather than by a sequence of
calculus and other continuous math courses.
Terminology and problem solving based on continuous mathematics will be better
imparted by a course in Continuous Math with Engineering Applications that specifically
focuses on the underlying concepts of continuous math. As noted above, applications of
continuous mathematics are studied in the upper division courses taken by students in
traditional engineering programs. Software engineering students who take the required
calculus sequence never have the opportunity to see or practice the applications. Hence, the
need for a course that emphasizes concepts and problem-solving applications of continuous
math as applied by traditional engineers.
Topics to be included in this course would include the following.
• Continuous and discontinuous functions
• Linear, logarithmic, polynomial, and exponential functions
• Integration as the limiting sum of rectangles
• Differentiation as rate of change
• Linear differential equations and their solutions
• Notations and terminology
• The logic of lemmas, theorems, and proof techniques
• Engineering applications of each topic
While mathematicians and traditional engineers would discount the value of this course,
it would serve the same purpose that similar courses in mathematics and physics serve for
humanities students and business majors, but with more rigor than is presented in math and
physics courses for humanities and business students.
An issue that must be addressed is lack of faculty resources and “return on investment”
to develop a course in Continuous Math with Engineering Applications for small student
populations. It is possible that funding can be found to develop this course and make the
material widely available, or perhaps an enterprising faculty member will develop this class
and make it widely available. Another issue, namely finding room in undergraduate
software engineering curricula for this course, and an Introduction to Software & Systems
Engineering course is resolved by replacing the typical Calculus 1 and 2 classes presently
found in most undergraduate software engineering curricula with these classes.
Accomplishing the proposed modifications to Mathematical and Engineering
Fundamentals in SE2004-based curricula should be somewhat easier for software
engineering programs that are not in engineering schools. Care must be taken when
developing or modifying a curriculum to satisfy the ABET requirement of one year of math
and science in a software engineering curriculum.

225
8. Summary
This paper has provided an overview of systems engineering and the relationships
between systems engineering and software engineering. Considerations for integrating
systems engineering concepts into software engineering curricula based on an enhanced
version of SEEK Areas (SEEK+SE) in the SE2004 Volume were presented and some
curriculum guidelines from SE2004 were presented.
Space limitations prevent a detailed presentation of the ways in which all ten of the
SEEK areas can be modified to include systems issues beyond the narrow confines of
software engineering. However, work to date based on Tables 1, 2, and 3, and the SE2004
Volume indicates that augmentation of the SEEK areas is straightforward.
Topics in the SE2004 Volume to be addressed in a subsequent paper include guidelines
for the SEEK+SE areas that are not addressed in this paper (software & systems modeling
and analysis, software & systems design, software & systems verification and validation,
and the other areas listed in Table 3); modification of the guidelines for curriculum design
and delivery; and the SEEK+SE capstone project.
Introducing software engineering topics into other disciplines is another topic to be
considered. In particular, systems engineering students and practitioners should be
educated and trained in the elements of software engineering and the similarities,
differences, and synergies between software engineering and systems engineering. This
topic is addressed in a companion paper.
It is also apparent that similar modifications can be made to Masters programs in
software engineering to incorporate the systems engineering topics from the SEEK+SE
curriculum model.
Finally, consideration should be given to delivery of short courses and training sessions
for practicing software engineers to enhance their skills in systems engineering.
9. Acknowledgements
The authors are grateful to Dr. Mark Ardis and Dr. Tom Hilburn for their constructive
comments on an earlier draft of this paper. Any incorrect interpretations of their comments
are the fault of the authors.
10. References
[1] http://sites.computer.org/ccse/SE2004Volume.pdf
[2] http://www.incose.org/practice/whatissystemseng.aspx
[3] http://www.computer.org/portal/web/swebok/html/contents

226