ENG 101

Sect 1
Job View - Systems Engineering is what a person with the titled position of "Systems
Engineer" does and has as his/her job description, responsibility and/or role Role

For example, a paper published in the International Council of Systems Engineers

(INCOSE) 1996 Proceedings identified 12 different job roles, based on a variety of
surveys that could be considered to constitute Systems Engineering. These job roles
included: Requirements Owner, System Designer, System Analyst, Test Engineer,
Logistics and Operations, System Integrator, Customer Interface, Technical
Manager, Information Manager, Process Engineer, Coordinator, and miscellaneous
Software Engineering roles. .
Organizational View - Systems Engineering is what an organization named
"Systems Engineering" does and has as its responsibility and/or role.
Problem-Solving View - Systems Engineering is a way of thinking about any
complex technical problem.
Multidisciplinary View - Systems Engineering is a multidisciplinary approach that
defines the total technical effort needed to realize system products and sustain their
life cycle services.
Systems Engineering is an interdisciplinary approach encompassing the entire
technical effort to evolve and verify an integrated and total life cycle-balanced set
of system, people and process solutions that satisfy customer needs.
The Acquirer: DoD program offices and agencies mainly use Systems Engineering
processes and tools to manage development activities.
The Developer: The defense industry mainly uses Systems Engineering processes
and tools as part of their approach both to manage development, as well as to
create products for the acquirer.
While there are many complex issues that contribute to program problems,
systemic problems related to Systems Engineering identified by the GAO include:
Requirements turbulence
Poor requirements management
Use of immature technologies
Inadequate technical assessment Technical Assessment

A key part of the Technical Assessment process is the use of the results of Technical
Design Reviews. Such reviews and the assessments that result from them are one of
the keys to a knowledge-based acquisition process. A recent GAO survey of over 70
major DoD programs concluded that:

The absence of a knowledge-based acquisition process steeped in disciplined

Systems Engineering practices contributes greatly to DoDs poor acquisition
outcomes. Systems Engineering is a process that translates customer wants into
specific product features for which requisite technological, software, engineering
and production capabilities can be identified.DoD programs often do not conduct
Systems Engineering in a timely fashionor in some cases, omit key Systems
Engineering activities altogether. Unstable/unproven product designs
Premature entry into production
Undisciplined software development
Lack of Robust Systems Engineering

Systems Engineering: Is an interdisciplinary approach encompassing the entire

technical effort to evolve and verify an integrated and total life cycle-balanced set
of system, people and process solutions that satisfy customer needs.

The Scope of Systems Engineering: Includes transformation of needed operational

capabilities into an integrated system design; integration of technical life cycle
efforts; and development of technical information to support program management
decision-making. Systems Engineering, because it encompasses the entire technical
effort, is a key enabler of effective Total Life Cycle System Management (TLCSM).

Challenges to Systems Engineering: Include growing system complexity; workforce

turbulence; low technical management investment; inconsistent application of
Systems Engineering; insufficient early use of Systems Engineering; and poor initial
program formulation, insufficient tools and environments and inconsistent
requirements management.
processProcess

1.3
A process is a sequence of steps or activities performed for a given purpose. A
process converts an input (such as requirements) to a desired output (such as
defined work products) through a set of structured activities. To execute a process,
it takes resources such as trained people, funds, facilities, equipment, tools and
methods. Processes are constrained by various management and legal and
regulatory directives and requirements. identifies "what" has to be done but not the
details of "how" to do it. Standardized processes are essential for:
Clarity in communicating taskings
Controlling the overall technical effort
Designing systems solutions
'Realizing' products that make up the system
"Realization" is a formal term used to precisely quantify the desired end-state of
Systems Engineering activities.

A formal definition of "realization" from a Systems Engineering perspective is shown

here.
The correct statements are "Transitioning the product, ultimately to the customer",
"Providing the physical design solution in an appropriate form" and "Verifying and
validating the product".

Which of the following statements about the various Technical Processes used in
Systems Engineering is correct? They are used for designing systems and for
product realization.

