MXD为ASPICE认证全力以赴系列二

需求特性

要求

不符合实例

不符合后果

不符合起因

不符合解决措施

不符合改进其他建议

完整性

需求涵盖了所有必要的方面和功能，没有遗漏重要的内容

1）未考虑ECU在极端低温环境下的工作性能需求。
  2）遗漏了ECU与车辆其他系统的兼容性需求。
  3）缺少对ECU长期使用后的维护和升级需求。

1）导致开发过程中频繁变更需求，项目延期和成本增加；
  2）产品投入使用后发现关键功能缺失，影响用户体验甚至带来安全隐患

1）对使用场景和用户需求了解不够深入全面；
  2）对相关标准和法规研究不足

1）建立全面的需求收集方法；
  2）对行业标准和法规进行细致研究；
  3）组织严格的评审会议

1）与不同领域专家和用户深入交流；
  2）定期回顾和更新需求

一致性

需求之间相互协调，没有冲突和矛盾

1）ECU的操作方式在不同文档中的描述不一致。
  2）对于ECU的性能要求，不同部门提出的标准相互矛盾。
  3）需求中ECU的尺寸规格与实际安装空间要求不一致。

1）导致系统功能混乱，无法正常运行；

2）可能引发内部矛盾，影响团队协作和项目进度

1）不同需求来源之间沟通不畅；
  2）需求变更管理不善

1）统一需求管理流程；
  2）加强需求变更的控制和记录

1）建立需求冲突解决机制；
  2）定期进行需求一致性审查

可验证性

需求能够通过具体的方法和标准进行检验和确认

1）需求中对ECU的精度要求未说明通过何种测试方法来验证。
  2）ECU的耐久性需求未结合具体的使用场景设定验证条件。
  3）需求未考虑到验证ECU性能所需的特殊设备和环境条件。

1）开发团队无法明确工作是否达到需求标准；
  2）产品交付后难以对质量进行有效评估和保障

1）需求中未明确验证的条件和方法；
  2）缺乏与实际业务场景的结合；
  3）未考虑验证所需的资源和成本

1）明确需求的验证条件和方法；
  2）结合实际业务场景进行需求编写；
  3）提前评估验证所需资源和成本

1）建立验证标准和流程；
  2）与相关人员共同确定验证方案

可追溯性

需求的来源、变更和影响能够清晰地追踪和记录

1）无法追溯某一ECU功能需求的提出者和变更记录。
  2）找不到需求文档与设计文档之间的对应关系。
  3）不清楚某个ECU性能优化需求的来源和演变过程。

1）产品问题难以回溯需求，无法确定问题根源和责任；
  2）增加项目风险和成本

1）未建立清晰的需求标识和编号体系；2）需求变更时未做好记录和关联；
  3）不同阶段需求文档缺乏有效链接和引用

1）建立规范的需求管理流程；
  2）严格遵循变更管理流程；
  3）建立不同文档的引用和关联关系

1）使用需求管理工具；
  2）定期进行需求追溯检查

安全性

需求满足产品在使用过程中不会对人员、环境等造成危害

1）ECU对突发故障的应急处理机制不完善，可能导致车辆失控。
  2）未对ECU的网络安全进行防护，易遭黑客攻击。
  3）需求未考虑驾驶员误踩油门时的底盘控制安全策略。

1）车辆发生事故，威胁乘客和行人生命安全；
  2）引发法律责任和品牌声誉重大损失

1）对潜在安全风险评估不足；
  2）未遵循相关安全标准和规范；
  3）未充分考虑人为误操作或外部恶意攻击影响

1）进行全面深入的安全风险评估；
  2）严格遵循安全标准和规范；
  3）明确防范措施

1）开展安全培训；
  2）进行安全模拟测试

可靠性

需求所描述的产品或系统能够稳定、持续地运行，减少故障的发生

1）ECU中的某个关键传感器易受干扰，导致数据错误。
  2）恶劣路况下，ECU的连接部件容易松动。
  3）高温环境使ECU的电子元件老化加速，影响可靠性。

1）系统频繁故障，影响车辆正常使用；
  2）降低用户信任度，影响产品市场竞争力

1）对零部件质量和寿命估计不足；
  2）未充分考虑环境因素对系统的影响；
  3）缺乏有效的故障监测和恢复机制

1）选用高质量零部件；
  2）进行环境适应性测试；
  3）建立完善的故障监测和恢复系统

1）引入可靠性评估模型；
  2）与供应商建立严格质量协议

明确性

需求的表述清晰、准确，不存在歧义

1）需求中“适当提高底盘高度”表述不明确，未给出具体数值范围。
  2）“增强悬挂系统性能”，未说明具体的增强方向和程度。
  3）“优化ECU的响应”，未明确是响应速度还是响应精度。

1）导致开发人员误解需求，开发出不符合预期的产品；
  2）增加沟通成本和时间浪费

1）需求表述模糊、歧义；
  2）使用专业术语未解释

1）使用清晰、简洁、无歧义的语言；
  2）对专业术语进行解释说明

1）组织需求澄清会议；
  2）邀请相关人员提前评审需求

次序性

需求的开发和实现顺序进行合理安排

1）先开发了非关键的ECU外观需求，而忽略了核心的性能需求。
  2）未优先处理影响车辆安全的ECU制动需求。
  3）把难度大但不紧急的ECU智能辅助功能需求排在了前面。

1）需求开发顺序混乱，影响项目进度；
  2）可能导致关键需求被延误

1）未对需求进行优先级排序；
  2）未合理规划开发阶段

1）对需求进行优先级评估；
  2）制定合理的开发计划和里程碑

1）根据资源和时间灵活调整次序；
  2）及时评估需求次序的合理性

黑盒性

需求的表述不涉及具体的设计和实现细节，为工程师的设计提供足够的灵活性和创新空间

1）需求中指定了ECU必须采用某种特定的算法。
  2）规定了ECU的硬件架构和芯片型号。

3）暗示了ECU开发平台的沿用。

1）约束工程师的自由设计，限制创新；
  2）可能导致设计不够优化

1）过早涉及设计细节；
  2）暗示特定设计方案

1）保持需求的抽象和高层描述；
  2）避免具体的技术和设计实现

1）开展需求规格和设计规格辨析；
  2）审计需求中设计约束的合理性

兼容性

新的需求在实现过程中能够与已有的需求、系统和环境相互适应和协同工作的特性。

1）ECU 无法适配常见氧传感器。

2）ECU 软件升级致旧款硬件死机重置。

3）ECU 与变速箱控制单元通信不良。

1）车辆故障，影响燃油和排放；

2）行车失动力，有安全风险；

3）换挡顿挫，影响舒适和变速箱。

1）开发未考虑传感器多样性；

2）未充分测试旧硬件；

3）通信协议和数据格式差异

1）重设计接口与协议，建立测试流程；

2）停止推送，修复硬件，优化升级方案；

3）优化协议和算法，联合调试

1）加强与供应商合作，预留接口；

2）升级前完善硬件测试环境；

3）制定统一通信标准，加强合作