软件需求（第二章）（重排版）

客户的需求观

Contoso 制药公司的高级管理长官Gerhard ,会见C o n t o s o公司的信息系统开发小组的新管理员C y n t h i a。“我们需要建立一套化学制品跟踪信息系统”，G e r h a r d说道。“该系统可以记录库房或某个实验室中已有的化学药品，这样，化学专家可以直接从楼下的某人那里拿到所需的药品，而不必再买一瓶新的。另外，卫生保健部门也得为联邦政府写些关于化学药品的使用报告。你们小组能在五个月内开发出该系统吗？”

“我已经明白这个项目的重要性了， G e r h a r d”C y n t h i a说，“但在我制定计划前，我们必须收集一些系统的需求。”

G e r h a r d觉得很奇怪“你的意思是什么？我不是刚告诉你我的需求了吗？”

“实际上，你只说明了整个项目的概念与目标，”C y n t h i a解释道，“这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。我们甚至并不需要开发一个新的软件系统，这样可节省许多钱。”

G e r h a r d此前还从未遇到过与这位系统开发人员类似的看法。“那些化学专家都非常忙”他坚持道，“他们没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？”

C y n t h i a尽力解释从使用新系统的用户处收集需求的合理性。“如果我们只是凭空猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非化学专家。我们并不能真正明白化学专家们需要这个化学制品跟踪系统做些什么。我曾经尝试过，未真正明白这些问题就匆忙开始编码，结果没有人对产品满意。”

“行了，行了，我们没有那么多时间” G e r h a r d坚持道。“我来告诉你需求，请马上开始开发系统。随时将你们的进展情况告诉我。”

像这样的对话经常出现在软件开发过程中。要求开发一个新信息系统的客户通常并不懂得从系统的实际用户处得到信息的重要性。市场人员在有了一个很不错的新产品想法后，也就自认为能充分代表产品用户的兴趣要求。然而，直接从产品的实际用户处收集需求有着不可替代的必要性。通过对8 3 8 0个项目的调查发现，导致项目失败的最主要的两个原因是缺乏用户参与和不完整的需求以及不完整的规格说明(Standish 1995)。

引起需求问题的一部分原因是对不同层次需求（业务、用户、功能）的混淆所致。G e r h a r d说明了一些业务需求，但他并不能描述用户需求，因为他并不是“化学制品跟踪系统”的实际使用者。只有实际用户才能描述他们要用此系统必须完成的任务。但他们又不能指出完成这些任务所有具体的功能需求。

本章说明客户与开发人员之间的关系，它对软件项目开发的成功极为关键。我建议写一份软件客户需求权利书和相应的软件客户需求义务书，以强调客户（和实际用户）参与需求开发过程的重要性。

2.1 谁是客户

通常意义下，客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者( s t a k e h o l d e r )或是获得产品所产生的结果的人。

G e r h a r d代表支付、采购( p r o c u r e )或投资软件产品的这类客户，处于G e r h a r d层次上的客户有义务说明业务需求。他们应阐明产品的高层次概念和将发布产品的主要业务内容。在第6章中讨论到业务需求应说明客户、公司和想从该系统获利的风险承担者或从系统中取得结果的用户所要求的目标。业务需求为后继工作建立了一个指导性的框架。其它任何说明都应遵从业务需求的规定，然而业务需求并不能为开发人员提供许多开发所需的细节说明。

下一层需求—用户需求—必须从使用产品的用户处收集。因此这些用户（通常称作最终用户），构成了另一种软件客户。他们能说清楚要使用该产品完成什么任务和一些非功能性的特性，而这些特性会对使用户很好接收具有该特点的产品是重要的。

说明业务需求的客户有时将试图替代用户说话，但通常他们根本无法准确说明用户需求。因为对信息系统、合同( c o n t r a c t )或是客户应用程序的开发、业务需求应来自风险承担者，而用户需求则应来自产品的真正使用、操作者。

不幸的是，这两种客户可能都觉得他们没有时间与(收集、分析与编写需求说明)需求分析者讨论。有时客户还希望分析人员或开发人员无须讨论和编写文档就能说出用户的需求。除非遇到的需求极为简单，否则不能这样做。如果你的组织希望软件成功，那必须要花上数天时间来消除需求中模糊不清的地方和一些使程序人员感到困惑的方面。

商业软件开发的情况有些不同，因为通常其客户就是用户。正如市场部这类客户代理，可能想确定究竟软件产品的购买者会喜欢什么。但即使是商业软件，也应该让实际用户参与到收集需求的过程中来（第7章将谈及）。如果你不这样做，那产品很可能会因缺乏足够用户提供的信息而出现不少隐患。

2.2 客户与开发人员之间的合作关系

优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系反而会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来一点益处。

只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的目标这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使开发者感到满足的优秀软件产品。

软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求。每一项权利都对应着软件开发人员、分析人员的义务。而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，可以将其作为开发人员的权利书。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有