Document # Date Effective

nd
LAT-MD-00066-01 3 Draft 1/23/01
Prepared by(s) Supersedes
Tim Thurston None
GLAST LAT PROJECT Warren Davis
Subsystem/Office
MANAGEMENT PLAN Systems Engineering
Document Title
LAT Systems Engineering Management Plan

Gamma-ray Large Area Space Telescope

(GLAST)
Large Area Telescope (LAT)
Systems Engineering Management Plan
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 2 of 29

CHANGE HISTORY LOG

Revision Effective Date Description of Changes DCN #

1 Initial Release LAT-CN-000xx
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 3 of 29

CONTENTS

1 Purpose and Scope .......................................................................................................... 5

2 Acronyms ........................................................................................................................ 5
3 Applicable Documents .................................................................................................... 6
4 Systems Engineering Process.......................................................................................... 7
4.1 Organizational Responsibilities and Relationships................................................. 7
4.2 Systems Engineering Process Planning .................................................................. 8
4.2.1 Major Systems Engineering Products ................................................................. 8
4.2.2 Technical Objectives ......................................................................................... 10
4.2.3 Work Breakdown Structure............................................................................... 10
4.2.4 Work Authorization .......................................................................................... 10
4.2.5 Verification: Integration and Test Plans ........................................................... 11
4.2.6 Participants........................................................................................................ 11
4.3 Requirements Analysis.......................................................................................... 12
4.3.1 Flowdown.......................................................................................................... 12
4.3.2 Engineering Considerations .............................................................................. 12
4.3.3 Allocated Requirements .................................................................................... 12
4.3.4 Review Process ................................................................................................. 13
4.4 System Analysis .................................................................................................... 13
4.4.1 Trade Studies..................................................................................................... 14
4.4.2 Cost Effectiveness Analyses ............................................................................. 14
4.5 System Control...................................................................................................... 14
4.5.1 Risk Management.............................................................................................. 14
4.5.2 Configuration Management .............................................................................. 15
4.5.3 Interface Management....................................................................................... 15
4.5.4 Technical Performance Metrics (TPMs)........................................................... 15
4.5.5 Technical Reviews ............................................................................................ 16
4.5.6 Supplier Control ................................................................................................ 17
4.5.7 Requirements Traceability ................................................................................ 17
5 Implementation ............................................................................................................. 18
5.1 Integration of Systems Engineering Effort ........................................................... 18
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 4 of 29

5.2 Problem Resolution............................................................................................... 18

5.3 Systems Engineering Plans and Specifications..................................................... 18
6 Other Systems Engineering Activities .......................................................................... 19
6.1 Long Lead Items ................................................................................................... 19
6.2 Engineering Tools ................................................................................................. 19
6.2.1 Requirements Management Software ............................................................... 19
6.2.2 Database Software............................................................................................. 20
6.2.3 Forms................................................................................................................. 20
APPENDIX A ....................................................................................................................... 21
LAT Level III Specification Review/Release Description and Charge ............................ 21
APPENDIX B ....................................................................................................................... 25
Technical Review Definitions and Checklists ...................................................................... 25
System Requirements Review (SRR) ............................................................................... 25
Preliminary Design Review (PDR)................................................................................... 26
Critical Design Review (CDR) ......................................................................................... 27
Test Readiness Review (TRR) .......................................................................................... 28
Pre-Shipment Readiness Review (PSRR)......................................................................... 29
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 5 of 29

1 Purpose and Scope

This Systems Engineering Management Plan (SEMP) describes the activities, processes,
and tools that will by used by the GLAST Large Area Telescope (LAT) Systems Engineering team
to support the design and construction of the LAT instrument and Instrument Operations Center.
The objective of the Systems Engineering effort is to assure successful development of the LAT
system primarily by defining clear and accurate system requirements and verifying compliance of
the system to those requirements.
The LAT system consists of the Science Instrument (SI) and the Instrument Operations
Center (IOC). The SI is a space-borne detector capable of measuring the direction and energy of
incident cosmic gamma rays. The IOC is the ground-based facility that controls the operation of
the SI and records and processes its raw data.
This SEMP is applicable to all Systems Engineering tasks to be performed in support of the
LAT project. This document will be placed under change control upon its initial release.

2 Acronyms
ACD – Anticoincidence Detector
CAL – Calormeter
CCB – Change Control Board
CDR – Critical Design Review
CEA – Commissariat à l'Energie Atomique
CMP – Configuration Management Plan
DAPNIA – Département d'Astrophysique, de physique des Particules, de physique
Nucleaire et de L’Instrumentation Associée
E/PO – Education and Public Outreach
GLAST – Gamma-ray Large Area Space Telescope
GSFC – Goddard Space Flight Center
IN2P3 – Institut National de Physique Nucleaire et de Physique des Particules
INFN – Istituto Nazionale di Fisica Nucleare, Italy
IOC – Instrument Operations Center
IPI – Instrument Principal Investigator
IPM – Instrument Project Manager
IPO – Instrument Project Office
ISE – Instrument Systems engineer
KTH – Royal Institute of Technology, Sweden
LAT – Large Area Telescope
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 6 of 29

