SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP)

Type and Working Draft

Updated Oct, 2000 from Oct, 1992 draft and Oct, 1994 “final”

1.0 SCOPE

1.1 Purpose. This System Engineering Management Plan describes an internally developed
approach to a fully integrated engineering effort. It addresses how the typical contract
will be managed and conducted to ensure that program cost, schedules and technical
performance address the requirements for a SEMP in accordance with MIL-STD-499A.
(Note that –499B was never officially issued. Some concepts are from Defense System
Management College).

1.2 Application. This SEMP applies to the wide range of engineering efforts currently being
being pursued, especially those that involve the integration of systems. It is applicable to
programs that transcend the entire life cycle (Concept Exploration, Demonstration and
Validation, Full-Scale Development, Production and Operational Phases) or programs
that encompass a single phase. Additionally, the SEMP is applicable to those contract
that involve System Engineering and Technical Assistance (SETA) efforts in support of a
prime or Government Program Management Office.

1.3 Implementation. The SEMP approach adheres to the management approach directed by
the Office of the Secretary of Defense (OSD) and implemented through Directive 5000.1
and DoD Instruction (DoD) 5000.2 (both dated 23 February 1991, subsequent
instructions and updates). DoDI 5000.2 requires an effective systems engineering
program be implemented for each acquisition program in accordance with MIL-STD-
499. This SEMP addresses Systems Engineering in three parts as defined on paragraph
5.1 and amplified in sections 4, 6 and 10 of MIL-STD-499A. Technical Planning and
Control will be addressed in Paragraph 5.1 following as an integrated topic with the
Systems Engineering Management Section. System Engineering Process and Specialty
Engineering will be discussed as integrated efforts in paragraphs 5.2 and 5.3 respectfully.

This SEMP address the three management functions typical with a matrix-managed
organization. These include the Program Management Function (Overall program
authority, responsibility and control) and the two main support functions (1) Engineering
and Technical Control (2) Administrative including financial planning. Cost collection
and Cost Reporting functions are included in the Administrative responsibilities.

a) Program Management. The designated Program Manager (PM) and his

immediate staff is the central management author for all contractual efforts.
Technical Planning Control functions shall reside with the Program Manager and
his staff.

b) Engineering Staff. The Director of Engineering shall perform under the direction
of the Program Manager. The Director of Engineering shall establish and
maintain a Core Engineering Staff that is dedicated for each program. In
addition, the Director of Engineering shall maintain a cadre engineering staff to
assist the Core Engineering Staff on an as required basis. Typical the cadre staff
would include design engineers, specialty engineers and operational specialists.

1
 c) Chief Engineer. The Chief Engineer and his staff will be responsible to the
Program Manager for technical program oversight. The Chief Engineer will be
responsible for tailoring all engineering processes to accommodate the needs of
the program and submit same to each designated PM for approval and
implementation. The Chief Engineer is responsible to the PM for defining and
conducting the technical review and audit process as defined in the Technical
Review and Audit Manual and for implementing and monitoring the Technical
Performance Measurement (TPM) program.

2.0 APPLICABLE SUPPORTIVE DOCUMENT AND PROCESS

• Task Authorization Process

• Contract Work Breakdown Structure Guidelines

• Financial Management Planning, Reporting and Monitoring Process Manual

• Technical Performance Measurement (TPM) Process

• Technical Review and Audit Manual

• Total Quality Management (TQM) or Continuous Process Improvement (CPI)

Manual

• Risk Management Manual

• Configuration Management Manual

• Data Management Manual

• Software Environment Program (SEP) Process

• Quality Assurance Process Manual

• Software Development Process

• Software Test and Evaluation Process

3.0 DEFINITIONS

3.1 Engineering Management. This office will conduct engineering management paralleling
the requirements invoked by DoDD 5000.1, DoDI 5000.2 and DoD 5000.2M for DoD
acquisition. The approach is based on the existence a flowdown of all these requirements
from acquisition managers either directly for contract execution or within the scope of a
SETA support requirement support to the acquisition manager.

3.2 Technical Program Planning and Control. The management of those design,
development, test and evaluation tasks required to progress from an operational need to

2
 deployment and operation of an integrated system (to include contractual efforts
specifically directed to a portion of that defined task within that phase or in support the
operational phase of such a program). The technical program planning and control
process is based on a risk management strategy and include a comprehensive TPM
approach.

3.3 System Engineering Process. The structured sequence of activities and decisions that
transform an operational need into a description of system performance parameters and a
preferred system configuration. The process included rapid prototyping as a means of
demonstration systems capabilities. Rapid Prototyping focuses on correcting system
requirements misconceptions and reducing ambiguities is performance parameters early
in the engineering design phase as a cost risk mitigation effort.

3.4 Engineering Specialty Integration. The timely and appropriate interactive process that
ensures that engineering efforts and disciplines such as reliability, maintainability, human
factors, safety, quality assurance, TQM/CPI, etc., will effectively influence the system
design throughout the design process.

3.5 Other. The definitions included in the applicable documents and processes listed in
Section 2 shall apply.

4.0 GENERAL CRITERIA

Our engineering management process shall conform to item (a) through (k) specified
in paragraph 4 of MIL-STD-499A. The MIL-STD-499A requirements are stated here for
convenience:

a) Technical Objectives. Technical objectives shall be established for each program

so that meaningful relationships among need, urgency, risks and worth can be
established.

b) Baselines. Functional, allocated, and product baselines shall be developed

progressively. Appropriate specifications shall be prepared in accordance with
MIL-STD-490.

c) Technology. Specification requirements shall be delineated in light of acceptable

technological risks defined by risk assessment.

d) Realistic System Values. Realistic Reliability, Maintainability, and other such

system values shall be established prior to full-scale development phase.

e) Design Simplicity. The concept of design simplicity and standardization shall be

evident.

f) Design Completeness. The design shall be complete from a total system element
viewpoint (hardware, facilities, personnel, computer programs, procedural data).

g) Documentation. The concept of minimum documentation shall be evident.

Where possible stipulated plans, reports, and other data items shall be used to
record the engineering outputs. The repository of this accumulated data will be

3
 defined. Engineering data shall be the sole source of performance requirements
used in the design and production of the system.

h) Engineering Decision Studies. Engineering decisions regarding design

alternatives and the technical program shall reflect consideration of system cost
effectiveness analysis based on the specified figure(s) of merit, performance
parameters, program schedule, resource constraints, producibility, and life cycle
cost factors.

i) Cost Estimates. Cost estimates shall include acquisition and ownership costs.
This shall include any established “design to” cost goals and a current estimate of
these costs.

j) Technical Task and Work Breakdown Structure Compatibility. Elements of the

Contract Work Breakdown Elements of the Contract Work Breakdown Structure
and associated technical tasks shall be identified and controlled in accordance
with this standard and MIL-STD-881.

k) Consistency and Correlation of Requirements. System technical program

requirements shall be consistent, correctable, and traceable throughout the
Contract Work Breakdown Structure so that impact of technical problems can be
promptly determine and accurately appraised.

l) Technical Performance Measurement. Progress in achieving technical

requirements shall be continually assessed. Problems and risk areas shall be
identified.

m) Interface Design Compatibility. Intra-system and inter system design

compatibility of engineering interfaces shall be delineated as interface
requirements in appropriate specifications. Interface control requirements and
drawings related to (1) the major system elements of a prime contractual
responsibility, (2) other equipment, computer programs, facilities, and procedural
data furnished by the Government, and (3) other program participants, shall be
coordinated established and maintained (MIL-STD- 483 (USAF)). Clear lines of
communication and timely dissemination of changes to these documents shall be
maintained.

n) Engineering Specialty Integration. Engineering efforts such as Integrated

Logistics Support (ILS), test engineering, production engineering,
transportability, reliability and maintainability engineering, value engineering,
safety engineering, electromagnetic compatibility, standardization, etc., shall be
integrated into the mainstream design effort.

o) Engineering Decision Traceability. Significant engineering decisions shall be

traceable to the system engineering process activities on which they were based.

p) Historical Data. Historical engineering/operational data available to system

designers shall be identified.

q) Responsiveness to Change. Changes to system and program requirements in

response to directed changes by the procuring activity, of problem solutions

4
 identified shall be evaluated, for total program impact with respect to
performance, cost and schedules.

r) Compatibility with Related Activities. Engineering Management activities shall

be compatible with related program management activities such as cost schedule
control system criteria, contract administration, production management, etc.

5.0 SYSTEM ENGINEERING MANAGEMENT

Under the charter to establish and maintain leadership in the development of systems and
in support of system acquisition managers, our management approach necessarily
parallels and supports the DoD acquisition policies set forth in DoDD 5000.1, DoDI
5000.2 and DoD 5000.2M. The fundamental philosophy is to allow engineering
directorates maximum flexibility and to eliminate over managing and its negative
attributes. The management philosophy is based on Risk Management strategies
followed by monitoring of cost, schedule and performance parameters. Comparison of
actual versus predicted, observing and evaluating trends, and using the latest management
analysis tools and techniques is the foundation of the management philosophy.

5.1 Technical Program Planning and Control. This System Engineering Management Plan
(SEMP) identifies organizational responsibilities and authority for systems engineering as
chartered by our corporation. This is illustrated in Figure 5-1 (put your org chart here).
Flexibility is provided by allowing administrative responsibilities at one level and
technical control at another, i.e., Director of Plans and Program can by under the
direction of Sr. VP MX operations for high risk programs of programs requiring high
corporate management visibility while still under SB administrative control.

5.1.1 Project Management. The program manager for each contractual effort is identified by
an officer of the company. He/she is be responsible to the Director of Plans and
Programs to perform business and program management efforts to accomplish overall
project objectives. These efforts include preparation, review, and revision/updating of
management documentation selecting and implementing the appropriate software
management tools for information management and performance analysis (including
requirement for upper management and customer review requirements) of overall
business, administration and engineering activities. Our organization will establish a
process for planning and controlling project, systems engineering and technical support to
acquisition mangers within this SEMP. Tailoring is the responsibility of the individual
PM. It is accomplished with concurrence by the acquisition manger.

Figure 5-2 delineates the responsibilities for the typical development

documentation that will govern system development. Under a prime contracting
approach, the Program Manager is typically is a contractor function. In the case of a
SETA and where the role of the prime is retained within the government, the SETA
contractor will support the government PM in the development of the top-level
documentation and review of the contractor produced documentation.

5.1.2 Contracts Management. The support contractor PM is required to perform judicious

monitoring of activities to keep their aspect of management in focus. If required, the PM
prepares Statements of Work (SOWs) for submittal to the Acquisition Manager for
contract execution. PM, upon contract approval, prepares task authorization tasking for

5
the Technical Director or Engineering Manager responsible for executing the engineering
efforts. This is accomplished in accordance with the Task Authorization process;
Program Manager is individually accountable for the effort serves as a single point of
contract of technical monitoring and development progress within our company and is the
single point of contract for reporting status to the customer.

6
 CEO Responsible for overall efforts and strategies and for corporate
performance

SR VP Responsible for Individual Program performance, Conducts

XX corporate management in-process reviews; Responsible for
OPERATIONS Corporate Resource Allocation (Manpower and Financial)

VP
xx Prime Responsibility for Program Execution
Systems Engineering

DIRECTOR
Responsible for Program Management including
of
sub-contracting
Plans of Program

DIRECTOR
Responsible for technical program execution including
of
technical planning and control
Engineering

Note: reduction by one layer is desirable.

Figure 5-1

TYPE ORGANIZATIONAL STRUCTURE

7
 CONCEPT DEMONSTRATION AND
DEFINITION VALIDATION PHASE FULL SCALE ENGINEERING PHASE
PHASE
A B B

PROGRAM SYSTEM SEGMENT

REQUIREMENT “A” SYSTEM
SPECIFICATION SPEC “A”
SPEC
A D D D

HWCI DRAFT HWCI

SIIs B1 HWCI C1
SPECS C1 SPEC
SPEC
A B B

TOP LEVEL SYSTEM INTERFACE

PROGRAM PROGRAM REQ’T
PLAN PLANS SPEC

SUBSITTED B D D D
WITH PROPOSAL

SOFTWARE SOFTWARE S/W

SEMP TAILORED B5 TOP LEVEL DETAILED
SEMP SPEC DESIGN DESIGN
DOCUMENT DOCUMENT
A B D C D

REVISIONS AND
PROGRAM SUBSYSTEM UPDATES AS REQUIRED INTERFACE SOFTWARE
DESIGN AND DESIGN AND DESIGN LISTINGS C5
SUPPORT SUPPORT DOCUMENT
PLANS PLANS SPEC

C C D

DATABASE
SEAR SEAR DESIGN
UPDATE DOCUMENT

A ACQUISITION MANAGER RESPONSIBLE SIIs – SYSTEM INTEGRATION INTERFACE SPECIFICATION

B PM RESPONSIBLE/ACQUISITION MANAGER APPROVAL
HWCI – HARDWARE CONFIGURATION ITEM
C PM RESPONSIBILITY
SEAR – SYSTEM ENGINEERING ANALYSIS REPORT
D PM RESPONSIBIITY/ACQUISITION MANAGER REVIEW

Figure 5-2 TYPICAL PROGRAM DEVELOPMENT PRODUCT AND RESPONSIBILITIE

8
5.1.2 Sub-Contractor Management. PM has the same responsibilities for sub-contractor
tasking, monitoring and oversight as he/she has for this firm’s internal engineering
efforts. The process will follow Vitro corporate processes and policies.

5.1.3 System Test Planning. Figure 5-3 depicts the typical program test requirements.
Acquisition Managers and Prime Contractor Program managers have the same
responsibilities if the Government retains prime contract role and contracts for System
Engineering and Technical Assistance (SETA) efforts.

The system test planning necessarily includes risk mitigation efforts with
experiments to demonstrate risk reduction. The system planning also includes provisions
for performance measures development and reporting. These include intermediate
performance criteria and key engineering milestones and schedules to complement
engineering management with risk management strategies. Technical Performance
Measurement (TPM) techniques is developed, implemented and maintained as integral to
the system test planning process.

5.1.4 Risk Analysis. The PM is responsible for structuring technically sound programs that
assess risk at all levels and identify areas of high risk. High-risk areas are subject to
corrective actions or risk mitigation activities. Risk analysis techniques and the
characteristics of software tools necessary to support program risk analysis are identified
in the Risk Management Manual. PM, with acquisition manager’s concurrence, is
responsible for tailoring the manual to achieve adherence to overall technical, financial
and schedule program goals.

The risk manual is used in conjunction with DoD 4245-7M, which serves as a
guideline for identifying areas of risk and determination of risk drivers for establishing
the uncertainties inherent to risk analysis efforts. The risk manual includes using outlines
contained in DoD 4245.7M for reducing risk and implementing risk abatement programs.
Risk Analysis is a major function at each System Design Review (Ref. internal Technical
Review and Audit Process Manual).

5.1.5 Contract Work Breakdown Structure (CWBS). The program CWBS developed in
accordance with CWBS development guidelines. The guidelines are in accordance MIL-
STD-181 and Defense Systems Management (DMSC) Systems Engineering Management
Guide. The Program CWBS is identifying tasking development, tasking, authorization
and status monitoring activities. Each task in the CWBS tree is assigned a code that
preserves and communicates the CWBS subdivisional/summation requirements.
Standardization of CWBS nomenclature is inherent in the process to maintain traceability
for historical costs to fulfill compliance with DFARS 215.811.

5.1.6 Technical Performance Measurement (TPM). The program manager implements TPM in
accordance with the Technical Performance Measurement Manual. TPM implementation
follows MIL-STD-499A requirements and is tailored by the program manager (with
acquisition manger concurrence) to specific programs needs. The program complements
the System Management Philosophy being implemented.

5.1.6.1 Performance Parameters. The selection of the TPM performance parameters is

predicated on (1) ability to provide visibility of actual versus planned performance to
support decision making process, (2) ability to provide early detection or prediction of

9
 CONCEPT DEMONSTRATION AND
EXPLORATION VALIDATION PHASE FULL SCALE ENGINEERING PHASE
PHASE

A C C C C C

PREPARE PREPARE PREPARE PREPARE PREPARE PREPARE

MASTER SYSTEM TEST HARDWARE HWCI TEST HARDWARE COMPONENT/
TEST PLAN TEST PROCEDURES CI PROCEDURES INSTALLATION SUBSYSTEM
PLAN TEST PLAN TESTS

B C C C B C C C C

PREPARE PERFORM PREPARE PREPARE PREPARE PERFORM

PROGARM PERFORM ADM/EPM SOFTWARE SOFTWARE SOFTWARE SOFTWARE COMPONENT/
TEMP EXPERIMENTS TESTING CI TEST TEST TESTS SUBSYSTEM
TEST PLAN DECRIPTION PROCEDURES
PREPARE PREPARE
TEST TEST D D D D D D
REPORTS REPORTS

PREPARE PREPARE PERFORM PERFORM

SYSTEM SYSTEM LBEF OPERATION
INEGRATION INTEGRATION TESTING TESTING
TEST PLAN TEST
PROCEDURES
PREPARE PREPARE
TEST TEST
REPORTS REPORTS

SYSTEM

A CI – CONFIGURATION ITEM
ACQUISITION MANAGER/PM RESPONSIBILITY
B PM/TECHNICAL DIRECTOR RESPONSIBLE/ACQUISITION MANAGER/PM APPROVAL
HWCI – HARDWARE CONFIGURATION ITEM
C PM/TECHNICAL DIRECTOR RESPONSIBILITY
D PM/TECHNICAL DIRECTOR RESPONSIBIITY/ACQUISITION MANAGER/PM OBSERVER
LBEF – LAND BASED EVALUATION FACILITY

TEMP – TEST AND EVALUATION MASTER PLAN

Figure 5-3 TYPICAL PROGRAM TEST REQUIREMENTS

10
 problems or trends which require management attention, and (3) ability to evaluate
change alternatives. The TPM risk assessment and related technical control processes are
a continuum of interrelated, interactive, and interdependent systems. TPM provides the
data for technical risk planning and assessment. TPM selection process receives input
from the risk management processes, wherein, parameter criticality is identified by the
critical path templates provided in DoD 4245.7M

5.1.6.2 TPM Assessment Methods. There is a wide range of methods available for technical
performance. Test methods supported by comparative analysis between actual and
predicted results are preferred but these do not necessarily meet the criteria for early
prediction of problems. Forecasting methods such as math models and simulations which
have application in the concept definition and feasibility demonstration phase and which
phase appear to be best suited for our development or technical assistance efforts. Vitro
recognizes the need for early detection of problems to support management decisions
before irrevocable cost or schedule impact occurs. We are constantly developing or
evaluating Computer Aided System Engineering (CASE) tool sets with emphasis of
Systems Requirements definition. We have significant internal resources applied to
development of Rapid Prototyping Techniques (System Requirements and Man-Machine
Interface evaluation aids) to supplement our extensive systems simulation and computer
modeling development programs.

5.1.6.3 Report Frequency and Timing. The tailoring of reporting requirements is left to the
discretion of the individual PMs (or Acquisition Managers). TPM tracking results will be
reported at each Systems Design or System Progress Review. Formal TPM assessments
are be planned to coincide with planned completion of significant design and testing tasks
and will be significant inputs program decision milestone activities.

5.1.7 Interface Compatibility.

5.1.7.1 Interoperability. Interoperability is defined as the ability of systems, units, or forces to

