20个需求分析的技巧.pdf

-

对商业用户来说，他们后面是成百上千个供货商，前面是成千上万个消费顾客。怎样利

用软件管理错综复杂的供货商和消费顾客，如何做好精细到一个小小调料包的进、销、

调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义

也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。

经理：经理：我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，

是总部-门店的连锁经营模式。通过通信手段门店自动订货，供货商自动结算，卖场通

过扫条形码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也

得为政府部门提供关于商品营运的报告。〞

分析员分析员：：我已经明白这个工程的大体构造框架，这非常重要，但在制定方案之前，我

们必须收集一些需求。〞

经理经理觉得奇怪觉得奇怪：：我不是刚告诉你我的需求了吗？〞

分析员分析员：：实际上，您只说明了整个工程的概念和目标。这些高层次的业务需求缺乏以

提供开发的内容和时间。我需要与实际将要使用系统的业务人员进展讨论，然后才能真

正明白到达业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即

可实现的，哪些是需要开发的，这样可节省很多时间。〞

经理：经理：业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不

能说明一下你们现有的系统？〞

分析员尽量解释从分析员尽量解释从用户用户处收集处收集需求的需求的合合理理性性：：如果我们只是凭空猜测用户的要求，结

果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，

我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些

问题就开场编码，结果没有人对产品满意。〞

经理经理坚持道坚持道：：行了，行了，我们没有则多的时间。让我来告诉您我们的需求。实际上

我也很忙。请马上开场开发，并随时将你们的进展情况告诉我。〞

风险躲在需求的迷雾之后

以上我们看到的是*客户工程经理与系统开发小组的分析人员讨论业务需求。在工程开

发中，所有的工程风险承当者都对需求分析阶段备感兴趣。这里所指的风险承当者包括

客户方面的工程负责人和用户，开发方面的需求分析人员和工程管理者。这局部工作做

得到位，能开发出很优秀的软件产品，同时也会令客户满意。假设处理不好，则会导致

误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了

软件工程和工程管理的根底。

拨开需求分析的迷雾

像这样的对话经常出现在软件开发的过程中。客户工客户工程程经理的需求对经理的需求对分析分析人人员员来来讲讲，，像像

雾里看花〞般模糊并令开发者感到困惑。则，我们就拨开雾影，分析一下需求的具体

内容：

·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在工程定

义与范围文档中予以说明。

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

以说明。

-

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

任务，从而满足了业务需求。

·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须

遵从的标准、标准和约束，操作接口的具体细节和构造上的限制。

·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。报告所说明的功能需求充分描述了软件系统所应具有的外部行为。

需求分析报告〞在开发、测试、质量保证、工程管理以及相关工程功能中起着重要作用。

前面提到的客户工程经理通常说明产品的高层次概念和主要业务内容，为后继工作建立

了一个指导性的框架。其其它任它任何何说明说明都都应遵应遵循循业务需求〞的业务需求〞的规规定，定，然然而而业务需求〞并

不能为开发人员提供开发所需的许多细节说明。

下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另

一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：

程序的易用性、强健性和可靠性，而这些特性将会使用户很好地承受具有该特点的软件

产品。

经理层有经理层有时时试试图代替图代替实实际际用户说用户说话话，，但但通常他们通常他们无法无法准准确确说明说明用户需求〞。用户需求

来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产

品很可能会因缺乏足够的信息而遗留不少隐患。

在实际需求分析过程中，