混在IT-（6）八股文之需求分析

我们先看看下面一个在生活中谣言是如何产生的笑话：

      Ａ对Ｂ说：“听说老王家的鸡刚生出的蛋落地便破壳，马上变出了小鸡。”

      Ｂ告诉Ｃ：“新鲜事，老王家的鸡生出的蛋，壳还没破，就变成了小鸡。”

      Ｃ又对Ｄ说：“真怪，老王家的鸡直接生出了小鸡！”

      Ｄ又对Ｅ说，Ｅ告诉了Ｆ，Ｆ告诉了Ｇ。

      恰好Ｇ巧遇Ａ，告诉Ａ：奇迹，老王家的鸡竟然生出一只小乌龟！

这里涉及到2类传播，一是人，就是常说的沟通，另外是事情，就是要实现的需求，在项目上可以理解为需求在变形，客户说要做个刚出生的小鸡，然后项目组很辛苦也很努力的去做，最后很兴奋的给客户说，我们做了一个很漂亮的小乌龟，考虑到扩展性，我们还安了一对翅膀，你觉得是不是很满意吗？这些绝对能满足现在和将来的需求。真实情况是这样吗？很显然，传播的人越多，沟通渠道越复杂，传播的事情越失真。

需求实现的渠道也许象这样：客户->项目经理->需求分析员->设计师->程序员->测试->客户的循环。那么在公司里面最经常见到的场景就是
       客户大骂项目经理：“这不是我要的”
       项目经理对程序员说：“你想的太多了”
       项目经理对老板说：“我们很努力了，客户需求老变，我们有什么办法”
       “哎，这周白做了，又返工”
       ......。
有很多理论一直在希望能够改善需求分析环节处理，就是因为需求分析太重要了，它是所有后续工作的起点。俗话说，男人怕入错行，女人怕嫁错男。源头错了，后面做的再好也白搭，等着被人骂。

这些年我在写需求分析成果需求规格说明书的历程，有六个阶段：

    第一阶段：2页搞定法，写一句目标，写几句背景、画一个功能结构图、每个功能写几句。大家能不能想到这种方法象什么，呵呵，就象在写简单的宣传材料，在结果出来前谁也都不知道象什么，大家都在猜，这些功能字眼很熟悉，至于怎么做，编码的人自己去想。这就是我早期做的事情，编码的时候这份文档唯一的作用就是做菜单。结果等软件出来，很神奇的，客户气死，老板气死、销售气死。

    第二阶段：总不能一直是用2页搞定客户吧，报告需要页数的，拿这点页数上不了台面的，只能凑字数，怎么办，就从技术的角度去做，画数据流图，写输入输出。写着写着就好像写成设计报告了，客户懵了，老板懵了，销售懵了，看不懂，程序员懂了。但从技术角度思考，我们做出来的东西就是客户想要的吗，因为前期很难和客户确认。结果等软件出来，也是很神奇的。

    第三阶段：从技术角度不能解决需求问题，那就抛开技术，从客户角度去写，把客户所做的业务完整描述出来，这下客户懂了，老板懂了，销售懂了，程序员懂了，可是做的时候遇到一个很大问题，描述中涉及到的业务是不是都需要实现，完整性描述意味着文档中有可能覆盖了很多不需要做到系统里面的业务点。这个怎么界定，开始没定好，那我们在实现的时候就会做了很多很多很有意思的功能，套用一句话：你知道的太多了。所以想的越多，事情做的越多，工期拖的越久。结果等软件出来，也是很神奇的。

    第四阶段：前三个阶段都有问题啊，写出来的内容对设计和开发指导意义不大，我们想到了原型法，原型法效果是不错，但有个问题，原型法很耗时间，对能力要求很高，要快速出代码。因此这种方法只用在对非功能性要求有特殊的情况下，如性能，新技术、复杂的场景中。如果简单的增删改查功能也用原型法是不是太奢侈了点，除非客户有硬性要求。

    第五阶段：这不行，那不行，这时候有个前辈忽然想到，发布给客户除了安装包以外，还有用户操作手册，我们能不能把用户操作操作手册提前到需求分析阶段，手册中涉及的界面用VISIO画出来，人机对话的过程用文字写出来。这个建议真的很厉害，当我们按用户操作手册方式写需求规格说明书，效果很快就出来了。从编写需求开始，就定下来一个重要的关键字，那就是边界。我们要做的系统最终发布给客户是什么样子，怎么操作，非常的明确，设计按它来做、编码不要在花太多的时间考虑界面，只要考虑已经定义好的样子、测试按说明书一步一步来验证。朋友，在整个开发过程没有返工啊，除非需求发生变更。所以我很佩服这个前辈，思路决定出路。这种方式很容易和客户、设计、程序员等等角色沟通确认，因为大家是看图说话。就是有点不好的就是文档太专业，太枯燥，没有优美的文字可以给客户领导、老板、销售。因为这些角色又不看具体的功能内容。

    第六阶段：终于大成，是我这几年一直使用的方法，也是我当时所在团队的集体最高成就：三分定天下。既然需求规则说明书要包含非常优美的文字给领导看，又要有功能列表给销售看，还要有已定义的无歧义内容给设计、程序员、测试看。那么三分定天下方法就把需求规格说明书一分为三，拆成三份文档

        1、总论。包含背景分析、业务描述、功能需求、非功能性需求、接口需求等内容，这些常常被拿去做宣传、立项、忽悠等等用途。属于编故事范畴，写的越优美越好。

        2、功能列表。系统要实现的功能点，你可以理解为USE CASE，是做定义边界的。我经常用它做进度估算、成本估算和报价用，也是后续工作的控制点。

        3、分册。与功能列表中的功能点一一对应，使用用户操作手册的方法做，严格要求这里描述的内容都是属于边界内的。不能有等等这类的字眼，要有图，有操作步骤，有操作规则，在和客户确认后到没发生变更前，是要没有任何歧义的。大家遵守这个手册来做事情。那么做出来的东西就是没有返工的，满足客户当前确认的需求。

