定义系统需求的主要缺陷

有几个缺陷会抑制生成和管理一组最佳的系统需求，如表5中所讨论的。

表5所示。定义系统需求的主要缺陷。

陷阱	描述
对利益攸关方需求的分析不足	如果利益攸关方需求的接受者没有对它们进行充分的批判性分析，结果可能是将它们转化为系统需求的困难和返回给利益攸关方的义务，损失了时间。
运营模式和场景分析不足	操作模式和操作场景没有被负责编写系统需求的人充分分析或定义。这些要素允许系统的结构和在工程过程的早期使用，并帮助设计者记住功能和接口。
	如果系统需求不够精确和完整，就会有很大的风险，即设计不会达到预期的质量水平，系统的验证和确认将被推迟。
缺少验证方法	延迟获取每个系统需求的验证方法和事件;对每个需求的验证方法的识别通常提供关于的正确性和必要性的额外洞察 需求本身。
丢失的可追溯性	对每个需求的不正确或缺少追溯性，包括对上层“父”需求的追溯分配到不合适的系统或系统要素。

表6中已被证明的实践已经多次被证明可以降低项目风险和成本，提高客户满意度，并产生成功的系统开发。

实践	描述
涉及到利益相关方	尽早让利益攸关方参与系统需求开发过程。
基本原理	捕获每个系统需求的基本原理。
总是在开始前完成	在开始定义系统需求之前，检查利益攸关方的需求是否尽可能的完整。
同行评审	与适用的主题专家组织对系统需求的同行评审。

表6所示。已证实的系统需求实践。

考虑使用需求管理工具，特别是对于更复杂的项目。这个工具应该能够跟踪系统需求之间的联系，从而显示它们之间的关系。需求管理工具旨在促进和支持整个项目生命周期的系统需求管理。

在需求工程中使用典型的措施;更多信息，请参考系统工程领先指标指南。过程和产品度量都应该用于需求工程。为了获得所需的洞察力来促进风险管理需求工程，可能需要使用基于需求信息需求(风险、目标、问题)的多个度量。有用的措施包括:

Ø 需求波动

Ø 需求趋势

Ø 需求验证进程(计划与实际)

Ø 需求验证进程(计划与实际)

Ø 每个计划的TBD和TBR关闭

Ø 同行评审的缺陷

原文标题：关于系统需求的实际考虑

文章出处：【微信公众号：汽车电子硬件设计】欢迎添加关注！文章转载请注明出处。

责任编辑：haq