第2章 客户的需求观

第2章客户的需求观

      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 客户与开发人员之间的合作关系

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

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

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

                                       软件客户需求权利书
客户有如下权利：
1. 要求分析人员使用符合客户语言习惯的表达。
2. 要求分析人员了解客户系统的业务及目标。
3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。
4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。
5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。
6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。
7. 描述产品使其具有易用、好用的特性。
8. 可以调整需求，允许重用已有的软件组件。
9. 当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。
10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

                                            软件客户需求义务书
客户有下列义务：
1. 给分析人员讲解业务及说明业务方面的术语等专业问题。
2. 抽出时间清楚地说明需求并不断完善。
3. 当说明系统需求时，力求准确详细。
4. 需要时要及时对需求做出决策。
5. 要尊重开发人员的成本估算和对需求的可行性分析。
6. 对单项需求、系统特性或使用实例划分优先级。
7. 评审需求文档和原型。
8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。
9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。
10. 尊重需求工程中开发人员采用的流程（过程）。

      当为内部集团使用而开发软件时，这些权利和义务可以直接应用于客户。这也适用于那些有合同关系或者有明确的主要客户集的情况。对普遍市场产品的开发，这些权利和义务更适于像市场部这样的客户代理者。

      作为项目计划的一部分，客户和开发人员应评审上述两张列表并达成共识。一些很忙的客户可能不愿意积极参与需求过程（也即，他们不太接受软件客户需求义务书），而缺少客户参与将很可能导致不理想的产品。故一定要确保需求开发中的主要参与者都了解并接受他们的义务。如果遇到分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦
（如一方要求而另一方不愿意或不能满足要求）。

2.2.1 软件客户需求权利书

      权利# 1：要求分析人员使用符合客户语言习惯的表达
      需求讨论应集中于业务需要和任务，故要使用业务术语，你应将其教给分析人员，而你不一定要懂得计算机的行业术语。

      权利# 2：要求分析人员了解客户的业务及目标
      通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要。这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件。为帮助开发人员和分析人员，可以考虑邀请他们观察你或你的同事是怎样工作的。如果新开发系统是用来替代已有的系统，那么开发人员应使用一下目前的系统，这将有利于
他们明白目前系统是怎样工作的，其工作流程的情况，以及可供改进之处。

      权利# 3：要求分析人员编写软件需求规格说明
      分析人员要把从你和其他客户那里获得的所有信息进行整理，以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息。通过这些分析就能得到一份软件需求规格说明。而这份软件需求规格说明 software requirements specification, SRS）便在开发人员和客户之间针对要开发的产品内容达成了协议。S R S可以用一种你认为易于翻阅和理解的方式组织编
写。要评审编写出的规格说明以确保它们准确而完整地表达了你的需求。一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品。

      权利# 4：要求得到需求工作结果的解释说明
      分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面。所以需求说明中的各种图表有着极高的价值。虽然它们不太难于理解，但是你很可能对此并不熟悉。因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义，及怎样检查图表有无错误及不
一致等。

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

      权利# 6：要求开发人员对需求及产品实施提供建议，拿出主意
      通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。在彻底弄清业务领域内的事情后，分析人员有时就能提出相当好的改进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性。

      权利# 7：描述产品易使用的特性
      你可以要求分析人员在实现功能需求的同时还要注重软件的易用性。因为这些易用特性或质量属性能使你更准确、高效地完成任务。例如，客户有时要求产品要“用户友好”或“健壮”或“高效率”，但这对于开发人员来说，太主观了并无实用价值。正确的应是：分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性（第11章将详细讨论它）。

      权利# 8：调整需求，允许重用已有的软件组件
      需求通常要有一定的灵活性。分析人员可能发现已有的某个软件组件与你描述的需求很相符。在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件。如果有可重用的机会出现，同时你又能调整你的需求说明，那就能降低成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一
些已有的商业常用组件，而它们并不完全适合你所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

      权利# 9：要求对变更的代价提供真实可信的评估
      有时人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的，所以，你有权利要求开发人员通过分析给出一个的确真实可信的评估，包括影响、成本和得失等评估。开发人员不能由于不想实施变更而随意夸大评估成本。

      权利# 1 0：获得满足客户功能和质量要求的系统
      每个人都希望项目获得成功。但这不仅要求你要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制。一定要明确说明你的假设和潜在的期望。否则，开发人员开发出的产品很可能无法让你满意。