LOF – LAT Operations Facility

NRL – Naval Research Laboratory
PAIP – Product Assurance Implementation Plan
PAPL – Program Approved Product List
PDR – Preliminary Design Review
PER – Pre-Environmental Review
PFR – Problem/Failure Report
PSR – Pre-Shipment Review
RMP – Risk Management Plan
SAS – Science Analysis Software
SEMP – Systems Engineering Management Plan
SI – Science Instrument
SLAC – Stanford Linear Accelerator Center
SRR – System Requirements Review
SSAC – Senior Scientist Advisory Committee
SSRR – Subsystem Requirements Review
SSU – Sonoma State University
SU – Stanford University
SU-HEPL – Stanford University High Energy Physics Lab
T&DF – Trigger and Dataflow
TKR – Tracker
TPM – Technical Performance Metric
UCSC – University of California at Santa Cruz
WBS – Work Breakdown Structure

3 Applicable Documents
The following documents are applicable to the development of this SEMP.
GLAST00110, “Mission Assurance Requirements (MAR) for Gamma-Ray Large Area Telescope
(GLAST) Large Area Telescope (LAT)”, June 9, 2000
GEVS-SE Rev A, “General Environmental Verification Specification for STS & ELV Payloads,
Subsystems, and Components”, http://arioch.gsfc.nasa.gov/302/gevs-se/toc.htm
“GLAST Large Area Telescope Flight Investigation: An Astro-Particle Physics Partnership
Exploring the High-Energy Universe”, proposal to NASA, P. Michelson, PI, November, 1999.
 LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 7 of 29

4 Systems Engineering Process

4.1 Organizational Responsibilities and Relationships

The LAT team consists of members from several geographically diverse organizations and
is managed by the LAT Instrument Project Office (IPO) at Stanford Linear Accelerator Center
(SLAC). The Instrument Systems engineer (ISE), who is part of the IPO and reports to the
Instrument Project Manager (IPM), manages and is responsible for the systems engineering
activities. The organizational structure of the LAT collaboration is shown in Figure 1.
The ISE provides technical leadership and directs the work of the subsystem development
teams through the development and tracking of requirements, reserves, interface control
documents, and performance and verification specifications. The ISE is responsible for assuring
that the subsystems are compatible and meet the overall objectives. The ISE also oversees, from
the instrument side, all aspects of the spacecraft/instrument interfaces.

E/PO Collaboration
SSU Principal Investigator Science Team
(IPI)
SU
Instrument Scientist SSAC
GSFC GSFC

Project Manager (IPM) Instrument Design Team

IPO SLAC SLAC

System Engineer Project Controls

(ISE) SLAC
SLAC

Electronics & DAQ Integration & Test

SLAC SLAC

Mech. Systems Performance & Safety

SLAC Assurance
SLAC

TKR CAL ACD IOC Sci. Software

UCSC, SLAC, NRL, France, GSFC SU SLAC
Italy, Japan Sweden

Figure 1: LAT Organization Chart

LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 8 of 29

The subsystem organizations provide support to the project systems engineering effort
through development of subsystem level specifications and test plans and overseeing the
subsystem-level verification process.

4.2 Systems Engineering Process Planning

This section describes the key components of the LAT systems engineering process,
including the major systems engineering products, technical objectives, work breakdown structure,
requirements verification, and engineering participants.

4.2.1 Major Systems Engineering Products

4.2.1.1 Integrated Database

Throughout the design phase of the LAT project, many studies and analyses will be
conducted to support decisions regarding requirements selection and system design. The collection
of these reports effectively documents the process of defining the LAT system and will be archived
for future reference. As requirements and specifications are recorded in the requirements database,
they will be linked to the applicable analyses to provide traceability to the rationale for the
requirements. By providing the original context in which a requirement was selected, any future
reconsideration of the requirement can determine if the original constraints are still valid.

4.2.1.2 Baselines
Throughout the lifecycle of the project, the LAT system configuration is defined in a series
of technical baselines, consisting of the approved documentation used to define the technical
requirements and interfaces. These baselines define the characteristics of the LAT system,
subsystems, software and equipment at different development stages of the project. The technical
baseline progresses from high-level requirements (the Functional Baseline) to more detailed
requirements, design drawings and specifications (the Allocated Baseline) to complete “as-built”
manufacturing drawings and specifications (the Product Baseline).
Specifications, interface control documents, and drawing packages are used to design and
fabricate or procure items. These baseline documents will be organized in a hierarchy that provides
design traceability to the lowest level. Once approved, these baseline documents are placed under
configuration control, as described in the Configuration Management Plan (CMP).

4.2.1.3 Specifications
The planned specification tree, Figure 2, shows the allocation of specifications to the
functional units of the LAT organization. The specification tree also represents the flow of
requirements from the top-level mission requirements to increasingly detailed requirements for the
subsystems.
The specifications are grouped into levels within the context of the GLAST project. The
LAT instrument and IOC are two elements of the GLAST system. The high-level mission
specifications are developed by the GLAST Project Office. The levels of specifications developed
and controlled by the LAT Project are:
• Elements, Level II(b): The Level II(b) specifications contain the high-level
performance requirements for the SI and IOC. These specifications are the
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 9 of 29