provide services to and accept services from other systems, units or forces and to use the
services, which are exchanged so as to enable them to act together. The typical system
interoperability requirements exist at three levels: between primary system under
development and an external hierarchical entity; between primary component systems;
and wotjom component systems.

5.1.7.2 System Integration Interfaces. The typical system achieves interoperability by

controlling and documenting the interfaces at the three levels of interoperability. These
interfaces are called System Integrating Interfaces (SIIs) and are defined as any interface,
internal or external, to the primary Systems that is identified, defined, and controlled by
the PM to ensure required system interoperability and commonality.

5.1.7.3 Interoperability Process. The interoperability process is a formal structure wherein

system compatibility requirements are defined. It is typically accomplished by an
analytical group within the engineering sector. The group will use functional analysis
techniques to develop the functional and interface requirements. As the total system is
broken down into functional areas, interfaces between the functional areas will be
identified as potential SIIs. Mission and design constraints are factored into the effort
further developing the SIIs. The primary method of definition is through an Interface
Working Group (IWG). An IWG is formed with specialists in each functional area
participating. The IWG is responsible for documenting the design and control

11
 requirement in the Interface Control Documents (ICDs) or SIIs. These must be approved
by all parties to ensure agreement on the interface design details. Detail design engineers
must satisfy the requirement of these interface documents as they realize the design of
their piece of the system. In this way, the system is integrated so all the pieces work
together in an orchestrated whole. In this manner systems engineering will be concerned
with total systems architecture allowing design engineers the flexibility with their detail
design. Systems integration assembles the pieces and tests to ensure compliance with
systems requirements. The Chief Engineer, through the Technical Review and Audit
process, is responsible for auditing the design documentation and results of the tests to
ensure system interface complies with the requirement documentation.

In complex systems a Test Interface Working Group (TIWG) will be chartered

with its own unique responsibilities. The IWG concept with adequately prepared
documentation will be complemented by the TIWG function to define the test, test
analysis functions and the test sequence that will influence the form and format of the
ICDs and SIIs. Interactive Staffing of both the IWG and TIWG functions promotes total
interoperability and compatibility.

5.1.8 Data Management. The PM will perform necessary activities in order to prepare, review,
and revise/update management data, as defined below, to reflect system design,
development, and installation requirements and status. As applicable, management data
will be inclusive of networks, cost estimates and models, cost performance reports, and
contractor funds status reports.

As a minimum the PM:

a) establishes and maintain a CWBS, which will be organized in accordance

with guidance provided herein, and utilize the CWBS to establish the
program database

b) develops and maintains a Project Master Schedule (PMS), which will include
design documentation deliveries, program and design reviews, equipment
acquisition, and installation planning milestones

c) conducts project reviews at least quarterly in order to provide status and

replanning data to acquisition manager throughout the development period
with respect to a summarization of accomplished work, problem area, cost
expenditures, and anticipated activities for the following period

d) prepares and maintain the status of work accomplished, with expenditures

identified to the appropriate CWBS element

e) provides financial analysis and cost breakdown reports that cover each task
and subtask order in terms of both planned and actual expenditures

f) conducts semiannual program status reviews for the purpose of financial

planning for anticipated tasking during forthcoming periods.

5.1.9 Configuration Management. The PM will establish a Configuration Management

Program guided by the requirements of MIL-STD-483 and the internal Configuration
Management Manual and assure a complete and accurate technical description of the

12
 system. The program will provide toe establishing and maintaining systems
configuration identifications, and auditing SII Technical Data Packages (TDPs),
controlling changes to baselines of Configuration Items/Computer Software
Configuration Items (CIs/CSCIs), and control and status accounting for identification of
approval baselines and proposed or approved changes.

5.1.10 Technical Reviews and Audit. Program reviews and audits are outlined in the internal
Technical Review and Audit Manual. Technical reviews will be conducted in general
compliance with MIL-STD-1521 and DoD STD 2167A. Figure 5-4 summarizes review
requirements and responsibilities.

5.1.11 Formal Program Reviews. The PM conducts quarterly formal program reviews to
present complete contract status including performance cost and schedule. The technical
management program status, problems, and issues shall be presented from each Project
Leader.

5.1.12 Informal Reviews. PMs are encouraged to hold informal reviews, as necessary or as
requested by the Acquisition Manager to discuss and answer questions or action items,
resolve issues and problems, review and discuss hardware, software, and documentation,
and to present results of test or analysis.

5.1.13 Financial Management. PM maintains and management control system that includes
policies, procedures and methods that are designed to ensure that they are in concurrence
with the requirements of DoDI 5000.2, Part II, Section B, Attachment 1. Specific
processors and software management tool characteristics applicable to various efforts are
delineated in the internal Financial Management Planning, Reporting and Monitoring
Process Manual.

5.2 System Engineering Process and Planning. This section describes the system engineering
process to ensure a successful, cost-effective development program. It also provides the
guidelines for effective use of Computer Aided System Engineering (CASE) tools,
models, and simulation to aid the process.

5.2.1 System Engineering Process. The system engineering process recommended is depicted
in Figure 5-5. It is a flexible approach that is adaptable to typical system development
programs and to each component subsystem of these programs.

5.2.2 General Approach. The system engineering process utilities tried and proven techniques.
It is a top down design methodology characterized by an evolutionary iterative and
interactive process. Use of automated systems engineering tools is encouraged. The
emphasis is on commercially available tool sets with new development of models and
simulations only when necessary. New development is accomplished in a manner that
allows easy aggregation into an existing inventory to provide systems solutions. The
approach emphasizes rapid prototyping to allow earlier and more comprehensive design
reviews. The reviews will uncover specification errors and ambiguities in the
development phase where corrections are the least expensive. Finally, the process is
documented. PM requires the maintenance of a System Engineering Analysis Report
(SEAR). The SEAR has the same utility as the engineering notebook has for the
researcher. It provides the necessary engineering traceability. It provides the background
for follow-on investigations and Preplanned Product Improvement (P3I) programs. It can

13
 CONCEPT DEMONSTRATION AND
EXPLORATION VALIDATION PHASE FULL SCALE ENGINEERING PHASE
PHASE
FUNCTIONAL FUNCTIONAL ALLOCATED
ANALYSIS & BASELINE BASELINE
SYSTEM ESTABLISHED ESTABLISHED
DEFINITION
COMPLETE

• PROGRAM MANAGER’S QUARTERLY PROGRAM REVIEW

A A A A A

