REG NASA-LLIS-5199-2012 Lessons Learned - Requirement Decision-Making Authority.pdf

《REG NASA-LLIS-5199-2012 Lessons Learned - Requirement Decision-Making Authority.pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-5199-2012 Lessons Learned - Requirement Decision-Making Authority.pdf（2页珍藏版）》请在麦多课文档分享上搜索。

1、Public Lessons Learned Entry: 5199 Lesson Info: Lesson Number: 5199 Submitting Organization: KSC Submitted by: Jenni Palmer Subject: Requirement Decision-Making Authority Abstract: The requirements development process for the Constellation Program was unnecessarily time-consuming. If the text met th

2、e intent of the requirement, it should not be unnecessarily rewritten. For future programs, requirements writing should be limited to a working group of key stakeholders, with the project integrator responsible for the wording. Description of Driving Event: When project integrators (PIs) were writin

3、g requirements and verification requirements (VRs) for Ground Systems in the Constellation Program, the review teams told the PIs how to write the requirements. However, there was a lack of consistency in the direction provided by the various review team members. As a result, the requirements were n

4、ot always agreed upon by all stakeholders. Too much rewriting led to weeks or months of unnecessary rework, at a time when the PIs needed to devote more time to technical integration. Also, PIs were required to flow down a requirement even though they believed the requirement itself was unnecessary.

5、 In some cases, requirements were approved and then reopened for further discussion and additional rewrites at the request of a team member that had been absent during the original discussion on the disposition of the requirement. Lesson(s) Learned: The requirements development process, as implement

6、ed, did not work well. It was not necessary to use a group forum to develop or rewrite a requirement. Too much rewriting led to a great deal of rework, making the requirements development process unnecessarily time-consuming. If the text meets the intent of the requirement, it should not be unnecess

7、arily rewritten. Recommendation(s): 1. Create a requirements development working group for each project. Limit this group to key stakeholders, including representatives from the technical integration, development, and operations organizations. 2. Clearly define the roles and responsibilities of each

8、 stakeholder in the requirements development process. Make project integrators responsible for the wording of the requirement and for configuration management of the requirements document. Make operations personnel responsible for ensuring that the wording meets the original intent of the requiremen

9、t. 3. If a working group member does not agree with the requirement wording used by the project integrator, he/she may elevate the issue to a technical authority. Evidence of Recurrence Control Effectiveness: N/A Documents Related to Lesson: N/A Mission Directorate(s): Provided by IHSNot for ResaleN

10、o reproduction or networking permitted without license from IHS-,-,-Exploration Systems Additional Key Phrase(s): Program Management. Program Management.Role of civil service technical staff versus contractor staff Additional Info: Project: Constellation Approval Info: Approval Date: 2012-05-08 Approval Name: mbell Approval Organization: HQ Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-