responsibility of the ISE. Changes to these specifications require approval of the

Configuration Control Board (CCB) and GSFC.
• Subsystems, Level III: The Level III specifications define the requirements of the
SI and IOC subsystems and components. These specifications are developed by the
Subsystem Managers, but are controlled and approved by the ISE. Changes to the
Level III specifications require approval of the CCB.
• Lower Levels: Lower-level specifications, not shown in Figure 2, describe
individual items that are part of the subsystems. They are the responsibility of the
Subsystem Managers and, once released, are controlled by the IPO. Changes to
lower-level specifications require approval of the responsible Subsystem Manager.
Project Specifications
Level I

Program Plan
Requirements

Operations Concept Science Req’ts

Level II(a) System

Document Document
GLAST00089 GLAST00010

Mission Assurance Mission System

Requirements Specification
GLAST00110 GLAST00074
Level II System Specifications

Spacecraft LV Interface SC-SI Interface GBM Instrument

Performance Spec. Specification Specification Performance Spec.
GLAST00038
Level II(b) Element

LAT Instrument SGL Comm Inter-Center GBM IOC

Performance Spec. Interface Spec. Interface Spec. Specification
LAT-SS-00010

Science Support Mission Operations LAT IOC

Center Spec. Center Spec. Performance Spec.
LAT-SS-00015
Subsystem Specifications

LAT - ACD Spec. LAT - TKR Spec. LAT - CAL Spec. LAT SAS Spec.
Level III

LAT-SS-00016 LAT-SS-00017 LAT-SS-00018 LAT-SS-00020

T&DF Spec. Aux. Subsystem Spec. LAT Interface Spec. LAT IOC Spec.
LAT-SS-00019 LAT-SS-000xx LAT-SS-000xx LAT-SS-00021

Document under control of the LAT Project Document not under control of the LAT Project

Figure 2: Specification Tree

LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 10 of 29

4.2.2 Technical Objectives

The technical objectives of the GLAST mission are described in the Science Requirements
Document. The objective of the systems engineering process is to assure that the LAT system
meets all the requirements that flow down from the mission objectives.

4.2.3 Work Breakdown Structure

The work breakdown structure (WBS) is a hierarchical tree-like depiction of the system
development activities as they relate to the LAT system architecture. The WBS provides a
coordinated and complete view of the LAT Project and is useful for technical systems engineering
and non-technical program management activities. The initial WBS has already been developed
for the Formulation Phase and the Implementation and Operations Phases of the project. The
structure of the WBS is shown in Figure 3. For a detailed description of the WBS elements down
to the fourth level, see the LAT proposal, Volume 2, Appendix F. This WBS will be maintained
and updated by the IPO with support from the ISE.
The WBS is used by Systems Engineering to aid in:
• Identifying products, processes, data and documents.
• Organizing risk management analysis and tracking.
• Implementing configuration management and control of subsystem interfaces.
• Organizing technical reviews and audits.

Level 1 LAT System

Level 2

IPO and System-Level Hardware Subsystems Instrument-Level

Science Functional Groups

Instrument Management Tracker Integration and Test

System Engineering Calorimeter Performance and Safety Assurance
Science Anticoincidence Detector Instrument Operations Center
Trigger and Dataflow Education and Public Outreach
Level 3 Grid

Figure 3: Work Breakdown Structure

4.2.4 Work Authorization

The WBS defines the limits of individual responsibility for work efforts. The method for
authorizing work within the LAT Project is defined in the Project Management Plan.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 11 of 29

4.2.5 Verification: Integration and Test Plans

Subsystems will undergo a subsystem-level test program to verify that the units meet all
subsystem requirements prior to delivery to SLAC for integration into the system. The Subsystem
Managers are responsible for developing the test plans.
The integrated instrument will undergo a system-level test program. The development of
the system-level Integration and Test Plan is primarily the responsibility of the Integration and Test
Manager.
Systems Engineering will review the test plans to assure that the requirements are
sufficiently verified and that the test plans conform to the GLAST Project requirements contained
in the Mission Assurance Requirements and General Environmental Verification Specification
documents.

4.2.6 Participants
The systems engineering process will involve coordinating the engineering efforts of
various institutions as they design and implement subsystems that will be integrated into a
complete system at SLAC. The primary technical contact for a subsystem will be the Subsystem
Manager. The engineering participants in the LAT Project are shown in Table 1.

Table 1: Participating Institutions