SYSTEM SYSTEM B B
REQUIREMENTS DESIGN PDR CDR HWCI
REVIEW REVIEW HWCI HWCI FCA
B B
HWCI SYSTEM
A B A A PCA FCA
B
* FORMAL SYSTEM
SYSTEM REQ’TS DRAFT PDR CDR QUALIFICATION PCA
RAPID HWCI CSCI CSCI REVIEW
PROTOTYPE B1 SPEC NO 1 NO 1 FORMAL
REVIEW REVIEW B QUALIFICATION
CSC1 CSCI REVIEW
A C B NO 2 NO 2
B
* CSC1 CSCI SOFTWARE A
NO ‘IV’ NO ‘IV’ FCA
MMI DRAFT DRAFT
RAPID SEGMENT SOFTWARE
PROTOTYPE SYSTEM SPEC SOFTWARE
PRODUCTION
REVIEW A SPEC REVIEW REVIEW PCA
READINESS
REVIEW

A CHIEF ENGINEERING RESPONSIBLE FOR INTERNAL REVIEW/PM FOR EXTERNAL REVIEW MMI – MAN-MACHINE INTERFACE
B PM RESPONSIBILITY HWCI – HARDWARE CONFIGURATION ITEM
C PM RESPONSIBILITY/ACQUISITION MANAGER REVIEW PDR – PRELIMINARY DESIGN REVIEW
CDR – CRITICAL DESIGN REVIEW
* RECOMMENDED ACTIVITIES FCA – FUNCTIONAL CONFIGURATION AUDIT
PCA – PHYSICAL CONFIGURATION AUDIT
CSCI – COMPUTER SOFTWARE CONFIGURATION ITEM

Figure 5-4
14
 ENVIRONMENT
OPS
STEP 2
REQUIREMENTS
REQUIREMENTS/ SUBSYSTEM-A
OPS CONCEPT
EXISTING STEP 1 STEP 3
DEFINITION CSCI-1
MISSION MISSION ANALYSIS
ANALYSIS REVIEW CSCI-2
SUBSYSTEM-M
STEP 4
SCENARIOS
PARAMETRIC CSCI-1
REQUIREMENTS CSCI-2
MISSION ANALYSIS
EFFECTIVENESS MODELS
& SIMULATIONS FUNCTIONAL
IDENTIFICATION
FUNCTIONAL
FUNCTIONAL ALLOCATION
PERFORMANCE
REQUIREMENTS
STEP 3 ANALYSIS
TRADE SUBSYSTEM
STUDIES PERFORMANCE

SCHEDULE RISK
PERFORMANCE
SOFTWARE
HARDWARE
ARCHITECTURE EFFECTIVENESS
ARCHITECTURE
PHYSICAL CONTRAINTS STEP 7
DEFINE SYSTEM
COST ALTERNATIVES
TECHNICAL RISK

STEP 8
EVALUATION
SUBSYSTEM
CANDIDATES
RM&A
ANALYSIS RISK
EFFECTIVENESS ANALYSIS
RISK
LOGISTICS COST LIFE
ANALYSIS CYCLE COST
SUPPORTABILITY ANALYSIS
MANPOWER
MANPOWER GROWTH POTENTIAL
& SKILL LEVEL
ANALYSIS
STEP 8 STEP 9 STEP 10
EVALUATE REQ’TS & PROGRAM
SYSTEM MMI RAPID DEFINITION/
ALTERNATIVE PROTOTYPING SPECIFICATION
MAIN PROCESS FLOW DEVELOPMENT
ITERATIVE PROCESS
SECONDARY FLOW

Figure 5-5. SYSTEM ANALYTICAL ENGINEERING PROCESS

15
 be extremely useful and cost effective for program managers and system engineers
performing similar design initiative.

5.2.2.1 Step 1 – Mission Analysis Review. Review of Mission Analysis, as depicted in Figure 5-
5-5 is defined for a complete System front-end design application. Mission analysis can
be equally applicable to analyzing the requirements for component subsystems,
feasibility of modifying existing systems to meet operational requirements, or
modifications (reliability or performance enhancements) to exiting system. Tasks
associated with these subsets require similar reviews and continue along the same
process, differing only in scope and depth of the numerous supporting analyses. Results
of Step 1 will be documented in the SEAR and summaries will be available for PM
review.

5.2.2.2 Step 2 – Operations Concepts/Requirements Definition. The beginning of the detailed

systems engineering design process commences with the definition of the many
operational concepts to fulfill a proposed mission requirement or profile. The totality of
missions and operational factors are integrated to further define flight profiles, operating
environment, communications, control hierarchy, and recovery responsibilities that
definitive the operational concepts. Further analysis results in the initial system concept
and leads to the development of the top-level requirements. The results of Step 2 shall be
documented in the SEAR and the top-level requirements submitted to PM and/or
Acquisition Manager for review.

5.2.2.3 Step 3 – Function Analysis and Allocation. Function analysis, as indicated, is composed
of two distinct process segments: (1) functional identification and, (2) functional
performance requirement analysis. The basic system engineering tool for functional
identification is the Functional Flow Diagram (FFD) that shows the logical sequences and
relationships between operational and supports functions at the system levels.
Commercially available tools, based on FFD techniques, aid and enhance the process.
Tool selection criteria should include ability to support the functional performance
requirement analysis. The output is then utilized for functional allocation processes.

Step 3 is indicative of the system engineering process at work. It should use

intermediate outputs for multiple purposes.

a) Initially, it should record performance against each function

b) During System Synthesis it records the allocation of functional requirements

to individual subsystem elements or combination of elements

c) Later, it will be used for formulating specification details.

Step 3 is an iterative process. Alternate allocations are made to create subsystem

options. Each option may produce a different operational concept and system
architecture. The output of Step 3, a top level description of the alternative system
architecture. The output of Step 3, a top level description of the alternative system
architecture and the alternative allocations of function to subsystems, shall be
documented in the SEAR.

5.2.2.4 Step 4 – Parametric Analysis. Parametric analysis that includes defining the
interrelationship between key subsystem performance requirements must be conducted

16
 for all the system architectures defined in Step 3. This step evaluates the combinations of
subsystem performance capabilities that can achieve the total system performance. This
step identifies and quantifies all the major performance relationships of the key
subsystems. Data, data sets, and summary graphs for each alternative and concept shall
be documented in the SEAR.

5.2.2.5 Step 5 – Trade-Off Studies. Trade-Off Studies commence during the conduct of
parametric analysis. Subsystem trade-off results are developed for performance versus
design parameters, cost, weight, and other technical performance measures. Parametric
requirements are used to bound the performance range being explored. The emphasis
may be either or subsystem trade-offs, on key subsystem combinations that lead to
modification of older systems, or on new systems. Its goal is to achieve a synergistic
balance between architectures (software and hardware) and subsystem performance
allocations.

