10. Lesson: Update Design Requirements
Review design requirements periodically to ensure the hardware continues to reflect the real program needs. Requirement maturity can affect not only the design, but also the test verification of design as well.
Background:
Design requirements are stated early in the development cycle and tend to be more rigid than they deserve. Design requirements are frequently formulated on the basis of the best information available at the time. These requirements should be examined at intervals to ensure that they are proper.
Early in the Skylab Program (1967-68) a design goal of 0.99+ probability of no penetration by micrometeroids was established and, based upon the environmental model available at the time and with the existent puncture mode analysis, the micrometeoroid shield design was established (the shield was, of course, the one which failed at the launch of Skylab 1). Later data (Pegasus, et al) demonstrated that the model was conservative and refinements to the analysis technique showed the problem to be greatly reduced.
No design change was made since the design was essentially complete and to change the design would have been costly. However, the first systems tests resulted in a failure to deploy. The tests had to be modified and repeated to prove the soundness of the design (the original test failure resulted because the "zero gravity" design of the micrometeoroid shield resulted in deformation during the one-g test. Zero gravity simulation during test is tricky and costly.)
These lessons learned are from SKYLAB LESSONS LEARNED AS APPLICABLE TO A LARGE SPACE STATION, A dissertation submitted to the faculty of The School of Engineering and Architecture Of the Catholic University of America For the Degree Doctor of Engineering by William C. Schneider, Washington, D.C., 1976.
Home - NASA Office of Logic Design
Last Revised:
February 03, 2010
Digital Engineering Institute
Web Grunt:
Richard Katz