Institution Areas of Responsibility
SLAC Instrument systems engineering; electrical system engineering;
TKR: mechanical design, construction, testing, integration;
Grid development;
Software management;
Instrument integration and test;
T&DF: engineering support
SU-HEPL T&DF subsystem development; IOC
GSFC ACD; thermal blankets; micrometeorite shield
NRL CAL: digital electronics and integration and test;
T&DF: DAQ/CPU, DAQ/DSF, S/C Interface Unit
CEA/DAPNIA, France CAL: front-end photo-diodes and electronics readout
IN2P3/France CAL: mechanical design and assembly; CAL and instrument simulation
KTH, Stockholm Univ. CAL: CsI crystals
UCSC TKR: electronics, mechanical design, assembly, testing
JGC, Japan TKR: silicon-strip detectors
INFN, Italy TKR: silicon-strip ladders and tray assembly
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 12 of 29

4.3 Requirements Analysis

Requirements analysis is the iterative process of transforming the mission objectives into a
set of requirements that define the characteristics and functions of the system and specify the
environment in which it must perform. The process is iterative because as the design of the system
progresses, further system analyses result in better understanding of the system and should prompt
a reconsideration of the system requirements.

4.3.1 Flowdown
The requirements analysis process involves transforming the mission objectives into high-
level performance requirements and then further refining those requirements into lower-level
performance requirements and design specifications.
The LAT system requirements flow down from the GLAST mission requirements. The
primary sources of the LAT requirements are:
• The GLAST Science Requirements Document
• The GLAST Science Instrument-Spacecraft Interface Requirements Document
• The Mission Assurance Requirements Document
• The General Environmental Verification Specification
• Derived Requirements
The high-level mission requirements and the GLAST performance verification
requirements are transformed into performance specifications for the LAT instrument and IOC.
These specifications are captured in the Level II(b) specifications, namely, the LAT Performance
Specification and the LAT IOC Performance Specification. These documents undergo extensive
review by the LAT team and are put under configuration management early in the Formulation
Phase.
The subsystem-level performance and design requirements will flow down from the Level
II(b) performance specifications. The flowdown of requirements will be documented and tracked
using a requirements management software tool. The LAT requirements database will interface
with the GLAST database, providing requirements traceability from the highest to lowest levels.

4.3.2 Engineering Considerations

The reliability, maintainability and supportability of the system as well as other human
factors should be considered when developing and analyzing the LAT requirements. This is to
ensure that the system will meet its performance requirements over its lifetime and in its operating
environment and that it can be logistically supported, operated, and maintained at the intended level
of skill and training.

4.3.3 Allocated Requirements

Some system parameters, such as mass, power usage, and physical dimensions, must be
distributed among the subsystems in order to meet the overall system requirements. The allocation
of these parameters is assigned by the IPO and is imposed on the subsystems through the
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 13 of 29

subsystem (Level III) specifications. The requirements analysis process will verify that
requirements are correctly allocated to the subsystems.

4.3.4 Review Process

All requirements documents will be subject to review by the appropriate LAT team
members prior to initial release. The reviewers are responsible for verifying that the higher-level
requirements are satisfied. The reviewers should also verify that the requirements have the
following attributes:
• Achievable – the requirement must be technically achievable within the allotted
schedule and budget constraints.
• Verifiable – the requirement must be expressed in a way that is verifiable by an
objective test or analysis.
• Unambiguous – the requirement must have only one possible meaning.
• Complete – the set of requirements must contain all the information necessary to
successfully meet the mission objectives, including mission profiles, environments
(including ground, handling and on-orbit environments), operational and
maintenance concepts and interface constraints.
• Consistent – each requirement must not conflict with another requirement.

4.3.4.1 Specification Reviews – Level III

Each Level III specification will be subject to a formal instrument-level review that is
coordinated by the ISE. Since the Level III specifications establish agreement between the IPO and
the responsible subsystem organizations on the high-level performance and interface requirements
that the subsystems must meet, it is important that these specifications undergo thorough review by
all Subsystem Managers and representatives of the IPO prior to initial release.
The Level III Specification review process and the charge for the Review Board are
described in detail in Appendix A.

4.3.4.2 Specification Reviews – Level IV and Lower

All Level IV and lower specifications should be reviewed by personnel within the
subsystem organizations before they are submitted for initial release. The Subsystem Managers are
responsible for reviewing and approving the specifications and submitting them to the IPO to be
placed under configuration management.

4.4 System Analysis

System analysis is the process of evaluating the system and documenting data and
decisions. System analysis activities support all steps of the systems engineering process and
provide a quantitative basis for selecting performance, functional, and design requirements. All
LAT system analyses will be documented and archived.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 14 of 29

4.4.1 Trade Studies

System analysis uses trade studies to support decisions about requirements selections and
design alternatives. These trade studies target performance drivers and constraints from the limited
resources, such as mass, power and dimension. Certain trade studies may also address increased
margins in power and reliability as well as ease of fabrication and testing.

4.4.2 Cost Effectiveness Analyses

Cost effectiveness analyses are used to provide economic balance to the systems
engineering decision-making process. Cost effectiveness analyses weigh the total cost of design
alternatives against their effectiveness in order to determine the relative value of solutions. These
analyses attempt to capture all short-term and long-term costs associated with an item. The
potential costs and effectiveness parameters to be considered in the analyses are listed in Table 2.
Table 2: Cost Effectiveness Parameters

