如何表达需求--CSDN研讨会之二

主持人：刚才讨论了很长时间，主要围绕问题焦点就是如何捕获需求。把需求素材都拿到以后，就进入到下一个阶段，就是把这些需求素材整理成文档，也就涉及到下一个话题，也就是需求表达方式。我想问大家一个问题，在目前各位所在的公司，你们在捕获需求之后，你们采取什么样的方式来表达需求。同样，我这里也有几个选项：需求列表、用例、数据流程图、各种实体关系图、类图、业务流程图。就这有几种表达需求的形式，我们现场做一个调查吧，看你们采取哪种方式来表达你们的获取需求。

殷志梅：分阶段，不同阶段采用不同的方式。最开始是列表，然后是流程图等，如果进一步细化的会有类图和流程图。

吴浩刚：这跟产品采用的生命周期模型有关系。

Kristian Persson：我们也是在不同阶段用不同的方法。在最开始的时候可能会用到列表或者用例场景，在细节的时候，会用类比图。

主持人：在我们调查结果中可以看出，列表、用例是比较常用的方法，在不同阶段会强调某一种方法。大家分析一下这几种方法的优缺点？

潘加宇：业务流程图表达的并不是直接的需求，而是表达现实里的情况，并没有说我这个软件要做什么，只是现在是怎么回事，算是捕获需求的一种工具，但表达的并不是需求。你也可以说把所有功能和用例串起来变为业务流程图，系统开发以后业务流程图是什么样的？从这个角度来看，业务流程图也可以表达需求，但往往用的业务流程图是描述现实的，现在公司的工作流程是这样的。并不是说系统怎么做，应该严格来说，是辅助的工具，除非是表达目标业务流程，打算这个系统上马以后公司流程是这样的，这样就表达了需求。需求列表是最通用的。用例组织需求方式用得越来越多，不管是正式还是非正式的。

白慧冬：通过业务流程图和客户做交流，获取的是大的需求列表，我会整理成用例图，在项目之前我会得到一个小的需求列表，也是和用户沟通得到的，这小的需求列表是开发人员看的，让开发人员知道根据这个怎么做实现，应该说这三个是我们经常用的东西。我书里面也是这样描述的，我这个人是做什么写什么，不做的就不敢写。

举一个例子吧，02年我在中国电信做过调研，我是先找网通负责人，从相关部门获取了一个大业务的整合，然后找相关人获取信息，在访谈过程中，我的方式是他说我划，我划的是目前业务操作过程，然后我就看，让他提意见，然后我做修改，直到他满意，访谈结束以后，我整理为文档，因为当时中国电信要求出一份全国的工程建设规划文档，再过三四天之后，这之间是访谈其他的人，我会再找他一次，往往当时一个人的想法会有一些冲突或者偶然性，甚至对于不同的人访谈同一个流程会得到不同的结果，所以我一般会做二到三次的反馈。

主持人：大家对这个案例有何点评呢？你在“需求定义”的过程中，又有哪些宝贵的经验可以与大家分享？

于波：按照需求细化也好，或者实现也好，是偏离用户的需要和需求，竞争力会出来，很多事情就会非常的麻烦。

Kristian Persson：大家要达成协议，比如客户访谈的目的是大家在同一个协议基础上提交需求。像刚才白慧冬所说的之所以反复去做，目的是达到大家都认同，不然的话，客户有很多需求，你成交不了，没有办法实现。

殷志梅：我觉得很多需求不一定是好需求，我以前做过一个用户的需求，用户的需求比较低，我们没法说服用户，结果也没有办法，最后按照用户的方式，有一个合同，希望与计算机界面上的合同做得一模一样，结果花了一百多万，用了几年就扔掉了。我认为对于需求应该以发展眼光来看，因为他们是做外贸的，要随时发展，很多东西都要变化，他没有考虑到这些点，说要完全符合这种模式做，结果也失败了。

于波：Kristian Persson先生用协议，大家共同的理解，我开发商和客户之间，对需求理解的是一致的，如果是一部分相交就麻烦了，通过互相理解，又有一个承诺就出来了，现在把需求到底是什么，做多深，有一个范围，这是对后续的管理是很重要的，很多人仅仅关注功能上，没有关注性能上，也有可能非功能的需求没有关注到。比如一些法律法规的限制都要考虑进来。再有就是你不仅仅要考虑到客户的需求，还有领导的需求，还要考虑产品是给谁去使用的，也就是最终用户的需求，哪些人要用，他们会怎么想。