Steps 3, 4, and 5 are necessarily highly iterative and highly interactive. The
system engineer must assess the impact on system complexity, cost, physical constraints,
and overall mission effectiveness of the requirement. An awareness of the penalty for not
achieving a particular requirement must be continually present during the process.
Sufficient number of alternative approaches should be visible and documented in the
SEAR to ensure subsystem optimization.

5.2.2.6 Step 6 – Evaluation of Subsystem Candidates. Evaluation of subsystem candidates

begins with defining a preliminary design approach. To the extent possible, the designs
are parametric because subsystem performance requirements should not be set until (1) a
total military system is defined and the combination of subsystem and/or payloads
working together in the different alternatives are known, and (2) the physical constraints
and the technological limitations are computed for a given configuration.

A preliminary evaluation considers performance (as related to parametric

requirements analysis), analysis of system capability (peak and sustaining rates), mission
effectiveness, physical constraints, and costs (development, unit production, and total life
cycle) will be interactive to reducing technical and schedule risks. Measures of Systems
Effectiveness will be developed to serve as evaluation criteria for the multiple interaction
of this step.

5.2.2.7 Step 7 – Define System Alternatives. The system alternatives are the logical combination
of subsystem candidates from a consideration of the evaluation criteria and other relevant
factors, e.g., potential for evolutionary growth.

5.2.2.8 Step 8 – Evaluate System Alternatives. The different alternatives are examined. The
evaluation criteria include but are not limited to mission effectiveness, risk (technical,
costs, and schedule), life cycle cost, supportability (including RMA), manpower
requirements, and growth potential. The evaluation is supported by a series of
documented analyses in the SEAR that include mission effectiveness, risk, life cycle cost,
RM&A, logistics, and manpower (to include skills requirements). The results of steps 6,
7, and 8 are a study report that is documented separately or as an addendum to the SEAR.

5.2.2.9 Step 9 – Requirements and Man-Machine Interface (MMI) Rapid Prototyping. Rapid
Prototyping is a relatively ne but essential element in the system engineering process.
Commercially-available tools are available to use as kernels of an evaluation system that

17
 achieves static and dynamic representations of the requirements. This allows customer
and the design staff to observe and interact with the systems concepts as modeled by the
analytical engineers. Moreover, the output of most models generates the detailed
requirements that become part of the specification. This eliminates the errors and
ambiguities that plague the translation of human ideas into specification language and
conveyance of those ideas to the design engineers.

Interactive with and iterative to the requirements modeling, rapid prototyping

(using commercially available tools) is key to the MMI in a virtual environment. This
will allow human factors and operational specialists to execute the display and control
functions and to influence the specification requirement in the infancy of the design
phase.

Results of the requirements and MMI rapid prototyping demonstration become

major agenda items for Preliminary Design Review (PDR) activities.

5.2.2.10Step 10 – Program Definition and System Specification Development. The final step is
to select the preferred alternative(s) and to define the required development. Programs
that could be effectively evolved into the final system. The product of the process is a
system specification or a set of modifications to the existing system specification.

5.2.3 Decision and Control (D&C) Processing. The typical Project Decision and Control
process is depicted in Figure 5-6. The key characteristic of the process is the orderly
flow down of requirements and the flexibility of options in the implementation. It is
generally the acquisition responsibility to flow down requirements from newly defined or
changing mission and operational requirements to the system requirements. The PM is
responsible to the Acquisition Manager for ensuring that alternatives are identified and
appropriately evaluated during that process. The Acquisition Manager will involve the
appropriate working groups for assistance in the Centers of Excellence, and operations
groups for assistance in the identification and evaluation process. Once decided, the
requirements will be flowed down to the contractor for implementation.

5.2.4 Interoperability Process. Interoperability, is assured through control of the mission

critical interfaces in each system. Precise definition of the System Integration Interfaces
(SIIs) early in the Program is essential to this process. The interoperability process will
be managed by the PM or SETA, who will coordinate with the Project Mangers or the
Acquisition Mangers Program Steering Group to define the SIIs. In addition, SIIs are
fabricated and validated in accordance with the SII documentation. The PM/SETA is
accountable for the proper performance of each SII.

5.2.5 Systems Modeling and Simulations. The PM shall develop and maintain a system
modeling and simulation capability that can be used to determine mission and system
performance effectiveness.

The individual component system Project Managers develops or acquires and

maintains modeling and simulations capability to perform the following analytical tasks:

• Rapid Prototyping of Systems Requirements and Architectures

• Rapid Prototyping of the Control System(s) Man-Machine Interfaces
• Parametric Requirements Analysis

18
 MISSION OPERATIONAL
REQ’TS REQ’TS

FUNCTIONAL
REQ’TS

OPERATIONAL
EXPERIMENTS
CRITICAL
PERFORMANCE REQ’TS

INTEROPERABILITY
TOP LEVEL
SUBPROCESS
SPEC

PROGRAM SIIs ICWG/CM

STEERING GROUP PROCESS

SYSTEM
CHARACTERISTIC WBS

NEW MODIFICATION NEW

APPLICATION DECISION DEVELOPMENT
DECISION DECISION

APPLICATION DEVELOPMENT TOP LEVEL SPEC

EVALUATION PROGRAM CHANGE

PRODUCTION TEST SII

PLANNING PROGRAM CHANGE

PRODUCTION TAILORED
DECISION PROGRAM

INDUSTRY/GOVERNMENT LABS DEVELOPMENT

TECHNOLOGY INFUSION PROGRAM

TEST
PROGRAM

PRODUCTION
DECISION

Figure 5-6 TYPICAL PROJECT D&C

19
 • Engineering Trade Studies
• System Control Algorithm Development
• System Flight Analysis
• System Test Analysis
• L-C-C Estimating
• Reliability and Maintainability Analyses
• Spares Computational Analysis.

The PM shall make the models and simulations available (if requested) to the
Acquisition Manager or his designate agent to allow aggregation for total system
analysis.

5.2.6 Specification Development. Specifications shall be prepared in accordance with MIL-

STD-490A, DoDD 4120.3, and DoD 4120.3M. Specification Tailoring is encouraged.
The PMs shall be responsible for ensuring that only the requirements that are truly
necessary will be imposed by the individual contracts.

5.3 Specialty Engineering Integration. This paragraph defines how the specialties
engineering of logistics, quality assurance, reliability, maintainability, human
engineering, system safety, and other areas are integrated into the mainstream design
effort. Figures 5-7 and 5-8 depict the processes for ensuring early influence of specialty
engineering on design process.

