Software System Engineering: A Tutorial

Dr. Richard Hall Thayer

Software Management Training LLC

Applying system-engineering principles specifically to the development of large, complex software systems provides a pow-
erful tool for process and product management. Software engineering has its early roots in system engineering which is reflect-
ed in their many common terms. This article discusses a merger between system engineering and software engineering called
software system engineering. System engineering looks at controlling the total system development including software.
Software engineering looks at controlling just software development. (System engineers would call software engineering com-
ponent engineering.) The application of system engineering to the development of software gives a large measure of control

A
software development.
pplying system engineering principles
specifically to the development of
large, complex software systems provides a
powerful tool for process and product
management. This process is called soft-
ware engineering. Dr. Winston Royce,
father of the Waterfall chart, points out
that software engineering was developed
from system engineering, and he argued for
calling the union software system engineer-
ing. Unfortunately, this did not stick, and
software engineering and software system
engineering can be viewed as separate
processes. Software systems have become
larger and more complex than ever. We can
attribute some of this growth to advances
in hardware performance advances that
have reduced the need to limit a software
systems size and complexity as a primary
design goal. Microsoft Word is a classic
example: A product that would fit on a
360-kilobyte diskette 20 years ago now
requires a 600-megabyte compact disc.
But there are other reasons for
increased size and complexity. Specifically,
software has become the dominant tech-
nology in many if not most technical sys-
tems. It often provides the cohesiveness
and data control that enable a complex
system to solve problems.
Figure 1 is a prime example of this
common goal of safely delivering an air-
craft from takeoff to landing. Software
provides the systems major technical
complexity.
Because of this increase in size and complex-
ity, the vast majority of large software sys-
tems do not meet their projected schedule
or estimated cost, nor do they completely
fulfill the system acquirers expectations1.
This phenomenon has long been known
as the software crisis [1]. In response to
this crisis, software developers have intro-
duced different engineering practices into
product development.
As large system solutions become
increasingly dependent on software, a sys-
tem engineering approach to software
development can help avoid the problems
associated with the software crisis.
Simply tracking a development pro-
jects managerial and technical status
resources used, milestones accomplished,
requirements met, and tests completed
does not provide sufficient feedback
about the projects health. Instead, we
must manage the technical processes as well as
its products. System engineering provides
Figure 1: Software Ties the System Together
Separation Assurance
the tools the technical management task
requires.
The application of system engineering
principles to the development of a comput-
er software system produces activities, tasks,
and procedures called software system engi-
neering (SwSE). Many practitioners consid-
er SwSE to be a special case of system engi-
neering and others consider it to be part of
software engineering. However, it can be
argued that SwSE is a distinct and powerful
tool for managing the technical develop-
ment of large software projects.
This tutorial integrates the definitions
and processes from the Institute of
Electrical and Electronics Engineers
(IEEE) software engineering standards [2]
into the SwSE process.
Systems and System
Engineering
A system is a collection of elements related
in a way that allows a common objective
to be accomplished. In computer systems,
these elements include hardware, soft-
ware, people, facilities, and processes.
System engineering is the practical appli-

concept. In an air traffic control system,

Conflict alert
Minimum safe altitude X

software connects the airplanes, people,

warning
Weather Data

radar, communications, and other equip-

Central weather processor

ment that successfully guide an aircraft to

Low-level wind shear alert system

its destination. When the Federal Aviation

Administration systems were upgraded to
Air Traffic Management
Traffic management system

automation back in the 1960s, the much

En route metering

larger systems could handle many more

Terminal
(Tower/TRANCON) Surveillance

aircraft over a larger terrain. However,

En route date link
Airport surveillance

these larger systems continued to use

radar (ASR-terminal) VORTAC Navigational Aids
Microwave landing systems

much of the earlier 1950s hardware; it was

Next-generation weather
radar Very High Frequency

the software that enabled larger groups of

Radio Omni-Directional Radio Range
Transmit Tactical Air Navigation Aid

hardware to work together towards the

Receiver (VORTAC)

Flight Service Communication

