Journal of Biomechatronics Engineering

Vol. 1, No. 1, (2008) 71-85

www.tibm.org.tw

A review of systems engineering standards and

processes
*
Guey-Shin Chang, Horng-Linn Perng, Jer-Nan Juang

National Applied Research Laboratories, 3F, No. 106, Ho-Ping E. Road, Sec. 2, Taipei 10622, Taiwan.

Abstract
This report provides an overview of the evolution of systems engineering standards and
guidelines, process models, and compliance assessment models from past to present. The history of
the development of systems engineering is introduced in order to show the need for its development
in that the traditional approach was deemed inadequate due to the difficulties associated with newer
larger-scale systems. Also in this report, systems engineering standards--defining the
interdisciplinary tasks that are required throughout a system’s life cycle in order to transform the
customer needs into a systems solution--are reviewed from the standpoint of their evolution. The
various commonly used system process models are addressed in order to emphasize that the
functions of the defined processes are performed in a parallel and iterative manner. The evolution
of compliance assessment models--used by organizations to investigate their compliance with all
standards, process models, evaluation, assessment, and certification criteria--are examined as well.
Finally, this report concludes that a working knowledge of systems engineering is an absolute
requirement of personnel working in modern enterprises and that the implementation of systems
engineering processes must be tailored to the scope of the job at hand.

1. Introduction

Systems engineering is a methodology developed to address the increasing

complexity that systems acquisitions have acquired over the past several decades. The
need for a systems engineering approach that is able to transfer user needs into an
operational system via an interdisciplinary process is highly sought after by both
government and industry. In the past, the fields of military defense, space exploration,
and software engineering were most interested in acquiring this type of capability.
Recently, however, many enterprises, professional societies, and other types of
organizations have recognized the importance of incorporating systems engineering
models into their own business models. To this end, a great deal of effort has been made

* Corresponding author. Tel.: +886-2-2737-8000; fax.: +886-2-2737-8044.

E-mail address: joe@narl.org.tw (J. N. Juang).
72 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

to develop a standard for systems engineering and to promote its use on the campuses of
engineering-focused universities.
As stated in ANSI/EIA 632 (1999), “Systems engineering is intended to enable an
enterprise to strengthen its competitiveness in global markets by engineering and
producing quality systems and by delivering its products on time at an affordable price or
cost. The focus, therefore, is on conceptualizing, creating, and realizing a system and the
products that make up a system.” Many global enterprises have included systems
engineering competence in their visions. Some such enterprises include:
․ Raytheon’s Vision statement: “We aspire to be one of the most admired technology
companies in the world, and a "System of Systems" integrator.” - Dan Burnham
(CEO), November 9, 2000
․ Lockheed Martin’s Vision statement: “To be recognized as the world’s premier
systems engineering and technology enterprise.” - Dan Tellep (CEO) and Norm
Augustine (President), May 5, 1995
It became evident that there was a need for the development of systems engineering
standards when the traditional approach was deemed inadequate due to the difficulties
associated with newer larger-scale systems. These difficulties include the increased
complexity of data, the expanding role of software, the lack of traceability, and cost
overruns. In order to address these issues, it was necessary that a new approach for
systems management, both from a technical and programmatic viewpoint, be established.
As a result, many different systems engineering standards and models have evolved over
the years. This proliferation of various standards serves to accommodate systems
development, compliance assessment, and certification processes and, as a consequence,
has created a set of diverse terminologies.
Systems engineering’s beginnings can be traced back to Bell Telephone Laboratories
in the 1940s. However, it was not until almost thirty years later that the first U.S. military
standard, MIL-STD-499, was published in 1969 (U.S. department of Defense, 1969).
Systems engineering standards and guidelines have evolved from a federal government
contract-centric approach to a commercial, voluntary-compliance approach. The first
professional systems engineering society, the International Council on Systems
Engineering (INCOSE), was not organized until the early 1990s and the first commercial
U.S. systems engineering standards, ANSI/EIA 632 (1999) and IEEE 1220 (1998),
followed shortly thereafter.
It should be noted that this report only addresses the evolution of systems engineering
standards and guidelines, process models, and compliance assessment models from past
to present. It is not intended to cover the most recent model developments or specific
implementations that appear within published literature.

