![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL | | |||||
Template Instructions
This Compliance Matrix documents the Center's compliance with the requirements of this NPR or justification for tailoring of those requirements. While all requirements of this NPR are fundamentally owned by the OCE, in some cases responsibility for those requirements has been delegated to the Center Director. Since approval for tailoring of those delegated requirements is the responsibility of the Center Director (or delegate), only the undelegated OCE requirements are listed in this table. This compliance matrix will be filled out and submitted to the OCE upon request and attached to a copy of the Center procedures. The matrix lists:
The "Requirement Owner" column designates which organization is responsible for maintaining the requirement for the Agency and which therefore has the authority for tailoring unless this authority has been formally delegated.
The "Comply?" column is filled in to identify the Center's approach to the requirement. An "FC" is inserted for "fully compliant," "T" for "tailored," or "NA" for a requirement that is not applicable. The column titled "Justification" documents the rationale for tailoring, documents how the requirement will be tailored, or justifies why the requirement is not applicable.
| Req ID | SE NPR Paragraph | Requirement Statement | Rationale | Req. Owner | Comply? | Justification |
|---|---|---|---|---|---|---|
| SE-01 | 2.1.4.3.a | Center Directors shall perform the following activities: establish policies, procedures, and processes to execute the requirements of this SE NPR. | The requirements of this NPR are to be flowed into Center-level command media for execution. This may require not only Center-level requirements, but also policy statements, work instructions, or other supporting or enabling processes. It is the responsibility of the Center Directors or designees to ensure that this occurs. | OCE | ||
| SE-02 | 2.1.4.3.b | Center Directors shall perform the following activities: assess and take corrective actions to improve the execution of the requirements of this SE NPR. | Continual improvement of Agency and Center processes is necessary to ensure they are efficient and effective. It is the responsibility of the Centers to bring forward any recommendations for improvement of this NPR. | OCE | ||
| SE-03 | 2.1.4.3.c | Center Directors shall perform the following activities: select appropriate standards applicable to projects under their control. | It is the responsibility of the Center organizations to identify which Agency and/or Center technical standards should be applied to the programs and projects within their purview. These will be recommended to the programs/projects through the technical authority lines. | OCE | ||
| SE-04 | 2.1.4.3.d | Center Directors shall perform the following activities: Complete the compliance matrix, as tailored, in Appendix H.1 for those requirements owned by the Office of Chief Engineer, and provide to the OCE upon request. | The Centers are to fill out the compliance matrix in Appendix H.1 to indicate how the OCE-owned requirements of this NPR have been flowed into Center-level processes. This ensures that the OCE requirements of the Agency are flowed into the Centers and that any waiver/deviation from the Agency requirements has been identified and approved by the OCE. | OCE | ||
| SE-07 | 3.2.2.1 | Center Directors or designees shall establish and maintain a Stakeholder Expectations Definition process to include activities, requirements, guidelines, and documentation for the definition of stakeholder expectations for the applicable product layer. | This requirement ensures that the Centers identify how they will gather and address stakeholder expectations. This ensures that the project will gain a thorough understanding of what the customer and other stakeholders expect out of the programs/projects. | OCE | ||
| SE-08 | 3.2.3.1 | Center Directors or designees shall establish and maintain a Technical Requirements Definition process to include activities, requirements, guidelines, and documentation for the definition of technical requirements from the set of agreed upon stakeholder expectations for the applicable product layer. | This requirement ensures that the Centers identify how they will select and gain agreement on the technical requirements for the program/project. | OCE | ||
| SE-09 | 3.2.4.1 | Center Directors or designees shall establish and maintain a Logical Decomposition process to include activities, requirements, guidelines, and documentation for logical decomposition of the validated technical requirements of the applicable product layer. | This requirement ensures that the Centers identify how they will take the technical requirements for the program/project and glean from them what is needed to accomplish them (functional block diagrams, timing, architectures, etc.). This places the requirements into context and ensures they are understood well enough to begin the design process. | OCE | ||
| SE-10 | 3.2.5.1 | Center Directors or designees shall establish and maintain a Design Solution Definition process to include activities, requirements, guidelines, and documentation for designing product solution definitions within the applicable product layer that satisfy the derived technical requirements. | This requirement ensures that the Centers identify how they will take the information from the stakeholder expectations, requirements, and logical decomposition and perform the design function. Since all designs are unique, this will describe the general steps that are taken. The specifics for each of the program/projects will be documented in the SEMP. | OCE | ||
| SE-11 | 3.2.6.1 | Center Directors or designees shall establish and maintain a Product Implementation process to include activities, requirements, guidelines, and documentation for implementation of a design solution definition by making, buying, or reusing an end product of the applicable product layer. | This requirement ensures that the Centers identify how they will execute the designs, whether through buying items off the shelf or contracting to have them built, building/coding them within the Center, or reusing products already developed by another program/project. The specifics for how each program/project will make this determination for the various components/assemblies within the product hierarchy are documented in the SEMP. | OCE | ||
| SE-12 | 3.2.7.1 | Center Directors or designees shall establish and maintain a Product Integration process to include activities, requirements, guidelines, and documentation for the integration of lower level products into an end product of the applicable product layer in accordance with its design solution definition. | This requirement ensures that the Centers identify how they will approach the integration of products within successive levels of the product hierarchy. This ensures that planning is performed that will enable a smooth integration of products into higher level assemblies. | OCE | ||
| SE-13 | 3.2.8.1 | Center Directors or designees shall establish and maintain a Product Verification process to include activities, requirements/specifications, guidelines, and documentation for verification of end products generated by the product implementation process or product integration process against their design solution definitions. | This requirement ensures that the Centers identify how they will verify that the end products will comply with the technical requirements. | OCE | ||
| SE-14 | 3.2.9.1 | Center Directors or designees shall establish and maintain a Product Validation process to include activities, requirements, guidelines, and documentation for validation of end products generated by the product implementation process or product integration process against their stakeholder expectations. | This requirement ensures that the Centers identify how they will show that the end products will meet the stakeholder expectations in the intended environment. This is in addition to verifying they meet the stated requirements and ensures the stakeholder is getting what was expected. | OCE | ||
| SE-15 | 3.2.10.1 | Center Directors or designees shall establish and maintain a Product Transition process to include activities, requirements, guidelines, and documentation for transitioning end products to the next higher level product layer customer or user. | This requirement ensures that the Centers identify how they will handle the end products as they move from one location to another. This includes shipping, handling, transportation criteria, security needs, and receiving facility storage needs. It ensures that receiving facilities are ready to accept the product and that no damage occurs to the product during handling and transportation. | OCE | ||
| SE-16 | 3.2.11.1 | Center Directors or designees shall establish and maintain a Technical Planning process to include activities, requirements, guidelines, and documentation for planning the technical effort. | This requirement ensures that the Centers identify how they will perform and document all the technical planning for the program/project. This includes all plans developed for the technical effort ??"Systems Engineering Management Plans, risk plans, integration plans, and VandV plans. This ensures that the program/project teams are thinking ahead for the work to be performed and capturing that information so it can be communicated to the rest of the team, customers, and other stakeholders. | OCE | ||
| SE-17 | 3.2.12.1 | Center Directors or designees shall establish and maintain a Requirements Management process to include activities, requirements, guidelines, and documentation for management of requirements throughout the system life cycle. | This requirement ensures that the Centers identify how they will handle tracking and changes to the baselined set of requirements. It defines who has authority to submit and approve changes and how requirements are tracked as they flow down to other elements in the product breakdown structure. This ensures that changes to requirements are evaluated and that their impacts are understood and communicated to the rest of the team. | OCE | ||
| SE-18 | 3.2.13.1 | Center Directors or designees shall establish and maintain an Interface Management process to include activities, requirements, guidelines, and documentation for management of the interfaces defined and generated during the application of the system design processes. | This requirement ensures that the Centers identify how they will manage the internal and external interfaces of their end product. This will ensure compatibility when the various parts of the system are brought together for assembly/integration. | OCE | ||
| SE-19 | 3.2.14.1 | Center Directors or designees shall establish and maintain a Technical Risk Management process to include activities, requirements, guidelines, and documentation for management of the risk identified during the technical effort. | This requirement ensures that the Centers identify how they will handle the technical portions of the program/project risks and report them for inclusion with the programmatic risk portions. It ensures that the technical aspects of risks to the program/project's successful execution are captured and reported to program/project management who will be developing the overall risk posture. | OCE | ||
| SE-20 | 3.2.15.1 | Center Directors or designees shall establish and maintain a Configuration Management process to include activities, requirements, guidelines, and documentation for configuration management. | This requirement ensures that the Centers identify how they will perform configuration management of the end products, enabling products and other work products key to the program/project. The technical products to be controlled are identified and tracked to ensure that the team knows what the configuration of their system is at all phases of the life cycle. | OCE | ||
| SE-21 | 3.2.16.1 | Center Directors or designees shall establish and maintain a Technical Data Management process to include activities, requirements, guidelines, and documentation for management of the technical data generated and used in the technical effort. | This requirement ensures that the Centers identify how they will handle all the technical data that is generated by the program/project. This will include all data needed to manage, operate, and support the system products over the life cycle. It ensures that the data is available and secure when needed. | OCE | ||
| SE-22 | 3.2.17.1 | Center Directors or designees shall establish and maintain a Technical Assessment process to include activities, requirements, guidelines, and documentation for making assessments of the progress of planned technical effort and progress toward requirements satisfaction. | This requirement ensures that the Centers identify how they will assess the progress of the program/project's technical efforts, including life-cycle reviews. It ensures that the program/project team, customers, and other key stakeholders know how the effort is progressing and if additional actions are needed to resolve issues prior to becoming too costly. | OCE | ||
| SE-23 | 3.2.18.1 | Center Directors or designees shall establish and maintain a Decision Analysis process to include activities, requirements, guidelines, and documentation for making technical decisions. | This requirement ensures that the Centers identify how they will make and document key technical decisions. It helps to ensure that all team members know who can make decisions, what their authority levels are, and where to go to gain an understanding of what key decisions have been made. | OCE |
Template Instructions
The Compliance Matrix documents the program/project's compliance or intent to comply with the requirements of this NPR or justification for tailoring. It is attached to the SEMP when submitted for approval. The matrix lists:
Programs/Projects may substitute a matrix that documents their compliance with their particular Center's implementation of NPR 7123.1, if applicable.
The "Requirement Owner" column designates which organization is responsible for maintaining the requirement for the Agency and which, therefore, has the authority for tailoring unless this authority has been formally delegated.
The "Comply?" column is filled in to identify the program/project's approach to the requirement. An "FC" is inserted for "fully compliant," "T" for "tailored," or "NA" for a requirement that is "not applicable." The column titled "Justification" documents the rationale for tailoring, documents how the requirement will be tailored, or justifies why the requirement is not applicable.
| Req ID | SE NPR Paragraph | Requirement Statement | Rationale | Req. Owner | Comply? | Justification |
|---|---|---|---|---|---|---|
| SE-05 | 2.1.5.2 | For those requirements owned by Center Directors, the technical team shall complete the compliance matrix in Appendix H.2 and include it in the SEMP. | For programs and projects, the compliance matrix in Appendix H.2 is filled out showing that the program/project is compliant with the requirements of this NPR (or a particular Center's implementation of NPR 7123.1, whichever is applicable) or any tailoring thereof is identified and approved by the Center Director or designee as part of the program/project SEMP. | CD | ||
| SE-06 | 2.1.6.1 | The DGA shall approve the SEMP, waiver authorizations, and other key technical documents to ensure independent assessment of technical content. | The DGA, who is often the TA, provides an approval of the SEMPs, waivers to technical requirements and other key technical document to provide assurance of the applicability and technical quality of the products. | CD | ||
| SE-24 | 4.2.1 | The NASA technical team shall define the engineering activities for the periods before contract award, during contract performance, and upon contract completion in the SEMP. | It is important for both the Government and contractor technical teams to understand what activities will be handled by which organization throughout the product life cycle. The contractor(s) will typically develop a SEMP or its equivalent to describe the technical activities in their portion of the project, but an overarching SEMP is needed that will describe all technical activities across the life cycle whether contracted or not. | CD | ||
| SE-25 | 4.2.2 | The NASA technical team shall use common technical processes, as implemented by the Center's documentation, to establish the technical inputs to the RFP appropriate for the product to be developed, including product requirements and Statement of Work tasks. | The technical team's participation in the development of the RFP is critical to enabling a successful contracted effort. Ensuring that the proper application of the common technical processes into the contracted effort will enhance the chances for success. | CD | ||
| SE-26 | 4.2.3 | The NASA technical team shall determine the technical work products to be delivered by the offeror or contractor, to include a contractor SEMP that specifies the contractor's systems engineering approach for requirements development; technical solution definition; design realization; product evaluation; product transition; and technical planning, control, assessment, and decision analysis. | The technical team is in the best position to determine what kind of work products from the technical effort will need to be delivered. These products will eventually be used by the technical team to determine the suitability of the contracted effort in its ability to meet requirements, satisfy the stakeholder expectations, and perform as planned. | CD | ||
| SE-27 | 4.2.4 | The NASA technical team shall provide the requirements for technical insight and oversight activities planned in the NASA SEMP to the contracting officer for inclusion in the RFP. | In addition to the work description and products to be delivered, how the technical team will gain an adequate understanding of the contracted work, what authority (if any) they will have to direct or influence the work, and their participation at key milestone reviews. In the end the technical team needs enough information to advise the program/project manager as to the adequacy of the technical work. | CD | ||
| SE-28 | 4.2.5 | The NASA technical team shall have representation in the evaluation of offeror proposals in accordance with applicable NASA and Center source selection procedures. | Technical personnel will need to be involved in reviewing the proposals and providing advice/guidance on their merits. These personnel may or may not be part of the technical team that will execute the program/project. | CD | ||
| SE-29 | 4.3.1 | The NASA technical team, under the authority of the contracting officer, shall perform the technical insight and oversight activities established in the NASA SEMP. | After the contract is awarded, the contracting officer will depend on the technical team to execute the oversight/insight of the technical work as defined in their SEMP and the contract. | CD | ||
| SE-30 | 4.4.1 | The NASA technical team shall participate in the review(s) to finalize Government acceptance of the deliverables. | Per the agreement in the SEMP and the contract, the technical team will participate in the milestone reviews. Ultimately, this knowledge will enable the technical team to provide advice to the program/project as to the suitability of the product for acceptance. | CD | ||
| SE-31 | 4.4.2 | The NASA technical team shall participate in product transition as defined in the NASA SEMP. | In accordance with the SEMP, the technical team will participate in the execution of the final aspects of the end product??"either its transference in whole to the program/project customer, its operations and/or the final decommissioning, and disposal. These activities may be performed by the same team that was involved in its development or by other technical teams. | CD | ||
| SE-32 | 5.2.1.1 | The technical team shall develop and document plans for life-cycle and technical reviews for use in the project planning process. | Each of the life-cycle reviews, as well as any other technical status reviews, needs to be identified and documented so that all stakeholders will know how the program/project's progress will be assessed. This will typically be captured within the SEMP or in a separate Review Plan. | CD | ||
| SE-33 | 5.2.1.3 | The technical team shall conduct the life-cycle and technical reviews as indicated in the governing project management NPR. | The technical team will be responsible for generating and presenting many of the technical topics during a life-cycle and technical review. | CD | ||
| SE-34 | 5.2.1.4 | The technical team shall participate in the development of entrance and success criteria for each of the respective reviews. | The entrance and success criteria in Appendix G are provided as guidelines (not requirements) except where notated. It is expected that they will be modified as needed by the program/project according to their size, complexity, type of end product being produced, formality, etc. Specific names of documents may be provided for clarity, non-applicable products eliminated, and new products added as needed for clarity and completeness. | CD | ||
| SE-35 | 5.2.1.5.a (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MCR: Baselined stakeholder identification and expectation definitions. | For a MCR one of the key products is capturing the stakeholder expectations. These may be identified as needs, goals, and objectives, or other methods for capturing their expectations. These are captured in a document or a database/model. After all comments from the MCR are dispositioned, the set of stakeholder expectations are updated with the approved comments and then baselined. | CD | ||
| SE-36 | 5.2.1.5.a (2) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MCR: Baselined concept definition. | Presenting one or more feasible ways of accomplishing the stakeholder expectations is a key product of the MCR. These are captured in a document or a database/model. After all comments from the MCR are dispositioned, the concept(s) are updated with the approved comments and then baselined. | CD | ||
| SE-37 | 5.2.1.5.a (3) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MCR: Approved MOE definition. | The Measures of Effectiveness capture the stakeholder's view of what would be considered the successful achievement of each expectation. These will help in the later identification of requirements, criteria for trade studies and in the success criteria for the validation efforts. | CD | ||
| SE-38 | 5.2.1.5.b (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: SRR: Baselined SEMP for projects, single-project programs, and one-step AO programs. | The SEMP is a key document for the technical effort in a similar manner that the program/project plan captures the programmatic efforts. These are captured in a document or a database/model. For projects, single-project programs, and one-step AO programs after all comments from the SRR are dispositioned, the SEMP is updated with the approved comments and then baselined. The SEMP is baselined in a later phase for the other types of programs and so will be a "Not Applicable" in this line for uncoupled, tightly coupled, and loosely coupled programs. | CD | ||
| SE-39 | 5.2.1.5.b (2) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: SRR: Baselined requirements. | The program/project requirements are a key product for the SRR. These are captured in a document or a database/model. After all comments from the SRR are dispositioned, the requirements are updated with the approved comments and then baselined. | CD | ||
| SE-40 | 5.2.1.5.c (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MDR/SDR: Approved TPM definitions. | A key product at the SDR is the set of TPMs that the program/project has identified as the important measures to track for their efforts. These may be associated with the key driving requirements, key performance parameters, leading or lagging indicators, or other measures that are important to periodically measure and track. | CD | ||
| SE-41 | 5.2.1.5.c (2) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MDR/SDR: Baselined architecture definition. | One of the key products of a SDR is the proposed architecture that will accomplish the requirements. These are captured in a document or a database/model. After all comments from the SDR are dispositioned, the architecture description is updated with the approved comments and then baselined. | CD | ||
| SE-42 | 5.2.1.5.c (3) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MDR/SDR: Baselined allocation of requirements to next lower level. | Now that the overarching architecture has been defined, it is important to show how the requirements are allocated to the architecture elements of the next lower level of the product hierarchy. These are captured in a document or a database/model. After all comments from the SDR are dispositioned, the allocation is updated with the approved comments and then baselined. | CD | ||
| SE-43 | 5.2.1.5.c (4) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MDR/SDR: Initial trend of required leading indicators. | The trend is presented for the leading indicators that have been identified by the Agency as required for each program/project. These will typically be in graphical form but could also be tabular or other form appropriate for the project. At SDR this will be the initial set of trends that have been captured since SRR. Since final hardware has not been produced at this point, the trends will be on the estimated parameters. | CD | ||
| SE-44 | 5.2.1.5.c (5) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: MDR/SDR: Baseline SEMP for uncoupled, loosely coupled, tightly coupled, and two-step AO programs. | The SEMP is a key document for the technical effort in a similar manner that the program plan captures the programmatic efforts. These are captured in a document or a database/model. For uncoupled, loosely coupled, tightly coupled, and two-step AO programs, after all comments from the MDR/SDR are dispositioned, the SEMP is updated with the approved comments and then baselined. The SEMP is baselined in an earlier phase for projects and single-project programs and so will be a "Not Applicable" in this line for those types of programs. | CD | ||
| SE-45 | 5.2.1.5.d (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: PDR: Preliminary design solution definition. | The key product of a PDR is the preliminary design itself. The design is captured in one or documents, models, databases, drawings, and other means. Comments from the PDR will be captured in the final design for the next review. | CD | ||
| SE-46 | 5.2.1.5.e (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: CDR: Baseline detailed design. | The key product of a CDR is the final design. The design is captured in one or more documents, models, databases, drawings, and other means. The final design is updated with approved comments from the review, and the design is updated to represent the design that will be implemented. | CD | ||
| SE-47 | 5.2.1.5.f (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: SIR: Updated integration plan. | A key product of a SIR is the updated integration plans. These will describe how the products associated with this review will be integrated. | CD | ||
| SE-48 | 5.2.1.5.f (2) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: SIR: Preliminary VandV results. | Another key product of a SIR is the initial VandV results from any of the lower level products that are associated with this review. With the recursive nature of the SE engine, products will be integrated and verified/validated from the bottom of the product layer to the top. So, prior to integration into larger assemblies, lower level products will have been through their VandV activities. This ensures that, when they are assembled into the higher product layers, they will work as intended. Programs/projects may decide to perform VandV only at assembly levels??"as captured in their SEMP??"and so initial VandV results may or may not be available. | CD | ||
| SE-49 | 5.2.1.5.g 1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: ORR: Updated operational plans. | The plans on how the product will be operated during its operational/sustaining phase are presented at the ORR. This is to ensure that all stakeholders are aware and approve of these plans. | CD | ||
| SE-50 | 5.2.1.5g (2) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: ORR: Updated operational procedures. | The procedures on how the product will be operated during its operational/sustaining phase are presented at the ORR. This is to ensure that all stakeholders are aware and approve of these procedures. | CD | ||
| SE-51 | 5.2.1.5.g (3) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: ORR: Preliminary decommissioning plans. | AT ORR it is important to describe how the product will ultimately be decommissioned when it has accomplished its mission. This is to ensure that decommissioning will be feasible before the product is put into use. These are captured in a document or a database/model. After all comments from the ORR are dispositioned, the plan is updated with the approved comments and then baselined. | CD | ||
| SE-52 | 5.2.1.5.h (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: FRR: Baseline disposal plans. | AT FRR it is also important to describe how the product will ultimately be disposed of when it has accomplished its mission. This is to ensure that disposal will be feasible before the product is put into use. These are captured in a document or a database/model. After all comments from the FRR are dispositioned, the plan is updated with the approved comments and then baselined. | CD | ||
| SE-53 | 5.2.1.5.h (2) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: FRR: Baseline VandV results. | At FRR, the baselined VandV results for the product are presented and any remaining open work identified. This is to ensure that the product is ready for flight. Note that for some programs/projects the VandV results may need to be baselined at ORR per Center policies/procedures. Maturing and presenting a product earlier than required in the Agency NPR is at the discretion of the program/project/Center and does not require a waiver. | CD | ||
| SE-54 | 5.2.1.5.h (3) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: FRR: Final certification for flight/use. | The key product at the FRR is the certification that the product is ready for flight/use. This gains agreement with all key stakeholders that the product is ready to put into the operational phase. Any remaining open items are identified, and plans for closure are developed. | CD | ||
| SE-55 | 5.2.1.5.i (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: DR: Baseline decommissioning plans. | The key product at the DR is the plan on how the product will be removed from service. The approved comments from the DR are used to baseline the plan. | CD | ||
| SE-56 | 5.2.1.5.j (1) | The technical team shall provide the following minimum products at the associated milestone review at the indicated maturity level: DRR: Updated disposal plans. | The key product of the DRR is the plan on how the product will be disposed of after it has been decommissioned. The approved comments from the DRR are used to update the plan. | CD | ||
| SE-57 | 5.2.2.2 | Technical teams shall monitor technical effort through periodic technical status reviews. | In addition to the life-cycle reviews, the technical teams need to periodically monitor the technical progress of their program/project. These may be held formally or informally with relevant personnel. | CD | ||
| SE-58 | 6.2.3 | The technical teams shall define in the project SEMP how the required 17 common technical processes, as implemented by Center documentation, including tailoring, will be recursively applied to the various levels of project product layer system structure during each applicable life-cycle phase. | The SEMP is the key document that lays out the work that the technical team needs to perform and the manner in which they will perform it. This requirement ensures that each of the 17 common technical processes is addressed and how it will be applied to the various levels in the end-item product hierarchy and their associated enabling products. | CD | ||
| SE-59 | 6.2.6 | The technical team shall ensure that any technical plans and discipline plans are consistent with the SEMP and are accomplished as fully integrated parts of the technical effort. | Since the SEMP is the primary planning document for the systems engineering effort, all subsequent planning documents are in alignment and consistent with the SEMP. | CD | ||
| SE-60 | 6.2.7 | The technical team shall establish TPMs for the project that track/describe the current state versus plan. | The measures that the program/project will use to track the progress of key aspects of the technical effort are identified and documented. These TPMs will include the required leading indicators described in other requirements of this NPR and also any project-unique measures deemed necessary to track the key performance parameters. | CD | ||
| SE-61 | 6.2.8 | The technical team shall report the TPMs to the program/project manager on an agreed-to reporting interval. | The selected TPMs need to be measured periodically and their trends reported to the program/project manager at the agreed-to interval as documented in the SEMP. This ensures the PM is kept up to date on these key parameters so that decisions can be made in a timely manner. | CD | ||
| SE-62 | 6.2.9.a | The technical team shall ensure that the set of TPMs include the following leading indicators: Mass margins for projects involving hardware. | If the program/project has hardware elements, tracking of the remaining margins associated with their mass is a required leading indicator measure by the Agency. This is especially important for flight projects. For ground or other projects in which mass is not relevant, a waiver to this requirement can be documented in the SEMP. | CD | ||
| SE-63 | 6.2.9.b | The technical team shall ensure that the set of TPMs include the following leading indicators: Power margins for projects that are powered. | If the program/project has elements that require power, tracking of the remaining margins associated with their power consumption is a required leading indicator measure by the Agency. This is especially important for flight projects. For ground or other projects in which power consumption is not relevant, a waiver to this requirement can be documented in the SEMP. | CD | ||
| SE-64 | 6.2.10 | The technical team shall ensure that the set of Review Trends includes 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. | During life-cycle reviews, comments from the reviewers are captured on forms, databases, spreadsheets, or other manner. Depending on the program/project, these may be called RFAs, RIDs, Action Items, or other terminology. Whatever they are called, the disposition and closure of these comments - typically called their burndown - are required indicator trends by the Agency. This ensures that the approved comments are incorporated into the designs and plans in a timely manner. | CD |
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |