.. Kenneth Lee 版权所有 2018-2020
:Authors: Kenneth Lee :Version: 1.0
怎么做初步的需求分析
本文介绍一下收到一个需求以后，如何进行分解和描述。
当客户向我们提出一个需求的时候，他们所使用的“概述名称”通常不是他们所面对的问题 ，而是这个问题被他注意到的“特征”。比如，用户要求支持“ESPI”，不表示他要你给他实 现一个通用的eSPI插槽，而可能仅仅是他打算用eSPI接口连接他的BMC。也不表示他要求你 在芯片或者单板上有这个硬件接口就好，可能他还需要你在Windows Server和Redhat Enterpise Edition中能直接和他的硬件通讯。
所以，需求分析才叫“需求分析”，而不是叫“需求记录”。
所以“需求分析”分析什么呢？它大概要分析这些东西：
（内涵）
这个需求是谁提出来的？如果我们实现这个需求，他能带来什么收益？
技术细节：这个需求是怎么实现这个收益的？有多少种备选方案？
这个需求包括哪些子需求？芯片的，单板的，软件的，生态的
这个需求是否有标准符合性要求和其他限制？这些标准和限制是什么？
（外延）
这是我要谈的第一部分问题，但很多需求分析的问题并不简单的是考虑不到这样的问题， 而是提供了不正确的信息。《论语》里说：知之为知之，不知为不知，是知也。很多人可 能从来没有深入考虑过这句话，这句话在进行技术文档写作的时候尤为重要。这句话表达 了一个非常重要的理念（也是很多人很容易陷入的误区），它说的是：真正的“知道”不是“ 知道”，而是“知道”“什么是知道的，什么是不知道的”。《道德经》里面有个更详细的表述 ：“知不知上，不知知病，圣人不病，以其病病，是以不病”。“不知道”是个客观存在，以 为自己可以“全知”，这不符合事实，以这个为努力方向，就是“以有涯随无涯”，“殆矣”。 所以，我们进行决策的时候，最后的形态是“知知，知不知”，这样我们决策的时候就可以 基于“知”而避开“不知”（病），这样才能进行正确的决策。这就是“病病”，以“病”为“病” ，所以才“不病”。
而我们很多人的需求分析，设计，都是这个问题，从来不提自己不知道的东西，如果真有 不知道的东西，要不避开不说，要不顾左右而言他，要不干脆强行判断，把“不知”写成“知 ”，这样整个需求分析就毫无价值了，我们很多设计文档也是这个毛病，让你花时间看了上 百页的内容，你才注意到这家伙根本就是在浪费你的时间。
所以我们需要写好需求分析，不用长，不用无所不知。也许你时间不够，也许是能力不够 ，也许你就是没有这个信息。但你说的每句话，都有用。但如果你连“知之为知之，不知为 不知”都做不到，那我宁愿你别给我这个文档了，说你没写就好了。
这说到底就是要虚心实腹。我们继续用前面这个eSPI做例子来说，有人找你做这个特性， 总是有找你的这个人的，比如，可能是你的主管，他不是客户，但你总是可以找到他，总 可以问他是谁说的，那个谁，又是听谁说的，最后这个原始需求到底在解决谁的问题，谁 会为此埋单，这总是可以搞清楚的。
接着我们看技术，支持某个标准。这涉及到这个东西谁提出来的，哪些公司附和，技术成 熟度有多高，相关软件、硬件、外接件的进展情况等等等等。你不可能都知道，更多的访 谈可能让你了解更多，但这些访谈和调查能否采信，那也是问题。我们会花时间了解更多 ，但我们必须知道“学海无涯”，你不可能有成本完成所有分析的。那么在初步的低成本分 析后，你最Solid的分析应该是你自己最熟悉的领域，比如我做软件的，你要Linux支持， 那么我首先查Linux是怎么支持它的，全文搜一下Linux Kernel的代码树，我就会发现有两 类实现：
drivers/spi/spi_fsl_espi.c：注册为SPI总线
drivers/pinctl/intel/pinctrl-denverton.c：注册为pinctrl子系统
我算你芯片会飞，你越不过，最终反射到软件的行为上吧？我把这部分“知”钉住了，我就 钉住其他所有的逻辑了。
反过来，如果我是做芯片的，这个东西总要从我的总线上出接口吧？它是个Master还是个 Slave？固定平台设备还是动态设备？我就算你软件会飞，也不可能不经过我的总线系统直 接访问BMC吧？
说到底，每个领域，都有自己“知”的部分，每方钉住自己“知”的部分，我们就有妥协的基 础，就有最大限度的“机数”可以活动了。