2. Systems and systems engineering defined

For people who are interested in the field of systems engineering, the questions most
often asked are, “What is a system and what is systems engineering?” Many different
definitions can be found on websites and in systems engineering standards and guidelines
but, basically, they are all the same in terms of the subject. “Systems Engineering
 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 73

Fundamentals,” published by Defense System Management College (DSMC, 2001),

provides perhaps the most useful definition:
“Simply stated, a system is an integrated composite of people, products, and
processes that provide a capability to satisfy a stated need or objective.”
“Systems engineering consists of two significant disciplines: the technical knowledge
domain in which the systems engineer operates and systems engineering management.”
Three commonly used definitions of systems engineering are provided by the best
known technical standards that apply to the subject. They all have a common theme:
․ A logical sequence of activities and decisions that transforms an operational need into
a description of system performance parameters and a preferred system configuration.
(MIL-STD-499A, Engineering Management, 1 May 1974. Now canceled (U.S.
department of Defense, 1974).)
․ An interdisciplinary approach that encompasses the entire technical effort and evolves
into and verifies an integrated and life-cycle balanced set of system people, products,
and process solutions that satisfy customer needs. (EIA /Standard IS-632, Systems
Engineering, December 1994.)
․ An interdisciplinary, collaborative approach that derives, evolves, and verifies a life-
cycle balanced system solution which satisfies customer expectations and meets
public acceptability. (IEEE P1220, Standard for Application and Management of the
Systems Engineering Process, [Final Draft], 26 September 1994.)
In summary, systems engineering is an interdisciplinary engineering management
process that evolves and verifies an integrated, life-cycle balanced set of system solutions
that satisfy customer needs. It is interesting to note that the ANSI/EIA 632 does not
define systems engineering as such, rather, it tries to define “what to do” with respect to
the “processes for engineering a system.”

3. Evolution of standards and guidelines

Systems engineering standards define the interdisciplinary tasks that are required
throughout a system’s life cycle to transform the customer needs into a systems solution.
US Military Standard MIL-STD-499, Engineering Management, dated July 17th, 1969,
was an early standard on the subject of systems engineering. It was produced by the
United States Department of Defense (DoD) for applications within the defense industry.
MIL-STD-499 provided the first definition of the scope of engineering management and
was very influential in defining the scope of systems engineering at that time. Five years
later, the A-version, MIL-STD-499A, was released on May 1st, 1974. The MIL-STD-
499B draft, dated 1992, was an updated and significantly rewritten version of MIL-STD-
499A that was distributed for review. At the time of its review, however, the majority of
industry did not accept the most comprehensive of these standards, that being MIL-STD-
499B.
In June 1994, as part of the acquisition reform effort, DoD decreed an end to military
standards other than performance specifications. Then Secretary of Defense, Dr. William
J. Perry, approved the Process Action Team’s recommendation “to use performance and
commercial specifications, unless no practical alternative exists to meet the user’s needs.”
74 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

A memorandum titled “Specifications and Standards – A New Way of Doing Business

