我眼中的需求管理
简单来说，“需求”就是你到底要什么？
在做系统工程师的那些年，也是经常被软件、算法、硬件、生产……哦，还有领导，问到这类问题，你到底想要什么，客户到底想要什么？
多人多脸懵逼并不是偶见的场景，整车厂客户不知道自己想要什么，就是我要，我要，系统工程师或需求工程师或产品经理等类似角色也常常一样，不清楚想要什么，客户要，我也要……
所以说啊，需求并不是个很容易搞清楚的东西，但它作为驱动后续方向的源头，又极具重要性。
往大了说，需求无所不包，各个干系人或者叫相关方想要的东西，都能称之为需求，有关注钱的，有关注时间的，有关注过程的，有关注结果的……
我们还是往小了说（每次都要提醒自己，一说一大了，一大就虚了，一虚就没啥用了），就是针对我们汽车软件产品开发来讲，而且是针对Technical来讲。
在此约束条件下，可以给需求下一个定义，需求是关于一个产品的必要功能（Function）或必要特性（Feature）或必要性能（Performance）的描述。
为了更好地理解需求的逻辑，我们再加入一个词——Use Case，姑且翻译为使用场景。
我们都知道，汽车的终端用户并不懂我们讲的那些技术概念，但他们这些掏钱的人的需求才是最重要的，所以“使用场景”基本可以说是针对他们而言，比如，遇到紧急情况猛打方向盘可以保持车身稳定、高速上可以自动跟车或者可以灵敏地识别语音控制等。
但是，Use Case还是比较高概括性的描述，再技术一点的描述就到了Function，比如，踩下刹车后巡航自动停止、根据雷达信号判断距离和速度进行相关调整等；不仅仅是描述而再到了软件实现的层面的话就是Feature，比如诊断、通讯、OTA、离手检测、系统警告等；而做到多好就是Performance，比如Security（信息安全）、Reliability（可靠性）、Maintainability（可维修性）、Safety（功能安全）等。
当然，这是一个理论概念的理解需要，实际中无法区分得很清楚。
以上这些需求的描述（多理解为客户需求）往往还不能进入开发，再往下需要拆分到更小的颗粒度，一般是系统需求和软件需求，有些可能还会涉及到硬件需求、算法需求、集成需求等等。
接下来看一张图，就可以更直观地看到需求的流转和V模型里的位置。
可以看出来，我们的Stakeholder或者说客户凭感觉给出需求后，需要先转换成技术性的系统需求，然后再拆分到给程序员看的软件需求。
值得一说的是，左侧的两根弧线箭头说明需求的下游并不像简单的V模型所展示那样，必然要对应架构，而后又一级一级分下去，要根据实际项目中需求的颗粒度大小和类型来定，比如，客户要改一个软件版本号，它是客户需求，也能作为系统需求，但也可以直接进入Coding，这种情况还要强调架构就多此一举了。
这也提示质量人员不要太Paperwork，不要对着标准照搬照抄，要深入业务，深入产品，深入项目。只会查文档的质量，显然不值钱。
这里的原则在于“双向追溯”，如上图的蓝色双向箭头，箭头一端的每一条都应有另一端对应，不能出现需求没被测，也不能出现测试不知道测得谁。如果有不对应的，需要有理由说明。
那么，在实际项目中，需求的来龙去脉到底是怎么样的？我们再看得更具体一点，具有实操性一点，或者说一种Good Practice。
首先，各种各样的方式下会产生第一层的需求，我们可以称之为原始需求或客户需求。比如，对于供应商而言，有主机厂的SOR/RFQ、主机厂或行业的技术标准、法律法规、内部规范以及对接客户各种非正式的需求……如果是主机厂自研视角，可能会是来自于各个部门的，如电子架构、功能安全、网络安全、功能规范及各种通用的标准等。道理基本接近。
这时的需求长成什么样子呢？一般是一份份的文档，excel、word、ppt、pdf或不那么规范的E-mail附件，都有可能。
由于这些文档的来源或定义往往都比较杂乱，是需要被梳理、拆分、分析及评审的。
一般是系统工程师或项目经理统筹负责对这些文档进行梳理，比如，文档是不是完整、哪个是最新的版本、是不是有重复的文档等，初步确认出来可用的文档，而后最好可以形成一个列表，包含名称、版本、来源人、释放日期及存档位置等，这份汇总后的原始需求列表其实可以作为一个配置项的。
当然，尽管这个列表给我们提供了很好的Overview，但颗粒度仍然太大，下一步我们可以选择导入需求管理系统，比如Doors/DNG等，这些工具有一个条目化的作用，所以呢，虽然这个导入阶段整体上依然是以Copy&Paste操作为主，但在这个过程后，理论上，条理会更清晰，冗余信息也会被剔除一部分，比如，我们一般会删减一些不必要的信息，以及加入一些Attributes，像类型、状态、涉及的Feature、是否涉及测试、责任人、覆盖范围（如是否在base项目已执行）、验证标准等。
当客户需求被清晰地识别出来后，就需要各个专家大显身手了，针对每一条的可行性、变更范围、技术方案、依赖关系、实现周期等进行分析，在这个过程中，可能会有各种疑问，需要和团队或客户确认等，最终被澄清了的被Release了的每条需求都应该有一个状态，比如Rejected、Approved、Implemented等，而对于是如何到这个状态的，可能就是质量人员要审计的点，是不是经过了正确的人的评审，有没有记录，有没有双方确认等。
相信，如果很好地走过了上面的过程，客户需求基本上被理得八九不离十了。但是，客户需求自带“原始”的属性，逻辑性、精准性和技术性都天然不足，我们还需要用更技术的语言写的系统需求，比如功能需求、性能要求、通信协议需求、接插件需求、输入输出、约束条件、
应用参数、诊断需求等。同样地，系统需求也会设置一些类似的Attributes。
系统需求下来还会到系统架构，再往下就是软件需求，软件需求呢，可以有三个来源：足够细化的客户需求、系统需求、系统架构。一般包括软件功能部分、信号处理、数据存储、编译参数、I/O、内存/容量要求、操作模式等，具体还是要根据具体产品来看。
一般来说，到这里可以打一下需求基线了，象征着需求冻结。后续再有变化，就需要走变更管理流程。
主体的内容差不多到这里。但值得强调的还是，理论归理论，实际归实际，实际情况中基本上不会线性地按部就班做完做好，会反反复复，会来来 回 回，会弄错，会扯皮，会没有追溯，会更新不及时，也会有各种个性化操作。这是因为传统的需求管理还是按照文档驱动开发的逻辑，按照这样的标准，做好需求管理，需要大量的且持续的文档工作，要做好确实不易。
不过呢，在敏捷化的时代，或许我们慢慢地不再强调传统的需求管理一定要做到多好，好的标准也可能会改变，而至于如何变，让我们一起摸索和拭目以待。
