![[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 | AppendixK | ALL | | |||||
Template Instructions
The Compliance Matrix documents the program/projects compliance or intent to comply with the requirements of this NPR or justification for tailoring. It is attached to the SEMP or other equivalent program/project documentation 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.
The “Comply?” column is filled in to identify the program/projects 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 | NPR Section | Requirement Statement | Rationale | Comply? | Justification |
|---|---|---|---|---|---|
| SE-01 to 05 | Deleted | See rationale in the Deleted Requirements Table J-1. | |||
| SE-06 | 6.1.8 | The ETA shall approve the SEMP, waiver or deviation authorizations, and other key technical documents to ensure independent assessment of technical content. | This requirement ensures that the ETA has reviewed and approved of key systems engineering documents. | ||
| SE- 07 | 3.2.2.1 | Program/Project Managers shall identify and implement an ETA-approved Stakeholder Expectations Definition process to include activities, requirements, guidelines, and documentation, as tailored and customized for the definition of stakeholder expectations for the applicable product layer. | This requirement ensures that the program/project and the ETA identifies how they will gather and address stakeholder expectations. This ensures that the program/project will gain a thorough understanding of what the customer and other stakeholders expect. | ||
| SE- 08 | 3.2.3.1 | Program/Project Managers shall identify and implement an ETA-approved Technical Requirements Definition process to include activities, requirements, guidelines, and documentation, as tailored and customized for the definition of technical requirements from the set of agreed upon stakeholder expectations for the applicable product layer. | This requirement ensures that the program/project and the ETA identifies how they will select and gain agreement on the technical requirements. | ||
| SE- 09 | 3.2.4.1 | Program/Project Managers shall identify and implement an ETA-approved Logical Decomposition process to include activities, requirements, guidelines, and documentation, as tailored and customized for logical decomposition of the validated technical requirements of the applicable product layer. | This requirement ensures that the program/project and the ETA identifies how they will take the technical requirements for the program/project and glean from them what is needed to accomplish them (e.g., functional block diagrams, timing, architectures). This places the requirements into context and ensures they are understood well enough to begin the design process. | ||
| SE- 10 | 3.2.5.1 | Program/Project Managers shall identify and implement an ETA-approved Design Solution Definition process to include activities, requirements, guidelines, and documentation, as tailored and customized for designing product solution definitions within the applicable product layer that satisfy the derived technical requirements. | This requirement ensures that the program/project and the ETA identifies 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 or other equivalent program/project documentation. | ||
| SE- 11 | 3.2.6.1 | Program/Project Managers shall identify and implement an ETA-approved Product Implementation process to include activities, requirements, guidelines, and documentation, as tailored and customized 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 program/project and the ETA identifies 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 or other equivalent program/project documentation. | ||
| SE- 12 | 3.2.7.1 | Program/Project Managers shall identify and implement an ETA-approved Product Integration process to include activities, requirements, guidelines, and documentation, as tailored and customized 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 program/project and the ETA identifies 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. | ||
| SE- 13 | 3.2.8.1 | Program/Project Managers shall identify and implement an ETA-approved Product Verification process to include activities, requirements/specifications, guidelines, and documentation, as tailored and customized 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 program/project and the ETA identifies how they will verify that the end products will comply with each of the technical requirements. | ||
| SE- 14 | 3.2.9.1 | Program/Project Managers shall identify and implement an ETA-approved Product Validation process to include activities, requirements, guidelines, and documentation, as tailored and customized for validation of end products generated by the product implementation process or product integration process against their stakeholder expectations. | This requirement ensures that the program/project and the ETA identifies 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. | ||
| SE- 15 | 3.2.10.1 | Program/Project Managers shall identify and implement an ETA-approved Product Transition process to include activities, requirements, guidelines, and documentation, as tailored and customized for transitioning end products to the next higher level product layer customer or user. | This requirement ensures that the program/project and the ETA identifies how they will handle the end products as they move from one location to another. This includes shipping, handling, transportation criteria, physical security, cybersecurity, 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. | ||
| SE- 16 | 3.2.11.1 | Program/Project Managers shall identify and implement an ETA-approved Technical Planning process to include activities, requirements, guidelines, and documentation, as tailored and customized for planning the technical effort. | This requirement ensures that the program/project and the ETA identifies 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 V&V 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. | ||
| SE- 17 | 3.2.12.1 | Program/Project Managers shall identify and implement an ETA-approved Requirements Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of requirements throughout the system life-cycle. | This requirement ensures that the program/project and the ETA identifies 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. | ||
| SE- 18 | 3.2.13.1 | Program/Project Managers shall identify and implement an ETA-approved Interface Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of the interfaces defined and generated during the application of the system design processes. | This requirement ensures that the program/project and the ETA identifies 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. | ||
| SE- 19 | 3.2.14.1 | Program/Project Managers shall identify and implement a Technical Risk Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of the risk identified during the technical effort. | This requirement ensures that the program/project and the ETA identifies how they will handle the technical portions of the program/project risks and report them for inclusion with the cost and schedule risk portions. It ensures that the technical aspects of risks to the program/projects successful execution are captured and reported to program/project management who will be developing the overall risk posture. | ||
| SE- 20 | 3.2.15.1 | Program/Project Managers shall identify and implement an ETA-approved Configuration Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for configuration management. | This requirement ensures that the program/project and the ETA identifies 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. | ||
| SE- 21 | 3.2.16.1 | Program/Project Managers shall identify and implement an ETA-approved Technical Data Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of the technical data generated and used in the technical effort. | This requirement ensures that the program/project and the ETA identifies 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. | ||
| SE- 22 | 3.2.17.1 | Program/Project Managers shall identify and implement an ETA-approved Technical Assessment process to include activities, requirements, guidelines, and documentation, as tailored and customized for making assessments of the progress of planned technical effort and progress toward requirements satisfaction. | This requirement ensures that the program/project and the ETA identifies 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. | ||
| SE- 23 | 3.2.18.1 | Program/Project Managers shall identify and implement an ETA-approved Decision Analysis process to include activities, requirements, guidelines, and documentation, as tailored and customized for making technical decisions. | This requirement ensures that the program/project and the ETA 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. | ||
| 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 or other equivalent program/project documentation. | 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 other equivalent program/project documentation to describe the technical activities in their portion of the project, but an overarching SEMP (or other equivalent program/project documentation) is needed that will describe all technical activities across the life-cycle whether contracted or not. | ||
| SE- 25 | 4.2.2 | The NASA technical team shall establish the technical inputs to the solicitation appropriate for the product(s) to be developed, including product requirements and Statement of Work tasks. | The technical team’s participation in the development of the solicitation 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. | ||
| 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 contractor documentation that specifies the contractor’s SE approach to the scope of activities described by the 17 common technical processes. | 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. | ||
| SE- 27 | 4.2.4 | The NASA technical team shall provide the requirements for technical insight and oversight activities planned in the NASA SEMP or other equivalent program/project documentation to the contracting officer for inclusion in the solicitation. | 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 life-cycle reviews. In the end the technical team needs enough information to advise the Program/Project Manager and ETA as to the adequacy of the technical work. | ||
| SE- 28 | 4.2.5 | The NASA technical team shall participate 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. | ||
| 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 contract including modifications to the original contract. | 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 (or other equivalent program/project documentation) and the contract. | ||
| 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 (or other equivalent program/project documentation) and the contract, the technical team will participate in the life-cycle reviews. Ultimately, this knowledge will enable the technical team to provide advice to the program/project and ETA as to the suitability of the product for acceptance. | ||
| SE- 31 | 4.4.2 | The NASA technical team shall participate in product transition as defined in the NASA SEMP or other equivalent program/project documentation. | In accordance with the SEMP (or other equivalent program/project documentation), 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. | ||
| SE- 32 | 5.2.1.1 | The technical team shall develop and document plans for life-cycle and technical reviews for use in the program/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/ projects progress will be assessed. This will typically be captured within the SEMP, in a separate Review Plan or other equivalent program/project documentation. | ||
| SE- 33 | 5.2.1.5 | The technical team shall participate in the life-cycle and technical reviews as indicated in the governing program/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. | ||
| SE- 34 | 5.2.2.1 | 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). 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, and risk acceptance posture. Specific names of documents may be provided for clarity, non-applicable products eliminated, and new products added as needed for clarity and completeness. | ||
| SE- 35 | 5.2.2.2.a (1) |
The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: MCR: Baselined stakeholder identification and expectation definitions. | For an 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. | ||
| SE- 36 | 5.2.2.2. a (2) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 37 | 5.2.2.2. a (3) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: MCR: Approved Measures of Effectiveness (MOE) definition. | The MOE capture the stakeholders’ 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. | ||
| SE- 38 | 5.2.2.2. b (1) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: SRR: Baselined SEMP (or other equivalent program/project documentation) 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 (or other equivalent program/project documentation) is updated with the approved comments and then baselined. The SEMP (or other equivalent program/project documentation) 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. | ||
| SE- 39 | 5.2.2.2. b (2) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 40 | 5.2.2.2.c (1) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 41 | 5.2.2.2.c (2) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: MDR/ SDR: Baselined architecture definition. | One of the key products of an 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. | ||
| SE- 42 | 5.2.2.2.c (3) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 43 | 5.2.2.2.c (4) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 44 | 5.2.2.2.c (5) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: MDR/ SDR: Baseline SEMP (or other equivalent program/project documentation) 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 (or other equivalent program/project documentation) is updated with the approved comments and then baselined. The SEMP (or other equivalent program/project documentation) 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. | ||
| SE- 45 | 5.2.2.2. d (1) | The technical team shall provide the following minimum products at the associated life-cycle 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 more documents, models, databases, drawings, and other means. Comments from the PDR will be captured in the final design for the next review. | ||
| SE- 46 | 5.2.2.2. e (1) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 47 | 5.2.2.2.f (1) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: SIR: Updated integration plan. | A key product of an SIR is the updated integration plans. These will describe how the products associated with this review will be integrated. | ||
| SE- 48 | 5.2.2.2.f (2) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: SIR: Preliminary V&V results. | Another key product of an SIR is the initial V&V 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 V&V activities. This ensures that, when they are assembled into the higher product layers, they will work as intended. Programs/projects may decide to perform V&V only at assembly levels—as captured in their SEMP (or other equivalent program/project documentation)—and so initial V&V results may or may not be available. | ||
| SE-49 and 50 | Deleted | See rationale in the Deleted Requirements Table. | |||
| SE- 51 | 5.2.2.2.g (3) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 52 | 5.2.2.2.h (1) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 53 | 5.2.2.2.h (2) | The technical team shall provide the following minimum products at the associated life-cycle review at the indicated maturity level: FRR: Baseline V&V results. | At FRR, the baselined V&V 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 V&V 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. | ||
| SE- 54 | 5.2.2.2.h (3) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 55 | 5.2.2.2.i (1) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 56 | 5.2.2.2.j (1) | The technical team shall provide the following minimum products at the associated life-cycle 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. | ||
| SE- 57 | 5.2.2.7 | Technical teams shall monitor technical effort through periodic technical 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. | ||
| SE- 58 | 6.2.3 | The technical teams shall define in the program/project SEMP how the required 17 common technical processes, as tailored, will be recursively applied to the various levels of program/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. | ||
| SE- 59 | 6.2.5 | The technical team shall ensure that any technical plans and discipline plans are consistent with the SEMP (or equivalent program/project documentation) and are accomplished as fully integrated parts of the technical effort. | Since the SEMP is the primary planning document for the SE effort, all subsequent planning documents are in alignment and consistent with the SEMP. | ||
| SE- 60 | 6.2.6 | The technical team shall establish TPMs for the program/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. | ||
| SE- 61 | 6.2.7 | 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 (or other equivalent program/project documentation). This ensures the PM and ETA are kept up to date on these key parameters so that decisions can be made in a timely manner. | ||
| SE- 62 | 6.2.8. 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 or other equivalent program/project documentation. | ||
| SE- 63 | 6.2.8. 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 or other equivalent program/project documentation. | ||
| SE- 64 | 6.2.9 | The technical team shall ensure that a set of review trends is created and maintained that includes closure of review action documentation (RIDs, RFAs, and/or Action Items as established by the project). | 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. | ||
Submitted By: Approved By: _______________________ ___________ _______________________________ __________ Program/Project Manager Date Engineering Technical Authority Date
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |