Requirement —— Where are you from and where are you going?

  更多精彩内容欢迎关注微信公众号：功能安全落地漫谈

---

在上一篇（《功能安全管理之需求管理（标准篇）》功能安全管理之需求管理（标准篇）-CSDN博客）中我们提到过功能安全的需求追溯链条，了解到功能安全管理很大一部分任务是在做需求管理，需求管理的一大任务是建立可追溯性，还顺便谈了谈双向可追溯性。

需求是产品开发工作的主线，产品整个生命周期各个阶段的工作都有需求的影子，所以能把各个阶段的需求整明白、写清楚、实现好、验证全，这侧面反映了组织具备了一定的成熟度，这种情况下整个功能安全管理工作的质量差不到哪去。

既然需求那么重要，那需求从哪里来？

需求来源比较广泛，按出处来说有来自内部的和来自外部的之分，一般地，产品的开发需求可以从以下几个方面获取：

• 用户反馈，比如你去4S店试乘试驾时反馈的意见，你在网上购物后给的评价。
• 用户调研，比如希望你的车的座椅具备什么样的功能？车外后视镜希望能做成什么样等问卷调查。
• 数据分析，如对测试数据的分析，通过收集相关数据，分析并提取有用信息并形成结论，这个结论将成为新开发需求的一部分。数据分析是一种手段，数据来源既可以是内部的也可以是外部的。
• 竞品分析，这个各行各业都适用，比如车厂的每款车都有自己的对标车型，比如特斯拉Model 3的上下电流程、充电流程是怎样的？买一台对标车型实车测试(包括驾驶)分析得到相关数据，然后开发出差异化的需求。
• 公司及团队内部，此来源包括：公司层面的战略规划，比如开发出能量密度高达1000Wh/kg的电池，10分钟将电量充到90%以上等；组织既有产品已开发的功能，这部分功能会形成对应需求；组织内部其他部门反馈的问题，比如运营部门从市场端、客户端收集整理的问题；组织头脑风暴想出来的问题、点子也都能形成需求。

以上关于需求来源的介绍可能是个比较通用的标准答案，可以作为一个参考。本文想探讨的更多的是安全需求的来源问题，或者说怎么分解出安全需求的问题。

在上一篇文章中我们了解到安全相关需求的追溯链条为：SG->FSR->TSR->HSR/SSR，不管是刚接触ISO26262的人员还是从事功能安全开发、管理工作多年的老兵们，几乎每天都要与这条安全需求链打交道。你是否思考过该需求链中每种需求是如何得到的呢？即，

• SG如何得到？
• FSR如何得到？怎么编写？
• TSR如何得到？怎么编写？
• HSR如何得到？怎么编写？
• SSR如何得到？怎么编写？

如果答案是这样的：HARA分析得到SG, SG分解得到FSR，FSR分解得到TSR，TSR分解得到HSR，SSR。

这个答案更多的只是将安全的需求链用自然语言描述一遍而已，但凡接触过功能安全的都知道这个答案，光知道这条追溯链就能写出对应的需求？

Show me！

个人觉得安全相关的需求首先要从功能本身出发，毕竟功能安全关注的是功能异常/故障后不能引起不合理的风险，所以得先要有功能再谈安全。

功能安全要落地得先把安全的需求链中各层级的安全需求定义好，安全需求要定义好得先把相关项的功能、设计意图、设计约束理清楚，然后再基于这些信息进行安全分析，通过分析得到对应的应对措施，再将分析得到的应对措施导出，经过收集、整理得到安全需求。

如果各位在为怎么写出需求而烦扰，不妨试试下面这个方法，此方法我称之为“需求分析三部曲”，具体如下：

第一步：梳理相关项的功能、设计意图及设计约束；

第二步：基于第一步的信息实施安全分析，得到不能满足第一步的应对措施；

第三步：收集、整理第二步分析得到的应对措施，加工描述成需求语言形成安全需求。

在《功能安全管理之需求管理（标准篇）》（功能安全管理之需求管理（标准篇）-CSDN博客）一文中我们提到过写需求的两大痛点是关于“颗粒度”和“完整性”的问题，颗粒度是一个“运用之妙存乎一心”的问题，你写的需求有没层次感跟需求写得对不对没有必然联系，但却很影响感观，这个需要根据层次化的架构思维多思考、多练才能解决，没什么方便法门。这里想再聊聊完整性(completeness)的问题。

Q: 怎么保证需求的完整性？

在上一篇文中介绍过“需求编写三板斧”（REQ-IPO）的方法，即从“输入-处理-输出”这三个方面来展开需求的编写，这三个方面恰好也是构成系统的三要素，这也印证了了这个方法具备一定的系统性。

我们来看看这“三板斧”是怎么将某一功能的需求提取完整的。

第一板斧——输入：即为实现当前功能需要什么样的输入信息？或者对输入信息有什么要求？写出来形成当前功能输入部分的需求。

第二板斧——处理：即当前功能本身要怎么使用、如何处理输入信息来达到设计意图/功能目的的？需要具备什么条件来实现这样的意图/目的？写出来形成当前功能处理部分的需求。

第三板斧——输出：即当前功能对数据/信息处理完后要把处理后的数据/信息发送给谁？通过什么方式发送？希望接收方有什么反应？写出来形成当前功能输出部分的需求。

这三板斧过后，还有哪条功能“不服的”？不服的再结合上文提到的“需求分析三部曲”中的第二步的分析来进一步验证需求的完整性，相当于再加一板斧，让需求形成“闭环”。

其实这三板斧，不仅是在写需求时适用，在做一些安全分析时也适用，典型的如FTA分析可以用三板斧这招，后面写FTA的专题文章时给大家讲讲FTA中的三板斧。

功能安全要落地，安全需求得先落地，安全需求提不清楚，那功能安全在项目中落地就无从谈起。上面介绍的“需求分析三部曲”以及“需求编写三板斧”就是编写安全需求的一种经过实践检验的可落地的方法论，可供参考但并不唯一，各位不妨试试。

百闻不如一试，落地不是挂在嘴上，动手才能落地。

---

为收集大家的宝贵意见以及方便大家进行交流，集思广益，已建立公众号同名交流群，有需要入群的读者请添加下方微信（WF_WANG-ANLUOVITA）以便邀请入群。