Jeremy Bambace - Systems Engineering Frameworks

NSYS-6120: RESEARCH PAPER
JEREMY BAMBACE
Page 1 of 20
Systems Engineering Frameworks
Creating Added Value in Complex System Implementations
‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗
‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗
NSYS-6120
RESEARCH PAPER
April 10, 2009
Jeremy Bambace
‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗
‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗‗

JEREMY BAMBACE
Page 2 of 20
TABLE OF CONTENTS
INTRODUCTION ………………………………………………………………………………………………………………… 3
REQUIREMENTS DEFINITION AND ANALYSIS ……………………………………………………………………… 4
SYSTEMS ARCHITECTING …………………………………………………………………………………………………… 10
CONCURRENT ENGINEERING …………………………………………………………………………………………….. 14
CONCLUSION …….……………………………………………………………………………………………………………… 17
REFERENCES …………………………………………………………………………………………………………………..… 20

JEREMY BAMBACE
Page 3 of 20
INTRODUCTION
For my research paper initiative, I plan to explore the ways in which the application of a
systems engineering framework and methodology can create added value within the context of
large and complex system implementations. Specifically, I would like to identify some of the
value-added processes and results attributable to systems engineering on projects that
incorporate a formal systems engineer role; and then compare and contrast against system
implementations which lack a designated systems engineer. My intent is to draw on research
resources to expound upon concepts and methodologies presented throughout the NSYS-6120
course, identify and elaborate on benefits and value-add aspects associated with these
concepts, and then compare and contrast against my own experiences of involvement in
system implementations which have lacked a formal systems engineer role. It is obvious that
the added value of implementing and utilizing a systems engineering approach within the
context of large and complex system installations can be substantiated in many ways; such as
shortening the duration of the implementation phase of the project, reducing costs, and
designing systems that are of higher quality, dependability, maintainability, and overall do a
better job in fulfilling the intended purpose of the system. These added value manifestations of
implementing a systems engineering methodology are realized due to a myriad of reasons from
which large volumes of research and literature have been produced. Consequently, the scope
of this paper will focus on several specific value-add attributes of the systems engineering
process, thereby accommodating the overall page count restriction of this research paper. The
intent is not to cover an exhaustive list of all applicable value-add aspects of applying a systems

JEREMY BAMBACE
Page 4 of 20
engineering methodology; rather the purpose is to merely touch upon several of the many
systems engineering concepts which deliver added value to large and complex system
implementations. Specifically, I will focus on the systems engineering concepts of requirements
definition and analysis, systems architecting, and concurrent engineering, within the scope of
this paper.
REQUIREMENTS DEFINITION AND ANALYSIS
Requirements definition and analysis is a critical component of defining what the objective
of the system is. Requirements definition and analysis as specified within the systems
engineering framework serves as a value-add attribute by reducing cost and schedule overruns,
providing the foundation to establish quantitative design-to objectives, and ultimately ensuring
the system does what it is supposed to [1]. At a more granular level, there are several aspects
of the requirements definition process which are important to point out. For instance, when
applied within the context of a systems engineering framework, the requirements definition
process will produce requirements that are both verifiable and measurable [2]. This property of
a properly implemented requirements definition process is important to ensure the system is
designed to fulfill its purpose as determined based on the specified requirements [1]. If a formal
and thorough requirements definition and analysis process has not occurred, it is probable that
the system could be under (or over) designed; essentially providing too little (or even too much)
functionality/capability as compared to what the stakeholders desired [1]. These scenarios
would likely result in a dissatisfied customer and/or an unnecessary increase in cost of
implementing the system [1]. To avoid such issues, the systems engineering process “places an