(1994),” by Dr. William J. Perry, cited a goal for DoD to increase its access to
commercial state-of-the-art technology and allow for dual-use processes and products
from the commercial sector in the military as a way to expand the potential industrial
base for military equipment and services. Due to this policy the revision of MIL-STD-
499A was canceled and MIL-STD-499B was not officially released. The MIL-STD-499B
standard, however, had been used extensively by the Air Force as well as by other high-
tech industries.
The Director of Systems Engineering within the Office of the Secretary of Defense
(OSD) asked that a group of organizations collaborate to develop a commercial systems-
engineering standard to replace the military one. The working group was called the
Electronic Industries Alliance (EIA) and was composed of representatives from the DoD,
the Aircraft Industry Association (AIA), the National Security Industries Association
(NDIA), the Institute of Electrical and Electronics Engineers (IEEE), and INCOSE. This
working group made minor wording changes in the MIL-STD-499B draft and released a
“commercialized” version of MIL-STD-499B in December 1994 that was known as EIA
Interim Standard 632 (EIA/IS 632), Systems Engineering. This draft was written using
considerably more industry input and then transformed into a replacement version called
ANSI/EIA 632-1998, Processes for Engineering a System. It was released in January
1999 (Electronic Industry Association, 1999; Martin, 1998; Valerdi and Wheaton, 2005).
At the same time, IEEE was also working on a commercialized systems engineering
standard. The IEEE standard also incorporated significant industry input and was based
on the MIL-STD-499B draft and an AT&T systems engineering manual. The result was a
systems engineering standard called IEEE 1220 (1998), Standard for Application and
Management of the Systems Engineering Process. A Trial-Use version of IEEE 1220 was
released in February 1995 and a Full-Use version in January 1999. The International
Organization for Standardization (ISO) along with the International Electrotechnical
Commission (IEC) jointly developed ISO/IEC 15288 (2002). ISO/IEC 15288 was an
effort to create an international system life-cycle standard that was initiated by the same
group that created the ISO software life-cycle standard, ISO/IEC 12207. ISO/IEC 15288
was augmented by people with systems engineering expertise. These three commercially-
derived standards each addressed the systems engineering processes at various levels and
all three were required to fully realize systems engineering success within the
organizations that needed them. Fig. 1 shows the evolution of systems engineering
standards.
 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 75

MIL-STD-499
July 1969 Perry Memo
Engineering Management Abolishes new military standards
June 1994
MIL-STD-499A
May 1974
MIL-STD-499B MIL-STD-499C MIL-STD-499C
June 1992 May 1994 March 2007
“Coordination Copy” Unreleased Draft Draft by TAC
IEEE 1220
1992 EIA/IS 632
Commercial SE Standard began December 1994 ISO 15288
Interim Standard 1996
After Perry Memo n
IEEE 1220 tio
dina
Trial Use X co
or ISO/IEC 15288
February 1995 ANSI/EIA 632 2002
January 1999
IEEE 1220 ISO/IEEE 15288
Full Use 2008
January 1999

Fig. 1. The evolution of systems engineering standards.

In addition to standards, many guidelines and handbooks on systems engineering

were released by organizations, especially in the space and military sectors. A handbook
with two volumes, MSFC-HDBK-1912A, Systems Engineering Handbook was released
by the National Aeronautics and Space Administration (NASA)/Marshall Space Flight
Center (MSFC) in 1991 and revised in 1994. NASA-SP-6105, NASA Systems
Engineering Handbook was published by NASA in 1992 and revised in 1995. A book
named Systems Engineering Fundamentals was published by Defense System
Management College (DSMC) in 1999 and revised in 2001. In Europe, the European
Space Agency (ESA) released a series of standards on space engineering including
ECSS-E-10 that was released in April 1996.

4. Systems engineering process models

The systems process model describes an enterprise’s activities as they relate to its
total engineering effort to achieve a given outcome (i.e., a product or service). The
systems process model illustrates the sequence and/or interaction among various project
activities from creation to disposal of the product/service. The most commonly used
process models are the Waterfall, Spiral, and Vee (Blanchard and Wolter, 2006).
The Waterfall model (Royce, 1970), introduced by Royce in 1970, initially was used
for software development. This model usually consists of five to seven series of steps or
phases for the systems engineering of software development. Boehm expanded this into
an eight-step series of activities in 1981. A similar model splits the hardware and
software into two distinct efforts. Ideally, each phase is carried out to completion in
76 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

sequence until the product is delivered. However, such is rarely the case. When
deficiencies are found, phases must be repeated until the product is corrected.
The Spiral process model of the developmental life cycle (Boehm, 1988) was
introduced as a risk-driven approach for the development of products or systems. This
model was an adaptation of the Waterfall model, which did not mandate the use of
prototypes. The Spiral model incorporates features from other models such as feedback.
The Spiral model application is iterative and proceeds through several phases each time a
different type of prototype is developed. It allows for risk evaluation before proceeding to
the subsequent phase.
The Vee process model was developed (Forsberg and Mooz, 1992, 1995) by Forberg
and Mooz and described by them as “the technical aspect of the project cycle.” This
model begins with the user’s needs on the upper left-hand side and ends with a user-
validated system on the upper right-hand side. On the left-hand side, decomposition and
definition activities resolve the system architecture, thus creating the design details.
Integration and verification flows up and to the right as successively higher levels of
subsystems are verified, thus culminating at the system level. The Vee process model
also shows the verification and validation progress from the component level to the
validation of the operational system. At each level of testing, the original specifications
and requirements are referenced to ensure that the components, subsystems, and the
system itself all meet the original specifications.
ITERATIVE TRADE-OFFS

Input Functional Evaluation Description

Requirements Analysis Synthesis OR and OR of System
Decision Elements
• WHAT • HOW
• WHY
SOLUTIONS
OR

Fig. 2. The systems engineering process.

The traditional systems engineering process for accomplishing system design tasks is
often referenced in publications (Systems Engineering Management Guide, DSMC, Jan
1990). Fig. 2 illustrates the activities of the basic systems engineering process. It consists
primarily of four activities: 1) functional analysis, 2) synthesis, 3) evaluation and decision,
and 4) a description of systems elements. The final product is production-ready
documentation of all system elements. Although this process only deals with system
design activities, it is the most traditional process used in the acquisition of defense
systems over the last several decades.
 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 77

Fig. 3. The SIMILAR process (Bahill and Gissing, 1998).

In addition to the most commonly used process models mentioned previously, Bahill
and Gissing (1998) proposed the so-called SIMILAR process. This process is usually
comprised of the following seven tasks: 1) state the problem, 2) investigate alternatives, 3)
model the system, 4) integrate, 5) launch the system, 6) assess performance, and 7) re-
evaluate. These functions are summarized using the acronym SIMILAR: State,
Investigate, Model, Integrate, Launch, Assess, and Re-evaluate. The SIMILAR systems
engineering process is illustrated in Fig. 3.

Fig. 4. The relationship between systems engineering processes.

78 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

ANSI/EIA 632 also defines 13 processes containing a total of 33 requirements that

are used in engineering a system. ANSI/EIA 632 can be applied to the developmental
process of any product. These processes can be applied to the engineering or re-
engineering of the end products that make up the system as well as to the development of
enabling products required to provide life-cycle support to system end products. Fig. 4
shows the relationships between the processes that make up this standard.
The key concepts for this standard cited from ANSI/EIA 632 are summarized as
follows:
“This Standard defines a systematic approach to engineering or reengineering a
system, incorporating best practices that have evolved during the second half of the
twentieth century. The defined approach has three premises:
a) A system is one or more end products and sets of related enabling products that allow
end products, over their life cycle of use, to meet stakeholder needs and expectations;
b) Products are an integrated composite of hierarchical elements so integrated as to meet
the defined stakeholder requirements;
c) The engineering of a system and its related products is accomplished by applying a
set of processes to each element of the system hierarchy by a multidisciplinary team
of people who have the requisite knowledge and skills.”

Fig. 5. The 33 Process Requirements Specified by ANSI/EIA 632.

 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 79

The process model is defined as an enterprise’s activities as they are related to the
total engineering effort to achieve a given outcome. Regardless of any defined processes,
it is important to note that the Systems Engineering
Process is not sequential. The functions are all performed in a parallel and iterative
manner. The previous review report can also be found in Systems Engineering Review
Report (2002) by Global Intergy Corporation.

5. Compliance assessment models