Which of the following statements about the various Technical Management Processes used in Systems
Engineering is correct? They are key to managing the overall technical effort.
Let's look at a simplistic (you'll find out why later!) example of Systems Engineering Technical
Processes in action, starting with the three Technical Processes used to design a system. These
processes are:
1.Stakeholder Requirements Definition Process : Requirements for DoD systems come from various
diverse constituencies (generically categorized as Acquirer Requirements Acquirer Requirements

Acquirer Requirements may be in the form of requirement statements from a customer, user or
operator; or be expressed as a set of assigned/allocated specifications developed previously. and Other
Interested Party Requirements Other Interested Party Requirements

These types of requirements include those of parties who have some interest in the system, such as
those providing life cycle support functions; OSD management or other government agencies; and
laws, regulations, treaties, policies, etc. which may affect the program or project. ). Together these
requirements comprise the set of Stakeholder RequirementsStakeholder requirements

These are requirements that represent what stakeholders of a system need or expect of the system
products. They are comprised of "Acquirer Requirements" and "Other Interested Party Requirements". ,
which also include Derived Requirements Derived Requirements

Derived Requirements are those that are not explicitly stated in the set of Stakeholder Requirements,
yet are required to satisfy one or more specific Stakeholder Requirements. Derived Requirements are
generated based on an operational or technical analysis of a Stakeholder Requirement in order to
clarify the requirement or make it achievable. For example:

Stakeholder Requirement: A missile must have a fly-out distance of 2 kms and hit a target having a
Radar Cross Section the size of a tennis ball.

Derived Requirement: The missile shall be aimed within 2 degrees of the target so that the warhead
terminal seeker can lock on and perform the terminal intercept. . These sets of requirements are
ultimately transformed into Technical Requirements Technical Requirements

A Technical Requirement is derived from analysis of Stakeholder Requirements. It is expressed as a

confirmed and quantitative "shall" statement. The set of Technical Requirements are inputs to the
Requirements Analysis Process. Technical Requirements establish the basis for system development. .
The latter ultimately become the basis for the design. Key Measures of Effectiveness Measures of
Effectiveness

Measures of Effectiveness (MOEs) give definition to the operational capabilities essential to mission
accomplishment. They represent the metrics by which satisfaction with products produced by the
technical effort will be measured. KPPs, established as part of the JCIDS process, are special cases of
MOEs. Typically if a system cannot satisfy its KPPs, its development should cease. are also initially
identified.
2.Requirements Analysis Process : Technical Requirements are then analyzed in various ways to
determine an optimal functional architecture Functional Architecture

This is an arrangement of functions and their sub-functions and interfaces (internal and external) that
defines the execution sequencing, conditions for control or data flow, and the performance
requirements to satisfy the requirements baseline. . Interfaces are defined in more detail. Performance
parameters are allocated. Important additional Technical Requirements (called Derived Technical
RequirementsDerived Technical Requirements

These are technical requirements that are further refined from a primary source requirement or a
higher-level derived requirement. Derived Technical Requirements are requirements that result from
the analysis of Technical Requirements, which is done as part of the Requirements Analysis Process or
Architecture Design Process. ) are identified. Work products Work Products

A work product is any artifact--material or electronic--generated during the conduct of the activities
and tasks of a process, including the desired outputs. are baselined.
3.Architecture Design Process : Using the outcomes from the Stakeholder Requirements Definition
Process and the Requirements Analysis Process, alternative design solutions are developed. More
Derived Technical Requirements may be identified as well. These design solutions are evaluated to
determine which are acceptable within cost, schedule and technical constraints. A design or a physical
architecture Physical Architecture

This is a hierarchical arrangement of people, product and process solutions; their functional and
performance requirements; their internal and external interfaces; and their physical constraints. It
forms the basis for the design. is established.
Outcomes of the Architecture Design Process typically include a set of Solution-Specified Requirements
Solution-Specified Requirements

These are the requirements that characterize and specify the functions and performance of the design
solution. They are expressed in the System Specification, subsystem specifications,
verification/validation criteria, various end product specifications and requirements for Enabling
Products. , a key component of which is the System Specification System Specification

This is a type of program-unique specification that describes the requirements and how they will be
verified for a combination of elements that must function together to produce the capabilities that
fulfill a mission need, including hardware, equipment and software. . These requirements are baselined
and become part of a Technical Data Package (TDP) A Technical Data Package (TDP)