5.3.1 Logistics Engineering. Integrated Logistic Support (ILS) is the composite of all the
support considerations necessary to ensure the effective and economical support of a
system, subsystem or component over its life cycle. This includes the principle logistic
personnel, support and test equipment, facilities, transportation sand handling, and
technical data. This also includes the logistics management activities required to
implement the logistics engineering concepts, funding, policies, and procedures
formulated through logistics engineering efforts during the system design development
phase. Typical Table 5-1 summarizes the major ILS activities and delineates the division
of responsibilities between Acquisition Manager and the Program Manager. The
program manager’s responsibilities are subject to authorization (or delineating of
responsibility) by the acquisition manager.

5.3.2 Quality Assurance.

5.3.2.1 Program Quality Assurance Requirements. The PM plans establish, implements and
maintains a Quality Assurance Program Plan. The Quality Assurance Program Plan
reflects the guidance of MIL-S-52779, MIL-Q-9858, and MIL-STD-2167. The plan
provides guidelines for PM Quality Assurance program and defines quality
responsibilities for participation in scheduled management and technical reviews, and in
support of the preparation of System test plans, test procedures, and specifications.
Details are provided in the SB Quality Assurance Process Manual.

5.3.2.2 System PM Quality Assurance Requirements. The System PM establishes and maintains
a comprehensive Quality Assurance Plan and documented Policy Papers. MIL-Q-9858 is
used for supplemental guidance. The PM implements Total Quality Management (TQM)
principles throughout the life of his cognizant program. Special care is taken to ensure
the use of TQM principles by contractors as described in the TQM principles by

20
 MISSION FUNCTIONAL PARAMETRIC
ANALYSIS ANALYSIS REQUIREMENTS
REVIEWS AND ANALYSIS
ALLOCATION

SYSTEM
TRADE SUBSYSTEM
STUDIES PERFORMANCE

SPECIALTY ENGEERING INPUT

• ENGINEERING
• RISK ANALYSIS
HARDWARE SOFTWARE • RM&A ANALYSIS
ARCHITECTURE ARCHITECTURE • L-C-C ANALYSIS
• LOGISTICS ANALYSIS

SUBSYSTEM
DESIGN
MISSION EFFECTIVENESS & SPECIALTY ENGINEERING INPUT
MODELS SIMULATIONS
SCHEDULE RISK RISK ANALYSTS/PRODUCIBILITY ANALYSTS/ACQUISITION MGMT
SYSTEMS ANALYSTS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS
PERFORMANCE SYSTEMS ANALYSTS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS
EFFECTIVENESS INSTALLATION SPEC/MARINE ENGRS/EMC ENGRS/SAFETY ENGRS
COST ANALYSTS
PHYSICAL CONTRAINTS
SYSTEMS ANALYSTS/RISK ANALYSTS/RMA ENGRS/LOGISTIC ENGR
COST
TECHNICAL RISK

EVALUATION
EQUIPMENT RM&A
DESIGN TECHNOLOGY RISK
APPROACHES
PRODUCIBILITY
COST SPECIALTY ENGINEERING INPUT
SUPPORTABILITY
RMA ENGR/LOGISTIC ENGR/SYSTEM ANALYSTS
EFFECTIVENESS SYSTEM ANALYSTS/RESEARCH ENGR/LOGISTICIANS
MANUFACTURING ENGR/LOGISTICIANS/SYSTEM ANALYSTS
PSI PLAN
COST ANALYSTS/ACQUISITION MGMT
LOGISTICS ANALYSTS/TRAINING SPEC/OPS SPEC
SYSTEM ANALYSTS/OPS SPECIALISTS
EVALUATE SYSTEMS ANALYST/LOGISTICIANS/ACQ MGMT
DESIGN
DETAILS

SYSTEM
DESIGN SPECIALTY ENGINEEERING INPUT

SYSTEMS ANALYSTS/OPERATIONAL SPECIALISTS

REQUIREMENTS LOGISTICS ENGR/RISK ANALYSTS
RAPID QA/CM/DM/TEST ENGR
PROTOTYPING LOGISTICS, CM/DM, TEST ENGR
BRASSBOARDS
RMA ENGR, ACQ MGMT, OPS SPECIALISTS
NDI
DEMOS
SEGMENT DESIGN REVIEWS
FUNCTIONAL COMPONENT DESIGN PROCESS TEAM MGRS/LOGISTICS/RMA
RISK ANALYSTS/SYSTEM ANALYSTS
EDM
BUILDING
TRANSITIONAL DESIGN REVIEW (ENGR TO PRODUCTION)
EDM TEST & EVALUATION LOGISTICS/MANFACTURING/PRODUCTION
PRODUCIBILITY ENGR/ACQ MGMT

Figure 5-7. Process for Early Specialty Engineering Influence into

System Design (Hardware Specific)
21
 MISSION FUNCTIONAL PARAMETRIC
ANALYSIS ANALYSIS REQUIREMENTS
REVIEWS AND ANALYSIS
ALLOCATION

SYSTEM
TRADE SUBSYSTEM
STUDIES PERFORMANCE

SPECIALTY ENGEERING INPUTS

• ENGINEERING
• RISK ANALYSIS
HARDWARE SOFTWARE • RM&A ANALYSIS
ARCHITECTURE ARCHITECTURE • L-C-C ANALYSIS
• LOGISTICS ANALYSIS

SUBSYSTEM
DESIGN
MISSION EFFECTIVENESS & SPECIALTY ENGINEERING INPUTS
MODELS SIMULATIONS
SCHEDULE RISK RISK ANALYSTS/PRODUCIBILITY ANALYSTS/ACQUISITION MGMT
SYSTEMS ANALYSTS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS
PERFORMANCE
SYSTEMS ANALYSTS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS
EFFECTIVENESS INSTALLATION SPEC/MARINE ENGRS/EMC ENGRS/SAFETY ENGRS
COST ANALYSTS
PHYSICAL CONTRAINTS
SYSTEMS ANALYSTS/RISK ANALYSTS/RMA ENGRS/LOGISTIC ENGR
COST
TECHNICAL RISK

SPECIALTY ENGINEERING INPUTS

EVALUATION MANPOWER/SKILLS/TRAINING ANALYSTS

SUBSYSTEM MANPOWER
RISK ANALYSTS/ACQUISITION MGMT
CANDIDATES RISK COST ANALYSTS/RISK ANALYSTS
COST LOGISTICS/RMA/SAFETY ENGRS
SYSTEM ANALYSTS/OPERATIONS SPECIALIST
SUPPORTABILITY
EFFECTIVENESS
GROWTH POTENTIAL

EVALUATE
SYSTEM
ALTERNATIVE

SYSTEM
DESIGN SPECIALTY ENGINEEERING INPUT