Organizations that want to remain competitive usually strive to comply with all
possible standards, process models, evaluation, assessment, and certification criteria.
Organizations use system capability and maturity models to investigate their processes as
well as the quality, cost, and effectiveness of their products. Capability models define the
characteristics of good processes but do not necessarily prescribe how the processes
should be implemented. Capability models are not actually processes. The purpose of
capability models is to establish a process improvement roadmap upon which a route can
be drawn from “where we are today” to “where we want to be.” In order to determine
“where we are today,” an organization performs an assessment, also called an appraisal,
sometimes with the aid of an outsider with specific expertise in that model. They
intentionally do not address a particular life-cycle or sequence of activities. The first
capability model, the Software-Capability Maturity Model (SW-CMM), was developed
for the field of software development, or more precisely, the management of software
development projects. Based on this, the Capability Maturity Model (CMM) models
expanded on and addressed systems engineering, integrated product development, as well
as other aspects of organizations including human resources and organizational security.
In 1992, the International Council on Systems Engineering (INCOSE) sponsored a
working group that began to address the assessment of systems engineering capability.
This group developed the Systems Engineering Capability Assessment Model (SECAM)
that was released in July 1996. Also, in December 1993, the Enterprise Process
Improvement Collaboration (EPIC) group spun off from the INCOSE SECAM working
group and developed the Systems Engineering Capability Maturity Model (SE-CMM)
that was released in December 1994. A service mark report on the SE-CMM Ver. 1.1
(1995) was released by Carnegie Mellon University’s Software Engineering Institute
(SEI) in November 1995. This standard evolved from a software legacy. The
development of these two groups meant there were now two systems engineering
capability maturity models on the market.
INCOSE and the Director for Systems Engineering in the Office of the Secretary for
Defense agreed that the two models should be combined into one single model. EPIC and
INCOSE agreed to work towards a merged model that was eventually called the Systems
Engineering Capability Model (SECM), EIA/IS 731. SECM was accepted as the standard
model within the systems and software engineering communities. It should be
emphasized that the SECM is not a process standard but actually a standard for defining
and assessing the maturity of the systems engineering discipline.
80 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

In 1997, the Software Productivity Consortium (SPC) created a website to help

organizations understand which frameworks were most important and how they related to
each other. Various combinations of international and national standards bodies,
governmental organizations, professional societies, and other quasi-legislative bodies
have promulgated a dizzying array of system process standards, recommended practices,
guidelines, and capability maturity models. The resulting quagmire has quenched the
ardor of many organizations seeking accreditation for one or more frameworks. The
Frameworks Quagmire (Sheard, 2001), proposed by SPC, as shown in Fig. 6, provides
detailed maps of the standards evolution and adds to the potential confusion over systems
engineering standards and models.
In December 2000, the Capability Maturity Model Integration (CMMI) was created
by SEI. CMMI integrated the capability models for software engineering, systems
engineering, and integrated product and process development processes. The CMMI
provided specific assessment and appraisal method for systems engineering (SE-CMM),
software engineering (SW-CMM), software acquisition (SA-CMM), integrated product
and process development (IPPD-CMM), EIA/IS 731 (Software Engineering Institute,
Carnegie Mellon University, 1995, 2001a, 2001b, 2001c, 2001d, 2002a, 2002b, 2002c,
2002d), etc. Before CMMI released their model, however, the U.S. Federal Aviation
Administration created its own integrated CMM, FAA-iCMM (1997). The FAA model
combined process areas from SW-CMM, SE-CMM, SA-CMM, ISO 9000, ISO/IEC
12207, ISO/IEC 15288, EIA 632, EIA/IS 731, ISO/IEC 15939, and the CMMI. The
current version for FAA-iCMM is Ver. DS2.0. Fig. 7 shows the modified Framework
Quagmire after CMMI published.
The new version further integrated into CMMI for Development (CMMI-SEI, 2006),
CMMI for Service (CMMI-SVC, 2006) – draft, and CMMI for Acquisition (2007). The
latest models integrate the bodies of knowledge that are essential for development and
maintenance, acquisition environment and services practices, but that have been
addressed separately in the past. The modified Framework Quagmire after three
published CMMI constellations is shown in Fig. 8.
 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 81

SDCE SCE People CMM PSP DOD- DOD-

DOD- STD- STD- Process Stds
CBA IPI SW-CMM TSP STD- 2167A 2168 Quality Stds
7935A Maturity or
SCAMPI ISO/IEC Capability
CMMI 15504 J-STD MIL-STD- Models
ISO FAA- 016 498 Appraisal
15939 SA- iCMM methods
Guidelines
#

CMM SSE- RTCA