Automation System National airspace data interchange network
Portions of this article appeared in Computer, Flight plan file Ground data link
Apr. 2002. 2003 IEEE. Reprinted with permis- Weather briefings Tower communication switching system
sion from Computer, Vol.35, Issue 4, pp. 68-73, Pilot reports Voice switching communication system
Credit: Logicon Inc. and Roger U. Fujii
Apr. 2002. ( 2002 IEEE)

October 2007 www.stsc.hill.af.mil 17

cation of scientific, engineering, and man- demonstration, analysis, examination, uct.
agement skills necessary to transform an and inspection. Necessary documentation to use,
operational need into a description of a System engineering provides the base- operate, and maintain it.
system configuration that best satisfies line for all project development, as well as SwSE is not a job description. It is a
that need. It is a generic problem-solving a mechanism for defining the solution space. process that many people and organiza-
process that applies to the overall technical The solution space describes the product tions perform: system engineers, managers,
management of a system development at the highest level before the system software engineers, programmers, and
project. This process provides the mecha- requirements are partitioned into the not to be ignored acquirers and users.
nism for identifying and evolving a sys- hardware and software subsystems. Software developers often overlook
tems product and process definitions. This approach is similar to the soft- system engineering and SwSE in their pro-
IEEE Std. 1220-1998 describes the ware engineering practice of specifying jects. They consider systems that are all
system engineering process and its appli- constraints as late as possible in the devel- software or that run on commercial off-
cation throughout the product life cycle opment process. The further into the the-shelf (COTS) computers to be just
[3]. System engineering produces documents, not process a project gets before defining a software projects, not system projects.
hardware. These documents are associated constraint, the more flexible the imple- Ignoring the systems aspects of software
with the developmental processes within mented solution will be. development contributes to our long-run-
the projects life-cycle model. They also ning software crisis.
define the expected process environments, What Is SwSE?
interfaces, products, and risk management The term software system engineering dates SwSE and Software
tools throughout the project. from the early 1980s and is credited to Dr. Engineering
System engineering involves five func- Winston Royce [4], an early leader in soft- Early in my software engineering career, I
tions: ware engineering. SwSE is responsible for was informed that software engineering
Problem definition determines the needs the overall technical management of the was the engineering of software copied
Assurance through analyzing the
and constraints system and the verification of the final from the hardware engineers (e.g. electri-
requirements and interfacingX with the system products. As with system engineer- cal engineers, mechanical engineers, and
Separation

acquirer. ing, SwSE produces documents, not com-

Conflict alert

so forth). I was well acquainted with the

Minimum safe altitude

Solution analysis determines the set of ponents. This differentiates Central weatherit from soft- mechanics of software engineering which
warning
Weather Data

possible ways to satisfy the require- ware engineering, Low-level whichwind produces com- made it different from computer science.
processor

ments and constraints, analyzes the puter programs and user manuals.
shear alert system

The following are examples of what

possible solutions, and selectsAir Trafficthe opti- SwSE begins after the system require- makes the mechanics of software engi-
mum one. ments have been partitioned into hard- neering different than computer science:
Management

ProcessTerminalplanning determines the tasks to ware and software subsystems. SwSE

Traffic management system

Dividing the project into phases such

En route metering

be done, the size and effort to route date link establishes the baseline for all project soft-
En develop
as life-cycle development methods.
(Tower/TRANCON) Surveillance

the product, the precedence between ware VORTAC

development. Like Aids software engi- Managing software as a separate pro-
tasks, and the potential risks to the weather neering, it is both Microwave
a technical landingand a man-
Airport surveillance

ject.
radar (ASR-terminal) Navigational

project. agement process.Omni-Directional

The SwSE Radiotechnical
systems

Using intermediate products (specifi-

Next-generation
Very High Frequency

Process control determines the methods process is the analytical effort necessary to
radar

cations), e.g., requirements specifica-

Radio Range

for controlling the project and the transform user operational needs into the
Transmit Tactical Air Navigation Aid

tions, design specifications.

Receiver (VORTAC)

process, measures progress, reviews following: Reviewing, testing, and auditing.

intermediate
Flight plan file products, and takes Ground cor- data linkA software system description.
Flight Service Communication

Using configuration management and

Automation System National airspace data interchange network

rective action when necessary. Tower Software system requirements and quality (process) assurance.
Product evaluation determines the quality design specifications.
Weather briefings communication switching system

