August 2011 

NASA/SP-2011-6128

Requirement Assurance: A Verification 

Process 

Michael G. Alexander 

Langley Research Center, Hampton, Virginia 
NASA STI Program . . . in Profile

 Since its founding, NASA has been 

dedicated to the advancement of aeronautics 

and space science. The NASA scientific and 

technical information (STI) program plays a 

key part in helping NASA maintain this 

important role. 

 The NASA STI program operates under the 

auspices of the Agency Chief Information Officer. It 

collects, organizes, provides for archiving, and 

disseminates NASA’s STI. The NASA STI program 

provides access to the NASA Aeronautics and Space 

Database and its public interface, the NASA Technical 

Report Server, thus providing one of the largest 

collections of aeronautical and space science STI in 

the world. Results are published in both non-NASA 

channels and by NASA in the NASA STI Report 

Series, which includes the following report types: 

 TECHNICAL PUBLICATION. Reports of 

completed research or a major significant phase 

of research that present the results of NASA 

programs and include extensive data or 

theoretical analysis. Includes compilations of 

significant scientific and technical data and 

information deemed to be of continuing 

reference value. NASA counterpart of peerreviewed formal professional papers, but having 

less stringent limitations on manuscript length 

and extent of graphic presentations. 

 TECHNICAL MEMORANDUM. Scientific 

and technical findings that are preliminary or of 

specialized interest, e.g., quick release reports, 

working papers, and bibliographies that contain 

minimal annotation. Does not contain extensive 

analysis. 

 CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

 CONFERENCE PUBLICATION. Collected 

papers from scientific and technical 

conferences, symposia, seminars, or other 

meetings sponsored or co-sponsored by NASA. 

 SPECIAL PUBLICATION. Scientific, 

technical, or historical information from NASA 

programs, projects, and missions, often 

concerned with subjects having substantial 

public interest. 

 TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific and 

technical material pertinent to NASA’s mission. 

 Specialized services also include creating custom 

thesauri, building customized databases, and 

organizing and publishing research results. 

 For more information about the NASA STI 

program, see the following: 

 Access the NASA STI program home page at 

http://www.sti.nasa.gov

 E-mail your question via the Internet to 

help@sti.nasa.gov

 Fax your question to the NASA STI Help Desk 

at 443-757-5803 

 Phone the NASA STI Help Desk at 

443-757-5802 

 Write to: 

 NASA STI Help Desk 

 NASA Center for AeroSpace Information 

 7115 Standard Drive 

 Hanover, MD 21076-1320
National Aeronautics and 

Space Administration 

Langley Research Center 

Hampton, Virginia 23681-2199 

 

August 2011 

NASA/SP-2011-6128

Requirement Assurance: A Verification 

Process 

Michael G. Alexander 

Langley Research Center, Hampton, Virginia 
Available from: 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 

443-757-5802 

Acknowledgments 

The Requirement Assurance Process presented in this report would not have been 

possible if it were not for Mr. Kevin Vipavetz, Systems Engineering and Integrations 

Office, Engineering Directorate and Mr. Kevin Kempton, Flight Software Systems 

Branch, Engineering Directorate. Mr. Vipavetz and Mr. Kempton were the Ares I-X 

Systems Engineering and Integration, Requirements and Verification Manager and 

Deputy Manager who developed the practices and procedures that are the foundation of 

this Requirement Assurance Process. The Ares I-X was a highly successful mission that 

received NASA’s prestigious “Systems Engineering Technical Excellence” Award in 

2010. 
iii 

Abstract 

Requirement Assurance is an act of requirement verification which assures the stakeholders that 

a product requirement has produced its "as realized product" and has been verified with 

conclusive evidence. Product requirement verification answers the question, "did the product 

meet the stated specification, performance, or design documentation?". In order to ensure the 

system was built correctly, the practicing system engineer must verify each product requirement 

using verification methods of inspection, analysis, demonstration, or test. The products of these 

methods are the "verification artifacts" or "closure artifacts" which are the objective evidence 

needed to prove the product requirements meet the verification success criteria. 

Institutional direction is given to the System Engineer in NPR 7123.1A NASA Systems 

Engineering Processes and Requirements with regards to the requirement verification process. 

In response, the verification methodology offered in this report meets both the institutional 

process and requirement verification best practices. 

 
 
v 

Table of Contents 

1 Introduction ............................................................................................................................ 1

1.1 Purpose ............................................................................................................................. 1

1.2 History .............................................................................................................................. 1

1.3 Requirement Assurance Process Overview ...................................................................... 1

1.4 Verification Hierarchy ...................................................................................................... 3

2 NPR 7123.1A Process ............................................................................................................. 3

2.1 Product Verification Process ............................................................................................ 4

3 Requirement Assurance Process ............................................................................................. 4

3.1 Requirement Owner ......................................................................................................... 5

3.2 Product Verification Preparation ...................................................................................... 6

3.2.1 Verification Matrix ................................................................................................... 6

3.2.2 Verification Compliance Sheet ................................................................................. 7

3.2.3 Workbook ................................................................................................................. 8

3.2.4 Cross Reference Table .............................................................................................. 8

3.3 Product Verification Execution ........................................................................................ 8

3.4 Product Verification Analysis of Outcomes ..................................................................... 9

3.4.1 Discrepancy or Non-Conformances .......................................................................... 9

3.4.2 Closure Artifacts ....................................................................................................... 9

3.4.3 Result Summary ........................................................................................................ 9

3.5 Product Verification Report Preparation ........................................................................ 10

3.5.1 Verification Compliance Document ....................................................................... 10

3.6 Work Product Capture .................................................................................................... 10

4 Conclusion ............................................................................................................................ 11

References .................................................................................................................................... 12

Acronyms ...................................................................................................................................... 12

Definitions..................................................................................................................................... 13

Appendix A: Verification Compliance Sheet Examples .............................................................. 15

Appendix B: Verification Matrix Example ................................................................................... 31
vi 

List of Figures 

Figure 1 - Requirement Assurance Verification Process ................................................................ 2

Figure 2 - NPR 7123-1A Product Verification Process .................................................................. 4

Figure 3 - NPR 7123.1A and Requirement Assurance Process Integration ................................... 5

List of Tables 

Table 1 – Cross Reference Table Example ..................................................................................... 8
1 

1 Introduction 

The verification process is an important, fundamental element in systems engineering (Ref 1.) 

and critical to a successful closure of the project’s requirements. When the requirements are 

developed early in the project’s life cycle, the verification methods are defined. These methods 

used in verifying product requirements are inspection, analysis, demonstration and test (Ref 2). 

Requirement verifications are defined as proof of compliance with specifications. The resultant 

products of the verification methods are documents that contain the closure artifacts 

demonstrating proof of compliance. 

The Requirement Assurance (RA) verification process is built around the Verification 

Compliance Sheets (VCS) as seen in Appendix A. This process establishes an auditable 

verification trail concluding in the absolute verification of requirements and meeting the 

institutional guidance given in NPR 7123.1A NASA Systems Engineering Process and 

Requirement (Ref. 3). This report articulates the RA process from its initial implementation until 

the final submittal of the Verification Compliance Document (VCD). 

1.1 Purpose 

The purpose of this report is to define the Requirement Assurance verification process 

establishing a proven product requirement verification methodology that meets NPR 7123.1A 

guidelines which are applicable to any size project and works across all WBS levels. 

1.2 History 

The Requirement Assurance verification process described herein is adapted from the ARES 1-X 

project verification process. The ARES 1-X mission was selected as the first suborbital 