PSM CMM DO-178B
FAM** IEEE/EIA
Six IPD- 12207
Sigma CMM* SE-CMM
Baldrige
EIA SECAM SAM ISO 9000 ISO/IEC
731 IEEE series 12207
Q9000
EIA/IS 1220 MIL-STD
632 499B* TL9000
ISO/IEC 15288
ANSI/EIA 632 Italic = obsolete

*not released **based on CBA IPI, SAM, and others Boxed = integrating

#
V2 also based on many others supersedes
See www.software.org/quagmire based on
uses/references

Fig. 6. The Frameworks Quagmire in 2001 (Source: Sheard 2001).

PSP MIL-STD-1803
TSP (1988) SDCCR MIL-STD-1679
MIL-Q-9858A (1983)
SW-CMM SDCE (1963) DOD-STD-2168
People SCE (1988)
CMM IEEE Stds -730, -828, -829, DOD-STD-2167A
SA-CMM -830, -1012, -1016, -1028, NATO (1988)
ISO 15504 -1058, -1063 AQAP 1, 4, 9 DOD-STD-7935A
(SPICE) EQA (1988)
2003 MIL-STD-498 DOD-STD-1703
FAA-iCMM CMMI Baldrige (1994)
Trillium BS 5750 (1987)
IPD-CMM* EIA/IEEE
SECM DO-178B ISO/IEC 12207 J-STD-016
SE-CMM EIA/IS 731 DoD IPPD (1995)

SECAM ISO 9000 IEEE 1074

SSE-CMM AF IPD Guide TickIT Series (1997)
IEEE 1220 (1993) Q9000
MIL-STD-499 (1998) EIA/IS 632 ISO 10011
(1967) ISO 15288* IEEE/EIA 12207*
MIL-STD-499B*
(1994) EIA 632*
MIL-STD-499A Green - US DoD: MIL, DOD, AF
(1974) Red - CMU-SEI: CMM, CMMI
Purple - International: ISO, IEC, EC, UK
Blue - US Industry: IEEE After: Sarah Sheard, SPC, 1997, www.software.com/quagmire
* Not yet released Quagmire is copyright Software Productivity Consortium (SPC)

Fig. 7. The Frameworks Quagmire after CMMI (Source: modified after SPC 1997).
82 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

CMMI-DEV
PSP
TSP CMMI-ACQ MIL-Q-9858A MIL-STD-1679
CMMI CMMI-SVC (1963) DOD-STD-2168 (1983)
People (1988)
CMM IEEE Stds -730, -828, -829,
-830, -1012, -1016, -1028, NATO DOD-STD-2167A
SA-CMM (1988)
ISO 15504 -1058, -1063 AQAP 1, 4, 9
EQA DOD-STD-7935A
(SPICE) (1988)
FAA-iCMM 2003 MIL-STD-498 DOD-STD-1703
Trillium Baldrige BS 5750 (1984) (1987)
(CAN) (US)
SSE-CMM DO-178B ISO/IEC 12207 EIA/IEEE
J-STD-016
(1995)
TickIT ISO 9000 IEEE 1074
IEEE 1220 Series (1994)
(1998) Q9000
MIL-STD-499 EIA/IS 632 ISO 10011 IEEE/EIA 12207
(1967) ISO 15288 (1998)
MIL-STD-499B* EIA 632 (2002)
(1994) (1999)
ISO/IEEE 12207
MIL-STD-499A MIL-STD-499C* ISO/IEEE 15288 (2008)
(1974) (Draft 2005)
Green - US DoD: MIL, DOD, AF
Red - CMU-SEI: CMM, CMMI (2008)
Purple - International: ISO, IEC
Blue - US Industry: IEEE After: Sarah Sheard, SPC, www.software.com/quagmire
* Not yet released Quagmire is copyright Software Productivity Consortium (SPC)

Fig. 8. The Frameworks Quagmire Now (Source: modified after SPC 1997).

6. Conclusions

This paper provides an overview of the evolution of systems engineering standards