A Technical Data Package (TDP) provides a comprehensive description of a given system element. The
TDP is used for the Implementation Process and is retained and placed under configuration
management and baselined throughout the life of the product.
Implementation Process : If subsystems do not need to be developed, then, using appropriate
elements from the TDP, the product is made, bought or reused. This may involve hardware fabrication,
manufacturing, software coding or purchase from outside sources. No matter what their source, some
degree of low-level verification and validation is performed to make sure that 'good' products are
implemented. Some supporting documentation may be developed.
5.Integration Process : At some point, implementation is completed. End product components are
assembled and integrated. As part of this, integrated components are verified and validated as
appropriate so as to ensure that only 'good' products actually get assembled and integrated.
6.Verification Process : Using criteria established as part of the Architecture Design Process and various
plans Various Plans

Key among these plans is the Test and Evaluation Master Plan (TEMP). The TEMP, one of the outcomes
of the Technical Planning Process, provides top-level details of systems-level verification
(Developmental Testing) and validation (Operational Testing). Specific test scenarios and scripts are
provided elsewhere in more detailed test plans. , the end product is verified. This ensures that it
conforms to its 'design-to' requirements and has been "built right".
7.Validation Process : Using criteria established as part of the Architecture Design Process and various
plans, the end product is validated. This ensures that it conforms to its Stakeholder Requirements and
is the "right product".
8.Transition Process : The end product either: (1) moves up a level (e.g., from subsystem to system) in
the physical architecture of the system for more development as needed; (2) it transitions to the next
acquisition life cycle phase; or (3) the End Product is delivered successfully to the user.
Technical Control Processes . These are:
1.Requirements Management Process : Used heavily as the three design Technical Processes iterate
and interact, it ensures that all of the generated Technical Requirements and Derived Requirements
can ultimately be traced back to user-defined capabilities and needs.
2.Interface Management Process : Used to support the Requirements Analysis Process (where many
interfaces are initially defined) as well as the Integration Process. Interface Management ensures
interface definition and compliance among system elements and for interoperability with other
systems.
3.Risk Management Process : Is a core process which underlies all others. It identifies, analyzes,
mitigates and tracks program technical risks.
4.Configuration Management Process : Ensures that baselines Baselines

Typically these include the following: Functional Baseline: Documentation describing system and
subsystem functional characteristics and the verification required to demonstrate the achievement of
those specified functional characteristics. Allocated Baseline: Documentation that designates the
Configuration Items (CIs) making up a system, and then allocates the system function and
performance requirements across the CIs (hence the term 'allocated baseline'). Product Baseline: The
approved technical documentation which describes a system's Configuration Item during the
production, fielding/deployment and operational support phases of its life cycle. are established,
controlled and kept consistent. Configuration Management is a key player with the Requirements
Management, Interface Management and Technical Data Management Processes.
5.Technical Data Management Process : A wide variety of data and information Data and Information

The term "data" as used in Technical Data Management includes technical data; computer software
documentation; or representation of facts, numbers, or datum of any nature that can be
communicated, stored and processed to form information required by a contract or agreement to be
delivered, or accessed by, the Government.

Information, on the other hand, is generally considered as processed data. The form of the processed
data is dependent on the documentation, report, review formats or templates that are applicable.

Of course, one needs wisdom to use either data or information most effectively. Unfortunately, that is
not one of the by-products of Technical Data Management! is produced as outcomes of various process
activities. Technical Data Management plans for it; acquires it; provides access to it; manages it; and
protects data and information of a technical nature needed to support the total life cycle of a system.
Technical Planning Process : This management process is the lynchpin of the entire Systems
Engineering process and ultimately, initiates the overall effort. Various key plans, such as the Systems
Engineering Plan (SEP) Systems Engineering Plan (SEP)

The SEP is a "living" "go to" technical planning document and the blueprint for the conduct,
management, and control of the technical aspects of the government's program from concept to
disposal. While a government plan, once a contract is awarded, it is expected that the SEP will be
updated to reflect the winning contractor(s)' technical strategy and System Engineering approach. ,
the Test and Evaluation Master Plan (TEMP) Test and Evaluation Master Plan (TEMP)
The TEMP is an important document in that it contains the required type and amount of integrated test
and evaluation events, along with their resource requirements. The TEMP focuses on the overall
structure, major elements and objectives of the T&E program, and it must be consistent with the
Systems Engineering Plan (SEP). and various other plans Other Plans