development flight test to help meet Constellation Program (CxP) objectives. The ARES 1-X 

was launched successfully on October 28, 2009, from the NASA Kennedy Space Center in 

Florida. 

1.3 Requirement Assurance Process Overview 

At each Work Breakdown Structure (WBS) level (system, element, subsystem, etc.), product 

requirements are defined and subsequently placed in the appropriate WBS level requirements 

document. At this time, the system engineer chooses the best verification method to verify each 

requirement. Once the requirement document is approved by the WBS level manager, the 

system engineer ensures the development and approval of a verification plan. This plan is 

created at each WBS level and details the Requirement Assurance verification process (Figure 1) 

and its execution at that level. 
2 

Figure 1 - Requirement Assurance Verification Process 

A key to the success of Requirement Assurance is the Requirement Owners (RO). Requirement 

Owners are assigned by the WBS level project manager to specific requirements as subject 

matter experts. In addition, the ROs are responsible to ensure assigned requirements are verified 

in accordance with the verification plan and the Verification Matrix (VMX). 

The VMX is typically a spreadsheet that contains the requirement’s pre-verification data that is 

needed to perform the product requirement verification such as the verification scope 
3 

(requirement), success criteria, rational, and etc. Based on a small project size and project 

management approval, some system engineer practitioners have continued to populate the VMX 

with verification data and submitted it as the project’s VCD. 

Once the information in the VMX is approved or concurred with, the data can be transferred 

using the mail merge function to the Verification Compliance Sheet (VCS) which is typically a 

Microsoft Word document. Each row of the VMX spreadsheet is a requirement verification and 

after the mail merge the requirement verification now has its own VCS. The pre-verification 

data-filled VCSs are organized and bound together to create a verification workbook for each 

RO. At this time, the VCS are partially completed and are not an official VCS until completely 

filled out and approved. 

The RO workbook is an unofficial working level document given to the RO to record notes, 

results, data, and any information the RO deems necessary to support the verification of a 

product requirement. When the RO approves the verification artifact(s) and populates the VCS 

with final data, the RO submits the VCS to the system engineer for requirement verification 

approval. 

The system engineer places the approved VCSs into the appropriate WBS level Verification 

Compliance Document (VCD) and submits the VCD to the project for approval and baselining 

upon completion. When approved, the requirements listed in the VCD are verified and closed. 

1.4 Verification Hierarchy 

As requirements are allocated down the WBS levels, each lower level WBS verification supports 

the verification of that WBS level and its parent requirement’s verification. To ensure this 

verification hierarchy flow is not compromised, the responsibility of the RO at each WBS level 

is to ensure all of his/her assigned requirement verifications also support the parent 

requirement’s verification. However, the greater verification responsibility lies with a System 

level RO who is verifying the system and determining whether all verifications (including lower 

level WBS verifications) support the assigned system requirements. The System level RO 

declares his/her assigned system requirements are verified when the system level verifications 

and the lower WBS level allocated requirement verifications are approved. 

2 NPR 7123.1A Process 

The Product Verification Process in NPR 7123.1A can be found in section C.2.3: “The product 

verification process is used to demonstrate that an end product generated from product 

implementation or product integration conforms to its design solution definition requirements as 

a function of the product-line life-cycle phase and the location of the WBS model end product in 

the system structure. Special attention is given to demonstrating satisfaction of the Measure of 

Performances (MOPs) defined for each Measure of Effectiveness (MOE).” 
4 

“A typical process flow diagram for product verification is provided in Figure 2 (Figure C-8 

from NPR 7123.1A) with inputs and his/her sources and the outputs and his/her destinations. The 

activities of the product verification process are truncated to indicate the action and object of the 

action.”

Figure 2 illustrates the Product Verification Process as defined in section C.2.3.4 of NPR 

7123.1A. The figure shows the requirement verification activities that the Requirement 

Assurance process must meet. 

2.1 Product Verification Process 

Figure 2 - NPR 7123-1A Product Verification Process 

 (* NPR 7123-1A section number) 

3 Requirement Assurance Process 

The Requirement Assurance (RA) process is a product requirement verification process that 

allows the WBS level system engineers to create a verification process that can be scaled to fit 

the project size and tailored to meet the project needs. The RA process is mapped (Figure 3) to 

its applicable NPR 7123.1A Activity†

 which demonstrates the RA process is in compliance with 

the guiding document. 

Prepare to Conduct Product Verification

*C.2.3.4a

Perform Product Verification

*C.2.3.4b

Analyze the Outcomes of the Product 

Verification

*C.2.3.4c

Prepare a Product Verification Report

*C.2.3.4d

Capture the Work Products from Product 

Verification

*C.2.3.4e

Activity

Product Verification Enabling 

Products

C.2.3.2d

From Existing Resources or 

Product Transition Process

Product Verification Plan

C.2.3.2c

From Design Solution and 

Technical Planning Processes

Specified Requirements 

Baseline

C.2.3.2b

From Configuration 

Management Process

End Products to Be Verified

C.2.3.2a

From Product 

Implementation Process or 

Product Integration Process

Product Verification Work 

Products

C.2.3.3d

Verified End Products 

C.2.3.3a

To Product Validation 

Process

Product Verification Results

C.2.3.3b

To Technical 

Assessment Process

Product Verification Results

C.2.3.3c

To Technical Data 

Management Process

†
5 

3.1 Requirement Owner 

Every requirement has a Requirement Owner (RO) assigned by the WBS level project manager. 

The RO is considered the subject matter expert of that requirement and is responsible to ensure 

assigned requirements are verified. The RO can delegate the responsibility to perform/record the 

verifications for which he/she is responsible. When the VCS is completed, the RO reviews it for 

completeness and accuracy and approves the closure artifacts as the conclusive proof/evidence 

necessary to verify the requirement. The RO submits the VCS to the WBS level system engineer 

for verification approval. 

 

Figure 3 - NPR 7123.1A and Requirement Assurance Process Integration 

Analyze the Outcomes of the Product 

Verification

C.2.3.4c

RO completes and 

submits VCS to 

SE for verification 

approval

RO identifies 

verification 

documents and 

concurs with 

verification 

procedures

C.2.3.4b

Perform Product Verification

RO or designee 

conducts 

Verification Event

Prepare to Conduct Product Verification

C.2.3.4a

Requirement 

Document

Verification 

Plan

Interface 

Requirement Misc.

SE submits VMX 

for approval

SE populates VCS 

with pre 

verification data 

from VMX

SE creates & 

distributes 

Requirement 

Owner’s (RO) 

workbooks

System Engineer 

(SE) develops 

Verification Matrix

(VMX) with preverification data
6 

3.2 Product Verification Preparation 

In preparing to conduct requirement verifications, NPR 7123.1A section C.2.3.4a directions 

suggest the following: 

“(1) reviewing the verification plan for any specific procedures, constraints, conditions 

under which verification will take place, pre- and post-verification actions, and criteria for 

determining the success or failure of verification methods and procedures; 

(2) arranging the needed product-verification enabling products and support resources; 

(3) obtaining the end product to be verified; 

(4) obtaining the specification and configuration baseline against which the verification is to 

be made; and 

(5) establishing and checking the verification environment to ensure readiness for 

performing the verification.”

In the Requirement Assurance process, the verification phase does not begin until the 

requirement document and verification plan have been approved. The suggested review topics in 

(1) above are conducted as a part of the verification event planning effort. 

Directions given in (2), (3), and (4) occur during the initial planning of the verification method 

activity and are added to the verification method’s procedure(s) as a check-off. The evidence of 

meeting (2), (3), and (4) in section C.2.3.4a is found in the closure documentation (procedure, 

process, checklist, etc.). 

3.2.1 Verification Matrix 

The Verification Matrix (VMX) (Appendix B - Figure B1) is a document that contains all the 

requirement pre-verification data needed to perform the requirement verification. It establishes 

the verification scope (requirement), success criteria, rational, traces, and environments of who, 

what, when, and where the verification event is to occur. The VMX is an optional document1

depending on the verification strategy of the project. The RO is responsible to provide the preverification data and the system engineer works collaboratively with the RO. Once submitted, 

the system engineer can directly populate the VCSs, or uses the VMX as suggested to hold all 

the pre-verification data and mail merges it into the VCS. If the project is small, the system 

engineer can develop the VMX directly into a VCD. 

To fulfill (5) of section C.2.3.4a (establishing and checking the verification environment to 

ensure readiness for performing the verification), a VMX is constructed at each WBS level using 

a spreadsheet. The VMX should not be confused with the Verification Cross Reference Matrix 

found in a WBS level requirement document. When the VMX is fully populated with preverification data, the WBS level system engineer can submit the VMX to the project to baseline 

all the pre-verification data. Another example of a VMX is found in reference 2 in Appendix D. 

 

1

 This SP assumes the Verification Matrix (VMX) is being used to hold pre-verification data. 
7 

From section C.2.3.3c, the VMX will have a minimum set of pre-verification information for 

each product requirement verification: 

“(1) the source paragraph references from the baseline documents for derived technical 

requirements, technical requirements, and stakeholder expectations; 

(2) bidirectional traceability among these sources (NOTE: The system engineer can place 

traces to IRDs or ICDs); 

(3) verification type(s) to be used in performing verification of the specified requirement; 

(4) reference to any special equipment, conditions, or procedures for performing the 

verification”; 

(5) verification scope (verification requirement); 

(6) verification success criteria (containing any MOPs or MOEs); 

(7) the approximate date when the closure artifact/document will be available; 

(8) anticipated scheduled occurrence of the verification event; 

(9) requirement number; 

(10) requirement text; 

(11) requirement owner’s name; and 

(12) any other information the system engineer requires such as a verification rationale. 

3.2.2 Verification Compliance Sheet 

When the project approves the requirement pre-verification data in the VMX, the system 

engineer accomplishes a simple mail merge between the VMX spreadsheet and the word 

processor’s VCS which populates the VCS with all the required pre-verification information. 

The system engineer collates the pre-verification VCSs by RO and places them in an electronic 

workbook (typically a Microsoft Word file) specific for each RO. A pre-verification VCS is 

observed in Appendix A, Figure A-1. 

When the verification event occurs and the VCS is populated with the final verification 

information (Result Summary and Closure Artifacts/Document sections, etc.), it becomes the 

requirement’s verification approval/closure documentation. As the RO or designee completes 

the VCS, the amount or type of data presented in the VCS, as seen in Appendix A, Figures A-2 

through A-5, is unrestricted. The RO approves each closure artifact and reviews the VCS prior 

to sending it to the WBS level system engineer for verification approval. 
8 

3.2.3 Workbook 

The workbook is an unofficial working level word processing document (typically Microsoft 

Word) created by the system engineer for the RO. The workbook contains all the RO’s assigned 

verifications as VCSs as well as any other supportive information. These VCSs are first 

populated with the required pre-verification data and then placed in the workbook. The 

workbook allows the RO to record, highlight, add working notes, and any information deemed 

necessary to support the verification of a requirement. 

3.2.4 Cross Reference Table 

Prior to a verification event such as testing, concurrence by the RO or his/her designee should be 

required in the procedure’s or process’s signature page which signifies that all applicable 

requirements for that event are identified and included in the procedure or process. A table 

should exist in the procedure or process similar to the Cross Reference Table example seen in 

Table 1 below that identifies the requirement and where its verification is located. 

Requirement 

Number being 

Verified 

Closure Document 

Page Number 

Closure 

Document 

Section 

Closure Document 

Procedure Step 

Number 

AI1-CML-009 14 1.2.3 N/A 

DTO2-AV-1029 17 3.2.4.1a 25 and 26 

HYT-008 35 4.5.1.2.e 3 

Table 1 – Cross Reference Table Example 

3.3 Product Verification Execution 

In accordance with NPR-7123.1A section C.2.3.4b: “Perform the product verification in 

accordance with the product verification plan and defined procedures to collect data on each 

specified requirement with specific attention given to Measure of Performance (MOPs).” 

When the verification event occurs, its outcome is measured against the requirement’s 

verification success criteria found in the VCS’s Verification Success Criteria section. Upon the 

event’s conclusion, the RO takes the workbook and completes the Result Summary and Closure 

Artifact/Document sections in the VCS. When the closure document (“as run” procedure, signed 

off reports, “as built drawings”, etc.) or closure artifact becomes available, the RO places a copy 

of it onto the project’s server and adds its filename and server URL to the Closure 

Artifact/Document section of the VCS (Appendix A, Figure A4). Once the VCS is completed 

and the RO has approved the closure artifact(s) or document, the VCS is submitted to the system 

engineer for verification approval. 
9 

3.4 Product Verification Analysis of Outcomes 

In accordance with NPR-7123.1A section C.2.3.4c: “Analyze the outcomes of the product 

verification, including identifying verification anomalies, establishing recommended corrective 

actions, and establishing conformance to each specified requirement under controlled 

conditions.” 

Further direction is given from section 2.3.3c of the NPR-7123.1A, “...(5) results of verification 

conducted; (6) variations, anomalies, or out-of-compliance results; (7) corrective actions taken; 

and (8) results of corrective actions.” 

The verification outcome analysis occurs following the completion of the verification event 

where the results are compared to the verification success criteria. When the analysis and 

comparisons are completed, the RO writes the results in the VCS Results Summary section. If a 

discrepancy or non-conformance is found, then it is entered in the WBS level non-conformance 

resolution process for corrective action. The VCS is left open until resolution. 

3.4.1 Discrepancy or Non-Conformances 

When the verification outcome is compared to the success criteria and the verification anomalies 

are observed, the RO ensures the product is entered into a recognized institutional nonconformance process which establishes corrective actions that must occur prior to the approval 

of the product/requirement verification. 

All non-conformances and discrepancies such as any procedural, equipment, operator or setup 

problems, etc., are annotated in the requirement’s VCS “NFR” section. The requirement cannot 

be verified until all non-conformances have been officially closed by corrective action or by an 

approved variance (waiver or deviation). Non-conformance and discrepancy actions and results 

are placed in the Results Summary section of the VCS by the RO. 

3.4.2 Closure Artifacts 

The closure artifact is the conclusive and indisputable evidence used during the outcome analysis 

that proves the requirement verification. Closure artifacts are stand alone “artifacts” or found in 

a closure document. These closure documents may be test, analysis or demonstration reports, 

“as-run” procedures, ”as built” drawings, and in some cases, photographs. However, design 

drawings and procedures without signatures or Quality Assurance sign-offs are not acceptable as 

closure documents or artifacts. The closure artifact and document references are found in the 

Closure Artifact/Document section of the VCS. 

3.4.3 Result Summary 

The Requirement Owner or designee writes a summary of the verification result of each test, 

analysis, demonstration, inspection, corrective actions, etc., for that requirement. It should make 

“reference to any special equipment, conditions, or procedures for performing the verification.” 

Enough written information should be evident so the reader has a basic understanding of what 
10 