2.2.2 软件客户需求义务书

      义务# 1：给分析人员讲解你的业务
      分析人员要依靠你给他们讲解的业务概念及术语。但你不能指望分析人员会成为该领域的专家，而只能让他们真正明白你的问题和目标。不要期望分析人员能把握你们业务的细微与潜在之处，他们很可能并不知道那些对于你和你的同事来说理所当然的“常识”。

      义务# 2：抽出时间清楚地说明并完善需求
      客户很忙，经常在最忙的时候还得参与需求开发。但无论如何，你有义务抽出时间参与“头脑风暴”会议的讨论，接受采访或其它获取需求的活动。有时分析人员可能先以为明白了你的观点，而过后发现还需要你的讲解。这时，请耐心一些对待需求和需求的精化工作过程中的反复，因为它是人们交流中的很自然的现象，何况这对软件产品的成功极为重要。

      义务# 3：准确而详细地说明需求
      编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且又耗时，故很容易留下模糊不清的需求。但是，在开发过程中，必须得解决这种模糊性和不准确性。而你恰是为解决这些问题作出决定的最佳人选。不然的话，你就只好靠开发人员去正确猜测了。

      在需求规格说明中暂时加上待定（ to be determined, TBD）的标志是个不错的办法。用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方。不过，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上T B D标志。尽量将每项需求的内容都阐述清楚，以便分析人员能准确的将其写进软件需求规格说明中。如果你一时不能准确表述，那就得允许获取必要的准确信息这样一个过程。通常使用所谓的原型技术。通过开发的原型，你可以同开发人员一起反复修改，不断完善需求定义。

      义务# 4：及时地作出决定
      正如一位建筑师为你修建房屋，分析人员将要求你做出一些选择和决定。这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权做出决定的客户必须积极地对待这一切，尽快做处理、做决定。因为开发人员通常只有等你做出了决定才能行动，而这种等待会延误项目的进展。

      义务# 5：尊重开发人员的需求可行性及成本评估
      所有的软件功能都有其成本价格，开发人员最适合预算这些成本（尽管许多开发人员并不擅长评估预测）。你所希望的某些产品特性可能在技术上行不通，或者实现它要付出极为高昂的代价。而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据，开发人员会对此作出负面的评价意见，你应该尊重他们的意见。

      有时，你可以重新给出一个在技术上可行、实现上便宜的需求，例如，要求某个行为在“瞬间”发生是不可行的，但换种更具体的时间需求说法（“在5 0 m s以内”），这就可以实现了。

      义务# 6： 划分需求优先级别
      绝大多数项目没有足够的时间或资源来实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，哪些是好的，是需求开发的主要部分。只能由你来负责设定需求优先级，因为开发者并不可能按你的观点决定需求优先级。开发者将为你确定优先级提供有关每个需求的花费和风险的信息。当你设定优先级时，你帮助开发者确保在适当的时间内用最小的开支
取得最好的效果。

      在时间和资源限制下，关于所需特性能否完成或完成多少应该尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对这种现实的。业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

      义务# 7：评审需求文档和原型
      正如我们将在第1 4章讨论的，无论是正式的还是非正式的方式，对需求文档进行评审都会对软件质量提高有所帮助。让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性。评审也给客户代表提供一个机会，给需求分析人员带来反馈信息以改进他们的工作。如果你认为编写的需求文档不够准确，就有义务尽早告诉分析人员并为改进提供建议。

      通过阅读需求规格说明，很难想象实际的软件是什么样子的。更好的方法是先为产品开发一个原型。这样你就能提供更有价值的反馈信息给开发人员，帮助他们更好地理解你的需求。必须认识到：原型并非是一个实际产品，但开发人员能将其转变、扩充成功能齐全的系统。

      义务# 8：需求出现变更要马上联系
      不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响。变更是不可避免的，但在开发周期中变更越在晚期出现，其影响越大。变更不仅会导致代价极高的返工，而且工期也会被迫延误，特别是在大体结构已完成后又需要增加新特性时。所以一旦你发现需要变更需求时，请一定立即通知分析人员。

      义务# 9：应遵照开发组织处理需求变更的过程
      为了将变更带来的负面影响减少到最低限度，所有的参与者必须遵照项目的变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后作出合适的决策以确定将某些变更引入项目中。

      义务# 1 0：尊重开发人员采用的需求工程过程

      软件开发中最具挑战性的    莫过于收集需求并确定其正确性。分析人员采用的方法有其合理性。也许你认为需求过程不太划算，但请相信花在需求开发上的时间是“很有价”的。如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。尽管去询问分析人员为什么他们要收集某些信息，或参与与需求有关的活动。

2.3 “签约”意味着什么

      为所开发产品的需求签订协议是客户与开发人员关系中的重要部分。许多组织在需求文档中使用“签约”这个概念来作为客户同意需求的标志行为。故要让所有需求参与者都真正明白“签约”的意思。

      但存在这样一个问题：客户代表经常把“签约”看作是毫无意义的。“他们要我在一张纸的最后一行文字下面签上名字，于是我就签了，否则这些开发人员不开始编码。”这种态度将来会带来麻烦，譬如客户想更改需求或对产品有不满时。“不错，我是在需求上签署了名字，但我并没有时间去读完所有的内容。我是相信你们的，是你们非要让我签字的。”

      同样的问题也会发生在仅把签约看作是完成文档的管理人员身上。一旦有需求变更出现，他便指着软件需求规格说明说道：“但你已经在需求上签约了，所以这些便是我们所要开发的。如果你想要别的什么，你应早些告诉我们。”

      这样的态度都是不对的，不可能在项目早期就了解所有需求，而且毫无疑问需求将会出现变更。在需求上签约是终止需求开发过程的正确方法。然而，参与者必须明白他们的签约意味着什么。

      更为重要的是签名是建立在一个需求协议的基线上，因此在需求规格说明上的签约应该这样理解：“我同意这份文档表述了目前我们对项目软件需求的了解。进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成本、资源和项目工期任务等”。

      关于基线达成一定共识会易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。给初步的需求开发工作画上双方都明确的句号会有助你形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了基础。

下一步：
• 让客户提供项目的业务需求和用户需求。对权利书和义务书的条目，哪些被客户接受、理解并付诸实践了？哪些没有？
• 与你的重要客户一起讨论权利书和义务书，以达成协议，并付诸实践。这些行为会有助于客户和开发人员更好地互相理解，以形成更融洽的关系。
• 如果你是软件开发项目中的客户参与方，你感到你的需求权利书没有被充分尊重，就可以与软件项目的领导人员或业务分析人员一起讨论权利书的内容。要想建立一种合作的工作关系，就要尽力使对方对你的义务书感到满意。