NASA ENGINEERING NETWORK
Follow this link to skip to the main content
+ Contact LLIS
Go
ABOUT NASALATEST NEWSMULTIMEDIAMISSIONSMyNASAWORK FOR NASA

+ NASA Home
FIND ENGINEERING RESOURCES BY
LLIS HOME
NASA CENTERS
MISSION DIRECTORATE
TOPICS
BY YEAR


Public Lessons Learned Entry: 1228

Lesson Info:

  • Lesson Number: 1228
  • Lesson Date: 1999-03-22
  • Submitting Organization: JSC
  • Submitted by: Dave Collins/ Ronald A. Montague

Subject:

Circular document referencing (establishing document relationships)

Description of Driving Event:

Specifications are written to control the baseline requirements to which the Space Station is designed, constructed, verified, and delivered. A common practice within most specifications is to reference documents (know as applicable documents) with the specification as a source of requirements. Early in the development of the specifications the undesirable practice of "circular" referencing of documents infiltrated the specifications within the Space Station Program. Circular references is, in general, a condition by which a specification or document at a low level of the specification (or document) tree hierarchy references a specification of document at a higher level in the specification (or document) tree hierarchy. The following example illustrates the impact of "circular referencing."

Within the Space Station Program the top level specification is the System Specification (SSP 41000). SSP 41000 references numerous documents. Among the referenced documents in SSP 41000 are SSP 30558 and SSP 30559. The SSP 30558 and SSP 30559 documents, in turn reference SSP 41000 (completing the "circle"). Other specifications within the Space Station Specification "Tree" referenced SSP 30558 and SSP 30559. Because 41000 is an applicable document in 30558 and 30559, a lower level specification with the spec tree (for example, the United States Lab (USL) Spec) was placed in the posture of inadvertently being subjected to all requirements within the System Specification. There are two undesirable results caused by this practice:

  1. Obviously the USL was not intended to fulfill all requirements as defined in the System Specification. The USL, however, under this structuring could have been construed as needing to meet all System Spec Requirements.
  2. Maintenance of the "applicable document" section of each individual specification becomes tangled and interwoven to the point that nonapplicable requirements must be verified. For example a modification to SSP 30559 would result in a required document change of every specification within the Space Station Specification Tree.
Root cause: Failure to establish guidelines that define the purpose, use, and relationships of applicable documents. (Center Data Manager's note: The confusion over applicable documents arises quite often from an author's perceived need to justify or establish authority for a document versus identifying documents that, when cited as applicable, will aid in document implementation. The two purposes are quite different but in a poorly defined process both can be considered as meaning "applicable.")

Lesson(s) Learned:

Document relationships in any program must be clearly defined and understood to ensure effective and straightforward implementation of specifications and requirements

Recommendation(s):

Provide early definition of both specification tree and document tree hierarchies applicable to the program. (from Center Data Manager: Consider performing the process for requirement compliance and traceability versus document / specification authority as separate exercises. For example, if a requirement must be traced to a standard, consider using a parallel traceability matrix or a commercial off the shelf requirements tracing package.)

Evidence of Recurrence Control Effectiveness:

Action taken at Huntsville: [CM] This lesson learned does apply to my area of responsibility. This lesson learned is already part of our standard practices for specification development. The spec tree is established early and the parent-child relationships established. In spec development, the "applicable documents" section should not reference any document that is a parent to that document on the spec tree. There may be references to parent documents, but they are usually qualified with a statement like -- in the case of a discrepancy between the (parent document) and (child document), the (parent document) always takes precedence.

Action taken at KSC: System and component specifications are not generated nor maintained by the processing team at KSC for flight items. When items of support equipment are designed for use at KSC, Design Certification Reviews are conducted to ensure all the proper specifications have been identified and properly annotated in the equipment spec.

Action taken at NASA/JSC: The lesson learned has been reviewed and the following is currently in place to correct this problem:

  1. The Program initiated Documents 50257 and 50258 (Program and Boeing Controlled Indexes). These two documents would house the inter-relationships between documents and traceability between higher and lower tiered documents. This was instituted on the Program in 1997.
  2. However, it was determined that these documents could not be responsive to the daily changes on the Program. Therefore, it was agreed that CM would build an interactive database to track these changes and the relationships between documents. This database is currently in work and is scheduled for implementation late FY99.

Documents Related to Lesson:

N/A

Mission Directorate(s):

  • Exploration Systems
  • Science
  • Space Operations
  • Aeronautics Research

Additional Key Phrase(s):

  • Administration/Organization
  • Configuration Management
  • Independent Verification and Validation
  • NASA Standards
  • Parts Materials & Processes
  • Policy & Planning
  • Procurement Small Business & Industrial Relations
  • Risk Management/Assessment
  • Safety & Mission Assurance
  • Standard

Additional Info:

    Approval Info:

    • Approval Date: 2002-06-27
    • Approval Name: Ronald A. Montague
    • Approval Organization: JSC
    • Approval Phone Number: 281-483-8576


    FirstGov - Your First Click to the US Government
    + 2004 Vision for Space Exploration
    + FY 2005 Budget Request
    + 2003 Strategic Plan
    + Freedom of Information Act
    + The President's Management Agenda
    + FY 2003 Agency Performance and Accountability Report
    + NASA Privacy Statement, Disclaimer,
    and Accessibility Certification

    + Freedom to Manage
    NASA
    Curator:Manson Yew
    NASA Official: Gregory Robinson
    + Contact LLIS