A number of "other plans" exist. Some of them frame the actual program's implementation of Technical
Management Processes. For example: Interface Management Plan; Requirements Management Plan;
Risk Management Plan; Configuration Management Plan; Data Management Plan, among others.
Others are so-called specialty plans which include: Electromagnetic Compatibility/ Interference
(EMC/EMI) Control Plan; Human Systems Integration (HSI) Plan; Producibility Plan; Programmatic
Environment, Safety, and Occupational Health Evaluation (PESHE); Security Plan; Information Support
Plan; Modeling & Simulation (M&S) Plan; Corrosion Prevention Plan, etc.

Many of these plans are discussed in various sections of the Defense Acquisition Guidebook (DAG). In
some cases, specific formats are suggested and in other cases, plan formats depend on local
command policies and regulations. Some plans are required by statute, and details about them are
provided via tabular format as enclosures to the DoD 5000-series of acquisition directives. are key
outcomes of the Technical Planning Process.
7.Technical Assessment Process : This process provides visibility to 'where we are' and 'where we are
going' in terms of the application of Technical Processes. Key tools used in Technical Assessment
include Technical Reviews Technical Reviews

Technical Reviews are an important oversight tool. They are used to review and evaluate the state of
the system and the program, re-directing activity after the review if found necessary. Technical
Reviews are key decision events used to measure technical progress and maturity in system
development as well as to assess various programmatic issues. , Earned Value Management (EVM)
Earned Value Management (EVM)

Earned Value Management is a tool that allows visibility into contractual technical, cost, and schedule
planning, performance, and progress. This visibility provides insight to contract performance, but also
provides the necessary data points to statistically estimate probable completion costs. EVM helps to
ensure that cost, schedule and technical aspects of the contract are truly integrated. and Technical
Performance Measurement (TPM) Technical Performance Measurement (TPM)

This is the technique of predicting the future value of a key technical parameter of the higher-level end
product under development, based on current assessments of products lower in the system structure.
In the DoD, these key technical parameters are typically related in some way to Key Performance
Parameters (KPPs) as well as Measures of Effectiveness (MOEs). .
8.Decision Analysis Process : This is a cross-cutting process that provides a rational, repeatable basis -both formal and informal -- for evaluating and selecting alternatives when a decision must be made. It
operates within the program's trade space Trade Space

Trade Space is the set of program and system parameters, attributes and characteristics required to
satisfy some aspect of system performance. Decision-makers define and refine the development
system by making trade-offs with regard to cost, schedule, risk and performance---all of which fall
within the "trade space".
Technical Processes get applied recursively to each system element, from the top to the bottom. This
continues until the lowest system products are defined to the point where they can be implemented
(i.e., bought, built or reused) and realized.

Meanwhile, Technical Management Processes are controlling all these Technical Processes and ensuring
their effective application.
There are eight Technical Processes that are used for designing and realizing systems.

Systems Engineering Technical Processes for designing systems include:

1.Stakeholder Requirements Definition: Translates stakeholder needs into Technical Requirements
2.Requirements Analysis: Improves understanding of requirements and their functional relationships
3.Architecture Design: Develops alternative design solutions, physical architectures and selects a final
design (Solution-Specified Requirements)
Systems Engineering Technical Processes for realizing systems products include:
1.Implementation: Creates (making, buying or reusing) low-level system elements
2.Integration: Incorporates lower-level system elements into higher-level ones
3.Verification: Confirms that system elements meet design-to or build-to specifications
4.Validation: Confirms that system elements meet Stakeholder Requirements

5.Transition: Moves a system element to the next development stage or, for the End Product, to the
user
Systems Engineering Technical Management Processes are used to control the application of the
Technical Processes and to help ensure that they're effectively used. The eight Technical Management
Processes are:
1.Technical Planning: Ensures the proper application of Systems Engineering processes
2.Requirements Management: Provides traceability of system and subsystem requirements, ultimately
back to user-defined capabilities and needs
3.Interface Management: Ensures interface definition and compliance among system elements,
including other systems
4.Risk Management: Examines the technical risk of deviating from program plans
5.Configuration Management: Establishes and maintains the consistency of a product's attributes with
its requirements and configuration information
6.Technical Data Management: Plans for, acquires, accesses, manages, protects and uses data of a
technical nature in order to support the total life cycle of a system
7.Technical Assessment: Measures technical progress and the effectiveness of plans and requirements
8.Decision Analysis: Provides the basis for evaluation and selection of technical alternatives when
decisions need to be made