潘加宇：我认为需求变化是非常复杂的，虽然认为非常简单的技能能做到，刚才于先生说到需求是一种承诺。在这个前提条件下，按照我里面所说的做，我就能够保证你到达，这是一种契约或者承诺。刚才殷志梅也说了用户满意的不一定就好，比如在台上表演的人不一定是最重要的人，在台下第一排看戏的人往往是最重要的人，比如台上演习，演员也很重要，但真正重要是坐在第一排看戏的人。需求怎么写，怎么做，这要考虑第一排的口味，第二排的口味，第三排的口味，用户可能坐在第一、二排，开发人员坐在最后一排，要求性能非常的高，看谁是坐在第一排，谁坐在第二排、第三排，他们对戏有什么要求，这是非常复杂的。

于波：作为开发商也好，作为提供商也好，其实有一个责任教育你的客户变为前瞻性的，刚才我从另外一个角度已经阐明了这一点，行业的趋势以及行业规范，比如是贸易性的，要加入WTO或者已经加入了，你肯定要把这部分考虑进来，如果你没有加入进来，可能之后又有需求的变化。

林治宇：我认为还有一个层面，我们还可以做一个内部的需求，也就是对于未来行业的发展趋势提供解决方案，对于这个怎么来做这是一方面。可能我们会请一些领导、专家、用户坐下来讨论，以这种方式和他们交流，从而引导出一些问题和方案，然后再进行改进。

潘加宇：用例这种技术把这些问题都暴露出来了，用例是执行者和用户者在台上看戏，比如东方通如果没有用户，是给中间件用的，这依然也有演员，照样有戏上演，照样台下有观众，东方通公司说我只照顾到开发人员的利益，只要用得方便就可以了，而开发人员就坐在最后一排，最大的受众是第一排，东方通公司是坐在第二排，所以要把这些利益关系以及对外做的承诺表达出来，这种技术承诺是非常有价值的。用过以后，做用例开发技术指导，往往做下去的话，是很难的。用例技术用到以后，理解了这一点，就觉得非常的妙，台上有人演戏，台下有很多人看戏，一旦进入这个阶段的话，就会产生很大的利润。如果大家有兴趣的话，可以试一试。

于波：从需求和管理来讲，软件开发企业当中怎样贴近客户关系，怎样使产品更加人性化，更接近它，这可能也要充分的考虑。因为刚开始很多人不懂得电脑，还有一种惧怕感，跟这有一些关系，但不完全是这样，中国实行ERP系统，很多人说花了巨资没有用，但也跟后期是否培训有问题。我认为现在不仅仅是开发，还讲究服务，这样可能会更好。无论需求管理也好，需求开发也好，真正是提高产品能力，提高公司效率，提高客户满意度，达到公司真正的经营目的，其他的方法都是以这样为服务的，而不是围绕需求做开发。

潘加宇：我举一个案例，有一个公司做调研的时候，说对于流水线的管理引进计算机管理，但工人说不用，只要手工管理就可以了。厂里面要求严格规范，必然带来工作量的提升。往往有这么几种方案，我可以搞电脑大奖赛什么的，谁得奖，给你发奖，或者我勒令你一定要学这套系统，否则就下岗。真正的需求公司是平衡这方面的利益，既要规范，又要像手写那样方便，把所有的缺陷变为几十个条码，这样比手写更方便，当然唯一的缺陷就是成本高了一点，要买扫描设备。实际上这也对需求公司提出了很高的要求，看能不能平衡，而不是说要牺牲某一方面的利益，否则这个系统也执行不下去。

观众提问：就需求调研这块，我也做了需求调研逐渐面向用户的，是否可以这样理解调研工作，因为是解决两个目的，或者两个疑问，第一是用户要的是什么东西？他完成什么工作，比如在现有工作流程上，提高管理，是要实现什么东西？第二，在开发之前，双向沟通当中，我们这样来实现是否能满足你的要求？是否需求调研起到这样的作用呢？

白慧冬：一般没有影响，但要考虑用户的需求你们公司能不能解决，这是你们要考虑的，但不是需求调研的关键问题，需求调研的关键问题是用户需要什么？以及用户需求了解以后你们到底怎么做。

你用不用原形方法跟用户没有关系，用户关心的是你能不能实现。你所要得到的是用户需要什么东西，关于实现，是你自己的问题。你用再高的技术和再低的技术，跟用户没有关系。

主持人：网上还有网友提问：需求有很多，怎样收集最有价值的需求呢？
于波：跟开发的周期、开发的方式都是有关系的。最后还是双方要达成一致的利益，双方要解决的是什么。

吴浩刚：要确定优先集的需求，以及在哪个阶段开发是最有用的，最后做一个比较，找一个双方更容易接受的方案。

于波：在需求收集或者分析过程当中，我们已经提到这样的问题，做一个简单的需求列表要比较，而且相互之间的需求，不管从哪方面来讲要有一个综合的过程，还要谈需求实现的优先集的问题。刚才用户会不断的提需求，如果需求控制不好的话，就会蔓延增长。现在这种失败的案例已经很多了，对于一些非功能的需求、成本呀，时间进度呀，都需要确定。

原文转自：http://www.ltesting.net