JEREMY BAMBACE
Page 5 of 20
emphasis on traceability, linking features of the system directly to requirements” [2]. This
traceability aspect, when properly enforced, prevents under- or over-design of sub-elements of
the system and indeed the system as a whole; assuring that what is delivered satisfies the
customer’s requirements, nothing more and nothing less.
From my experience, lack of a formal requirements definition process (and the associated
traceability aspect) has the potential to lead to extreme scope creep on a project. Although I
have seen varying outcomes, I believe the exposure to risk increases significantly when the
customization involved on the project increases. In other words, the greater the customization
required for the project, the greater the need for a formal, structured requirements definition
process to be utilized. I have observed delivery of customized product to the client and
subsequent rejection of acceptance due to a “missing function” which was not developed, or
did not perform all “expected” processes. In these scenarios, review of the specifications have
often revealed that the “omitted” function could potentially be legitimate within the context of
the existing documentation, due to generalized statements and failure to nail down verifiable
and measurable acceptance criteria. As a result, there is a definite potential to add value to
these system implementation projects by applying a structured and systematic methodology
based on fundamentals of systems engineering. Enforcing a systematic requirements definition
process that yields a clear definition of the scope of the system; provides unambiguous design-
to requirements that are verifiable and measurable; and ultimately ensures traceability of
lower-level functions back to originally stated system-level requirements; all create added value
by reducing reworks by development at late stages in the project, avoiding project delays, and
ensuring system acceptance by the customer upon delivery.

JEREMY BAMBACE
Page 6 of 20
Moving beyond the obvious benefits of employing a systematic and formal requirements
definition process, there is also evidence that even the “metadata” byproduct of conducting a
thorough requirements definition and analysis process can be useful. According to Valerdi and
Eiche [3], “System requirements are the foundation upon which an entire system is built.
Therefore, they serve as useful measures of system size.” Consequently, it can be useful to
actually draw inferences based simply on the number, or count, of requirements which have
been identified at the close of the requirements definition and analysis process. Two
methodologies, COSYSMO (Constructive Systems Engineering Cost Model) and SPUR (System
Parametric Utilizing Requirements), can essentially be utilized for the “purposes of estimating
the functional size of a system and to estimate effort associated with the implementation of
that system” based on the number of requirements identified during the requirements process
[3]. In this sense, there is additional added value to be attained from employing the
requirements definition process, beyond the justifications typically referenced. In other words,
the direct added value of utilizing a systematic requirements definition methodology are
realizable and justifiable, as outlined in the preceding paragraph; but the results of this
requirements definition process also presents an opportunity for further analysis to aide in
subsequent estimation of effort, time, and costs associated with a project. Relative to projects I
have worked, I can see an obvious value-add opportunity to use these estimation models for
the purpose of formulating a more accurate breakdown of the work, schedule, and costs.
Ultimately, applying the systems engineering framework to the requirements definition and
analysis process should result in many benefits, and serve to crystallize the scope and objective
of the system implementation. According to a joint paper by INCOSE and AIAA entitled ‘Systems

JEREMY BAMBACE
Page 7 of 20
Engineering - A Way of Thinking, A Way of Doing Business, Enabling Organized Transition from
Need to Product’ [4], the systems engineering discipline when properly implemented will:
Provide a structured process for integrating and linking requirements, schedule, decision
milestones, and verification
Enable the project team to work to a single, integrated set of requirements and processes
Enable integration of the system at the requirements and design stages (before sunk costs)
rather than waiting until hardware and software is available
Reduce unplanned and costly reengineering necessary to resolve omissions and integration
difficulties
Thus, all of these examples serve to illustrate the benefits of incorporating a formal
requirements definition process into the timeline of a project. Indeed, there are also arguments
rebutting criticisms of the necessary increase in up-front efforts, which are required to conduct
such a process. “The time required at the beginning of any project to establish these tools will
be well spent because systems engineering-style requirements definition provides an
integrated, verified product that meets the customer’s needs while minimizing changes that
cause schedule delays and cost overruns” [2]. Correspondingly, INCOSE notes that “a product’s
life cycle costs are determined early in requirements development. Timely analysis and
integration of requirements at this point can achieve substantial long term savings” [4]. So
there is a notable tradeoff, to some degree, requiring additional upfront investments which in
turn yield significant savings over the entire lifecycle of the system.
From my experience, bypassing these upfront investments to cut costs has resulted in
substantial issues later in project timelines. Realization of discrepancies between expectations
of the client and the implementation team can be traced back to lack of a thorough