1.4
Additionally, standards play key roles in the following areas:
They provide a baseline of the "what's" and "why's". This provides a basis for assessing and
improving an organization's policies and procedures.
They are used by developers Developers

Although the 'developer' is cited here as reflective of the defense industry, in some situations, the DoD
is both the 'acquirer' and the 'developer'. to:
Establish and standardize internal processes
Direct usage by suppliers and subcontractors
Assess internal and supplier capabilities
Develop Systems Engineering technical plans
They are used by acquirers to:
Understand the developer's Systems Engineering activities
Determine and assess developer capabilities
They are used by countries to: Provide an industry segment with a set of national practices.

NOTE: DoD acquirers need to be familiar with standards that developers may use. This is so they can
properly evaluate the developer's proposals relative to Systems Engineering submitted as part of the
contracting process. However, the DoD does not generally contractually impose any particular SE
standard on developers.

These Systems Engineering standards differ primarily in their depth and breadth of coverage.
ISO/IEC 15288 (which is identical to IEEE Std 15288) has the greatest breadth (25 system life cycle
processes including post-deployment ones) but the least depth of coverage. It is useful for top-level
planning, primarily at the organizational level. This standard is designed to be used by an organization,
a project within an organization, or an acquirer and a supplier via an appropriate agreement.
EIA 632 defines the set of requirements for engineering a system. The processes in EIA 632 describe
'what to do' with respect to the processes for engineering a system. These are at the next level down
from the ISO/IEC 15288 level of system life cycle processes.
IEEE 1220 defines a Systems Engineering process. It gives the next level of detail below the process
requirements described in EIA 632. The process is described more at the task or application level.
IEEE 1220 has the greatest depth of coverage for its limited scope but the least breadth. EIA-632 falls
between the other two standards.
Key commercial Systems Engineering standards include _____. EIA 632, IEEE 1220 and ISO/IEC 15288

The scope, breadth and life cycle applicability of the various Systems Engineering commercial
standards such as EIA 632, IEEE 1220 and ISO/IEC 15288 are consistent. False

Standards vs. Maturity Models

Standards are by design useful for helping a project implement Systems Engineering. They provide a
set of processes that, if performed by qualified persons using appropriate tools and methods, will
provide a capability for effective and efficient engineering of systems.

Maturity models (e.g., the CMMI) are by intent useful for determining the capability and/or maturity of
an organization to perform Systems Engineering. A maturity model is used to assess, from an
organizational perspective, how well processes have been established and instituted and how well they
are being followed.

1.5
Broad categories of system models include:
1.A generic dictionary type of definition that provides some insight but limited usefulness
for actually engineering a particular system

2.A definition that considers the system as the operational entity

3.A definition encompassing both operational products and related enabling (life cycle
support services) products

The notion behind this system model is that every system consists of:
1.One or more End Products that will perform the intended operational functions expected
by the customer and be within the constraints set by other stakeholders
2.A set of Enabling Products that perform life cycle service functions required for the End
Product to operate effectively
Each End Product will have its unique and common set of Enabling Products that will
enable the End Product to be designed, realized, deployed, operated, maintained and,
when the End Product has finished its useful life, to be properly disposed.

Enabling Products also include training products that will enable the operators and
maintainers of the system to perform their missions.
End Products and Enabling Products can be further characterized as outlined below.
End Product :

Defined by a customer need

Performs the operational functions required by a customer
Has '-ilities' designed in - Producibility, Testability, Trainability, Supportability,
Disposability, etc.
Enabling Product :

Defined as those products required to enable the End Product to be developed, produced,
tested, deployed, utilized, supported and disposed of
May need to be developed or may already exist and thus constrain Constrain

For instance, the size and operation of nozzles and clamping devices used for air-to-air
refueling have been standardized over many years within the Air Force and Navy tanker
fleets. Existing aircraft use these nozzles and clamping designs. New aircraft must
accommodate them as well. Similar considerations regarding so-called Ground Handling
Equipment (GHE), used to service aircraft, may apply as well. the End Product
Each End Product has its own set of Enabling Products
Enabling Products are determined by End Product life cycle requirements
Must be available to support End Product life cycle functions
An End Product can be:
1.Self-contained in terms of its use and operations

Examples: An aircraft, a tank, a submarine, a communications module or a satellite