Prototyping and the reuse of existing

Pilot reports Voice switching communication system

and quantity of the delivered product Necessary procedures to verify, test, components.
Credit: Logicon Inc. and Roger U. Fujii

and accept the finished software prod-

( 2002 IEEE)

through evaluation planning, testing, Later, I had an opportunity to mingle

Figure 2: Engineering Relationships with a number of engineers from a con-
ventional engineering discipline, and I
asked them about some of our software
engineering processes such as those listed
A T

above. Most had no idea what I was refer-

ring to.
System
Sy

Then by chance, I had an opportunity

Integrated

to work for a company that used system

Sys
Sy
ystem Engineeri
rin
ing Testing

engineering. I then realized that I had

Software (SW) SwSE
SW m

found the source of software engineering

Requirements T

processes: It was system engineering.

Analysis

Both SwSE and software engineering

SW on

are technical and management processes,

S n

but software engineering produces soft-

ware components and their supporting
SW Engineeri
rin
ing SW Engineering
Det W W tem

documentation. Specifically, software

engineering is the following:
The practical application of computer
Code
d and d

science, management, and other sci-

Unit Test
( 2002 IEEE)

18 CROSSTALK The Journal of Defense Software Engineering October 2007

 Software System Engineering: A Tutorial

ences to the analysis, design, construc-

tion, and maintenance of software and Project Management
its associated documentation.
An engineering science that applies the
Planning

concepts of analysis, design, coding,

Organizing

testing, documentation, and manage-

Staffing

ment to the successful completion of

Directing

large, custom-built computer pro-

Controlling

grams under time and budget con-

straints.
The systematic application of meth-
ods, tools, and techniques that achieve
SWSE Software Engineering

a stated requirement or objective for an Problem definition Software design

effective and efficient software system. Solution analysis Coding
Figure 2 illustrates the engineering Process planning Unit testing
relationships between system engineering,
Process control Software subsystem
SwSE, and software engineering.
Product evaluation integration
Traditional system engineering does initial
analysis and design as well as final system Figure 3: Management Relationships
( 2002, IEEE)

integration and testing. software requirements specification or ware requirements, software develop-
During the initial stage of softwareTable both. Software requirements include capa-to SwSE. ment standards, and software quality
Figure 3. Management Relationships

development, SwSE is responsible for bilities that a user needs to solve a problem assurance standards.
1. System Engineering Functions Correlated

software requirements analysis and archi-System or achieve an objective as well as capabili- Quality attributes specify the degree to
tectural design. SwSE also manages theEngineering
ties that a system or component needs to which software possesses attributes that
SwSE SwSE Function Description

final testing of the software system compo-Function

satisfy a contract, standard, or other for- affect quality, such as correctness, relia-
Function

nent engineering. mally imposed documentDetermine

[6]. bility, maintainability, and portability.
Project Management
We can categorize software require- Planning Softwaresoftware.
requirements analysis begins after
Problem Requirements needs and constraints by analyzing

SwSE and Project ments as follows [7]: system engineering has defined the acquir-
Definition Analysis system requirements allocated to
Solution Software Determine ways to satisfy requirements and

Management Functional requirements specify functions er and user system requirements. Its func-
Analysis Design
Organizing
constraints, analyze possible solutions, and select the

The project management process involvesProcess that a system or system

Determine product development tasks,identification
component tions include precedence, of all or as
optimum one. Staffing

assessing the software systems risks and must be capable of performing. many as possible software system
Process Directing

Performance
costs, establishing a schedule, integratingProcess requirementsDetermine perfor- forrequirements,
specify methods andandits conclusion marks
Planning Planning and potential risks to
the Controlling
project.

the various engineering specialties andControl mance Control characteristics process,

that a system
measureorprogress,the established requirements baseline,
Process controlling project

system component must possess such sometimes called the allocated baseline.
and take corrective
design groups, maintaining configurationProduct
as speed, accuracy, and frequency.
action where necessary.

control, and continuously auditing theEvaluation

effort to ensure that the project meets External interface requirements specify Software Design
Verification, Evaluate final product and documentation.
Validation, andSWSE Software Engineering
costs and schedules and satisfies technical hardware, software,
Problemor database ele- Software design is the process of selecting
Testing (V V&T)

