Appendix A    Acronyms  
Appendix B    Glossary  
Appendix C    How to Write a Good Requirement— Checklist
Appendix D    Requirements Verification Matrix  
Appendix E    Creating the Validation Plan with a Validation Requirements Matrix
Appendix F    Functional, Timing, and State Analysis
Appendix G    Technology Assessment/Insertion
Appendix H    Integration Plan Outline
Appendix I     Verification and Validation Plan Outline
Appendix J     SEMP Content Outline
Appendix K    Technical Plans
Appendix L     Interface Requirements Document Outline
Appendix M    CM Plan Outline
Appendix N    Guidance on Technical Peer Reviews/Inspections
Appendix O    Reserved
Appendix P    SOW Review Checklist
Appendix Q    Reserved
Appendix R    HSI Plan Content Outline
Appendix S    Concept of Operations Annotated Outline
Appendix T    Systems Engineering in Phase E

References Cited
Bibliography

J.1    SEMP Content

The Systems Engineering Management Plan (SEMP) is the foundation document for the technical and engineering activities conducted during the project. The SEMP conveys information to all of the personnel on the technical integration methodologies and activities for the project within the scope of the project plan. SEMP content can exist as a stand-alone document or, for smaller projects, in higher-level project documentation.

The SEMP provides the specifics of the technical effort and describes what technical processes will be used, how the processes will be applied using appropriate activities, how the project will be organized to accomplish the activities, and the resources required for accomplishing the activities. The SEMP provides the framework for realizing the appropriate work products that meet the entry and success criteria of the applicable project life cycle phases to provide management with necessary information for assessing technical progress.

Because the SEMP provides the specific technical and management information to understand the technical integration and interfaces, its documentation and approval serve as an agreement within the project of how the technical work will be conducted. The SEMP communicates to the team itself, managers, customers, and other stakeholders the technical effort that will be performed by the assigned technical team.

The technical team, working under the overall program/project plan, develops and updates the SEMP as necessary. The technical team works with the project manager to review the content and obtain concurrence. The SEMP includes the following three general sections:

1. Technical program planning and control, which describe the processes for planning and control of the engineering efforts for the design, development, test, and evaluation of the system.
2. Systems engineering processes, which include specific tailoring of the systems engineering process as described in the NPR, implementation procedures, trade study methodologies, tools, and models to be used.
3. Engineering specialty integration describes the integration of the technical disciplines’ efforts into the systems engineering process and summarizes each technical discipline effort and cross references each of the specific and relevant plans.

The SEMP outline in this appendix is guidance to be used in preparing a stand-alone project SEMP. The level of detail in the project SEMP should be adapted based on the size of the project. For a small project, the material in the SEMP can be placed in the project plan’s technical summary, and this annotated outline should be used as a topic guide.

Some additional important points on the SEMP:

• The SEMP is a living document. The initial SEMP is used to establish the technical content of the engineering work early in the Formulation Phase for each project and updated as needed throughout the project life cycle. Table J-1 provides some high level guidance on the scope of SEMP content based on the life cycle phase.
• Project requirements that have been tailored or significant customization of SE processes should be described in the SEMP.
• For multi-level projects, the SEMP should be consistent with higher-level SEMPs and the project plan.
• For a technical effort that is contracted, the SEMP should include details on developing requirements for source selection, monitoring performance, and transferring and integrating externally produced products to NASA.

J.2    Terms Used

Terms used in the SEMP should have the same meaning as the terms used in the NPR 7123.1, Systems Engineering Processes and Requirements.

J.3    Annotated Outline

Title Page

1.0 Purpose and Scope

This section provides a brief description of the purpose, scope, and content of the SEMP.

• Purpose: This section should highlight the intent of the SEMP to provide the basis for implementing and communicating the technical effort.
• Scope: The scope describes the work that encompasses the SE technical effort required to generate the work products. The plan is used by the technical team to provide personnel the information necessary to successfully accomplish the required task.
• Content: This section should briefly describe the organization of the document.

2.0 Applicable Documents

This section of the SEMP lists the documents applicable to this specific project and its SEMP implementation. This section should list major standards and procedures that this technical effort for this specific project needs to follow. Examples of specific procedures to list could include procedures for hazardous material handling, crew training plans for control room operations, special instrumentation techniques, special interface documentation for vehicles, and maintenance procedures specific to the project.

3.0 Technical Summary

This section contains an executive summary describing the problem to be solved by this technical effort and the purpose, context, and products to be developed and integrated with other interfacing systems identified.

Key Questions

