第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 “签约”意味着什么

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

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

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

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

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

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

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