JEREMY BAMBACE
Page 8 of 20
requirements definition process, which indeed saved time and resources in the short-run at the
outset of the project. However, I have observed this short-term tradeoff manifest into
significant cost increases due to high volumes of development re-work to further enhance the
product in order to satisfy customer requirements which were never properly documented to
begin with. Obviously, this high volume of development re-work could have been avoided if a
more thorough and disciplined requirements definition process had been initiated.
Overall, the benefits of utilizing a formal requirements definition process are evident as
described in the preceding paragraphs. The importance of such a practice is also obviously well
known and agreed upon throughout the systems engineering professional community. Indeed,
in exploring future directions and applications of the requirements-driven process, INCOSE has
noted expanded uses and ways to improve existing and traditional methodologies. For instance,
Model-based Systems Engineering (MBSE) is another SE methodology that can be useful for
purposes of improving the requirements definition process. “For example, in lieu of a textual
statement of requirements, some acquirers develop models defining the performance,
environment, constraints, measures of effectiveness, quality, stakeholders and their roles, and
specific scenarios, in which their envisioned system will operate–all defined around a “black
box” system. Suppliers respond with their own model that replaces the black box with a
detailed white box representation of their system concept, including design and operational
concepts and risk mitigation approaches. Acquirers are then able to select the bidder whose
model (and proposal) best satisfies their requirements” [5]. This evolving structure and
application of the requirements definition process provides insight into the potential for
improvement and growth in this area, and illustrates how a modeling approach can enhance

JEREMY BAMBACE
Page 9 of 20
the ‘traditional’ requirements statements that are most prevalently used today. Within the
scope of system implementations I have worked in the past, I believe requirements definition
built upon MBSE framework could potentially alleviate issues of interdependent variables that
often cause development reworks and delays. Especially on projects which have required high
levels of customization, I have observed delivery of multiple enhancements designed to the
stated specifications of the customer, and the team has discovered during unit testing and
integrated testing phases that the inter-related behaviors of the enhancements on one another
result in issues that require additional development work. Using an MBSE approach could
potentially mitigate these scenarios.
For all of these aforementioned reasons, it is abundantly apparent that adequate efforts
should be made to employ a formal, structured, and thorough requirements definition process.
Failure to do so can be extremely costly and timely, and result in a dissatisfied customer base.
In reviewing the abundance of supporting documentation and research which has been done
on this subject, it has become increasingly clear to me how much potential for improvement
exists within the context of system implementations which I have been involved in. The
potential level of quality which could feasibly be attained through the use of a structured
requirements analysis and definition process is something that should be explored in closer
detail. Although any level of customization calls for requirements and functional specs to be
produced, I feel that the lack of a designated and formal systems engineer on these projects
has been costly. Future refinements may be possible despite the lack of a systems engineer
present in the project implementation, through the application and shared acceptance of the
requirements definition process by all stakeholders of the project.

JEREMY BAMBACE
Page 10 of 20
SYSTEMS ARCHITECTING
The second systems engineering concept I will review as part of this research paper is
that of systems architecting. Architecting systems to ensure compliance with requirements is a
responsibility that is closely managed and monitored by the systems engineer. Output from the
requirements analysis and definition process serves as input for defining functions and
subsequently establishing an allocated architecture of the system [1]. “The form of a system is
strongly driven by the functions it is called upon to perform. Architecting defines that form by
matching, fitting, balancing, and compromising proposed functions and forms until a practical
result can be achieved” [6]. However, the importance of the systems engineering methodology
and influence on the architecting process is critical to ensuring a quality system that satisfies
designated requirements. “Systems architects who work with systems must be specialists in
relationships – not generalists who know a little bit about all the parts. Their specialty is a
concentration on the system as a whole: that is, on those elements, interfaces, and factors that
have the most effect on overall system performance, cost, and schedule. Systems architects
must necessarily know, or learn, a great deal about some details – those that impinge on the
overall system – but need not, and probably should not, pay much attention to the rest, which
are best handled by the subsystem experts with whom the systems specialists work” [6].
Consequently, it is critical that a systems engineering methodology be utilized to ensure that
requirements defined in prior processes are correctly flowed down to subsystem levels, and
that effective integration amongst these lower levels be realized. Without a systems engineer
to oversee this process, it is possible that subsystems may be designed to perfectly acceptable

