需求分析与解决方案设计ch

1、1 第2章 客户眼中的需求4某些需求问题源于混淆了不同层次的需求(业务需求、用户需求和功能需求)。 4这一章将讨论客户与开发人员之间的关系，这对软件项目的成功至关重要。4还提出了软件客户权利法案和对应的软件客户责任法案，这些法案强调了需求开发中客户(尤其是用户)参与的重要性。2 2.1 客户4最广义地讲，客户泛指直接或间接得益于产品的个人或组织。4软件的客户客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众。4低一层的需求用户需求则应来自实际使用产品的人。这类用户(通常被称为“最终用户”)构成了另一类型的客户。 4对于签约开发或自己开发的项目，业务需求应来自投资项目

2、人，而用户需求则应来自产品的实际使用者。32.2 客户与开发人员的合作伙伴关系 要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。 而高质量的需求则源自开发人员与客户之间的沟通与合作，即所谓的合作伙伴关系。然而很多时候开发人员与客户之间却是一种对立关系，项目经理如果只考虑自己的进度而不考虑用户提出的需求，就会造成矛盾，这样对谁都没有好处。 只有参与各方都了解自己获得成功的条件，并且理解和尊重合作者的成功条件时合作才能取得成功。 客户与开发人员的合作伙伴关系，体现在软件客户的权利与义务法案42.2 客户与开发人员的合作伙伴关系4软件客户的权利法案(见表2.1)列出了10项权利。在项目需

3、求工程的实施过程中，客户可以理直气壮地向需求分析员和开发人员提出这些要求。10. 获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意9. 在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估8. 调整需求，便于重用已有的软件组件7. 要求开发人员实现能让产品使用起来更容易、更有趣的特性6. 要求需求分析员和开发人员为需求和产品实现提供思路和备用方案5. 要求需求分析员和开发人员尊重客户，始终以合作和专业的态度与客户进行互动4. 要求需求分析员解释需求过程生成的所有工作结果3. 要求需求分析员把需求收集过程中客户提供的信息组织成书面的软件需求规格说明2. 要求需求

4、分析员熟悉客户的业务，了解客户对系统的目标1. 要求需求分析员使用客户的语言客户有权利表2.15软件客户有义务1. 为需求分析员和开发人员讲解业务并定义业务术语2. 提供需求，阐明需求，通过与开发人员的交互将需求充实完善3. 对系统需求的描述必须详细、准确4. 需要时，及时对需求做出决断5. 尊重开发人员对需求成本和可行性的评估6. 与开发人员协作，为功能需求、系统特性和用例设置优先级7. 审阅需求文档，评估原型8. 发现需要变更需求时，及时与开发人员沟通9. 按照开发组织的变更控制过程提出需求变更10. 尊重需求分析员在需求工程中使用的过程 2.2 客户与开发人员的合作伙伴关系4 软件客户的

5、义务法案(见表2.2)则列出了需求过程中客户对需求分析员和开发人员承担的10项义务。注意：不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。 表2.26 2.2.1 软件客户的权利法案4 权利之一：要求需求分析员使用客户的语言 需求的讨论必须以客户的业务需求和业务工作为中心，使用客户的业务用语。 客户可以通过词汇表向需求分析员提供业务术语。 4 权利之二：要求需求分析员理解客户的业务和目标 通过与客户交流获得需求，需求分析员能够更充分地理解客户的业务以及如何让产品适合业务需求。 4 权利之三：要求需求分析员编写软件需求规格说明 需求分析员对来自不同客户的信息进行

6、整理，把用例同业务需求、业务规则、功能需求、质量目标、对解决方案的建议等内容区分开来。 4 权利之四：听取对需求工作成果的解释 需求分析员也许会使用不同的示意图来配合SRS文本对需求进行描述。 4 权利之五：得到需求分析员和开发人员的尊重 参与需求开发过程时，客户有权要求需求分析员和软件人员尊重他们的想法，并且珍惜他们为项目成功所付出的时间。7 2.2.1 软件客户的权利法案4 权利之六：听取开发人员对于需求及如何实现需求的想法和备用方案 需求分析员应该了解客户现有的系统为何不能很好地满足他们的业务流程需要，从而保证新的系统能够更高效满足新需要。4 权利之七：描述使产品易于使用的特性 客户可以