occurred for this requirement’s verification. The RO is not restricted on the type of information 

or the use of references included or the length of this section. 

3.5 Product Verification Report Preparation 

In accordance with NPR-7123.1A section C.2.3.4d: “Prepare a product verification report 

providing the evidence of product conformance with the applicable design solution definition 

specified requirements baseline to which the product was generated, including bidirectional 

requirements traceability and actions taken to correct anomalies of verification results.”

To meet this guidance, the Verification Compliance Document (VCD) is developed using 

information from section C.2.3.4d. The recommended content of this document (report) can be 

found in section 2.3.3c. of NPR-7123.1A. 

3.5.1 Verification Compliance Document 

When the verification data matures and the closure artifacts are approved, the RO completes and 

delivers the VCS to the system engineer for verification approval. The WBS level system 

engineer reviews the information on the VCS for completeness, accuracy, and details, and the 

closure artifacts for approval. If the system engineer cannot approve the VCS, the system 

engineer works with the RO to resolve any issues such that the requirement verification obtains 

approval. 

After all the VCSs have been submitted and approved by the system engineer, the Verification 

Compliance Document (VCD) is developed by the WBS level system engineer by placing the 

approved VCSs within the document. The system engineer submits the VCD to the appropriate 

WBS level approval authority for baselining. After baselining, the requirements and closure 

artifacts are closed. 

. 

3.6 Work Product Capture 

In accordance with NPR-7123.1A section C.2.3.4e: “Capture the work products from the 

product verification. Note: Work products include verification outcomes; records of procedural 

steps taken against planned procedures; any failures or anomalies in the planned verification 

procedures, equipment, or environment; and records citing satisfaction or non-satisfaction of 

verification criteria. Also, records should document: 

(1) the version of the set of specification and configuration documentation used; 

(2) the version of the end product verified; 

(3) the version or standard for tools and equipment used, together with applicable 

calibration data; 

(4) results of each verification including pass or fail declarations; and 

(5) discrepancies between expected and actual results.” 
11 

The products listed from section C.2.3.4e and seen from (1) through (5) are found in the VCD. 

When a VCD is approved and baselined, all closure artifacts and documents are made available 

and archived in accordance with the WBS level data management or verification plan. 

4 Conclusion 

The Requirement Assurance process presented provides the system engineering practitioner a 

process that ensures product requirement verification that meets NPR 7213.1A direction. This 

process is mapped into the NPR 7213.1A section C.2.3 - Product Verification Process which 

provides a confidence of applicability. The Requirement Assurance verification process defines 

and demonstrates how the process components fit within each Activity in section C.2.3. This 

verification process easily allows product requirement verification to occur on one Verification 

Compliance Sheet or multiple continuation sheets. In addition to its effectiveness, this method 

can be scaled to any size project and tailored for any WBS level (system, element, subsystem, 

etc.). This process integrates with industry standard requirements and Systems Engineering 

tools. 

 
12 

References 

1. Hooks, Ivy F.; and Farry, Kristin A.: Customer Centered Products: creating successful 

products through smart requirements management. AMACOM, 2001, pp.103-107. 

2. NASA SP/2007-6105 Rev1.; NASA System Engineering Handbook; 2007, pp. 86. 

3. NPR 7123.1A.; NASA Systems Engineering Process and Requirement w/Change 1 

(11/04/09), March 26, 2007. 

Acronyms 

ERD Element Requirement Document 

IAW In Accordance With 

ICD Interface Control Document 

IRD Interface Requirement Document 

LPR Langley Procedural Requirement

MOE Measure of Effectiveness 

MOP Measure of Performance 

NFR Non-conForm ance Report 

NPR NASA Procedural Requirement 

RA Requirem ent Assurance 

RO Requirem ent Owner 

SE System Engineer 

SRD System Requirements Document 

VCD Verification Compliance Document 

VCS Verification Compliance Sheet 

VMX Verif ication MatriX 

WBS Work Breakdown Structure 

 
13 

Definitions 

Applicable documents: - Further sources of detailed information for meeting this verification 

(e.g., NASA test or analysis standards, project documents, etc.) 

Closure Artifact: - This is the basic datum that is the conclusive proof or evidence by which the 

requirement is verified and closed. A closure artifact can be where a MOP or MOE has clearly 

shown with independent assurance (typically a Quality Assurance sign-off) has been met. The 

closure artifact is under configuration control and cannot change. In some rare instances, the 

closure artifact can be the closure document (i.e. inspection sheet). 

Closure Documents: – A document that contain the closure artifact(s) used to conclusively 

prove the requirement was verified. closure documents include test reports, analysis reports, 

inspection reports, and as-run procedures, as-built drawings, etc. In some rare instances, the 

closure document can be the closure artifact (i.e. test report or “as run” procedure). 

Measure of Effectiveness (MOE): – A measure by which a stakeholder’s expectations are 

judged in assessing satisfaction with products and systems produced and delivered in accordance 

with the associated technical effort. The MOE is deemed to be critical to not only the 

acceptability of the product by the stakeholder, but also critical to the operational / mission 

usage. An MOE is typically qualitative in nature or not able to be used directly as a “design-to” 

requirement. 

Measure of Performance (MOP): – A quantitative measure that, when met by the design 

solution, will help ensure that an MOE for a product or system will be satisfied. These MOPs are 

given special attention during design to ensure that the MOEs to which they are associated are 

met. There are generally two or more measures of performance for each MOE. 

NFR: - This is a non-conformance report written against a verification anomaly which must have 

corrective action done prior to verification approval. 

Requirement Owner: - This person is the subject matter expert of his/her assigned 

requirements. They’re also responsible to ensure assigned requirements are verified. They also 

approve closure artifacts. 

Scheduled Activity: - The activity on the project schedule where the verification event should 

occur. The verification event does not necessarily need to be scheduled on the project schedule, 

just tied to and existing one. This information is used to help manage verification activities 

where there may be multiple verifications occurring at a single facility or resource. This 

information is not used to measure performance or delivery dates. 

Verification Rationale: – An explanation and justification for “why” the specific method, 

success criterion, measure, constraints, conditions, and assumptions were stated. 

Verification Scope or Requirement: - Description of the work to be performed, described in 

one or more “shall” statements (requirements) stating the measure (a parameter, quantity, or 

condition) for the verification success criterion. This part should state how to obtain (generally, 

not calling out a specific tool) values or states for this measure. This part may state required 

assumptions and conditions for the verification. 
14 

Verification Success Criteria: - A single “shall” statement (requirement) stating the required 

criterion (MOPs/MOEs) for the verification to be considered successful in terms of the measure 

for the success criterion. 

WBS level: - Level(s) of assembly at which the requirement will be verified (e.g., system, 

element, subsystem, etc.). 

 
15 

Appendix A: Verification Compliance Sheet Examples 

Appendix A contains example of VCSs. Figure A-1 is an example of a VCS completed with 

only “pre-verification data” that goes into the Requirement Owner’s workbook. Figures A-2 

through A-5 are examples of a completed VCS of different project sizes and WBS levels.

Figure A-1 

Verification Compliance Sheet (Workbook Example) 

Populated with Pre-Verification Data 

Requirement Title: 

Bending Stiffness Profile 

Requirement No.: 

CML-062 

Verification Method: 

Analysis 

Requirement Text: The CM/LAS 

bending stiffness shall be within +/- 

10% of the EI profile shown in the 

CM/LAS portion of the SRD 

requirement FTV-008. 

Parent Rqmt: 

FTV-008, 011

Description of Verification Activity (Verification Scope):CM/LAS personnel shall show by 