JEREMY BAMBACE
Page 11 of 20
or even exceptional standards within a subsystem context, but that their integration with other
components of the overall system may be deficient.
I have personally been involved on software system implementation projects with no
formal systems engineer and have observed proliferation of these types of deficiencies.
Essentially, some interface or process that one specialist is working on is not compatible (for
some reason or another) with other key components of the system. Knowledge transfer and
transparency across sub-units would have made this realization occur at a much earlier
juncture; and yet I have observed these types of issues creep into the project at points in the
timeline as late as just prior to a scheduled go-live. Obviously, the presence of a systems
engineer, who is appropriately intimate with the allocation of lower-level functional details (yet
also knowledgeable of higher-level requirements), would mitigate the probability of such issues
occurring at so late a juncture. Project managers have typically not possessed the requisite
functional knowledge to tie the incompatibilities together, and thus issues ensue at late
junctures in the project timeline.
Also notable from a systems engineering and architectural standpoint is the distinction
of software-intensive projects, such as the type I have been involved with in the past. As the
role of software continues to grow within the context of the overall system, so must the
architectural considerations and integration of software and non-software components.
“Software development is still considered simply a part of systems development, where defined
development processes of general systems engineering typically handle software sub-systems
via strict requirements flowdown from system to software development. However, software is

JEREMY BAMBACE
Page 12 of 20
different from electronics or mechanics. So, this can be problematic like the waterfall model,
especially since more and more systems are becoming software-intensive” [7]. These changes
have the potential to create additional layers of complexity as the interaction between
software and other components of the system increase. Software issues identified must be
tightly controlled in tandem with changes that may impact other aspects of the system. “After
engineering the changed system requirements, possible changes in the system architecture
may be needed as well, depending also on the design rationale for its current version. This will
probably lead to changes in the flowdown of derived requirements for several subsystems, not
only the one that had triggered the upflow” [7]. So essentially, it is critical that overall
architecture of the system be considered, not just silos applicable to software and other non-
software elements of the subsystem. And the criticality of designing effective architecture with
these integrated components in mind becomes even more significant as the size and
complexity of the system increases. “Even when a large-scale system software is partitioned
across subsystems and farmed out to subcontractors specializing in, for example, ‘fire control’
or ‘flight control,’ these systems eventually need to be made interoperable. Clearly, discovering
interoperability issues during development inevitably leads to schedule and cost over-runs” [8].
Again, working on projects that have not had a formal systems engineer role assigned, I
have observed similar issues due to failure to consider all components of the system, primarily
those outside the boundaries of the software. By neglecting to consider the human process
mechanisms vital to the success of the system, “gaps” in functionality have surfaced much later
in the project and have been traceable back to dysfunctional architecting of the many various
components of the system (beyond the software components). Considerations for manual and

JEREMY BAMBACE
Page 13 of 20
automated processes, timing, and the related interdependent requirements of the software
and user aspects of the system have been neglected, resulting dysfunctional architectures that
require increased manual efforts and/or increased re-works of software by development. The
added value that can be created by employing a methodical systems engineering approach to
systems architecting is obvious and is another example of up-front costs that can pay
substantial dividends later in the project.
As systems continue to evolve in terms of functional capabilities as well as complexity,
the importance of effectively architecting system designs will continue to grow in importance.
According to INCOSE, “by 2020, systems will exhibit extensive interconnectedness. In
geographical terms, local systems are giving way to regional systems. Systems engineers will
continue to be challenged by the ability of new and legacy systems to join the encompassing
system of systems. Issues surrounding legacy systems will increasingly influence system
acquisition, design and upgrades. Systems will be designed for continuous adaptation, which
will stimulate greater use of off-the-shelf components. The term ‘system architecture’ will
connote more than the technical architecture of the system. Architecture will envelope
markets, customers, technology insertion, product development and deployment, and the
needs of the enterprise into an integrated framework” [5]. This vision of systems architecture
reveals the broad range of considerations which comprises this process; and illuminates the
expansive breadth of discipline which will be vital to performing effective systems architecting
in the future.