2.Items that have no use outside a larger end product, but that are developed as an end
product of a subsystem
Examples: An engine or radio for an aircraft; a power train or braking system for a tank;
switches or transducers for a communications module; a solar panel or transmitter for a
satellite
Enabling Products perform non-operational functions of the system. Some examples
include:
Development Plans and schedules; engineering policies and procedures; automated tools;
models; qualified engineering and management personnel

Manufacturing Policies and procedures; manufacturing facilities; jigs, special tools and
equipment; production processes; manufacturing and procurement personnel
Test Test plans, policies and procedures; models and mockups; special tools and test
equipment; test facilities and sites; simulation or analytical models; inspection procedures
and test personnel
continue with examples of generic Enabling Products:
Operations/Deployment: Plans, policies and procedures; packaging materials; storage
facilities; special handling and transportation equipment; installation procedures and
environmental permits; deployment instructions; and installation personnel
Training/Utilization: Plans and schedules; simulators and training models; courses and
materials; special training facilities, ranges and trainers
Support: Policies and procedures; tools and repair equipment; support facilities and
handling equipment; maintenance manuals; maintenance management systems; special
diagnostic equipment; repair personnel
Retirement: Plans, schedules and procedures; refurbishment facilities; environmental
permits and disposal sites; equipment for disposal/recycling of spent products; qualified
disposal personnel
Planning and managing the Systems Engineering effort by:
Identifying products to be engineered
Assigning work packages
Making cost estimates
Assessing risks and opportunities
Organizing IPTs and facilitating teamwork
Orchestrating technical reviews
Defining and structuring specifications, including interfaces
Creating system structure (level-by-level development and product realization)
Identifying and developing enabling products

Each IPT is responsible for:

Planning their work
Making cost estimates related to their work and the product
Doing the work described in the team's approved work package
Identifying and managing the risks and opportunities associated with the development of
the product, including interfaces with other products in the model
A system model can be used to assist in ________________. Orchestrating incremental reviews
Structuring IPT team assignmentsDeveloping specifications
"It is a product-oriented family tree composed of hardware, software, services, data and
facilities." and "It is used to consistently link program and contracting reporting
activities.". WBS
"Realization of system model end products should be accomplished from the bottom up so
as to find and correct problems at the lowest possible level.".
The Requirements Analysis Technical Process has been completed on a portion of the XYZ
system. However, an In-Progress Review (IPR) of the work products indicated that many

Technical Requirements were not adequately considered in development of the functional

architecture. Consequently, a decision was made to redo Requirements Analysis using
these additional missing Technical Requirements. This is an example of _____. Process
Recursion
The Architecture Design Technical Process has nearly been completed on the XYZ system.
As a result, Derived Technical Requirements were baselined that pertain to one of the XYZ
proposed subsystems, Subsystem ABC. These have resulted in the initiation of the
Stakeholder Requirements Definition Process for Subsystem ABC. Meanwhile, Technical
Process activities continue at the XYZ system level. This is an example of _____. Process
Recursion
Efforts are focused on continued trade studies working toward a final System Specification
and demonstration of design maturity during the _____ phase. Technology Maturation and
Risk Reduction
Which phase has outputs that include validation of the manufacturing processes and
confirmation that End Products are being manufactured in accordance with the specified
manufacturing processes? Production and Deployment
System: An aggregation of End Products and Enabling Products that achieves a given
purpose
Products: A 'system' consists of a wide variety and large number of different products.
Categories of such products include:
End Products, which actually perform the intended operational functions of the system
Enabling Products, which are those products that must be available to enable the End
Product to be developed and supported over its life cycle
Realization: For each end product design solution, provides a product in a form suitable for
meeting the applicable acquisition life cycle phase exit criteria, including verification and
validation and transitioning the product to the parent system model for integration into
another end product or to the customer.
Role of Systems Models: In order to unambiguously describe various Systems Engineering
processes and activities as well as provide a framework for their application, a system
model is used.
Work Breakdown Structure (WBS): Is a product-oriented family tree composed of hardware,
software, services, data and facilities. MIL-STD-881 provides details on use of a WBS to
include illustrative WBSs for a variety of defense system categories. Within the DoD, a
WBS is the most common way that a system model is formally documented
Iteration and Recursion: Are key concepts in the application of Systems Engineering
processes
Iteration: The re-application of processes already applied to a system model based on
feedback indicating a problem that needs resolution
Recursion: The repeated application of the same Technical Processes to either
successively lower system models within the system structure or to end products at
successively higher levels

