如表5所示，有几个缺陷会抑制最佳系统需求集的生成和管理。定义系统要求的主要缺点。陷阱描述了对利益相关者需求的分析不足。如果利益相关者需求的接收者没有对他们进行足够的批判性分析，结果可能是将它们转换为系统需求的难度以及返回利益相关者的义务，这浪费了时间。对操作模式和方案的分析不足。负责编写系统要求的人员尚未完全分析或定义操作模式和操作方案。这些元素允许在工程设计过程的早期阶段对系统进行结构和使用，并帮助设计人员记住功能和接口。如果系统要求不准确且不完整，则存在很大的风险，即设计将无法达到预期的质量水平，并且系统的验证和确认将被延迟。缺少验证方法会延迟每个系统需求的验证方法和事件的获取；确定每个需求的验证方法通常可以进一步了解需求本身的正确性和必要性。失去可追溯性。每个需求的不正确或缺乏可追溯性，包括上级“父”资产的可追溯性对不适当的系统或系统元素的要求。表6中已证明的实践已得到反复证明，可以降低项目风险和成本，提高客户满意度，并能成功进行系统开发。实践描述涉及利益相关者，使利益相关者尽早参与系统需求开发过程。基本原理捕获每个系统要求的基本原理。在开始之前始终完成操作在开始定义系统需求之前，请检查涉众的需求是否尽可能完整。同行评审和适用的主题专家组织对系统要求的同行评审。表6示出。经验证的系统需求实践。考虑使用需求管理工具，尤其是对于更复杂的项目。该工具应该能够跟踪系统需求之间的关系，从而显示它们之间的关系。需求管理工具旨在在整个项目生命周期中促进和支持系统需求管理。在需求工程中使用典型措施；有关更多信息，请参考《系统工程领先索引指南》。在需求工程中应同时使用过程和产品指标。为了获得所需的见解以促进风险管理需求工程，可能有必要根据需求信息需求（风险，目标，问题）使用多个度量。有用的措施包括：Ø需求波动Ø需求趋势Ø需求验证过程（计划的和实际的）Ø需求验证过程（计划的和实际的）Ø每个计划的TBD和TBR关闭Ø同行评审的缺陷原始标题：关于系统需求实际考虑的文章来源：[微信公众号：汽车电子硬件设计]欢迎大家关注！请指出转载文章的来源。