Life-Cycle Costs System Effectiveness Parameters

• Research, design, and • System performance

development cost
• Availability, reliability,
• Construction cost supportability
• Production cost • Producability
• System operation cost • System quality
• Maintenance and support cost • Disposability
• Retirement and disposal cost • Other technical factors

4.5 System Control

System control is the collection of methods used to manage the project configuration, risk,
and subsystem and external interfaces, as well as to track both the LAT system performance and
the progress of the system development.

4.5.1 Risk Management

Risk management will be included as part of the system control process to accomplish the
following objectives:
• Identify the potential sources of risk and identify risk drivers.
• Quantify risks and assess their impacts on cost, schedule and performance.
• Determine the sensitivity of these risks to program, product and process
assumptions, and the degree of correlation among the risks.
• Determine and evaluate alternative approaches to mitigate moderate and high risks.
• Take actions to avoid, control, assume or transfer each risk, and
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 15 of 29

• Ensure that risk is factored into decisions on selection of specification requirements

and solution alternatives.
The risk management process for the LAT Project is described in detail in the LAT Risk
Management Plan.

4.5.2 Configuration Management

Systems engineering will exercise control of the LAT system design and fabrication
through configuration management. The objective of configuration management is to ensure that:
• Baselines are defined and documented
• Documentation is identified, released and controlled
• The Configuration Control Board (CCB) is established and functions according to
CMP guidelines
• Changes to the baseline are evaluated and controlled
• Approved configuration changes are implemented and tracked
• Configuration status accounting is accomplished
Configuration management is the responsibility of the Instrument Program Manager, but is
coordinated by the Instrument Systems Engineer. The configuration management process is
described in detail in the LAT Configuration Management Plan.

4.5.3 Interface Management

The interfaces between LAT subsystems will be defined in the LAT Subsystem Interface
Requirements Document. This document imposes the interface requirements on the subsystems.
Changes to this document must be approved by the Configuration Control Board.
The LAT external interfaces are controlled by the GLAST Science Instrument-Spacecraft
Interface Requirements Document. The LAT external interface requirements cannot be changed
unless approval is granted by the GSFC Project Office.

4.5.4 Technical Performance Metrics (TPMs)

The IDT will establish a set of TPMs to track critical performance parameters throughout
the development of the instrument. These TPMs are parameters that will impact the science, cost
or schedule if they exceed critical values. These parameters, which are either directly measurable
or derivable from modeling of the instrument, will be tracked as part of the systems engineering
process to ensure that the mission objectives are met.
The technical performance metrics will be monitored and reported at project status and
technical reviews. The report will include the current value and the threshold or “trigger point” for
the current phase of development. The “trigger point” is the value which, if exceeded, triggers an
automatic review of the entire system by the IPO to assess impacts and corrective actions.
The system-level metrics are flowed down and budgeted to the subsystems by the IDT. The
top-level TPMs for the LAT instrument are:
• Instrument Mass
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 16 of 29

• Instrument Electrical Power

• Center of Gravity Offset from Instrument Interface Plane
• Horizontal Dimension
• Instrument Dead Time
• Background Rejection
• Field of View
• Single Photon Angular Resolution (68%) @ 1 GeV
• Single Photon Angular Resolution (95%) @ 1 GeV
• Peak Effective Area
• Energy Resolution @ 1 GeV

4.5.5 Technical Reviews

The systems engineering process will utilize technical reviews to promote communication
and guidance within the LAT team and to provide status to and obtain feedback from the GSFC
Project Office. These technical reviews will include the NASA mission-level reviews, NASA
instrument-level reviews and LAT internal peer reviews. The time order of these reviews is
depicted in Figure 4. The suggested content of these reviews is given in Appendix B.

Formulation Phase Implementation Phase

Time

NASA Mission Reviews SRR M-PDR M-CDR

NASA Instrument Reviews I-PDR I-CDR

LAT Internal L-SRR

Instrument Reviews L-IRR
L-PDR
L-CDR

L-PRR
L-TRR
L-PSRR
Acronyms: CDR Critical Design Review
IRR Interface Requirements Review
PDR Preliminary Design Review
TRR Test Readiness Review
PRR Production Readiness Review
PSRR Pre-Shipment Readiness Review
SRR System Requirements Review
Figure 4: Technical Review Timeline
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 17 of 29

The IPO will support the NASA mission-level reviews, including the M-PDR and the M-
CDR, with status reporting on the instrument technical and programmatic progress.
For the NASA instrument-level reviews, the IPO will present designs, test plans, and
verification plans. The review team will develop and present specific recommendations, actions,
and concerns to the Project. These actions will be tracked to resolution by the IPM, to ensure
closure, and then presented to the same team at the next review. The NASA instrument-level
reviews include the SRR, I-PDR, and I-CDR.
The LAT internal peer reviews will be convened and managed by the ISE. For these
reviews, technical experts from within the instrument subsystems will be called upon to engage in
reviews of plans, designs, and implementations. Formal notes and action items will be taken at
these peer reviews and will be presented at the NASA reviews. These peer reviews will occur at
key development stages, such as preliminary design, design completion, pre-production, pre-test
and pre-shipment.
Subsystem-level internal peer reviews, not shown in Figure 4, will be conducted at key
development stages for major subsystem components. These reviews will be identified and called
for by the ISE in concert with the responsible Subsystem Manager.
The ISE may convene other internal reviews not shown in Figure 4 on an ad hoc basis.
GSFC will be invited to all peer reviews in accordance with the Mission Assurance Requirements.