1. What is the problem we’re trying to solve?
2. What are the influencing factors?
3. What are the critical questions?
4. What are the overall project constraints in terms of cost, schedule, and technical performance
5. How will we know when we have adequately defined the problem?
6. Who are the customers?
7. Who are the users?
8. What are the customer and user priorities?
9. What is the relationship to other projects?

3.1 System Description

This section contains a definition of the purpose of the system being developed and a brief description of the purpose of the products of the product layer of the system structure to which this SEMP applies. Each product layer includes the system end products and their subsystems and the supporting or enabling products and any other work products (plans, baselines) required for the development of the system. The description should include any interfacing systems and system products, including humans with which the system products will interact physically, cognitively, functionally, or electronically.

3.2 System Structure

This section contains an explanation of how the technical portion of the product layer (including enabling products, technical cost, and technical schedule) will be developed, how the resulting product layers will be integrated into the project portion of the WBS, and how the overall system structure will be developed. This section contains a description of the relationship of the specification tree and the drawing tree with the products of the system structure and how the relationship and interfaces of the system end products and their life cycle-enabling products will be managed throughout the planned technical effort.

3.3 Product Integration

This section contains an explanation of how the products will be integrated and describes clear organizational responsibilities and interdependencies and whether the organizations are geographically dispersed or managed across Centers. This section should also address how products created under a diverse set of contracts are to be integrated, including roles and responsibilities. This includes identifying organizations—intra-and inter-NASA, other Government agencies, contractors, or other partners—and delineating their roles and responsibilities. Product integration includes the integration of analytical products.

When components or elements will be available for integration needs to be clearly understood and identified on the schedule to establish critical schedule issues.

3.4 Planning Context

This section contains the programmatic constraints (e.g., NPR 7120.5) that affect the planning and implementation of the common technical processes to be applied in performing the technical effort. The constraints provide a linkage of the technical effort with the applicable product life cycle phases covered by the SEMP including, as applicable, milestone decision gates, major technical reviews, key intermediate events leading to project completion, life cycle phase, event entry and success criteria, and major baseline and other work products to be delivered to the sponsor or customer of the technical effort.

3.5 Boundary of Technical Effort

This section contains a description of the boundary of the general problem to be solved by the technical effort, including technical and project constraints that affect the planning. Specifically, it identifies what can be controlled by the technical team (inside the boundary) and what influences the technical effort and is influenced by the technical effort but not controlled by the technical team (outside the boundary). Specific attention should be given to physical, cognitive, functional, and electronic interfaces across the boundary.

A description of the boundary of the system can include the following:

• Definition of internal and external elements/items involved in realizing the system purpose as well as the system boundaries in terms of space, time, physical, and operational.
• Identification of what initiates the transitions of the system to operational status and what initiates its disposal is important. General and functional descriptions of the subsystems inside the boundary.
• Current and established subsystem performance characteristics.
• Interfaces and interface characteristics.
• Functional interface descriptions and functional flow diagrams.
• Key performance interface characteristics.
• Current integration strategies and architecture.
• Documented Human System Integration Plan (HSIP)

3.6 Cross References

This section contains cross references to appropriate nontechnical plans and critical reference material that interface with the technical effort. It contains a summary description of how the technical activities covered in other plans are accomplished as fully integrated parts of the technical effort.

4.0 Technical Effort Integration

This section describes how the various inputs to the technical effort will be integrated into a coordinated effort that meets cost, schedule, and performance objectives.

The section should describe the integration and coordination of the specialty engineering disciplines into the systems engineering process during each iteration of the processes. Where there is potential for overlap of specialty efforts, the SEMP should define the relative responsibilities and authorities of each specialty. This section should contain, as needed, the project’s approach to the following:

• Concurrent engineering
• The activity phasing of specialty engineering
• The participation of specialty disciplines
• The involvement of specialty disciplines,
• The role and responsibility of specialty disciplines,
• The participation of specialty disciplines in system decomposition and definition
• The role of specialty disciplines in verification and validation
• Reliability
• Maintainability
• Quality assurance
• Integrated logistics
• Human engineering
• Safety
• Producibility
• Survivability/vulnerability
• National Environmental Policy Act (NEPA) compliance
• Launch approval/flight readiness

The approach for coordination of diverse technical disciplines and integration of the development tasks should be described. For example, this can include the use of multidiscipline integrated teaming approaches—e.g., an HSI team—or specialized control boards. The scope and timing of the specialty engineering tasks should be described along with how specialty engineering disciplines are represented on all technical teams and during all life cycle phases of the project.

4.1 Responsibility and Authority

This section describes the organizing structure for the technical teams assigned to this technical effort and includes how the teams will be staffed and managed.