Systems Model - Systems Engineering Connection: Is a structure based on a hierarchy of

layered systems models which provides the basis for Top-Down System Design and BottomUp Product Realization
Top-Down System Design: System Design Processes are applied to each 'system model' of
the system structure. Upper system models must be fully defined and appropriate
Technical Reviews successfully completed in order to be able to start development of a
lower system model. This application of System Design Processes continues until all
system model end products can be built (or coded), bought, or reused/off-the-shelf and are
ready for realization.
Bottom-Up Product Realization: At the point when end products are ready for realization,
Product Realization Processes are applied from the bottom up to realize the design
solution for that end product. An end product obtained from the Implementation Process is
then verified, validated and transitioned for assembly and integration into its parent
system model end product which in turn is verified, validated and transitioned. This
sequence continues until the desired system-level End Product is realized.
Specifications: A key part of Systems Engineering involves the development and
management of various specifications. The system model aids in understanding which
products and their interfaces need to have specifications as outputs of the System Design
Processes.
MIL-STD 961, Defense and Program-Unique Specification Format and Content, is the DoD
specification standard. It defines generic categories of specifications as: System
Specification, Performance Specification, Detail Specification, Item Specification and
Software Specification.
Defense Acquisition Life Cycle: The 5000-series of DoD publications specifies policies and
processes to be applied within the context of the acquisition life cycle. Phase entry and
exit criteria are used for determining the maturity of the system under development and
whether it is ready to proceed (or transition) to the next acquisition phase.
Summary of key Systems Engineering activities by defense acquisition phase include:
Materiel Solution Analysis Phase: Is focused on trade studies and concept analyses to
better understand Stakeholder Requirements.
Technology Maturation & Risk Reduction (TMRR) Phase: Continued trade studies and
analyses working toward a final System Specification, risk analysis of key and enabling
technologies, and evidence of design maturity via a PDR.
Engineering and Manufacturing Development Phase: Completion of any remaining
preliminary design efforts and start of critical design activities, which culminate in an
initial Product Baseline. End Products are implemented, integrated and verified to that
baseline.
Production and Deployment Phase: Low-Rate Initial Production (LRIP) units are
constructed using the processes and tools planned for final production. LRIP units are also
used for initial product validation. Activities also include ramp-up to full-rate production
and delivery to the first receiving organizations.
Operations and Support Phase: Includes monitoring of service use data to determine and
correct any problems with the End Products being used. Support of disposal or retirement
activities may also be needed.

1.6
A SEP is prepared by the Program Management Office and is one of the expected outcomes
of the Technical Planning Process.
Contracting considerations include:
Formally evaluating Systems Engineering during the source selection process
Assessing a contractor's Systems Engineering past performance and demonstrated
process maturity level as part of source selection considerations
Using various contract types (e.g., incentive or award fees) to promote Robust Systems
Engineering
The Systems Engineering Plan is first required at program initiation at Milestone B. False

"Rules for Robust Flying" found posted anonymously in a aircraft squadron ready room:
Regarding flying near the edges of the flight envelope:
1.Try to stay in the middle of the air.
2.Do not go near the edges of it.
3.The edges of the air can be recognized by the appearance of ground, buildings, sea,
trees and interstellar space. It is much more difficult to fly there.
A robust (or resilient) design is a flexible and adaptable one that is tolerant of end product
failure points and/or operating conditions and accommodates human interaction with the
system. In robust design, errant excursions outside the operating 'flight envelope' of an
end product do not necessarily result in catastrophic consequences.
Use of Open System Architectures---key to flexible and adaptable designs---is another
characteristic of robust Systems Engineering.
An Open System Architecture (OSA) is appropriate for some module interfaces and is
emphasized by DoD policies. An OSA uses commercial or non-proprietary (i.e., open
system) standards Standards

The DoDAF is used to formally document a program's architectures via a series of highlyformatted 'viewpoints'. One of these is the Standards Viewpoint (StdV). The StdV
articulates applicable operational, business, technical and industry policies, standards,
guidance, constraints, and forecasts that will be employed on a given program.

An extensive collection of DoD endorsed IT-related standards (many of them are

commercially-based open standards) has been created for programs to consider using.
Those that are appropriate are incorporated into that program's technical architecture.
This collection of standards is documented in the GIG Technical Guidance Federation.