analysis found in AI1-CML-SAR-CM that the joint stiffness between the CM/LAS and USS is 

greater than 20% of the adjacent sectional bending stiffness. 

Note: USS personnel will also analyze this joint since it is shared between the CM/LAS and USS 

IPTs (Requirement ICMLAS-USS.003 in AI1-IRD-C2U). The CM/LAS analysis results will be 

compared with those obtained by Upper Stage Simulator (USS). Modal test data obtained by 

SE&I for the Stack 5 hardware in the VAB will provide additional, corroborating information for 

these analyses.

.

Verification Success Criteria: The verification shall be successful when the joint stiffness 

between the CM/LAS and USS is shown by analysis to be greater than 20% of the adjacent 

sectional bending stiffness and the CM/LAS results compare well with the USS results.

Rationale: Simulation using independent and validated analysis tools and techniques (by both 

CM/LAS and USS IPTs) is an accepted method to verify requirements for such properties that 

can only be accurately tested at an assembly level. Modal test data for Stack 5 at KSC will be 

available from SE&I to substantiate the analysis results.

Result Summary (Compliance Statement): 

Closure Artifact/Document(s): 

Waivers/ (NFRs): Requirement Owner: Verification Closed 

 
16 

Figure A-2 (Large Project Example) 

Verification Compliance Sheet (System level) 

Ares I–X FTV System 

Verification Requirement Definition Sheet

FTV SRD Requirement to be Verified 

Verification 

Number: 

VR-FTV-001 

Requirement Number: 

FTV-001 

Requirement Title: FTV Elements 

Verification Requirements 

Verification method: Verification that the FTV consists of the following elements (CM/LAS, USS, RoCS, FS, 

& Avionics) shall be by Inspection.

Description of verification activities to be performed: 

The Ares I-X Vehicle Assembly and Integration Lead will review final designs that have been 

approved at the Ares I-X CDR to verify inclusion of the five listed elements. 

The Ares I-X Interface Custodians shall review artifacts from each IPT showing compliance with 

his/her side of the interfaces defined in the applicable Element to Element IRD. When all elementlevel interface requirements associated with an Element to Element IRD have been verified to his/her 

satisfaction, each Interface Custodian shall provide a summary of the interface verifications to the 

Ares I-X Lead Systems Engineer. The summary report shall include any waivers or deviations to the 

interface requirements. 

 The Ares I-X Lead Systems Engineer shall review the interface verification summary reports and the 

integrated vehicle drawing to verify that the FTV is constructed from the five elements listed.

Success Criterion: 

CDR approved design of the Ares I-X FTV includes the five elements listed in FTV-001 and Interface 

Verification Summary Reports for all Element to Element IRDs. 

Rationale: 

Verification by inspection of CDR designs is appropriate for the requirement.

Verification Implementation 
17 

Level: The Ares I-X FTV System does comply with FTV-001. See attached compliance statement. 

Applicable documents: 

CDR Data from all FTV IPTs. 

Nonconformance history: List any waivers below; address them later in the compliance statement.

 CR-AIX-0344 “CM/LAS CM Flange Flatness Local Exceedance. (AIX-IRD-C2U [ICMLASUSS.001.5] Flatness)” 

 CR-AIX-0359 “USS SM to CM/LAS Mechanical Interface” 

 CR-AIX-0363 “USS US-1 US RCS Cover Protuberance Pressure Transducer with No 

Bonding Check” 

 Plus 50 Element IRD/ICD waivers, listed in the Interface Custodian Verification Summary 

reports in Section 1.2

Closure data/documentation required: 

Electronic/Written confirmation from the Ares I-X Lead Systems Engineer that the approved CDR 

design includes the required elements and that the element to element interfaces have been verified.

 

Event preceding Verification Activity: 

Element to Element Interface Requirements are closed. 

Estimated Duration of Verification Activity: 5 Days 

Closure Of FTV SRD Requirement 

Requirement Owner: 

Richard Harris 

(with compliance statement write-up support 

from Paul Luz) 

Systems Engineer: 

Cheryl Harrison 

Technical Management Approval: 

Joe Smith 

Date Closed: _____________

S&MA Approval: 

Dave Jones

SE&I Lead Engineer Approval: 

Stewart Long

Compliance Evaluation for Ares I-X Verification Number: VR-FTV-001 “FTV Elements” 

The Ares I-X FTV is in compliance with requirement FTV-001, “The FTV shall consist of the 

following five elements: FS, USS, CM/LAS, Avionics, and RoCS.” A summary of the analysis 

and a review of verification artifacts are provided below. 

The design snapshot below and photographic evidence on the next page show compliance with 

paragraph 1 of 3 in the Verification Requirement Definition Sheet (VRDS) for requirement VRFTV-001, which states, “The Ares I-X Vehicle Assembly and Integration Lead will review final 

designs that have been approved at the Ares I-X CDR to verify inclusion of the five listed 

elements.” 
18 

Ares I-X High Level Poster/Drawing

E-mail from Bruce Askins, the Ares I-X Project Integration Manager, “The high level Ares I-X 

posted has been updated to reflect the configuration and detail as of 9/1/08 by Jonathan Behun 

with contributions from Terry White and Roosevelt Wright. It is set-up where it can be printed 

as a 22 x 36 poster. 2 

Ares I-X top level assembly drawing is 1264846. 

NASA KSC Media Photo release KSC-2009-4954 on August 31, 2009

 “CAPE CANAVERAL, Fla. – Work platforms surround the Ares I-X launch vehicle in the 

Vehicle Assembly Building's High Bay 4 at NASA's Kennedy Space Center in Florida. The rocket 

has undergone a sway test that simulated conditions the rocket could experience during rollout 

to Launch Pad 39B...”

 

2

 Ares I-X Project Integration Manager Bruce Askins, e-mail to NASA-DL-AresIX-Primary-Contacts distribution 

list, “Ares I-X High Level Poster/Drawing Update”, September 22, 2008 at 6:39 AM. 
19 

Bottom line: All 5 elements have been delivered and assembled, demonstrating that requirement 

FTV-001 has been fulfilled. For a summary recap that lists when each element was delivered, 

please see Section 5.0. 

Paragraph 2 of 3 in the VRDS for FTV-001 states, “The Ares I-X Interface Custodians shall 

review artifacts from each IPT showing compliance with his/her side of the interfaces defined in 

the applicable Element to Element IRD. When all element-level interface requirements 

associated with an Element to Element IRD have been verified to his/her satisfaction, each 

Interface Custodian shall provide a summary of the interface verifications to the Ares I-X Lead 

Systems Engineer. The summary report shall include any waivers or deviations to the interface 

requirements.” 

 
20 

Interface Requirement 

Documents (IRDs) 

Interface Custodian Delivery Date

Interface Custodian’s Summary Report 

delivered to the Ares I-X LSE 

USS to CM/LAS 

(AI1-IRD-C2U v3.01) 

LaRC/ Mark McMillin 2009-10-16 via e-mail, AI1-SYS-IVSR. 

3 CM/LAS waivers, all were approved by 

XCB. 

USS to Roll Control 

(AI1-IRD-R2U v2 04) 

LaRC/ Mark McMillin 2009-10-16 via e-mail, AI1-SYS-IVSR. 

3 RoCS waivers, all were approved by XCB. 

USS to First Stage 

(AI1-IRD-U2F v2.02) 

LaRC/ Mark McMillin 2009-10-16 via e-mail, AI1-SYS-IVSR. 

4 FS waivers, all were approved by XCB. 

Flight Test Vehicle to 

