一、需求的定义
需求到底是什么，我们天天都能够在耳边听到这么熟悉的词汇，但是我们如何用一句话概括，是不是感到熟悉而又陌生。我接触到最完美的需求的定义：用户在特定的场景下所期望实现的目标。三个词汇：用户、场景、目标；因此，我们定义任何一条需求都要结合这三个词汇，例如当车辆处于行车模式下，驾驶员踩下油门踏板，车辆能够移动。用户是驾驶员，场景是处于行车模式下，目标是车辆能够移动。也可以从输入，处理，输出的三个维度进行需求的定义：输入时驾驶员踩下了油门踏板，处理是控制器计算了油门踏板的扭矩发给电机控制器，输出是扭矩转换成了电机的旋转运动，带动车辆运动。第一个定义是不是更通俗移动，第二种定义是不是一般常人难懂。第一种定义是用户层面的需求，第二种定义是技术方案层面的需求定义。对于第二种定义接下来就是将每一个需要实现的技术方案进行需求分析和需求分解及分配。需求分析是分析出具体的解决方案，需求分解及分配是结合车辆的架构到底哪个系统哪个控制器实现该功能。例如驾驶员踩下油门踏板，控制器计算油门扭矩发送给电机控制器，这个功能由VCU实现，MCU电机控制器执行VCU发送来的扭矩。VCU采集计算扭矩，MCU执行扭矩请求。->需求文档编制是非常重要的工作，对于系统工程师最重要的工作输出物，传统车发展的时代，车上的控制器都是通过采购的方式导入的，供应商都开发完成了，针对特定的车型进行适配即可，相关需求都是掌握在供应商那里，主机厂提的需求不需要很详细；但是新能源汽车时代，每家车企都在提升自己的控制器开发技术，技术差异性也非常大，特别像域控制器的开理念的提出，控制器不在局限于实现一个功能，是一个非常庞大的系统，非常复杂的系统，提出的需求是需要落地的需求，需求的重要性越来越重要了，编制需求的岗位是系统工程师，其应该是团队技术经验或者技术背景最为丰富的工程师。完善的需求能够提升团队的开发效率，能够提升控制器的开发质量。->需求是开发的基础，后续的开发工作都是依赖需求去实现特定的目标。制定和变更需求的导入到最终输出需要经过哪些环节：上一级需求输入-需求分析-分解需求-编制需求-评审需求-修改需求-评审需求-修改需求………-需求输出。产品随着时间的推移不断导入新的功能，新的技术方法，因此，需求是不断变更，不断完善的过程。
->上一级需求，需求分为整车需求（VTS-VehicleTechnicalSpecification）、系统需求（STS-SystemTechnicalSpecification）、子系统需求（SSTS
– SubSystem Technical Specification）、软件需求（SRS–SoftwareRequirementSpecification）、硬件需求（HRS - Hardware
Requirement Specification ）、其它还包括功能安全需求（FSR – FunctionSafetySpecification），整车需求的上一级是功能配置表/市场调研报告/用户调研报告等，系统需求的上一级是整车需求，子系统的上一级是系统需求等。以此类推。->需求分析，需求分析的思维路径是明确问题，分解需求，针对问题提供技术解决方案，就是挖掘和提炼上一级的需求，并把需求转为该层级的需求（解决方案）的过程。->需求分解，每个系统每个控制器都有适合实现的功能，针对每个系统每个控制器的特性进行分析，结合整车的架构设计，将整车级的功能进行分解到具体的系统及控制器进行实现。->编制需求，整个公司应该将整车级需求，系统级需求，子系统级需求，软硬件需求行车规范化的文档（模板、规范、统一），做到能够查询，能够传承，能够通俗易懂，条理清晰。并形成层级的追溯性，不要是为了写文档而写文档。目前文档有三个层级，第一完全无文档，第二部分有文档但是经常不更新，只是应付了事，第三种，文档写的非常详细。目前大多数都处于第二层到第三层及的爬坡阶段，主要原因是因为当传统车到新能源车的转变，自主开发能力逐渐加强，没有文档能力会造成团队一团糟，因此，慢慢的大家都开始注重编制文档、管理文档。->评审需求，多轮的迭代编制与评审，评审是为了让需求开发链上的相关人员都能看得懂，同时避免沟通和编制过程造成的错误，引起后续的连锁反应，闻道有先后，术业有专攻，每个需求的编制都是技术点的提炼，难免在某些地方有错误。->输出需求，做好文档管理和输出，不仅仅是输出需求文档，还需要输出评审记录、变更记录等文档，并管理好文档。- 完整性， 用户在特定的场景下所期望实现的目标。用户、场景、目标；技术层面，定义输入、处理、输出。每个都需要描述清楚。
- 明确性，不带有概率性词汇，只能是False或者Ture。
- 正确性，符合实际产品的本质设计要求，不能违背自然和物理规律，每项功能和科学技术都是始于科技，融于自然和生活。
- 可追溯性（定义规范ID规则，每一条需求与上一层级需求形成追溯性）
- 可测试性，能够设计测试用例、执行测试用例，具有验证评判准则。
接下来的更新计划：
->汽车控制器子系统需求编制方法及模板
->汽车控制器软件需求编制方法及模板
->汽车控制器硬件需求编制方法及模板
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
