abstract:
在软件开发中，客户通常不理解从实际用户收集需求的重要性。市场人员可能过于自信能代表用户兴趣。客户指获益于产品的个人或组织，用户需求应从最终用户收集，他们能详细说明任务和非功能性特性。有时客户试图替代用户需求，但通常无法准确说明。成功软件需花时间消除需求模糊和困惑。商业软件开发中，即使市场部想确定购买者喜好，实际用户参与需求收集仍至关重要。

客户的需求观

物流管理案例：

物流公司的高级管理长官 张经理 会见了公司的信息系统开发小组的新管理员 李开发。“我们需要建立一套物流管理系统”，张经理 说道。“该系统可以记录在仓库或某个配送中心中已有的货物，这样，物流专家可以直接从楼下的某人那里拿到所需的货物，而不必再购买新的。另外，运营部门也需要为公司高层写一些关于货物流动的报告。你们小组能在五个月内开发出该系统来吗？”

“我已经明白这个项目的重要性了， 张经理”，李开发 说道。“但在我制定计划前，我们必须收集一些系统的需求。”

张经理 觉得很奇怪：“你的意思是什么？我不是刚告诉你我的需求了吗？”

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

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

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

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

像这样的对话经常出现在软件开发过程中。要求开发一个新信息系统的客户通常并不懂得从系统的实际用户处得到信息的重要性。市场人员在有了一个很不错的新产品想法后，也就自认为能充分代表产品用户的兴趣要求。

1 谁是客户?

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

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

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

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

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

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

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

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

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

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

软件客户需求权利书

客户有如下权利:

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

软件客户需求义务书

客户有下列义务:

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

当为内部集团使用而开发软件时,这些权利和义务可以直接应用于客户。这也适用于那
些有合同关系或者有明确的主要客户集的情况。对普遍市场产品的开发,这些权利和义务更
适于像市场部这样的客户代理者。
作为项目计划的一部分,客户和开发人员应评审上述两张列表并达成共识。一些很忙的
客户可能不愿意积极参与需求过程,而缺少客户参与将很可
能导致不理想的产品。故一定要确保需求开发 ^[2]中的主要参与者都了解并接受他们的义务。如
果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦(如一方要求
而另一方不愿意或不能满足要求)。

2.1 软件客户需求权利书

权利#1: 要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务，因此要使用业务术语。你应该将这些术语教给分析人员，而你不必了解计算机的行业术语。

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

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

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

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

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

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

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

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

权利#10: 获得满足客户功能和质量要求的系统

为确保项目的成功，重要的是要确保开发人员能够充分理解客户关于系统应完成哪些功能的详细信息。这不仅包括明确的功能需求，还包括对系统性能、可靠性和其他质量标准的期望。同时，客户需要明确表达任何假设或预期的限制，并就项目的取舍做出清晰的指示。

以下是实现权利#10的一些关键点：

1. 清晰沟通: 客户必须清楚地传达他们的需求和期望，包括功能要求、性能指标以及任何相关的业务规则或约束条件。
2. 详细讨论: 开发团队应与客户进行深入的讨论，以确保他们完全理解客户的需求，并能够识别和提出潜在的问题或建议。
3. 文档记录: 所有的需求和期望都应该被详细地记录在文档中，形成正式的需求文档，供所有相关方参考。
4. 确认和验证: 客户应该有机会审查需求文档，并对其中的内容提供反馈，确保所有的信息都准确无误。
5. 管理变更: 在项目开发过程中可能会出现需求变更，因此需要有一个清晰的流程来管理这些变更，评估它们的影响，并相应地调整项目计划。
6. 持续沟通: 在整个开发过程中，保持客户与开发团队之间的持续沟通至关重要，这样可以确保任何问题及时得到解决，避免误解和错误的发生。
7. 质量保证: 开发团队需要确保开发出的产品符合客户的质量和性能标准，这可能包括执行测试、代码审查和其他质量控制措施。
8. 用户验收测试(UAT): 在产品交付之前，进行用户验收测试是必要的步骤，以确保系统满足商业需求并且可以在实际工作环境中正常运行。
9. 后续支持: 即使产品已经交付，也可能需要提供培训、技术支持或维护服务，以确保客户能够有效地使用系统，并解决后续可能出现的问题。

通过遵循上述步骤，客户可以确保他们的需求得到满足，并获得一个能够满足他们功能和质量要求的成功系统。

2.2 软件客户需求义务书

义务#1:向分析人员解释你的业务
分析人员需要了解你的业务概念和术语，但你不能期望他们成为该领域的专家。他们可能不了解你们业务的细微之处和潜在问题。

义务#2:抽出时间澄清并完善需求
客户很忙，可能需要在最忙的时候参与需求开发。但你有责任参加“头脑风暴”会议，接受采访等获取需求的活动。有时分析人员可能误解了你的需求，需要你耐心解释和澄清。

义务#3:清晰而详细地描述需求
编写清晰、准确的需求文档很困难。有时会出现模糊不清的需求，但在开发过程中必须解决这些问题。你需要决定哪些需求需要进一步讨论、分析或增加信息。如果无法准确表达，可以使用原型技术与开发人员一起修改和完善需求定义。