Ground Systems 

(AI1-IRD-F2G v5.05) 

JSC / Jim Wiehoff 2009-10-20

9 GS waivers, all were approved by XCB. 

Avionics to Ground 

System (AI1-IRD-F2G 

Appendix I v5.05) 

LaRC / Jose Ortiz 2009-10-13 via e-mail. 

1 waiver; it was approved by XCB. 

Lockheed Martin Ground 

Command, Control, 

Communications (GC3) 

To NASA Ground 

Element (AI1-IRD-F2G 

Appendix II v5.05) 

LaRC / Jose Ortiz 2009-10-13 via e-mail. 

1 waiver; it was approved by XCB. 

Avionics to Flight Vehicle 

Elements 

(AI1-ICD-A2V v5.0) 

LaRC / Jose Ortiz 2009-10-13 via e-mail. 

28 waivers, all were approved by XCB. 

Paragraph 3 of 3 in the VRDS for FTV-001 states, “The Ares I-X Lead Systems Engineer shall 

review the interface verification summary reports and the integrated vehicle drawing to verify 

that the FTV is constructed from the five elements listed.” 

In regard to the LSE review of interface verification summary reports is covered by XCB 

Approval. 

In regard to the LSE review of the integrated vehicle drawing to verify that the FTV is 

constructed from the five elements listed, please see the drawing and photograph provided within 

Section 1.1. Bottom line: All 5 elements have been delivered and assembled, demonstrating that 

requirement FTV-001 has been fulfilled. For a summary recap that lists when each element was 

delivered, please see Section 5.0. 
21 

Requirement Recap

Ares I-X requirement FTV-001 is documented in the “System Requirements Document for the 

Ares I-X Flight Test Vehicle”, AI1-SYS-SRD v4.15a, December 7, 2008, pp28-29: 
22 

Trace Analysis

Table 3.0-1 IPT Children Requirements that were traced to SRD Requirement FTV-001 

Child Reqmt Title Disposition 

CML 

CML-001 CM/LAS Sub-Elements Submitted to the XCB via CR-AIX-0435. 

Approved by XCB 20090625 

RAVEN comment: “Closed 9/24 per Barry”

RoCS 

RoCS-037 RoCS Installation 

Submitted to the XCB via CR-AIX-0313. 

Approved by XCB 20090605.

RoCS-039 RoCS Ordnance 

RoCS-040 RoCS Engine 

USS 

USS-001 USS Element Simulators Submitted to the XCB via CR-AIX-0318. 

Approved by XCB 20090331 

USS-041 RoCS Interfaces Submitted to the XCB via CR-AIX-0463. 

Approved by XCB 20090728.

USS-053 FS Mechanical Interfaces Submitted to the XCB via CR-AIX-0570. 

Approved by XCB 20090929.

USS-054 CM/LAS to USS Mech. 

Interfaces 

Submitted to the XCB via CR-AIX-0463. 

Approved by XCB 20090728 

USS-055 Avionics Structural Interfaces Submitted to the XCB via CR-AIX-0570. 

USS-056 Avionics G&B Interfaces Approved by XCB 20090929.

USS-115 FS to USS Interface Markings Submitted to the XCB via CR-AIX-0377. 

Approved by XCB #USS AR (XCB 20090505).

USS-117 FS Human Access Submitted to the XCB via CR-AIX-0570. 

Approved by XCB 20090929.

USS-118 CM/LAS to USS Interface 

Markings Submitted to the XCB via CR-AIX-0348. 

Approved by XCB 20090421 

USS-119 CM/LAS to USS Human Access 

USS-120 RoCS to USS Electrical Bonding Submitted to the XCB via CR-AIX-0377. 
23 

Child Reqmt Title Disposition 

USS-121 FS to USS Electrical Bonding Approved by XCB #USS AR (XCB 20090505).

USS-122 CM/LAS to USS Electrical 

Bonding 

Submitted to the XCB via CR-AIX-0348. 

Approved by XCB 20090421 

USS-124 RoCS Mass Interface Submitted to the XCB via CR-AIX-0377. 

Approved by XCB #USS AR (XCB 20090505).

USS-125 RoCS Human Access Interface Submitted to the XCB via CR-AIX-0377. 

Approved by XCB #USS AR (XCB 20090505).

AVI 

AVI-200 Avionics [Baseline] Submitted to the XCB via CR-AIX-0372. 

Approved by XCB 20090428.

AVI-208 USS Electrical [Baseline] Submitted to the XCB via CR-AIX-0627. 

Approved by XCB 20091020 

AVI-209 CM/LAS-Electrical [Baseline] Submitted to the XCB via CR-AIX-0404. 

Approved by XCB OSB on 20090803.

AVI-210 First Stage-Electrical [Baseline] Submitted to the XCB via CR-AIX-0627. 

Approved by XCB 20091020 

AVI-215 USS-Physical [Baseline] Submitted to the XCB via CR-AIX-0627. 

Approved by XCB 20091020 

AVI-216 CM/LAS-Physical [Baseline] Submitted to the XCB via CR-AIX-0404. 

Approved by XCB OSB on 20090803

AVI-217 First Stage-Physical [Baseline] Submitted to the XCB via CR-AIX-0574. 

Approved by XCB 20091006. 

AVI-242 FSAM [Baseline] Submitted to the XCB via CR-AIX-0627. 

Approved by XCB 20091020 

AVI-261 RoCS-Physical [Baseline] Submitted to the XCB via CR-AIX-0453. 

Approved by XCB OSB on 7-27-2009.

AVI-262 RoCS-Electrical [Baseline] Submitted to the XCB via CR-AIX-0627. 

Approved by XCB 20091020 

FS 
24 

Child Reqmt Title Disposition 

FS-001 RSRM Submitted to the XCB via CR-AIX-0583. 

FS-002 FS Safe and Arm System Submitted to the XCB via CR-AIX-0508. 

FS-003 System Tunnel Submitted to the XCB via CR-AIX-0554. 

FS-004 Aft Skirt Assembly Submitted to the XCB via CR-AIX-0583. 

FS-005 Thrust Vector Control Submitted to the XCB via CR-AIX-0554 

(Electrical) and also CR-AIX-0618 (Interstage). 

FS-008 First Stage Deceleration 

Subsystem 

Submitted to the XCB via CR-AIX-0554. 

FS-009 Nosecap Submitted to the XCB via CR-AIX-0560. 

FS-010 Thrusters Submitted to the XCB via CR-AIX-0624. 

FS-012 Parachutes Submitted to the XCB via CR-AIX-0518. 

FS-013 Booster Deceleration/Tumble 

Motor 

Submitted to the XCB via CR-AIX-0469. 

RAVEN comment: “A-PYR-6124-7/10PLN0060A-Baselined” 

FS-206 Ignition Separation Controller Submitted to the XCB via CR-AIX-0605. 

FS-207 Recovery Controller Unit Submitted to the XCB via CR-AIX-0605. 

FS-208 Heritage Altitude Switch 

Assembly 

Submitted to the XCB via CR-AIX-0605. 

FS-209 APUC Heritage Submitted to the XCB via CR-AIX-0605. 

FS-210 ISC Interface Submitted to the XCB via CR-AIX-0605. 

FS-211 RCU Interface Submitted to the XCB via CR-AIX-0605. 

FS-212 SRB Heritage ASA Submitted to the XCB via CR-AIX-0605. 

NOTE: FS verifications are considered approved upon receipt of the CR per MMO directive 

CR-AIX-0537. 

There is a subfolder for each XCB that was held. The CR’s are in the folder that corresponds to 