and guidelines, process models, and compliance assessment models from past to present.
The evolution of systems engineering required tremendous efforts on the part of many
professional societies, enterprises, and academia. The impact that systems engineering
has had on academia, government, and industry is immeasurable. It is important to note
that:
․ Systems engineering is a methodology that, by definition, assists enterprise personnel
to produce an end product that meets customer needs. Systems engineering does this
by helping the producer organize related processes, methods, and tools. Indeed, a
methodology is primarily created by accumulating the experience of failures or
overruns encountered in previous projects. Implementation of systems engineering
process defined in standards does not necessarily ensure a successful project;
however, it can help mitigate the risks associated with the project.
․ Systems engineering was developed to manage the acquisition of highly complex
high-end systems such as those utilized in the military, space, and software
development fields, of which the government was the primary customer during early
development. Various standards such as ANSI/EIA 632 and ISO/IEC 15288 have
been extended to enable enterprise to strengthen its competitiveness in global markets
by engineering and producing quality systems and by delivering products on time and
 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 83

at an affordable cost. Systems engineering has become a discipline required for every
enterprise’s personnel working in technical or programmatic fields.
․ Systems engineering has value and application well beyond the bounds of traditional
engineering. Due to the different implications and objectives for each project, no
single systems engineering approach or capability assessment model can be applied to
all cases. It is extremely important to remember that, when implementing the systems
engineering processes, it must be properly tailored to the scope and level of the job at
hand.

References

ANSI/EIA-632, 1999, Process for Engineering a System. Electronic Industry Association.

Bahill, A. T., Gissing, B., 1998. Re-evaluating systems engineering concepts using systems thinking. IEEE
Transaction on Systems, Man and Cybernetics, Part C: Applications and Reviews 28 516-527.
,

Blanchard, B. S., Fabrycky, W. J., 2006. Systems Engineering and Analysis, 4 ed. Prentice-Hall International,
London.
Boehm, B. W., 1988. A spiral model of software development and enhancement. Computer and Electronics in
Agriculture 21, 61-72.
CMMI for Services, 2006. Initial Draft. Software Engineering Institute (SEI). Carnegie Mellon University, USA.
CMU/SEI-95-MM-003, 1995a. A Systems Engineering Capability Maturity Model. (SE-CMM Ver. 1.1).
Software Engineering Institute (SEI). Carnegie Mellon University, USA.
CMU/SEI-95-MM-003, 1995b. A Systems Engineering Capability Maturity Model. (SE-CMM Ver. 1.1).
Software Engineering Institute, Carnegie Mellon University, USA.
CMU/SEI-2002-TR-001, 2001a. Capability Maturity Model Integration for Systems Engineering and Software
Engineering. (CMMI-SE/SW Ver. 1.1), Continuous Representation. Software Engineering Institute,
Carnegie Mellon University, USA.
CMU/SEI-2002-TR-002, 2001b. Capability Maturity Model Integration for Systems Engineering and Software
Engineering (CMMI-SE/SW Ver. 1.1), Staged Representation. Software Engineering Institute, Carnegie
Mellon University, USA.
CMU/SEI-2002-TR-003, 2001c. Capability Maturity Model Integration for Systems Engineering, Software
Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD Ver. 1.1),
Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA.
CMU/SEI-2002-TR-004, 2001d. Capability Maturity Model Integration for Systems Engineering, Software
Engineering, and Integrated Product and Process Development (CMMI-SE/SW/IPPD Ver. 1.1). Staged
Representation. Software Engineering Institute, Carnegie Mellon University, USA.
CMU/SEI-2002-TR-011, 2002a. Capability Maturity Model Integration for Systems Engineering, Software
Engineering, Integrated Product and Process Development and Supplier Sourcing (CMMI-
SE/SW/IPPD/SS Ver. 1.1), Continuous Representation. Software Engineering Institute. Carnegie Mellon
University, U.S.A.
CMU/SEI-2002-TR-012, 2002b. Capability Maturity Model Integration for Systems Engineering, Software
Engineering, Integrated Product and Process Development and Supplier Sourcing (CMMI-
SE/SW/IPPD/SS Ver. 1.1), Staged Representation. Software Engineering Institute, Carnegie Mellon
University, USA.
84 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85