JEREMY BAMBACE
Page 14 of 20
CONCURRENT ENGINEERING
The final systems engineering concept I will review in this paper is that of concurrent
engineering. Concurrent engineering pertains to a greater integration of engineering
considerations that span all lifecycles of the system. “System life-cycle engineering goes beyond
the product life cycle. It must simultaneously embrace the lifecycle of the manufacturing
process, the life cycle of the maintenance and support capability, and the life cycle of the
phase-out and disposal process” [1]. In other words, a tight integration and coordination of
engineering must exist across all of these various phases of the system’s life. This is necessary
because requirements or considerations from one aspect of the system’s lifecycle could be
significantly influenced by requirements or considerations of a different lifecycle. For instance,
aspects of retirement or disposal could potentially influence design considerations, or
maintenance requirements could impact functional analysis and allocation considerations, etc.
“To the extent possible, life-cycle thinking should invoke end-of-life considerations for
recyclability, reusability, and disposability” [1]. This concurrent engineering framework has
steadily evolved to its current state. According to INCOSE, “the current state of systems
engineering practice is the product of changes that have taken place over the past 25 years,
beginning with concurrent engineering practices introduced in the early 1980s. The tendency
towards sequential and separate discipline practices of the past have been replaced by
integrated product and process development where developers consider all life-cycle elements
at the earliest stages. As indicated by Figure 2 below, a significant motivation for this trend is

JEREMY BAMBACE
Page 15 of 20
the potential to reduce risks and control costs beginning in the earliest stages of product
development” [5].
Figure 2 – Costs committed during preliminary conception of product development [5]
As a result of applying these concurrent engineering perspectives and methodologies,
involving forward thinking and coordination and collaboration across functional boundaries, the
system tends to evolve into a more mature existence at an earlier point in the project. For
example, this earlier maturity is also evident within the context of a specific value-add model
that is representative of a concurrent engineering approach, namely Capability Maturity Model
Integration, or CMMI. “Capability Maturity Model Integration provides an opportunity to avoid
or eliminate (organizational) barriers through integrated models that transcend disciplines.
CMMI consists of best practices that address product development and maintenance. It
addresses practices that cover the product's life cycle from conception through delivery and
maintenance” [9]. I believe that applying CMMI on large-scale projects can create added value

JEREMY BAMBACE
Page 16 of 20
by ensuring integrated coordination across the various disciplines and phases of the project.
Indeed, “organizations that base their process improvement activities on CMMI models can and
have achieved marked performance improvements” [10]. For example, the table pictured
below shows the results of a study conducted to determine improvements made along various
performance measures attributable to the implementation of CMMI [10].
As the above table illustrates, the potential to add value through the application of a
concurrent engineering approach is both quantifiable and realizable, and will continue to be a
long-term focus of systems engineering in the future. Indeed, a sustained emphasis on the
importance of concurrent engineering within the professional systems engineering community
is prevalent, as evident by the following excerpt from INCOSE’s paper envisioning the state of
system’s engineering in the year 2020: “Engineering and acquisition processes will evolve to
fully support concurrently engineered systems. The success criteria will likely include the ability
of a system to interoperate with other evolving systems, or its resilience in accommodating
new technology or interfaces” [5].

JEREMY BAMBACE
Page 17 of 20
I believe the lack of incorporating a formal systems engineer role into project
implementations does result in deficiencies within the context of concurrent engineering
considerations. For instance, I have observed issues resulting from the specific configuration of
systems which manifest into significant increases in manual effort when annual maintenance is
required. Analyzing the configurations at a later point in time has revealed opportunities to
greatly reduce human effort by making changes in the existing system configurations. Had a
greater emphasis on concurrent engineering methodologies been incorporated into the earlier
phases of the system implementation, then significant increases in efficiencies and automation
could have been realized at an earlier juncture and with far less corrective maintenance efforts
than after the system go-live. The key point is the facilitation of integrated collaboration across
the various stakeholder silos, combined with an increase in analysis of total lifecycle
considerations which are often traditionally overlooked.
CONCLUSION
Three distinct systems engineering concepts which have potential to add value to large
and complex system implementations have been reviewed in this paper. The abundance of
research material which is available on these subjects builds a strong supporting argument in
favor of utilizing these methodologies to achieve better results within the context of system
implementations. Additionally, by aggregating various materials available on these topics and
combining with content absorbed throughout the NSYS-6120 course, I have been able to view
my own personal experiences with system implementations through a lens that both
illuminates deficiencies and highlights opportunities to create significant value. The fact that a

