关于如何理解软件需求的清单

关于如何理解软件需求的清单

作者：付裕

1.新增需求或者变更需求的出现标志着现在的软件无法满足使用者的某一项工作。解决办法是在现有的软件上通过某些操作的组合满足使用者的需求，或者对现有的软件进行改造。换句话说，在需求的最初要区分出来究竟需不需要改程序。

2.在需求的提出者提出某项需求之后，作为接收方要协助需求提出者完整的讲一个“故事”，也就是敏捷开发体系中的“story”的概念。故事一般包含5W的要素。

    a)WHO（不一定是一个）

    b)WHEN（不一定是一个）

    c)WHAT

    d)WHY

    e)WHATELSE

也就是说，谁在什么时候利用本机能做什么？为什么要做这些？（即，本模块能给使用者带来什么便利的结果）。如果要达到上述目的是否还有更好的办法（即，WHAT ELSE）

3.一般而言，经过5W分析之后的需求，会产出一张完整的软件操作流程图，或者最终结果预想图。同时，这种操作流程图或者最终结果预想图在逻辑上是自洽的，同时也是逻辑闭环。即业务有发起点，也有终结点。业务的最终结果要反馈到业务发起点上等等。

4.注意区分软件的使用者的角色。针对某一个需求，每个角色的动作是不一样的。一般采用矩阵式的分析方式来确保某一个story对于所有的角色都考虑到了。

以新闻发布系统为例，

5.注意业务的分歧点和具有真实含义的业务分类。表现形式一般是画面上的下拉框，单选框，或者复选框。这些业务分类很容易在提出需求的阶段遗漏，或者每个业务都有每个业务不同的处理。比如，政务信息发布系统·字段类型的下拉框

默认【单行文本框】，隐含的还有【多行文本框】，【下拉框】，【单选框】和【复选框】。在编码实现的过程中，要考虑兼容这五种类型。

6.一般而言，在需求提出的阶段，提出者一定不会完整的表达出所有的想法。而我们通过这一系列的做法只是确保尽最大可能的消化吸收需求提出者的想法。

如下图：

我们的目标是：

无论如何还是会有一些双方都想不到的内容。但是我们要确保想不到的这部分的比例很低。根据顾客满意度的相关研究，我们要完成真实需求的97%，才会给人【完成的非常好】的印象。

7.如果是公司内部的发包项目，一般而言容易产生【反正后面还有人改，这一期先这样】的心理，在这种心理下造成的隐藏风险是非常高的。我们的5W分析的另一个目的是在一期内把能想到的都想到，降低隐藏风险。同时要有一期一完结的心态。不要把工作的风险转移给后续流程。

8.如果是一些官僚作风比较重的客户，在需求阶段会一直闪闪烁烁的不说，或者非常急切，恨不得放下电话的一瞬间，你就把东西修改好。针对这种问题，没有特别立竿见影的办法，只能先确保我们已有的内容品质过硬，各种接口比较全面。所以，千万不要随口就答应任何需求，一定要经过5W分析。

9.其他未尽事项，后续会继续追加。