the date the XCB was held. For example, the RoCS IPT CR-AIX-0313 can be found in folder 

“XCB 20090605”. 

Waivers against FTV-001

This section only identifies and discusses the system-level waivers that were written directly against 

system-level verification requirement FTV-001 in the “System Requirements Document for the Ares I-X 

Flight Test Vehicle”, AI1-SYS-SRD v4.15a, December 7, 2008, pp28-29. 
25 

For a review of the element-level IRD/ICD waivers (these were waivers to the IRDs and not waivers to 

AI1-SYS-SRD), please see the Interface Custodian Verification Summary reports listed in Section 1.2. 

There were 50 IRD/ICD waivers from the elements, all of which were approved by the XCB. 

CR-AIX-0344 “CM/LAS CM Flange Flatness Local Exceedance (AIX-IRD-C2U [ICMLASUSS.001.5] Flatness)” 

 This waiver was traced to requirements FTV-001 and AI1-IRD-C2U v3.00, Section 4.1.1 

Mechanical Assembly Joint, Requirement [ICMLAS-USS.001.5] - Flatness. 

 The waiver was “Approved as presented” by XCB 20090512. 

 Conclusion: Given that this waiver really affects an IRD requirement and not the higher 

system-level requirement FTV-001, “The FTV shall consist of the following five elements: 

FS, USS, CM/LAS, Avionics, and RoCS”; and given that the waiver was approved by the 

XCB in any case; the waiver therefore does not impact the verification of FTV-001. 

CR-AIX-0359 “USS SM to CM/LAS Mechanical Interface” 

 This waiver was traced to requirements USS-054. One could argue that this waiver is 

also relevant to the verification of FTV-101 “Stack/Destack Assembly Joints”. The 

verification compliance statement for FTV-101 already does include an evaluation of this 

waiver for completeness. 

 The waiver was submitted “... to communicate several non-conformances to the SM 

segment top flange mechanical interface as documented in the CM/LAS to USS IRD, AI1-

IRD-C2U”, and specifically “Flange local flatness, Tension bolt hole spotface 

depth/flange thickness, Flange O.D. tolerance”. 

 The waiver was “Approved as presented” by XCB 20090512. 

 Furthermore, Ares I-X finished stacking CM/LAS onto USS on August 13, 2009. 

 Conclusion: Given that this waiver really affects requirement FTV-101 “Stack/Destack 

Assembly Joints” and not requirement FTV-001, “The FTV shall consist of the following 

five elements: FS, USS, CM/LAS, Avionics, and RoCS”; and given that the waiver was 

approved by the XCB in any case; the waiver therefore does not impact the verification of 

FTV-001. 

CR-AIX-0363 “USS US-1 US RCS Cover Protuberance Pressure Transducer with No 

Bonding Check” 

 This waiver was elevated from CR-AIX-DXCB-0006 “USS US-1 US RCS Cover 

Protuberance Pressure Transducer with No Bonding Check”. 

o The DXCB waiver traced to requirements FTV-001, USS-056, and AI1-ICDA2V. 

o The DXCB waiver was submitted “...to communicate one non-conformance on 

the US-1 segment for the requirement to perform a bonding check on all DFI 

sensors that are installed into segment skins and the OML protuberances.” 
26 

o The DXCB waiver was “Approved” by DXCB Chair Lanny Upton on March 23, 

2009 and elevated to the XCB as CR-AIX-0363. 

 On April 7, 2009, XCB Secretariat Heather Altizer distributed an e-mail stating: 

o “CR AIX-0363 was withdrawn per email notification from DxCB secretariat.” 

o “Waiver was dispositioned at DxCB and upon futher investigation system level 

documents identified as affected products on the DxCB waiver were not 

affected.” 

 Conclusion: Given that this waiver was withdrawn, and given XCB statement above that 

“...upon further investigation system level documents identified as affected products on 

the DxCB waiver were not affected”;the waiver therefore does not impact the verification 

of FTV-001.

 
27 

Example A-3 (Large Project Example) 

Verification Compliance Sheet (Element Level) 

Verification No. ERD Requirement No. 

VR-CML-009 CML-009 

 

Requirement Title: Joint Stiffness

Verification Method: Analysis

Description of Verification Activity (Verification Scope): CM/LAS personnel shall show by 

analysis found in AI1-CML-SAR-CM that the joint stiffness between the CM/LAS and USS is 

greater than 20% of the adjacent sectional bending stiffness. 

Note: USS personnel will also analyze this joint since it is shared between the CM/LAS and USS 

IPTs (Requirement ICMLAS-USS.003 in AI1-IRD-C2U). The CM/LAS analysis results will be 

compared with those obtained by Upper Stage Simulator (USS). Modal test data obtained by 

SE&I for the Stack 5 hardware in the VAB will provide additional, corroborating information for 

these analyses.

 

Verification Success Criteria: The verification shall be successful when the joint stiffness 

between the CM/LAS and USS is shown by analysis to be greater than 20% of the adjacent 

sectional bending stiffness and the CM/LAS results compare well with the USS results. 

 

Rationale: Simulation using independent and validated analysis tools and techniques (by both 

CM/LAS and USS IPTs) is an accepted method to verify requirements for such properties that 

can only be accurately tested at an assembly level. Modal test data for Stack 5 at KSC will be 

available from SE&I to substantiate the analysis results. 

 

FTV-Trace: FTV-002, 004, 006, 009, 124 

Scheduled Activity: UID - 1591 Final Structural Analysis Doc Complete

Closure Report No.: AI1-CML-SAR-CM 

AI1-IRD-C2U Trace: CMLAS-USS.003 

Requirement Owner: David Alexander

 
28 

Figure A-3 (concluded) 

Verification Compliance Sheet 

Requirement Title: Joint Stiffness Requirement No. 

CML-009

Verification Method 

Analysis 

Verification No. 

VR-CML-009 

CM/LAS–USS Trace: 

ICMLAS-USS.003 

FTV-Trace: 

FTV-002, 004, 006, 009, 

124

Result Summary: 

This requirement was verified by a nonlinear NASTRAN structural analysis (SOL 600), which is 

documented in Section 11.4 of the CM Structural Analysis Report, AI1-CML-SAR-CM, version 

1.0. This analysis used a bolt preload of 36,000 lbs, an applied load of 5000 lb, symmetry 

constraints, and 36-inch total joint length. (The 5000 lb applied load was selected based on 

predicted CM-to-SM fastener load distributions, documented in Section 10.4 of AI1-CML-SARCM, and the 36-inch total joint length was a directive from the Ares I-X SE&I Office.) The 

results are compared with the predicted deflection for a solid steel plate of the same size but 

without the bolted joint. This detailed analysis shows that the CM-to-SM joint has a predicted 

stiffness of 27.5% of the adjacent sectional bending stiffness, which satisfies the 20% minimum 

stiffness requirement. 

Structural analysts at Glenn Research Center conducted an independent analysis of this joint, and 

his/her results also show that the stiffness of this joint is greater than 20% of the adjacent 

sectional bending stiffness. 

The finite element models used for these analyses are available upon request. 

Interface Requirement ICMLAS-USS.003 is identical to CM/LAS Requirement CML-009, and 

is therefore also verified. 

W.O. No. / Tracker No.: 

1) 76158/D213B08T0015 

2) 76783/D213A08F00556 

Closure Report(s): 

AI1-CML-SAR-CM

Drawing No.: 

1243204, 1261200, 

1261209, 1261214, 

1261231, 1261248, 

1261249, 1261280, 

1261200,

