网页制造aiyiweb文章简介：如何无效收集与分析客户需求？

在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴味。这里所指的风险承 担者包括客户方面的项目担任人和用户，开发方面的需求分析人员和项目管理者。

对商业用户来说，他们后面是成百上千个 供货商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供货商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通任务，这些都是商业企业需求信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。

经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁运营模式。通过通信手段门店自动订货，供货商自动结算，卖场通过扫条形码实现销 售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

分析员：“我曾经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

经理觉得奇怪：“我不是刚通知你我的需求了吗？”

分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需求与实际将要使用系统的业务人员进行讨论，然 后才能真正明白达到业务目标所需功用和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需求开发的，这样可节省很多时间。”

经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财 务专家，我们并不真正明白您这个企业内部运营需求做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

经理坚持道：“行了，行了，我们没有那么多的时间。让我来通知您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况通知我。”

风险躲在需求的迷雾之后

以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴味。这里所指的风险承 担者包括客户方面的项目担任人和用户，开发方面的需求分析人员和项目管理者。这部分任务做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理 不好，则会导致误解、波折、妨碍以及潜在的质量和业务价值上的要挟。因此可见——需求分析奠定了软件工程和项目管理的基础。

拨开需求分析的迷雾

像这样的对话经常出如今软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下 需求的具体内容：

·业务需求——反映了组织机 构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

·用户需求——描述了用户使 用产品必需要完成的任务，这在使用实例或方案脚本中予以说明。

·功用需求——定义了开发人 员必须实现的软件功用，使用户利用系统能够完成他们的任务，从而满足了业务需求。

·非功用性的需求——描述了 系统展现给用户的行为和执行的操作等，它包括产品必须服从的标准、规范和约束，操作接口的具体细节和结构上的限制。

·需求分析报告——报告所说 明的功用需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功用中起着重要作用。

前面提到的客户项目经理通常阐明产品的高层次概念和次要业务内容，为后继任务建立了一个指点性的框架。其它任何说明都应遵照“业务需求”的规定，然而“业 务需求”并不能为开发人员提供开发所需的许多细节说明。

下一层次需求——用户需 求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功用性的特性需求。例如：程序的易用 性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

经理层有时试图代替实际用户说话，但通常他们无法精确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这 样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到 的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必需要花上数天时间来消弭需求中模糊不清的地方和一些使开发者感到困惑的方面。

优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间无效的交流和合作。只要双方参与者都明白本人需求什么、成功的合作需求什么 时，才能建立起一种良好的合作关系。

由于项目的压力日积月累，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀 软件产品。

客户的需求观

客户与开发人员交流需求好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的互相理 解，以便减少当前的磨擦（如一方要求而另一方不情愿或不能够满足要求）。

1、 分析人员要使用符合客户言语习惯的表达

需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术 语。

2、分析人员要了解客户的业务及目标

只要分析人员更好地了解客户的业务，才能使产品更好地满足需求。这将有助于开发人员设计出真正满足客户需求并达到期望的优秀软件。为协助开发和分析人员， 客户可以考虑约请他们观察本人的任务流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样任务的，其流程情 况以及可供改进之处。`

3、 分析人员必须编写 软件需求报告

分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功用需求、质量目标、处理方法和其它信息。通过这些分析，客户就能得到一份“需求 分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保 报告内容精确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需求的产品。

4、 要求得到需求任务结果的解释说明

分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，由于任务图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价 值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发任务的结果，以及怎样检查 图表有无错误及不分歧等。

5、 开发人员要尊重客户 的意见

如果用户与开发人员之间不能互相理解，那关于需求的讨论将会有妨碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍 惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一