软件客户需求权利书，软件客户需求义务书

      优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人
员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系反而
会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，
在这种情况下，不会给双方带来一点益处。
      只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，
才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的目标这
一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使
开发者感到满足的优秀软件产品。
      软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员
交流时的合法要求。每一项权利都对应着软件开发人员、分析人员的义务。而软件客户需求
义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，可以将其作为开发人
员的权利书。

客户有如下权利：
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. 尊重需求工程中开发人员采用的流程（过程）。

软件客户需求权利书

权利# 1：要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务，故要使用业务术语，你应将其教给分析人员，而你
不一定要懂得计算机的行业术语。
权利# 2：要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使
产品更好地满足你的需要。这将有助于开发人员设计出真正满足你的需要并达到你期望的优
秀软件。为帮助开发人员和分析人员，可以考虑邀请他们观察你或你的同事是怎样工作的。
如果新开发系统是用来替代已有的系统，那么开发人员应使用一下目前的系统，这将有利于
他们明白目前系统是怎样工作的，其工作流程的情况，以及可供改进之处。
权利# 3：要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理，以区分开业务需求及规范、
功能需求、质量目标、解决方法和其它信息。通过这些分析就能得到一份软件需求规格说明。
而这份软件需求规格说明（ software requirements specification, SRS）便在开发人员和客户之
间针对要开发的产品内容达成了协议。S R S可以用一种你认为易于翻阅和理解的方式组织编
写。要评审编写出的规格说明以确保它们准确而完整地表达了你的需求。一份高质量的软件
需求规格说明能有助于开发人员开发出真正需要的产品。
权利# 4：要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。因为如工作流程图
那样的图表能很清楚地描述出系统行为的某些方面。所以需求说明中的各种图表有着极高的
价值。虽然它们不太难于理解，但是你很可能对此并不熟悉。因此可以要求分析人员解释说
明每张图表的作用或其它的需求开发工作结果和符号的意义，及怎样检查图表有无错误及不
一致等。
权利# 5：要求开发人员尊重你的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍，共同合作能使
大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成
功所付出的时间。同样，客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊
重与感激。
权利# 6：要求开发人员对需求及产品实施提供建议，拿出主意
通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些
解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保
产品不会无效或低效。在彻底弄清业务领域内的事情后，分析人员有时就能提出相当好的改
进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统
特性。
权利# 7：描述产品易使用的特性
你可以要求分析人员在实现功能需求的同时还要注重软件的易用性。因为这些易用特性
或质量属性能使你更准确、高效地完成任务。例如，客户有时要求产品要“用户友好”或
“健壮”或“高效率”，但这对于开发人员来说，太主观了并无实用价值。正确的应是：分析
人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性（第11章将详细讨
论它）。
权利# 8：调整需求，允许重用已有的软件组件
需求通常要有一定的灵活性。分析人员可能发现已有的某个软件组件与你描述的需求很
相符。在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发
中重用一些已有的软件。如果有可重用的机会出现，同时你又能调整你的需求说明，那就能
降低成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一
些已有的商业常用组件，而它们并不完全适合你所需的特性，这时一定程度上的需求灵活性
就显得极为重要了。
权利# 9：要求对变更的代价提供真实可信的评估
有时人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影
响进行评估从而对业务决策提供帮助，是十分必要的，所以，你有权利要求开发人员通过分
析给出一个的确真实可信的评估，包括影响、成本和得失等评估。开发人员不能由于不想实
施变更而随意夸大评估成本。
权利# 1 0：获得满足客户功能和质量要求的系统
每个人都希望项目获得成功。但这不仅要求你要清晰地告知开发人员关于系统“做什么”
所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制。一定要明确说明你
的假设和潜在的期望。否则，开发人员开发出的产品很可能无法让你满意。

