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

上传人:arrownail386 文档编号:1019489 上传时间:2019-03-21 格式:PDF 页数:2 大小:58.19KB
下载 相关 举报
REG NASA-LLIS-5199-2012 Lessons Learned - Requirement Decision-Making Authority.pdf_第1页
第1页 / 共2页
REG NASA-LLIS-5199-2012 Lessons Learned - Requirement Decision-Making Authority.pdf_第2页
第2页 / 共2页
亲,该文档总共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-,-,-

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 国际标准 > 其他

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1