SYSTEMS ANALYSTS/OPERATIONAL SPECIALISTS

REQUIREMENTS LOGISTICS ENGR/RISK ANALYSTS
RAPID QA/CM/DM/TEST ENGR
PROTOTYPING HUMAN ENGINEERINGS/OPERATIONAL SPECIALISTS
MAN-MACHINE INTERFACE
TRAINING SPECIALISTS/MAINTAINABILITY ENGRS
NDI
DEMOS/
DESIGN TRANSITIONAL REVIEW(S)
APPROVAL (DESIGN TO SOFTWARE DEVELOPMENT)

PROGRAM DEFINITION/IRSs/ SYSTEM DESIGN/SOFTWARE DESIGN

DEVELOPMENT SPECIFICATION(S) QA/CM/DM/RISK MGMT
APPROVAL ACQUISITION MGMT/TEST ENGRS

FULL SCALE ENGINEERING DEVELOPMENT

Figure 5-8. Design Phase (Software Intensive System Specific)

22
 Table 5-1. Integrated Logistic Support

REQUIREMENT ACQUISITION MANAGER PM RESPONSIBILITY

RESPONSIBILITY

LS Planning Ensure establish ILS Directorate Designate ILS manager; ensure each
Responsibilities contractor has appointed ILS Manager with
sign-off authority equal to engineering and
production managers

Develop an Integrated Support Plan Develop and ILS Plan (ILSP) for
(ISP) to provide ILS Planning implementing Project Manager and
guidelines over the entire life cycle; subcontractor responsibilities
establish the ILS/System
Engineering Iterative, Interactions

Maintain centralized logistic Develop a logistics requirements in

support cost data file for the accordance with WBS as part of ILSP and
program; reporting format to be forward reports monthly to Acquisition
defined in the ISP Manager

Encourage CALS technology usage Establish a management process to encourage

as delineated in DoDI 5000.2, Part use of CALS technology
6, Section H

Logistic Support Coordinate task ILS Directorate to Organizational and intermediate level LSA
Analysis (LSA) Requirements tasks

LSA guidance; establish the MIL-STD-1388-1A define tasks: LSA Plan;

LSA/System Engineering Linkages reviews; mission hardware; S/W and support
system standardization; LOR program; task
analysis, early fielding assessment;
supportability assessment

Establish and maintain a validated Require use of a validate LSAR automatic

LSA Record (LSAR) automated data processing system compatible with the
data processing system Acquisition Manager’s System

Maintenance Develop depot level maintenance Organizational and intermediate level tasks
Planning Program requirements from the LSA process using LSA/LORA process
• Identify miniature/microminiature
repair capability requirements
• Demonstrate (by analysis) fault
detection, fault isolation, and fault
localization capabilities
• Identify Maintenance Assist
Modules (MAMs)

23
 Table 5-1. Integrated Logistic Support (Continued)

REQUIREMENT ACQUISITION MANAGER PM RESPONSIBILITY

RESPONSIBILITY

Maintenance • Identify use of Standard

Planning Program Electronic Modules (SEMs)
(Cont’d)

Manpower and Provide guidelines Demonstrate that LSA documented manpower

Personnel and personnel levels are commensurate with
operational and maintenance requirements

Perform HARDMAN analysis

Training and Provide Training Plan guidelines Develop training plan using HARDMAN
Training Support analysis and LSA
Provide the Training/Systems
Engineering Linkages Develop training course in accordance with
MIL-STD-1379

Provide factory training as authorized

Supply Support Provide guidelines Prime responsibility for procuring and

maintaining supply support before
Provide the System Engineering- transitioning the service supply support
Support System Linkages activity

Technical Manuals Establish requirements Develop and validate technical manuals

contractors as described in the TQM (often considered CPI) and Subcontractor Control
Templates of DoD Manual 4245.7M.

5.3.3 System Safety. The PM develops and implements with Acquisition Manager approval
Safety Program Plan in general compliance with MIL-STD-882.

• PM maintains system safety data files available to and compatible with Acquisition
Manager’s requirements,
• Maintains a system safety report database available to and compatible with
Acquisition Manager’s requirement, Subsystem or Component Hazard Safety
Analysis responsibilities are included,
• System Hazard Analysis of Test Configuration is generally the responsibility of the
PM (Task 204) with Acquisition Managers assistance, if required,

24
 • Operating and Support Hazard Analysis (O&SHA) is generally the responsibility of
System PM,
• Software Requirements Hazard Analysis, responsibility of the PM, to include Hazard
Analysis of (1) Top Level Design, (2) Detailed Design, (3) Code Level, (4) Software
Testing, (5) Software User Interface, and (6) Software Safety changes,
• A Fault Tree Analysis, to be conducted to identify all failure modes contributing to
an undesired event, is generally the responsibility of System PM
• Acquisition Manager generally establishes a System Safety Working Group as
detailed in MIL-STD-882 (task 104).

5.3.4 Human Engineering (HE). PM develops a Human Engineering Program Plan in

accordance with DoDI 5000.2, Part 6, Section H Human Factors which provides general
HE requirements and is readily tailored to meet specific system requirements. PMs
develop appendices to address the specifics unique to their programs.

5.3.5 Reliability, Maintainability, and Availability (RMA). The PM establishes effective

RM&A Engineering “By Design” efforts in accordance with Acquisition Policy Papers.
The program includes the additional guidance provided by MIL-STD-470, MIL-STD-
785, DoD-STD-2167, and DoD Manual 4245.7M. Testability efforts in accordance with
MIL-STD-2165 are considered within the RMA requirement scope.

5.3.5.1 Failure Reporting, Analysis, Corrective – Action System (FRACAS) and Test Analysis
and Fix (TAAF) Program. PM establishes FRACAS and TAAF Programs. Failure
collection and recording commences with either first functional hardware test or first
formal software and continues through production. Data collection, analysis, and
correction requirements for Maintainability and Testability efforts are integrated with
FRACAS and reported at all Failure Review Board Meetings. All software and hardware
failures are used to determine the maturity of System Reliability and all test activities are
monitored and failures subjected to analysis to determine the effectiveness and adequacy
of BIT/BITE and to identify corrective actions in both design and production.

5.3.5.2 Models and Prediction. PM develops and maintains reliability (MIL-STD-756 Tasks 102
and 104 provide guidance) and maintainability (derived from the Reliability Model to
address Organizational Level maintenance) models. A method for allocating reliability
and maintainability to lower levels shall be evident in the processes. Reliability
predictions are accomplished in accordance with MIL-STD-756 and Maintainability in
accordance with MIL-HDBK-472. Predictions are continuously updated and integrated
into the LSA process.

25