More information about the DoDAF and the GIG Technical Guidance Federation is available
in References. for selected Key Interfaces. Potentially, this allows multiple vendors to
implement different modules which may be totally different internally, but which externally
function equivalently in their parent system End Product.

The DoD characterizes an Open System as one which:

Is based around a modular design, and
Uses widely supported and consensus-based ('open') standards for its key interfaces, and
Successfully verifies and validates the openness of these interfaces
Other advantages of Open System designs are that they:
Better adapt to evolving requirements and threats
Promote easier technology transition
Facilitate system integration efforts
Contribute to a 'robust' design
Reduce development time and life cycle costs
Enhance interoperability, reuse and supportability
Provide better access to cutting-edge technologies
Mitigate technology obsolescence and single-supplier risks
Which of the following statements about Robust Systems Engineering and Open Systems
are correct?
Key aspects of Robust Systems Engineering include robust design and use of Open System
Architectures.", "Enablers for effective use of Open System Architectures are a modular
design and the identification of Key Interfaces." and "The Requirements Analysis Process
and the Architecture Design Process play important roles in modular design.".
A model is a "physical", mathematical or logical representation of an system entity,
phenomenon, process or end product. A simulation is the manipulation of that model.
Modeling and Simulation (M&S), properly used, can be highly effective Systems
Engineering tools applicable across the total life cycle. It is not uncommon for hundreds of
different M&S assets to be used on a major program.

Some examples of M&S usage include:

Using M&S to explore concept alternatives, reliability, availability, maintainability,
transportability, human-machine interfaces and estimate life cycle sustainment costs
Using modeling environments provided by Systems Engineering tools, Computer-Aided
Design (CAD), etc. to better manage complexity, increase design quality and improve
productivity

Helping to answer questions about the probability of meeting requirements for system
performance
Selective use as part of the verification and possibly, the validation processes
During production, using M&S to make the manufacturing process more efficient
Predicting maintenance and repair levels anticipated during system operation
Which of the following is characteristic of Open Systems Architectures (OSAs)? They
facilitate technology and software upgrades over a system's life.
'Ethics' is related to morality, but the two terms are not synonymous.
Ethics: The rules or standards governing the conduct of a person or the conduct of the
members of a profession
Morality: Concern with the distinction between good and evil or right and wrong; right or
good conduct
Executive Order 12731
Avoiding financial conflicts impacting duty performance
Not using information for private financial gain
Prohibition on solicitation for financial gain
Not using public office for financial gain
Avoiding inappropriate outside employment
Good faith discharge of financial obligations
Adhering to equal opportunity laws
Disclosing waste, fraud, abuse and corruption to appropriate authorities
Avoiding the appearance of non-ethical behavior

Essential considerations that affect the conduct of Systems Engineering within a DoD
program include:
Systems Engineering Plan (SEP): A detailed formulation of actions that should guide all
technical aspects of an acquisition program. It is established early in the program and
updated at each subsequent milestone and as needed. It is a living document, tailored to
the program, and a government technical roadmap that supports program management.
Robust Systems Engineering: Refers to the use of a disciplined Systems Engineering
approach in conjunction with a robust (or resilent) product design. A "robust design" is
one that:
Encompasses design and process flexibility which can rapidly, safely and affordably
accommodate change

Is tolerant of end product failure points and/or operating conditions

Employs modular architectures with open systems standards used for selected Key
Interfaces
A Model is a 'physical,' mathematical or logical representation of an system entity,
phenomenon, process or end product. A Simulation is the manipulation of that model.
Modeling and Simulation (M&S) can be an effective Systems Engineering tool across the
life cycle.
Open Systems Architectures: Use technical interface standards based on non-proprietary,
"open" standards that are widely used, consensus-based, published and maintained by
recognized industry standards organizations.
Evolutionary Acquisition: A type of acquisition approach used at the system level that
builds and fields core portions of a system by selectively evolving it through phased
upgrades. It is the preferred DoD strategy for software-intensive system developments,
especially for network-centric or information-based systems. It should also be used for
other types of systems whenever appropriate. The flexibility inherent in Open System
Architectures facilitates effective use of Evolutionary Acquisition.
Ethics: Ethical behavior and conduct is required for all DoD employees. Presidential
Executive Order 12731 established the framework for ethical conduct of all government
employees. The U.S. Office of Government Ethics (OGE) contains references on specific laws
and regulations related to ethical behavior.