写了这么多，其实我给大家分享的就是需求规则说明书的三分定天下方法，在第六阶段。至于需求怎么采集这个要看个人，八仙过海，各显神通，能给大家建议的只有一点，在和客户做需求调研的时候，请花点时间通过其它途径先了解客户的业务，不然在沟通过程中很尴尬，客户会认为你水平不够，不愿和你沟通。


----------------------------
Ps:本来想在这篇也包含一个需求规则说明书的小案例，考虑到如果文章篇幅如果太大，大家看起来会很枯燥很辛苦，就改到下一篇需求规格说明书案例分享，这几天会补上。

评论

12 楼 xxwinnie 2013-03-28  

“三分定天下”，不错~ 还没机会实践，先拜过大师~  

11 楼 zwm 2010-10-27  

曾经在用第5个阶段。有了第六阶段，不错。。

10 楼 alexandrae2008 2010-10-19  

既然需求规则说明书要包含非常优美的文字给领导看，又要有功能列表给销售看，还要有已定义的无歧义内容给设计、程序员、测试看。那么三分定天下方法就把需求规格说明书一分为三，拆成三份文档
。受教了。

9 楼 jordan_micle 2010-10-19  

思维很不错。。。

8 楼 todo158 2010-10-19  

histan 写道

引用

客户大骂项目经理：“这不是我要的”
       项目经理对程序员说：“你想的太多了”
       项目经理对老板说：“我们很努力了，客户需求老变，我们有什么办法”
       “哎，这周白做了，又返工”
       ......。

最近一个人去做一个维护和升级，貌似处于这个困境~~~

这些情况在做维护和升级的时候很常见，我也经历过。
在这种环境下，我们所要做的就是要把工作量给体现出来，建议是：
1、使用需求跟踪表，把每个修改的内容记录下来，什么时间、什么需求、什么人提的，什么时候实现了。这个是给老板和销售看的，说明你在很努力的干活，如果不记下来并且及时汇报，时间一长，谁也不知道你做了什么，只知道你还没有做完，另外在表中有工作量的需求，最好事先和销售通个气，让销售评估是否收维护费用
2、借用版本管理一些概念，就是在需求跟踪表里面你大概估个量，量够就结一个版本，这样就有了里程碑，做汇报的时候至少别人都知道这段时间你做了几个版本，解决了客户多少需求。花了多少工作量。
通过这2种方式，你就不会在乎客户的需求怎么变，你把每次修改都当做新需求，及时和老板、销售沟通，把工作量报给他们，让他们考虑维护费用，这样你的压力就会减很多，做的比较舒服些。

啊，写了这些，好像把我后面要写的内容给提前了

7 楼 todo158 2010-10-19  

Sunny_kaka 写道

我惊讶地发现我处于第一阶段.

坐等规格说明书案例

呵呵，谢谢支持：）

6 楼 histan 2010-10-19  

引用

客户大骂项目经理：“这不是我要的”
       项目经理对程序员说：“你想的太多了”
       项目经理对老板说：“我们很努力了，客户需求老变，我们有什么办法”
       “哎，这周白做了，又返工”
       ......。

最近一个人去做一个维护和升级，貌似处于这个困境~~~

5 楼 Sunny_kaka 2010-10-18  

我惊讶地发现我处于第一阶段.

坐等规格说明书案例

4 楼 todo158 2010-10-18  

guofengcn 写道

好嘞！等着看案例……

案例在整理中，谢谢：）

3 楼 todo158 2010-10-18  

Javakeith 写道

谢谢

2 楼 guofengcn 2010-10-18  

好嘞！等着看案例……

1 楼 Javakeith 2010-10-18