4.5.6 Supplier Control

Control of suppliers for subsystem components will be the responsibility of the Subsystem
Managers. In order to minimize the number of different part types used in the system and preclude
use of parts with reliability deficiencies, the IPO will develop a Program Approved Parts List
(PAPL). This is described in the Product Assurance Implementation Plan.

4.5.7 Requirements Traceability

A requirements management software package will be used to facilitate requirements
traceability. This software will allow the LAT Project to convert requirements documents into
requirements databases, with each requirement receiving a unique identifier. Each requirement in
the database can then be assigned a link to a higher-level requirement. As lower-level requirements
are developed, imported into the database, and linked to the higher-level requirements, a structure
evolves which allows the flowdown of requirements to be traced from the highest-level mission
objectives to the lowest-level component specifications.
The requirements database will include the following information about each requirement:
• Higher-level requirement satisfied
• Related documents (trade studies, system analyses, etc.)
• Requirement owner
• Requirement change history
• Verification method
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 18 of 29

5 Implementation

5.1 Integration of Systems Engineering Effort

Through all phases of the LAT project, the systems engineering effort is managed by the
ISE. The systems engineering team will consist of engineering representatives from each of the
subsystems. When special engineering disciplines are required, the ISE will obtain engineering
support from SLAC resources or from other organizations if required.
During the integration and test phase at SLAC, the systems engineering team will work
closely with the on-site LAT integration team to review and approve all test data and to identify
and resolve problems.

5.2 Problem Resolution

Problems or failures occurring during ground test of any flight hardware or software will be
identified, documented, assessed, tracked and corrected according to the procedures to be defined
in the LAT Quality Manual. The process to assure closure of all such incidents is the
Problem/Failure Report (PFR) system.
Systems Engineering is generally responsible for identifying the troubleshooting steps and
other analyses required to assess the problem and to determine the resolution and corrective action.
The ISE gives final approval of the corrective actions. The PSAM is responsible for tracking and
closing PFR’s.

5.3 Systems Engineering Plans and Specifications

LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 19 of 29

The systems engineering processes will be implemented upon release of the defining
documents. The planned release of systems engineering documents is shown in Figure 5.

6 Other Systems Engineering Activities

6.1 Long Lead Items

As stated in the LAT proposal, the instrument has only one long-lead item, the silicon-strip
detectors for the Tracker subsystem. An aggressive development program has been undertaken to
fully characterize the requirements and performance of these detectors early in the Formulation
Phase. Procurement of these items will begin early to ensure that delivery will pose a low schedule
risk.

6.2 Engineering Tools

6.2.1 Requirements Management Software
In order to facilitate requirements tracking, a requirements management software tool, such
as DOORS®, will be implemented and maintained at the IPO.

Project Milestones SRR SSRR PDR

LAT SE Documents

Configuration Mngt Plan (CMP)

Systems Engineering Mngt Plan (SEMP)
Risk Mngt Plan (RMP)
Software Mngt Plan (SMP)
Integration and Test Plan (ITP)

Level II(b) SAT System Specifications

LAT Performance Specification (L-PS)

LAT IOC Performance Spec. (L-IPS)

Level III LAT Subsystem Specifications

LAT – ACD Subsys. Spec. (L-ASS)

LAT – Tracker Subsys. Spec. (L-TSS)
LAT – Calorimeter Subsys. Spec. (L-CSS)
LAT – Trigger & Data Subsys. Spec. (L-TDSS)
LAT – Grid/Thermal Subsys. Spec. (L-GSS)
LAT – Subsystem IRD (L-SIRD)
LAT – Mechanical Design Spec. (L-MDS)
LAT – Electronics Design Spec. (L-EDS)
LAT – IOC Subsystem Spec. (L-ISS)
LAT – Science Analysis Software Spec. (L-SSS)

Level IV LAT Design Specifications

LEVEL V LAT Detail Design Specifications

Doc. Development Doc. Review Doc. Initial Release

Figure 5: LAT Systems Engineering Documentation Plan

LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 20 of 29

6.2.2 Database Software

Several databases will be maintained for systems engineering, such as an action item
database and configuration management and risk management databases. These databases will be
implemented using simple database software, such as Microsoft Access.

6.2.3 Forms
The IPO will provide forms to aid in risk management, configuration management, and
problem resolution activities. These forms, listed in Table 3, are provided to help capture all the
pertinent information for systems engineering tasks.
Table 3: Systems engineering Forms

Form Purpose Where found