JEREMY BAMBACE
Page 18 of 20
formal systems engineer role has not been established at any point prior is problematic in that
value is lost and increased issues arise; however, this approach is not necessarily uncommon.
Although the values associated with employing a formal and structured systems engineering
function within the scope of large and complex systems implementations may be known and
even quantifiable, the reality is that many organizations do not capitalize on these benefits.
One of the exploratory conceptual purposes of this paper was to assess potential added value
aspects of utilizing a systems engineering approach on such projects, and subsequently
compare and contrast against personal experiences of project implementations which have
lacked a formal systems engineering role.
Based on my research of the three designated systems engineering concepts which I
have explored in this paper, it is apparent that the science-technology foundation of systems
engineering translates into best results when applied in a distributed fashion amongst
professional systems engineers and program managers. For this reason, it is obviously sub-
optimal to attempt to allocate the systems engineering functions to various team members
from the project, in the absence of a formal systems engineer position on the project team.
Nevertheless, when organizational constraints prevent the employment of a single agent to
carry out these duties, I believe the logical distribution of functions is to allocate activities
further “up” the vee model to program management, while assigning intermediary aspects
(revolving around the interface or translation from system-level to lower-level) to traditional
engineering disciplines. The potential negative implications of this (such as biased focus on
individual engineering discipline and thus preferential optimization of certain subsystems and
components, lack of consideration of reasonable trade-offs and a high-level systems

JEREMY BAMBACE
Page 19 of 20
perspective) would need to be managed by the program manager in the absence of a formally
designated systems engineer.
In conclusion, I believe the value-add manifestations of employing a requirements
definition process, systems architecting, and concurrent engineering, all within the context of a
structured systems engineering framework, are justified based on the benefits outlined in this
paper. Working within the confines of organizational constraints (and therefore in the absence
of a formally appointed systems engineer), my goal is to strive to identify a manageable
approach to employ these methodologies in future system implementations, and thereby
reduce critical project delays and added costs, and overall generate added value that is indeed
recognizable and measurable.

JEREMY BAMBACE
Page 20 of 20
References
[1] BLANCHARD, B. AND FABRYCKY, W., 2006. Systems Engineering and Analysis. 4th
ed. New
Jersey: Pearson Prentice Hall
[2] RUSSELL, J., 2008. Systems Engineering Requirements Definition Provides a Quantitative
Foundation for Project Management Tools. Conference on Systems Engineering Research, April
4-5, 2008, Los Angeles, CA, USA.
[3] VALERDI, R. AND EICHE, B., 2005. On Counting Requirements. Conference on Systems
Engineering Research, March 23-25, 2005, Hoboken, NJ, USA.
[4] INCOSE AND AIAA, 1997. Systems Engineering - A Way of Thinking, A Way of Doing Business,
Enabling Organized Transition from Need to Product. Paper available from www.incose.org
[5] INCOSE, 2007. Systems Engineering Vision 2020. Paper available from www.incose.org
[6] RECHTIN, E., 1992. The Art of Systems Architecting. IEEE Spectrum Magazine, Vol. 29 (Issue
10), pg. 66-69.
[7] KAINDL, H., 2005. System and software co-architecting. Conference on Systems Engineering
Research, March 23-25, 2005, Hoboken, NJ, USA.
[8] CAPELL, P. AND MADNI, A., 2008. Complexity and Architecture. Conference on Systems
Engineering Research, April 4-5, 2008, Los Angeles, CA, USA.
[9] LOUREIRO, G. AND CURRAN, R., 2007. Complex Systems Concurrent Engineering:
Collaboration, Technology Innovation and Sustainability. Springer Publishing.
[10] GIBSON, D., GOLDENSON, D. AND KOST, K., 2006. Performance Results of CMMI-Based
Process Improvement. Technical Report, Carnegie Mellon University.

Jeremy Bambace - Systems Engineering Frameworks

Recommended

Recommended

More Related Content

Similar to Jeremy Bambace - Systems Engineering Frameworks

Similar to Jeremy Bambace - Systems Engineering Frameworks (20)

Recently uploaded

Recently uploaded (20)

Jeremy Bambace - Systems Engineering Frameworks