requirements [5]. ments with which a system or compo- and documenting the most effective
Coding and
definition Software design

Figure 3 illustrates the managementTable 2.nent must interface,

Processor set forth con- efficient system elements that Unittogether
( 2002, IEEE)
Solution analysis

relationships between project manage- straints on formats, timing, or other will implement the software system
planning
Process Planning Versus Project Planning.
testing

ment, SwSE, and software engineering. factors caused by such an interface. requirements [8]. The design represents
integrationa
Process control Software subsystem

Project management has overall manage- SwSE Design constraints affect or constrain the Management
specific, logical approach to meet the soft-
Product evaluation

design of a software system or soft- ware requirements.

Project Planning

ment responsibility for the project and the

Planning Activities

waretasks
system
to becomponent, for example, Software design
to do is
thetraditionally parti-
Activities ( 2002, IEE

authority to commit resources. SwSEDetermines

language requirements, physical hard- tioned into two components:
done. Determines skills necessary

determines the technical approach, makesEstablishes order of precedence between Establishes schedule for completing the
Figure 3. Management Relationships tasks.

technical decisions, interfaces with thetasks. Table 1: System Engineering Functions Correlated project. to SwSE
Table 1. System Engineering Functions Correlated to SwSE.
technical acquirer, and approves the finalDetermines size of the effort.
software product. Software engineering is
Determines cost of the effort (in staff

responsible for developing the software

System SwSE SwSE time).Function Description
Determines technical approach to solving Determines managerial approach to
design, coding the design, and developingSelectsFunction
Engineering Function
the problem. monitoring the projects status.

software components.
analysis and design tools. Selects planning tools.
Problem Requirements Determine needs and constraints by analyzing

The Functions of SwSE

Determines technical risks.
Definition Analysis Determines management risks.
system requirements allocated to software.
DefinesSolution
process model.Software Defines process
Determine ways tomodel.
satisfy requirements and
Table 1 lists the five main functions ofdevelopment environment change.
UpdatesAnalysis
plans when theDesign
requirements or constraints, analyze
Updates plans whenpossible solutions, and select the
the managerial

system engineering correlated to SwSE,

optimum one.and environment change.
conditions

along with a brief general description of

Process Process Determine product development tasks, precedence,

each SwSE function.

( 2002, IEEE)
Planning Planning and potential risks to the project.
Process Process 2
Determine methods for controlling project and

Requirements Analysis
Control Control process, measure progress, and take corrective

The first step in any software development

action where necessary.

activity is to determine and document the

Product Verification, Evaluate final product and documentation.

system-level requirements in either a sys-

Evaluation Validation, and
Testing (V V&T)
tem requirements specification (SRS) or a ( 2002, IEEE)

October 2007 Table 2. Process Planning Versus Project Planning. www.stsc.hill.af.mil 19


Systems
TableEngineering
2. Process Planning Versus Project Planning.
SwSE Planning Activities
Determines tasks to be done.
Establishes order of precedence between
tasks.
Determines size of the effort.
Determines technical approach to solving
the problem.
Selects analysis and design tools.
Determines technical risks.
Defines process model.
Updates plans when the requirements or
development environment change.
Table 2: Process Planning Versus Project Planning
Architectural design is equivalent to sys-
tem design, during which the develop-
er selects the system-level structure
and allocates the software require-
ments to the structures components.
Architectural design sometimes
called top-level design or preliminary design
typically defines and structures com-
puter program components and data,
defines the interfaces, and prepares
timing and sizing estimates. It includes
information such as the overall pro-
cessing architecture, function alloca-
tions (but not detailed descriptions),
data flows, system utilities, operating
system interfaces, and storage
throughput.
Detailed design is equivalent to compo-
nent engineering. The components in
this case are independent software
modules and artifacts.
The methodology proposed here allocates
architectural design to SwSE and detailed
design to software engineering.
Process Planning
Planning specifies the project goals and
Table 3: Process Control Versus Project Control
Table 3. Process Control Versus Project Control.
SwSE Control Activities
Determines the requirements to be met.
Selects technical standards to be followed, Selects managerial standards to be
for example, IEEE Std. 830 [7].
Establishes technical metrics to control
progress, for example, requirements
growth, errors reported, or rework.
Uses peer reviews, in-process reviews,
software quality assurance, VV&T, and
audits to determine adherence to
requirements and design.
Re-engineers the software requirements
when necessary.
20 CROSSTALK The Journal of Defense Software Engineering
( 2002, IEEE)
measures performance and results against
plans, notes deviations, and takes correc-
tive actions to ensure conformance
Project Management Planning
Activities
between plans and actual results.
Process control is a feedback system
Determines skills necessary to do the
for how well the project is going. Process
tasks.
Establishes schedule for completing the
project.
control asks questions such as the follow-
Determines cost of the effort (in staff
ing: Are there any potential problems that
will cause delays in meeting a particular
time).
requirement within the budget and sched-
Determines managerial approach to
ule? Have any risks turned into problems?
monitoring the projects status.
Is the design approach still doable?
Selects planning tools.
Control must lead to corrective action
Determines management risks.
Defines process model.
either bringing the status back into con-
Updates plans when the managerial formance with the plan, changing the
conditions and environment change.
plan, or terminating the project.
Project control also has two separate
components: control that project manage-
( 2002, IEEE)
ment accomplishes and control that soft-
objectives and the strategies, policies,
2
ware systems engineering accomplishes.
plans, and procedures for achieving them.
Table 3 shows an example partitioning of
It defines in advance what to do, how to
control functions for a software system
do it, when to do it, and who will do it.
project.
Planning a software engineering pro-
ject consists of SwSE management activi-
VV&T
ties that lead to selecting a course of
The VV&T effort determines whether
action from alternative possibilities and
the engineering process is correct and the
defining a program for completing those
products are in compliance with their
actions.
requirements [9]. The following critical
There is an erroneous assumption that
definitions apply:
project management performs all project
Verification determines whether the
planning. In reality, project planning has
products of a given phase of the soft-
two components one accomplished by
ware development cycle fulfill the
project management and the other by
requirements established during the
SwSE and the bulk of project planning
previous phase. Verification answers
is an SwSE function. (This is not to say
the question, am I building the product
that project managers might not perform
right?
both functions.)
Validation determines the correctness
Table 2 shows an example partitioning
of the final program or software with
of planning functions for a software sys-
respect to the users needs and require-
tem project.
ments. Validation answers the ques-
Process Control tion, am I building the right product?
Control is the collection of management Testing is the execution of a program or
activities used to ensure that the project partial program, with known inputs
goes according to plan. Process control and outputs that are both predicted
and observed for the purpose of find-
ing errors. Testing is frequently consid-
ered part of validation.
Verification and Validation (V&V) is a
continuous process of monitoring system
Project Management Control
engineering, SwSE, software engineering,
Activites
and project management activities to deter-
Determines the project plan to be
mine that they are following the technical
followed.
and managerial plans, specifications, stan-
dards, and procedures. V&V also evaluates
followed, for example, IEEE Std. 1058 [5].
the software engineering projects interim
Establishes management metrics to
and final products. Interim products
control progress, for example, cost growth
schedule slippage, or staffing shortages.
include requirements specifications, design
descriptions, test plans, and review results.
Uses joint acquirer-developer (milestone)
Final products include software, user man-
reviews and software configuration
management to determine adherence to
uals, training manuals, and so forth.
cost, schedule, and progress.
Any individual or function within a
software development project can do V&V.
Replans the project plan when necessary.
( 2002, IEEE) SwSE uses V&V techniques and tools to
October 2007

evaluate requirements specifications, design
descriptions, and other interim products of
the SwSE process. It uses testing to deter-
mine if the final product meets the project
requirements specifications.
The last step in any software develop-
ment activity is to validate and test the final
software product against the software
requirements specification and to validate
and test the final system product against
the SRS. System engineering and SwSE are
disciplines used primarily for technical
planning in the front end of the system life
cycle and for verifying that the plans were
met at the projects end. Unfortunately, a
project often overlooks these disciplines,
especially if it consists entirely of software
or runs on COTS computers.
Summary and Conclusions
Ignoring the systems aspects of any soft-
ware project can result in software that will
not run on the hardware selected or will
not integrate with other software systems.
Conducting software engineering without
conducting SwSE puts a project in jeop-
ardy of being incomplete or having com-
ponents which do not work together,
and/or exceeding the projects scheduled
budget.
Software engineering and SwSE are
primarily disciplines used in the front end
of the system life cycle for technical plan-
ning and at the very late part of the life
cycle to verify if the plans have been met.
A review of the emphasis in this article
will show that much of the work of plan-
ning and SwSE is done during the top-
level requirements analysis and top-level
design phases. The other major activity of
SwSE is the final validation and testing of
the completed system.
Software engineering principles, activi-
ties, tasks, and procedures can be applied
to software development. This article has
summarized, in broad steps, what is nec-
essary to implement SwSE on either a
hardware-software system (that is primari-
ly software) or on an almost total software
system. SwSE is not cheap, but it is cost
effective.
References
1. Gibbs, W.W. Softwares Chronic
Crisis. Scientific American Sept. 1994:
86-95.
2. IEEE. Software Engineering Stand-
ards Collection. Vol. 1-4. Piscataway:
IEEE Press, 1999.
3. IEEE. Standard for Application and
Management of the System Engineer-
ing Process. Std. 1220-1998, Piscata-
way: IEEE Press, 1998.
4. Royce, W.W. Software Systems Engi-
October 2007
Software System Engineering: A Tutorial
neering. Management of Software
Acquisition. Fort Belvoir, VA: Defense COMING EVENTS
Systems Management College, 1981-
1988. October 2-3
5. IEEE. Standard for Software Project
Management Plans. Std. 1058-1998.
Department of Homeland Security
Piscataway: IEEE Press, 1998. Department of Defense Software
6. IEEE. Standard Glossary of Software Assurance Forum
Engineering Terminology. Std. 610.
12-1990. Piscataway: IEEE Press,
Tysons Corner, VA
1990.
https://buildsecurityin.
7. IEEE. Recommended Practice for
us-cert.gov/daisy/bsi/events.html
Software Requirements Specifica-
tions. Std. 830-1998. Piscataway: IEEE November 4-7
Press, 1998.
8. IEEE. Recommended Practice for
AYE 2007
Software Design Descriptions. Std.
Amplifying Your Effectiveness
1016-1998. Piscataway: IEEE Press, Phoenix, AZ
1998.
9. IEEE. Standard for Software Verifi-
www.ayeconference.com/
cation and Validation. Std. 1012-1998.
conference.html
Piscataway: IEEE Press, 1998.
November 8-9
Note
Static Analysis Summit II
1. This article uses the definitions from
IEEE/EIA 12207.0-1997, where
Fairfax, VA
acquirer is used for customer and sup-
https://buildsecurityin.
plier is used for developer or contrac- us-cert.gov/daisy/bsi/events.html
tor.
November 12-16
About the Author
ICSPI 2007
Richard Hall Thayer,
Orlando, FL
Ph.D., is a senior lectur-
www.icspi.com
er for Software Manage-
ment Training, LLC, and November 14-16
is a professor emeritus in The 10 IEEE High Assurance Systems
th
software engineering at
California State University, Sacramento.
Engineering Symposium
He is a retired Air Force colonel and
Dallas, TX
managed many of the Air Forces soft-
http://hase07.utdallas.edu
ware engineering projects. Thayer is also
a consultant in software engineering and November 19-21
project management and a visiting
The 11 International Conference on
th
researcher and lecturer at the University
Software Engineering and Applications
of Strathclyde, Glasgow, Scotland. He
has written more than 50 papers and
Cambridge, MA
books on software engineering, includ-
www.iasted.org/conferences/
ing two software engineering standards.
cfp-591.html.
Thayer received his doctorate in electri-
May 2008
cal engineering from the University of
California at Santa Barbara and a mas-
ters and bachelors in engineering
degrees from the University of Illinois at
Champaign/Urbana.
Systems and Software
Software Management
Technology Conference
Training, LLC
www.sstc-online.org
6540 Chiquita WY COMING EVENTS: Please submit coming events that
are of interest to our readers at least 90 days
Carmichael, CA 95608 before registration. E-mail announcements to:
E-mail: r.thayer@computer.org nicole.kentta@hill.af.mil.
www.stsc.hill.af.mil 21