义务#4:及时做出决定
分析人员会提出一些选择和决定，你需要积极处理这些决定，以便开发人员能够采取行动。尽快做出决策，避免延误项目进展。

义务#5:尊重开发人员的可行性和成本评估
分析人员对技术可行性和成本评估最了解。有些功能无法实现，或者实现成本过高。你需要考虑这些因素，并与开发人员共同决定哪些需求是重要的、可行的和合理的。

义务#6:划分需求优先级 ^[4]
确定哪些需求是必要的、重要的和好的是需求开发的主要任务。你需要设定需求优先级，并帮助开发人员确保在适当的时间内以最小的开支取得最好的效果。在时间和资源限制下，需要尊重开发人员的意见，根据优先级调整项目范围 ^[5]或工期。

义务#7:评审需求文档和原型
评审需求文档和原型有助于提高软件质量。让客户参与评审能确保需求文档完整准确地描述了期望的必要特性。通过原型可以更好地理解需求，并提供有价值的反馈信息给开发人员。你需要尽早告诉分析人员并为改进提供建议。

义务#8:及时通知变更需求
不断的需求变更会给高质量产品带来负面影响。变更是不可避免的，但在开发周期中越早发现变更，影响越小。变更会导致高代价的返工和工期延误。一旦你发现问题，请立即通知分析人员进行变更处理。

义务#9:遵守项目变更控制流程
为了减少变更对项目的影响，所有参与者都必须遵守项目的变更控制流程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后作出合适的决策以确定是否将某些变更引入项目中。

义务#10:尊重并支持需求工程过程
软件开发中最具有挑战性的是收集需求并确定其正确性。分析人员采用的方法有其合理性所在。你需要支持他们的工作，参与与需求有关的活动，并向他们询问为什么要收集某些信息。

3 “签约”意味着什么?

在客户与开发人员的关系中，需求签订协议是非常重要的一部分。许多组织使用“签约”这个概念来表示客户同意需求的标志行为。因此，需要确保所有需求参与者都真正理解“签约”的含义。

然而，存在一个问题：客户代表经常把“签约”看作是毫无意义的。例如，他们可能只是简单地在需求文档的最后一行签字，而没有仔细阅读所有的内容。这种态度可能会导致将来的问题，比如当客户想要更改需求或对产品不满意时。

同样的问题也可能会出现在那些只把签约看作是完成文档的管理人员身上。一旦有需求变更出现，他们可能会说：“你已经在需求上签约了，所以这就是我们要开发的。如果你想要别的什么，你应该早点告诉我们。”

这种态度都是不对的。在项目早期不可能了解所有需求，而且需求肯定会发生变化。在需求上签约是终止需求开发过程的正确方式。然而，参与者必须明白他们的签约意味着什么。更重要的是，签约名字是建立在一个需求协议的基础上的，因此在需求规格说明上的签约应该被理解为：“我同意这份文档表述了目前我们对项目软件需求的了解。进一步的变更可以在这个项目定义的变更过程的基线上进行。我知道变更可能会使我们不得不重新协商成本、资源和项目工期任务等。”

关于基线的共识可以降低未来摩擦的风险，这些摩擦可能来源于项目的改进、需求的误解或市场和业务的新要求等。给初步的需求开发工作画上双方都明确的句号会有助于你建立一个持续良好的客户与开发人员关系，为项目的成功奠定基础。

下一步行动计划：

1. 收集业务需求和用户需求：与客户进行深入沟通，了解他们的项目需求和用户期望。确保理解他们的需求并明确地记录下来。

2. 分析权利书和义务书的条目：对权利书和义务书中的各项条款进行分析，确定哪些内容已被客户接受、理解和付诸实践。同时，也要识别出那些尚未被接受或实践的内容。

3. 与重要客户讨论：与重要的客户一起讨论权利书和义务书，以达成共识，并将这些协议落实到实际操作中。这样的讨论有助于增强双方的理解，建立更紧密的合作关系。

4. 处理权利书未被尊重的问题：如果在软件开发项目中，你感到你的需求权利书没有被充分尊重，那么你应该与项目的领导或业务分析人员进行讨论。目标是使对方对你的义务书感到满意，从而建立起一种合作的工作关系。

以上四个步骤将帮助你更好地理解和满足客户的需求，同时也能提升你的项目管理能力。

本文同步发表在 软件需求探索的http://www.srs.pub/theory/ke-hu-de-xu-qiu-guan.html

---

1. 需求文档的编写.http://www.srs.pub/theory/xu-qiu-wen-dang-de-bian-xie.html ↩

2. 需求开发向设计规划的转化.http://www.srs.pub/theory/xu-qiu-kai-fa-xiang-she-ji-gui-hua-de-zhuan-hua.html ↩

3. 软件的质量属性分析.http://www.srs.pub/theory/ruan-jian-de-zhi-liang-shu-xing.html ↩

4. 需求优先级.http://www.srs.pub/theory/xu-qiu-you-xian-ji.html ↩

5. 项目视图与范围.http://www.srs.pub/theory/xiang-mu-shi-tu-yu-fan-wei.html ↩