软件客户需求义务书
义务# 1：给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语。但你不能指望分析人员会成为该领域
的专家，而只能让他们真正明白你的问题和目标。不要期望分析人员能把握你们业务的细微
与潜在之处，他们很可能并不知道那些对于你和你的同事来说理所当然的“常识”。
义务# 2：抽出时间清楚地说明并完善需求
客户很忙，经常在最忙的时候还得参与需求开发。但无论如何，你有义务抽出时间参与
“头脑风暴”会议的讨论，接受采访或其它获取需求的活动。有时分析人员可能先以为明白了
你的观点，而过后发现还需要你的讲解。这时，请耐心一些对待需求和需求的精化工作过程
中的反复，因为它是人们交流中的很自然的现象，何况这对软件产品的成功极为重要。
义务# 3：准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且又耗时，
故很容易留下模糊不清的需求。但是，在开发过程中，必须得解决这种模糊性和不准确性。
而你恰是为解决这些问题作出决定的最佳人选。不然的话，你就只好靠开发人员去正确猜测
了。
在需求规格说明中暂时加上待定（ to be determined, TBD）的标志是个不错的办法。用该
标志可指明了哪些需要进一步探讨、分析或增加信息的地方。不过，有时也可能因为某个特
殊需求难以解决或没有人愿意处理它而注上T B D标志。尽量将每项需求的内容都阐述清楚，
以便分析人员能准确的将其写进软件需求规格说明中。如果你一时不能准确表述，那就得允
许获取必要的准确信息这样一个过程。通常使用所谓的原型技术。通过开发的原型，你可以
同开发人员一起反复修改，不断完善需求定义。
义务# 4：及时地作出决定
正如一位建筑师为你修建房屋，分析人员将要求你做出一些选择和决定。这些决定包括
来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权做出
决定的客户必须积极地对待这一切，尽快做处理、做决定。因为开发人员通常只有等你做出
了决定才能行动，而这种等待会延误项目的进展。
义务# 5：尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格，开发人员最适合预算这些成本（尽管许多开发人员并
不擅长评估预测）。你所希望的某些产品特性可能在技术上行不通，或者实现它要付出极为高
第2章客户的需求观15
下载
昂的代价。而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到
的数据，开发人员会对此作出负面的评价意见，你应该尊重他们的意见。
有时，你可以重新给出一个在技术上可行、实现上便宜的需求，例如，要求某个行为在
“瞬间”发生是不可行的，但换种更具体的时间需求说法（“在5 0 m s以内”），这就可以实现
了。
义务# 6： 划分需求优先级别
绝大多数项目没有足够的时间或资源来实现功能性的每个细节。决定哪些特性是必要的，
哪些是重要的，哪些是好的，是需求开发的主要部分。只能由你来负责设定需求优先级，因
为开发者并不可能按你的观点决定需求优先级。开发者将为你确定优先级提供有关每个需求
的花费和风险的信息。当你设定优先级时，你帮助开发者确保在适当的时间内用最小的开支
取得最好的效果。
在时间和资源限制下，关于所需特性能否完成或完成多少应该尊重开发人员的意见。尽
管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对这种现实的。业务
决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
义务# 7：评审需求文档和原型
正如我们将在第1 4章讨论的，无论是正式的还是非正式的方式，对需求文档进行评审都
会对软件质量提高有所帮助。让客户参与评审才能真正鉴别需求文档是否的确完整、正确说
明了期望的必要特性。评审也给客户代表提供一个机会，给需求分析人员带来反馈信息以改
进他们的工作。如果你认为编写的需求文档不够准确，就有义务尽早告诉分析人员并为改进
提供建议。
通过阅读需求规格说明，很难想象实际的软件是什么样子的。更好的方法是先为产品开
发一个原型。这样你就能提供更有价值的反馈信息给开发人员，帮助他们更好地理解你的需
求。必须认识到：原型并非是一个实际产品，但开发人员能将其转变、扩充成功能齐全的系
统。
义务# 8：需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响。变更是不可避
免的，但在开发周期中变更越在晚期出现，其影响越大。变更不仅会导致代价极高的返工，
而且工期也会被迫延误，特别是在大体结构已完成后又需要增加新特性时。所以一旦你发现
需要变更需求时，请一定立即通知分析人员。
义务# 9：应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度，所有的参与者必须遵照项目的变更控制过
程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后作出合适
的决策以确定将某些变更引入项目中。
义务# 1 0：尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性。分析人员采用的方法有其合
理性。也许你认为需求过程不太划算，但请相信花在需求开发上的时间是“很有价值”的。
如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过
程将会更为顺利。尽管去询问分析人员为什么他们要收集某些信息，或参与与需求有关的活
动。

出自《软件详细需求分析说明书》。很不错的一本书，推荐大家看看。