Non-Conformance Reports (NFRs): 

None 

Requirement Owner: 

David Alexander

Reference Docs. 

AI1-SYS-SDB 

AI1-SYS-TDB 

AI1-SYS-ACO 

AI1-SYS-ARO

 
29 

Figure A-4 (Medium Project Example) 

Verification Compliance Sheet (Subsystem Level) 

Requirement Title: 

Mounting 

Requirement No.: 

DTO2-AV-1008 

Verification Method: 

Inspection 

Requirement Text: The Avionics 

Assembly shall mechanically 

interface to an Adaptive Payload 

Carrier (APC). 

Parent Rqmt: 

DTO1-SYS-1605 

DTO1-AVENC-1004

Description of Verification Activity (Verification Scope): The Mechanical Lead shall verify by 

inspection that the Avionics Assembly is designed to mount to an APC carrier in Port side bay 3.

Verification Success Criteria: The verification shall be succesful when: 

 - the Avionics Enclosure meets the APC interface spec. 

 - the Avionics mounting plate is fit checked with the APC carrier.

Result Summary (Compliance Statement)): The AEA baseplate was fit checked to an APC at 

KSC and was found to fit correctly, prior to the buildup of the AEA. It was designed to the APC 

interface drawing given in ICD-A-21551, Figure 3.0.4.2.1.3.1-1.

Closure Artifact/Document(s): 

STORRM ICD-A-21551: http://www.unitedspacealliance.com/icd/RNS/contents.html 

STORRM Drawing 1250637_REV_A AEA Mounting Plate dwg.pdf 

Fit check photos: SN -001 Picture 1.jpg 

Waivers/ (NFRs): 

None 

Requirement Owner: 

Kevin Taylor

Verification Closed 

3-16-2010-MA 

 
30 

Figure A-5 (Small Project Example) 

Verification Compliance Sheet (System Level) 

Req. No. Requirement Title Verification 

method SRD No. 

VR-09 Spatia l Resolution Analysis HYT-009 

Description of Verification Activity (Verification Scope): HYTHIRM personnel shall show 

by analysis of the Imaging Assets IR Imaging system is less than 18-inches per pixel using the 

Rayleigh Criteria. 

Success Criteria: The verification shall be successful when the analysis is confirmed and the 

Spatial Resolution is determined to be 18-inches per pixel or less. 

Result Summary (Compliance Statement): 

1) CAST GLANCE: I verify by Analysis of the calibration data and mathematical calculations 

that the Spatial Resolution is less than 18-inches per pixel. 

2) MARS: (Mobile Aerospace Reconnaissance System): 

Closure Artifact/Document(s):: 

1) APL_HYTHIRM_Radiance_Modeling_v1.5_v1_0.pdf 

2) STS-125 ViDi MARS & CG Imagery Asset Placement 

4/28/2009.ppt 

Req. R.O.: 

Richard Harris 

NFR: 

None 

Applicable Documents: 
31 

Appendix B: Verification Matrix Example 

Figure B-1 

Verif

No.

REQ

ID

REQ

TITLE REQ Text VM REQ OWNER Verification Scope Verification Success Criteria Verification Rational 

VR‐CML‐0091 CML‐009 Joint Stiffness

• The jointstiffness between the CM/LAS and USS shall be

greater than 20% of the adjacentsectional bending stiffness

as set forth in section 4.1.3 Joint Stiffness of the document;

Ares I‐X Crew Module and Launch Abort System and Upper

Stage Segment Interface Requirement Document ‐ AI1‐IRD‐

C2U

Analysis Harris

CM/LAS personnelshall show by analysis found in AI1‐CML‐SAR‐

CM that the joint stiffness between the CM/LAS and USS is greater

than 20% of the adjacent sectional bending stiffness.

:The verification shall be successful when the joint

stiffness between the CM/LAS and USS is shown by

analysis to be greater than 20% of the adjacent

sectional bending stiffness and the CM/LAS results

compare well with the USS results.

Simulation using independent and validatedanalysis tools and techniques (by both CM/

and USS IPTs) is an accepted method to verrequirements for such properties that can o

accurately tested at an assembly level. Mod

data for Stack 5 at KSC will be available from 

to substantiate the analysis results

VR‐CML‐012 CML‐012 Data Collection

• The CM/LAS shall provide location and orientation of

sensors as defined in the document AI1‐SYS‐DFI, DFI/OFI

Measurement List

Inspection Miller

CM/LAS personnelshall show by reviewing the inspection reports

of all DFI locations, orientations, alignments, and correct PSM ID#

labeling of all CM/LAS sensors that they are in compliance with the

document AI1‐SYS‐DFI, DFI/OFI Measurement List and approved

drawings

The verification shall be successful when CM/LAS

personnel determine sensor location, orientation, and

alignment coincide with those defined in theinspection reports, AI1‐SYS‐DFI and DFI/OFI

Measurement list

: Verification of the proper location, alignmand correct PSM ID# labeling of all CM/LAS

sensors is critical. Verification of the appro

flight drawings and hardware will be perfor

by inspection of these items at the assembl

VR‐CML‐019 CML‐019 Element Weight

• The CM/LAS shall meet its unballasted mass allocation as

stated in the Ares I‐X Mass Allocation Baseline ‐ AI1‐SYS‐

MAB Test Young

:CM/LAS personnelshall show by using a calibrated scale to weigh

the CM and LAS assemblies that the CM/LAS meets the unballasted

mass allocated in the AI1‐SYS‐MAB.

The verification shall be successful when the actual

mass is demonstrated to meet the requirement.

The mass requirement was generated by an

and the verification of the mass will be

determined by lifting the CM and LAS. CM/

weighing all the individual pieces/parts and 

of the sub‐assemblies. These data are used 

verify the ProE model.

VR‐CML‐052 CML‐052

Individual Sub‐Element

Hoisting

• The CM/LAS Simulator sub‐elements shall have lifting

points for vertical and horizontal handling.

Demo Lewis

CM/LAS personnelshall demonstrate, by lifting and handling the CM

and LAS, that the sub‐elements have lifting points for vertical and

horizontal handling.

The verification shall be successful when the

demonstration verifies the provision for the lifting

points per the AI1‐CML‐AIT and conforms to the

drawings.

Demonstration is the most effective metho

show compliance with the specification.

VR‐CML‐065 CML‐065 Workmanship (Electronics)

• The CM/LAS shall comply with workmanship standards

per NASA‐STD‐8739.1‐8739.5, NASA series of

Workmanship Standards, and ANSI/ESD s20.20, Protection

of Electrical and Electronic Parts, Assemblies and Equipment

(Excluding Electrically Initiated Explosive Devices) for non‐heritage hardware.

Inspection,

Test

Jones

Quality Assurance with CM/LAS personnel shall show by inspection

of the workmanship that the CM/LAS complies with workmanship

standards per NASA‐STD‐8739.1‐8739.5, NASA series of

Workmanship Standards, and ANSI/ESD s20.20.** This inspection

shall address QA inspection of cable installation, verification of

termination, verification of workmanship related to bonding,

grounding, and certification of compliance with s20.20 ESD

processes. CM/LAS personnelshall perform liveness and

continuity tests on allsensors.

**CM/LAS is using NASA‐STD‐8739.7 in lieu of ANSI/ESD s20.20.

Jose Otriz has concurred that 8739.7 meets the intent of s20.20,

and no waiver is required.

The verification shall be successful when inspection of

the approved drawings and hardware demonstrates

compliance with the specification and the ICD.

Inspection and test demonstrate complianc

the specification.