Problem/Failure Report (PFR) Document and resolve a hardware/software PAIP
failure
Document Change Notice (DCN) Authorize a change to a controlled CMP
document
Change Request (CR) Request CCB approval for a DCN if CMP
required
LAT Risk Appraisal Form Document and quantify risks to be RMP
evaluated by Risk Review Board
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 21 of 29

APPENDIX A

LAT Level III Specification Review/Release Description and Charge

Refer to the Figure A-1 for a graphical depiction of the review and release
process.

Prepare Specification
The Subsystem Manager prepares or is responsible for preparing the review draft
of the specification and requests the Project Manager for a review.

Charge Review Board and Announce Review

The Project Manager identifies and assigns members of the Review Board. A
Review Charge and Notice is prepared and distributed to the Review Board. The Review
Notice includes the following:
• Review Board assignments
• Date and time of the review meeting
• Expectations of Review Board members

Distribute Review Material and Solicit Comments

The Review Notice and a copy of the specification are sent out to the Review
Board for comment two weeks prior to the review. The review materials are posted for
general review by all LAT collaborators. Review Board comments are collected one
week prior to the review meeting and are distributed to the Subsystem Manager and the
other Review Board members.

Review Meeting
At the review meeting, the specification is presented by the Subsystem Manager
or his representative. The specification is reviewed for completeness. This meeting is
open to all LAT collaborators.

Review Record
The Review Board Secretary records the comments, actions, resolutions, etc.
agreed upon by the Review Board and obtains Review Board concurrence for
recommendations and changes to the specification. A Review Report is generated that
captures review comments, recommends changes to the specification, and refers the
specification for approval contingent upon the recommendations.

Resolve Actions and Update Specification

The Subsystem Manager is responsible for updating the specification according to
the review report.
 LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 22 of 29

Specification Signoff and Release

The final draft of the specification is submitted to Systems Engineering for
approval. All required approvals are obtained and a Document Change Notice is
generated. The document and DCN are then released, placed under Configuration
Management and are posted to the CyberDocs system.

Figure A-1. LAT Level III Specification Review Process

SSM prepares PM charges Review SE distributes review Review Board

specification and Board and announces material 2 weeks prior comments are collected
requests a review. review. to review meeting. and distributed by SE
one week prior to
review meeting.

Review Meeting

Specification is presented by the

specification owner for Board review
and comment.

Open to all

SSM = Subsystem Manager

SE = System Engineering
PM = Project Manager
SE assembles Review
Record, which contains:
• Comments
• Actions SSM resolves SSM and SE
• Recommendations actions and submit
updates specification for
• Board concurrence
specification. signoff and
release.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 23 of 29

Review Board Charge

Specification Reviews – Level III
(Subsystem performance specification)
The purpose of the Level III specification review is to validate the flow-down of
requirements from higher-level specifications. The LAT Performance Specification,
LAT IOC Performance Specification, and Mission System Specification as well as other
GLAST specification are where most level III requirements are decomposed.
The review board is charged with sitting in review of the specification to assess
the completeness of the requirements, recommend acceptance of the specification, and
summarize the review and assessments in a review report.
The Specification:
The specification, prepared by the subsystem manager, will be distributed to the
review board at least two weeks prior to the review. At the completion of the review, the
subsystem manager will be responsible for updating the specification according to the
recommendation of the review Board.
The Review Board:
The review board consisting primarily of the LAT subsystem managers and
functional leads are expected to review the submitted specification and submit comments
to the committee chairperson one week prior to the review meeting. Each member of the
board is expected to query the specification and presenter at the review meeting as
necessary to understand and assess the requirements. The chairperson or project manager
may add additional members of the board.
Level III Specification Review Board:
ACD Subsystem Mng’r Jonathan Ormes jfo@lheapop.gsfc.nasa.gov
CAL Subsystem Mng’r Neil Johnson johnson@gamma.nrl.navy.mil
TKR Subsystem Mng’r Robert Johnson johnson@scipp.ucsc.edu
IOC Subsystem Mng’r Scott Williams scott@razzle.stanford.edu
Electronics Systems Eng’r Gunther Haller haller@slac.stanford.edu
Mechanical Systems Eng’r Martin Nordby nordby@slac.stanford.edu
Instrument Scientist Steve Ritz ritz@milkyway.gsfc.nasa.gov
Instrument System Eng’r(chair) Tim Thurston thurston@slac.stanford.edu
Instrument Technical Mng’r Tune Kamae kamae@slac.stanford.edu
PSA Mng’r Darren Marsh dmarsh@slac.stanford.edu

Review Board Secretary Warren Davis wdavis@slac.stanford.edu

The Assessment:
The level III specification review board is selected and charged with probing the
specification to assess a) the completeness, b) the source of requirements, and c) the
verifiability of submitted requirements.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 24 of 29