Key Questions

1. What organization/panel will serve as the designated governing authority for this project?
2. How will multidisciplinary teamwork be achieved?
3. What are the roles, responsibilities, and authorities required to perform the activities of each planned common technical process?
4. What should be the planned technical staffing by discipline and expertise level?
5. What is required for technical staff training?
6. How will the assignment of roles, responsibilities, and authorities to appropriate project stakeholders or technical teams be accomplished?
7. How are we going to structure the project to enable this problem to be solved on schedule and within cost?
8. What does systems engineering management bring to the table?

The section should provide an organization chart and denote who on the team is responsible for each activity. It should indicate the lines of authority and responsibility. It should define the resolution authority to make decisions/decision process. It should show how the engineers/engineering disciplines relate.

The systems engineering roles and responsibilities need to be addressed for the following: project office, user, Contracting Officer’s Representative (COR), systems engineering, design engineering, specialty engineering, and contractor.

4.2 Contractor Integration

This section describes how the technical effort of in-house and external contractors is to be integrated with the NASA technical team efforts. The established technical agreements should be described along with how contractor progress will be monitored against the agreement, how technical work or product requirement change requests will be handled, and how deliverables will be accepted. The section specifically addresses how interfaces between the NASA technical team and the contractor will be implemented for each of the 17 common technical processes. For example, it addresses how the NASA technical team will be involved with reviewing or controlling contractor-generated design solution definition documentation or how the technical team will be involved with product verification and product validation activities.

Key deliverables for the contractor to complete their systems and those required of the contractor for other project participants need to be identified and established on the schedule.

4.3 Analytical Tools that Support Integration

This section describes the methods (such as integrated computer-aided tool sets, integrated work product databases, and technical management information systems) that will be used to support technical effort integration.

5.0 Common Technical Processes Implementation

Each of the 17 common technical processes will have a separate subsection that contains a plan for performing the required process activities as appropriately tailored. (See NPR 7123.1 for the process activities required and tailoring.) Implementation of the 17 common technical processes includes (1) the generation of the outcomes needed to satisfy the entry and success criteria of the applicable product life cycle phase or phases identified in D.4.4.4, and (2) the necessary inputs for other technical processes. These sections contain a description of the approach, methods, and tools for:

• Identifying and obtaining adequate human and nonhuman resources for performing the planned process, developing the work products, and providing the services of the process.
• Assigning responsibility and authority for performing the planned process (e.g., RACI matrix, [http://en.wikipedia.org/wiki/Responsibility_assignment_matrix]), developing the work products, and providing the services of the process.
• Training the technical staff performing or supporting the process, where training is identified as needed.
• Designating and placing designated work products of the process under appropriate levels of configuration management.
• Identifying and involving stakeholders of the process.
• Monitoring and controlling the systems engineering processes.
• Identifying, defining, and tracking metrics and success.
• Objectively evaluating adherence of the process and the work products and services of the process to the applicable requirements, objectives, and standards and addressing noncompliance.
• Reviewing activities, status, and results of the process with appropriate levels of management and resolving issues.

This section should also include the project-specific description of each of the 17 processes to be used, including the specific tailoring of the requirements to the system and the project; the procedures to be used in implementing the processes; in-house documentation; trade study methodology; types of mathematical and/or simulation models to be used; and generation of specifications.

Key Questions

1. What are the systems engineering processes for this project?
2. What are the methods that we will apply for each systems engineering task?
3. What are the tools we will use to support these methods? How will the tools be integrated?
4. How will we control configuration development?
5. How and when will we conduct technical reviews?
6. How will we establish the need for and manage trade-off studies?
7. Who has authorization for technical change control?
8. How will we manage requirements? interfaces? documentation?

6.0 Technology Insertion

This section describes the approach and methods for identifying key technologies and their associated risks and criteria for assessing and inserting technologies, including those for inserting critical technologies from technology development projects. An approach should be developed for appropriate level and timing of technology insertion. This could include alternative approaches to take advantage of new technologies to meet systems needs as well as alternative options if the technologies do not prove appropriate in result or timing. The strategy for an initial technology assessment within the scope of the project requirements should be provided to identify technology constraints for the system.

Key Questions

• How and when will we insert new of special technology into the project?
• What is the relationship to research and development efforts? How will they support the project? How will the results be incorporated?
• How will we incorporate system elements provided by others? How will these items be certified for adequacy?
• What facilities are required?
• When and how will these items be transitioned to be part of the configuration?

7.0 Additional SE Functions and Activities

This section describes other areas not specifically included in previous sections but that are essential for proper planning and conduct of the overall technical effort.

7.1 System Safety

This section describes the approach and methods for conducting safety analysis and assessing the risk to operators, the system, the environment, or the public.

7.2 Engineering Methods and Tools

This section describes the methods and tools that are not included in the technology insertion sections but are needed to support the overall technical effort. It identifies those tools to be acquired and tool training requirements.

This section defines the development environment for the project, including automation, simulation, and software tools. If required, it describes the tools and facilities that need to be developed or acquired for all disciplines on the project. It describes important enabling strategies such as standardizing tools across the project, or utilizing a common input and output format to support a broad range of tools used on the project. It defines the requirements for information management systems and for using existing elements. It defines and plans for the training required to use the tools and technology across the project.

7.3 Specialty Engineering

This section describes engineering discipline and specialty requirements that apply across projects and the WBS models of the system structure. Examples of these requirement areas would include planning for safety, reliability, human factors, logistics, maintainability, quality, operability, and supportability. It includes estimates of staffing levels for these disciplines and incorporates them with the project requirements.

7.4 Technical Performance Measures

a.    This section describes the TPMs that have been derived from the MOEs and MOPs for the project. The TPMs are used to define and track the technical progress of the systems engineering effort. (The unique identification numbers in red reference the corresponding requirement in NPR 7123.1.) The performance metrics need to address the minimally required TPMs as defined in NPR 7123.1. These include:

1. Mass margins for projects involving hardware [SE-62].
2. Power margins for projects that are powered [SE-63].
3. Review Trends including closure of review action documentation (Request for Action, Review Item Discrepancies, and/or Action Items as established by the project) for all software and hardware projects [SE-64].

b.    Other performance measure that should be considered by the project include:

• Requirement trends (percent growth, TBD/TBR closures, number of requirement changes);
• Interface trends (percent ICD approval, TBD/TBR burndown, number of interface requirement changes);
• Verification trends (closure burndown, number of deviations/waivers approved/open);
• Software-unique trends (number of requirements per build/release versus plan);
• Problem report/discrepancy report trends (number open, number closed);
• Cost trends (plan, actual, UFE, EVM, NOA);
• Schedule trends (critical path slack/float, critical milestone dates); and
• Staffing trends (FTE, WYE).

Key Questions

1. What metrics will be used to measure technical progress?
2. What metrics will be used to identify process improvement opportunities?
3. How will we measure progress against the plans and schedules?
4. How often will progress be reported? By whom? To whom?

7.5 Heritage

This section describes the heritage or legacy products that will be used in the project. It should include a discussion of which products are planned to be used, the rationale for their use, and the analysis or testing needed to assure they will perform as intended in the stated use.

7.6 Other

This section is reserved to describe any unique SE functions or activities for the project that are not covered in other sections.

8.0 Integration with the Project Plan and Technical Resource Allocation

This section describes how the technical effort will integrate with project management and defines roles and responsibilities. It addresses how technical requirements will be integrated with the project plan to determine the allocation of resources, including cost, schedule, and personnel, and how changes to the allocations will be coordinated.

Key Questions

1. How will we assess risk? What thresholds are needed for triggering mitigation activities? How will we integrate risk management into the technical decision process?
2. How will we communicate across and outside of the project?
3. How will we record decisions?
4. How do we incorporate lessons learned from other projects?

This section describes the interface between all of the technical aspects of the project and the overall project management process during the systems engineering planning activities and updates. All activities to coordinate technical efforts with the overall project are included, such as technical interactions with the external stakeholders, users, and contractors.

9.0 Compliance Matrices

Appendix H.2 in NPR 7123.1A is the basis for the compliance matrix for this section of the SEMP. The project will complete this matrix from the point of view of the project and the technical scope. Each requirement will be addressed as compliant, partially compliant, or noncompliant. Compliant requirements should indicate which process or activity addresses the compliance. For example, compliance can be accomplished by using a Center process or by using a project process as described in another section of the SEMP or by reference to another documented process. Noncompliant areas should state the rationale for noncompliance.

Appendices

Appendices are included, as necessary, to provide a glossary, acronyms and abbreviations, and information published separately for convenience in document maintenance. Included are: (1) information that may be pertinent to multiple topic areas (e.g., description of methods or procedures); (2) charts and proprietary data applicable to the technical efforts required in the SEMP; and (3) a summary of technical plans associated with the project. Each appendix should be referenced in one of the sections of the engineering plan where data would normally have been provided.

Templates

Any templates for forms, plans, or reports the technical team will need to fill out, like the format for the verification and validation plan, should be included in the appendices.

References

This section contains all documents referenced in the text of the SEMP.