CMU/SEI-2002-TR-028, 2002c. Capability Maturity Model Integration for Software (CMMI-SW Ver. 1.1),
Continuous Representation. Software Engineering Institute, Carnegie Mellon University, USA.
CMU/SEI-2002-TR-029, 2002d. Capability Maturity Model Integration for Software (CMMI-SW Ver. 1.1),
Staged Representation. Software Engineering Institute. Carnegie Mellon University, USA.
CMU/SEI-2006-TR-008, 2006. Capability Maturity Model Integration for Development (CMMI-Dev Ver. 1.2),
Software Engineering Institute. Carnegie Mellon University, USA.
CMU/SEI-2007-TR-017, 2007. CMMI for Acquisition Ver. 1.2. Software Engineering Institute, Carnegie
Mellon University, USA.
DSMC, 1990. Systems Engineering Management Guide. Defense Systems Management College, Department of
Defence.
DSMC, 2001. Systems Engineering Fundamentals. Defense System Management College, Department of
Defence.
ECSS-E-10A, 1996. Space Engineering- Systems Engineering. European Space Agency.
EIA/IS 632, 1994. Systems Engineering, Interim Standard. Electronics Industry Association.
EIA/IS 731.1, Systems Engineering Capability Model, Electronic Industry Association (EIA).
EIA/IS 731.2, Systems Engineering Capability Model Appraisal Method, Electronic Industry Association (EIA).
FAA-iCMM, 1997. The Federal Aviation Administration Integrated Capability Maturity Model, Ver. 1.0: An
Integrated Capability Maturity Model for the Acquisition of Software Intensive Systems. Federal Aviation
Administration.
Forsberg, K., Mooz, H., 1992. The relationship of systems engineering to the project cycle. Engineering
Management Journal 4 36-43.
,

Forsberg, K., Mooz, H., 1995. Application of the “Vee” to incremental and evolutionary development. In:
Proceedings of the Fifth Annual International Symposium of the National Council on Systems Engineering,
St. Louis, MO., USA.
Global Intergy Corporation, 2002e. Systems Engineering Process Review Report, Ver. 2.
IEEE 1220, 1998. IEEE Standard for Application and Management of the Systems Engineering Process. IEEE
Computer Society.
INCOSE Website, 2006. A consensus of the INCOSE fellows. On-line available at
http://www.incose.org/practice/fellowsconsensus.aspx.
ISO/IEC 12207, Systems and Software Engineering - Software Life Cycle Processes. International Organization
for Standardization.
ISO/IEC 15288, Systems and Software Engineering - System Life Cycle Processes. International Organization
for Standardization.
Martin, J. N., 1998. Overview of the EIA 632 standard: processes for engineering a system. In: Digital Avionics
System Conference, Seattle, Washington, USA, October 31- November 6, 1998, B32-1-9.
MIL-STD-499, 1969. Engineering Management. U.S. Department of Defense.
MIL-STD-499A, 1974. Engineering Management. U.S. Department of Defense.
MSFC-HDBK-1912A, 1994. Systems Engineering Handbook. NASA/Marshall Space Flight Center.
NASA-SP-6105, 1995c. Systems Engineering Handbook. NASA.
Perry, W. J., 1994. Specification and Standards – a New Way of Doing Business. Memorandum from the
Secretary of Defense to various military departments. Washington DC.
Royce, W. W., 1970. Managing the development of large software systems. Proceedings of IEEE WESCON 26 ,

1-9.
Sheard, S. A., 1997. The Frameworks Quagmire, A Brief Look. In: Proceedings of INCOSE.
 G. S. Chang et al. / Journal of Biomechatronics Engineering Vol. 1, No. 1, (2008) 71-85 85

Sheard, S. A., 2001. Evolution of the Frameworks Quagmire. Computer and Electronics in Agriculture 34, 96-
98.
Valerdi, R., Marilee, W., 2005. ANSI/EIA 632 as a standardized WBS for COSYSMO. In: AIAA 5th Aviation
Technology, Integration, and Operations Conference (ATIO), Hyatt Regency Crystal City, Arlington,
Virginia, USA, September 26-28, 2005, Paper No. AIAA 2005-7373.