The completeness of the requirement set should be assessed for the following:
Performance – Do the derived requirements satisfy the performance requirements
of higher-level requirements? How?
Functionality – Are requirements defined and consistent with higher-level and
interfacing requirements?
Feasibility – Are presented requirements achievable? Does any evidence exist in
support of this?
Quality – Have standards been established in specification?
Reliability – Do requirements clearly support the mission life? Are redundancy
and component reliability identified in supports mission reliability?
Operability – Do requirements support performance throughout the mission life?
Is performance degradation taken in to account?
The source of stated requirements should be assessed to identify the flow-down.
Additionally, studies and analyses should be identified that demonstrate how the higher-
level or shared requirements are satisfied.
Verifiability of requirements should be assessed for feasibility and practicality of
the verifying method. Since all requirements must be verified, the specification should
identify the methods to be employed.
The Review:
The committee chair will conduct the review. The subsystem manager submitting
the specification will make a presentation of requirements, walking the board through
each requirement, its source, and verification. Board members will submit
recommendations for action (RFA) forms for any item of concern. The secretary will
record minutes of the meeting.
The Review Recommendation:
The review board is expected to make a recommendation for approval contingent
on resolution of open issues. Questions, concerns, deficiencies and comments regarding
a requirement will be documented and carried in the review.
The Review Report:
The secretary will collect RFA’s, comments, and decisions and prepare a
summary report of the review for concurrence for the review board. The Review report
will be distributed within the week following the review. The report will be presented
and discussed at a subsequent IDT meeting.
The Specification Approval and Release:
The updated document, and review recommendations will be forwarded to the
project manager for approval. A document change notice (DCN) will accompany the
documentation as it is released and distributed through the LAT Document Control
System.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 25 of 29

APPENDIX B
Technical Review Definitions and Checklists

System Requirements Review (SRR)

The SRR occurs early in the Formulation Phase and is used to reach mutual agreement between
all parties to the development of system requirements. In this review, the draft system requirements
should be reviewed for completeness and necessity. The draft system specification should be
complete with all TBR items clearly identified with planned closure responsibility and dates. The
draft system architecture and external interfaces should also be reviewed.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 26 of 29

Preliminary Design Review (PDR)

The Preliminary Design Review occurs at the end of the Formulation Phase and is used to
determine if the project is ready to authorize the detailed design work involving a considerable
increase in manpower and cost. All system and subsystem requirements must be complete as well as
credible design concepts that are responsive to those requirements. The PDR should address the
following items:
G Subsystem block and functional diagrams
G Equipment layouts and preliminary drawings
G Environmental controls and thermal design aspects
G Power distribution and grounding
G Electromagnetic compatibility considerations
G Instrumentation, control, and diagnostic design approach
G Producibility and manufacturing considerations
G Preliminary parts lists
G Support system requirements and design approach
G Preliminary Development Specifications
G Physics parameter modeling, test, and simulation data
G Software Development Plan
G Software requirements specifications (Preliminary Design)
G Risk and abatement strategy
G Interface control documents
G Design standardization and logistic considerations
G Trade and design studies
G Preliminary reliability, maintainability, and availability studies
G Transportation, packaging, and handling considerations
G Environmental, Health, and Safety analyses
G Quality Control Planning
G Test methodology
G Schedules
G Problems and Concerns
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 27 of 29

Critical Design Review (CDR)

The CDR occurs after the design is approximately 90% completed and is used to determine if
the project is ready to proceed to the manufacture of flight and ground support hardware and the
coding of software. The following items should be addressed to the extent possible:
G Subsystem block and functional diagrams
G Drawing packages (assembly drawings and majority of remaining drawings)
G Final parts lists
G Final Development Specifications
G Design analysis and engineering test data
G Detailed software design, database design, interface design, firmware support, and
computer resources integrated support documents
G Logistic support considerations
o Transportation, packaging, and handling
o Standardization
o Support equipment requirements
o Spares requirements
o Calibration requirements
G Risk: cost, schedule, and technical
G Plans for acquisition of parts, components, and materials needed for fabrication
G Integration and Test Plans
G Software Test Plans
G Design reliability and maintainability
G System safety
G Quality control plans
G Schedules
G Problems and concerns
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 28 of 29

Test Readiness Review (TRR)

The PER occurs prior to the start of environmental testing of the integrated instrument. The
primary purpose of the PER is to establish the readiness of the system for test and to evaluate the
environmental test plans. The following items should be addressed:
G Changes since the CDR
G Tests planned
G Test facilities
G Test configuration
G Test procedure status
G Staffing plans
G System performance during initial performance testing
G Significant Problem/Failure Reports (status and plans for closure)
G Risk: cost, schedule, and technical
G System safety
G Schedules
G Problems and concerns
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 29 of 29

Pre-Shipment Readiness Review (PSRR)

The PSR takes place prior to shipment of the instrument for integration with the spacecraft.
The PSR establishes the completion of the integration and test of the instrument. This review focuses
on the system performance during qualification testing and the verification of all system requirements.
The following items should be addressed:
G Changes since the PER
G System performance during environmental and final performance testing
G Significant Problem/Failure Reports (status and plans for closure)
G Documentation to be sent to spacecraft contractor
G System safety
G Constraints to spacecraft integration
G Schedules
G Problems and concerns