7、要求需求分析员留意用户功能需求之外的软件特性。 4 权利之八：为实现重用而对需求做出调整 需求分析员也许知道有现成的软件组件大致符合客户描述的部分需求。需求分析员应该把这种情况告诉用户，让他们选择是否对需求做出修改，以便开发人员能够重用已有的软件。 4 权利之九：获得对变更成本的真实估算 如果知道还有开销更小的方案，客户会作出不同的选择。 4 权利之十：得到满足功能和质量需求的系统 大家都希望项目达到的圆满结果。但有两个前提：客户将开发产品需要的所有信息明确告知了开发人员；开发人员也让客户清楚了所有的选择和约束。8 2.2.2 软件客户的义务法案4 义务之一：为需求人员和开发人员讲解业务 开发

8、小组依靠客户为他们讲解客户的业务概念和术语。 讲解业务的目的不是要把业务分析员培养成该领域的专家，而是帮他们理解客户的问题和目标。 4 义务之二：花时间提供并阐明需求 有义务投入时间去参与产品开发过程、自由讨论、会谈以及其他需求获取活动。 4 义务之三：对需求的说明必须具体和准确 客户应尽量把每项需求的意图阐述清楚，以便需求分析员可以在SRS中将其准确表达出来。如果无法准确描述，客户应该同意采用能达到所需准确度的方法。4 义务之四：及时做出决定 需求分析员会要求客户做出很多选择和决定，包括解决来自多个客户的需求间不一致的问题，以及评估信息的准确性。 4 义务之五：尊重开发人员对成本和可行性的评

9、估 开发人员最有资格来估算这些成本，尽管他们中很多人并非熟练的评估员。 9 2.2.2 软件客户的义务法案4 责任之六：为需求设置优先级 对于设置优先级，客户应该起主导作用，因为开发人员无法确定某个需求对客户究竟有多重要。开发人员将提供关于每项需求的成本和风险的信息，帮助确定最终的优先级。客户确定了需求的优先级后，开发人员可以据此在合适的时间内，以最低的成本创造出最大的价值。4 义务之七：审阅需求文档，评估原型 让客户参与审阅是评估需求是否具备完整性、正确性和必要性的唯惟一方法 。4 义务之八：将需求变更及时告知开发人员 客户一旦意识到需要更改需求，就应马上通知需求分析员。 4 义务之九：遵循

10、开发组织的变更过程 为了将变更的负面影响降至最低，客户就必须遵循项目中定义的变更控制过程。 4 义务之十：尊重需求分析员使用的需求工程方法 需求分析员使用的各种方法都有其理论基础。 如果客户能够理解并尊重需求分析员用于需求开发的方法，整个需求过程就会变得更轻松。10 2.3 关于“签字”4 客户和开发人员之间合作伙伴关系的核心是就产品的需求达成一致。很多组织把在需求文档上签字作为客户认可需求的标志。 4 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。 问题之一是客户代表把在需求文档上签字视作毫无意义的仪式。另一个关于签字的问题是开发经理把签字作为冻结需求的方法。 4 签

11、字不仅仅是仪式，更重要的是建立需求协议的基线 。要求说明在批准需求文档时签字的真正含义，把这个定义写下来。注意：不要把签字当成武器。应该把它作为项目的一个里程碑。对于签字之前应进行哪些活动，以及签字对将来变更的影响，各方应形成明确一致的理解。 11 2.3 关于“签字” 需求基线4需求基线(requirement baseline)是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。4定义了一个需求基线之后，项目的涉众各方就可以对发布的产品中希望具有的功能和属性有一个一致的理解。12 2.3 关于“签字”l 设置基线是很有意义的，它能给所有主要的涉众带来信心：客户管理

12、层相信项目的范围不会过度膨胀直至失控 。用户代表有信心开发团队会跟他们一同努力开发出符合需求的系统 。开发管理人员有信心，因为开发团队有了业务伙伴。业务伙伴能够保证项目的中心工作集中在业务目标上。他们将与开发人员一起在进度、成本、功能和质量之间做出平衡。需求分析员也充满信心，因为他们可以有效地管理项目的变更，将变更引起的麻烦减至最小。13本次课小结4客户与开发人员之间的关系；4软件客户权利法案和责任法案，这些法案强调了需求开发中客户(尤其是用户)参与的重要性；4关于“签字” ，明确签字不仅仅是仪式，更重要的是建立需求协议的基线 。要求说明在批准需求文档时，签字的真正含义，把这个定义写下来。144明确由哪些客户负责为项目提供业务需求和用户需求。看看权利法案和义务法案中哪些条款是他们理解、接受和已经实行的。4跟重要客户一起讨论权利法案，了解他们是否认为有些权利自己没有享受到。与他们讨论责任法案，就接受哪些条款达成一致。根据讨论结果对权力法案和义务法案做出相应的修正，这样各方便能就如何进行合作达成共识