同事karen已经在她的公司里成功地引入软件需求文档的正式评审。她已经注意到在评审会议上所提出的许多问题都与项目所设定的范围有关。参与评审的的专家经常难以理解项目所设定的范围，并且在项目的最终目标上所持的看法各不相同。因此，他们发现在哪一个功能需求应该列入软件需求规格说明的问题上很难达成一致的意见。正如我们在第1章所叙述的那样，业务需求代表了需求链中最高层的抽象：他们为软件系统定义了项目视图（vision）和范围（scope）。软件功能需求必须根据用户的需求来考虑，且要与业务需求所设定的目标相一致。对不利于实现项目业务目标的需求应该排除在外。一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。

如果一个项目缺乏明确的规划和良好的信息交流途径，那将是十分糟糕的。如果项目的参与者持有不同的目标和优先权，那么他们只能各抒己见，无心工作。如果项目的风险承担者在产品所能满足的业务需要和产品所能提供的利益问题上不能达成一致的意见，那么需求决不会稳定。一个清晰的项目视图和范围过于分散在多个地方开发，在这样的项目中，地理位置上的分离使项目开发组成员必须天天进行相互沟通才能保证他们之间能进行更有效的合作。业务需求中某些特性最初被列入规格说明，而后又被删除，最后又加入，则说明此业务需求未完全定义好。在确定详细的功能需求之前，必须很好地解决项目的视图和范围问题。对范围和局限性的明确说明将在很大程度上有助于对所建议特性的探讨和最终产品的发行。一个明确定义了项目视图和范围的文档也可以为所建议的需求变更的决策提供参考。

通过业务需求确定项目视图

项目视图可以把项目参与者定位到一个共同和明确的方向上。项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能。相反的，范围描述了产品应包括的部分和不应包括的部分。范围的说明在包括与不包括之间划清了界线，当然，它还确定了项目的局限性。项目的业务需求在视图上和范围上形成文档，这些必须在创建项目之前起草。开发商业软件的公司经常编写市场需求文档，其实这种文档也是为了类似的目的，但这种文档较为详细地涉及关于目标市场部分的内容，这是为适应商业的需要。视图和范围的文档为项目的主办者或具有同等地位的人所拥有。业务需求是从各个不同的人那里收集来的，这些人对于为什么要从事该项目和该项目最终能为业务和客户提供哪些价值有较清楚的了解。它们包括主办者(sponsor)、客户、开发公司的高级管理人员及项目的幻想者(visionary)，例如产品的代表和市场部门人员。

来自各个渠道的业务需求可能会发生冲突。比如，考虑具有嵌入软件的售货亭管理系统，

它将卖给零售店并由零售客户使用。售货亭管理系统的开发者有如下的业务目标：

•向零售商发行并销售售货亭产品。

•通过售货亭软件向客户销售消费品。

•吸引客户对商品的兴趣。

•改变原有的开发者—客户的关系。

零售亭业务对如下方面感兴趣：

•通过客户使用售货亭软件而获利。

•吸引更多的客户来商店购买。

•如果售货亭软件替代了人工操作，就可节省钱。

开发者可能要为客户建立高科技系统，并且引导客户紧跟新的发展方向。而零售商则需要一个简易、方便使用的系统，客户需要便利和良好的性能。这三者在目标、限制和费用因素上的不同将导致业务需求的冲突，这必须在售货亭管理系统的软件需求说明制订之前予以解决。也可以利用业务需求对使用实例及与它们相关的功能需求设置实现优先级。例如，业务需求的确定可以从售货亭软件产生最大收益考虑，这意味着软件性能的最初实现是与销售更多的产品或对客户服务有直接关系，而不是去强调只吸引少量客户的软件性能。业务需求不仅决定了应用程序所能实现的业务任务（使用实例）的设置（所谓的应用宽度），还决定了对使用实例所支持的等级和深度。支持的深度可以从一个很小的实现细节到具有许多辅助功能的完全自动化的操作。对于每个使用实例都必须决定其宽度和深度，并编写出文档。如果业务需求帮助你确定一个在应用范围之外特殊的使用实例，那么此时，你正在确定产品的应用宽度。业务需求还可以帮助你确定哪一个使用实例需要健壮的、综合的功能实现，哪一个仅需要一般实现，至少需要初始实现。

项目视图和范围的文档

项目视图和范围的文档（visionandscopedocument）把业务需求集中在一个简单、紧凑的文档里，这个文档为以后的开发工作奠定了基础。项目视图和范围文档包括了业务机遇的描述、项目的视图和目标、产品适用范围和局限性的陈述、客户的特点、项目优先级别和项目成功因素的描述。这必须是一个相对简短的文档，也许只有3～8页纸，这取决于项目的性质和大小。

图6-1描述了一个对项目视图和范围文档的推荐模板，文档模板对公司项目所创建的文档结构进行了标准化。就像其它模板一样，必须对图6-1所示的模板图进行改写来满足你项目的需要。

下面介绍这个模板的每一个部分。

a.业务需求

业务需求说明了提供给客户和产品开发商的新系统的最初利益。不同的产品，例如信息管理系统，商业软件包，系统捆绑软件将有不同的侧重点。然而，项目开发的投入是由于人们坚信：有了新产品，世界将变得更加美好。本部分描述了你为什么要从事此项项目的开发，以及它将给开发者和购买者带来的利益。

a.1背景

在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。

a.2业务机遇

描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。认识到目前只能使用该产品才能解决的一些问题，并描述产品是怎样顺应市场趋势和战略目标的。

a.3业务目标

用一个定量和可测量的合理方法总结产品所带来的重要商业利润。关于给客户带来的价值在本模板a.5的项目视图和范围文档中阐述，这里仅把重点放在给业务的价值上。这些目标与收入预算或节省开支有关，并影响到投资分析和最终产品的交付日期。如果这些信息在其它地方已叙述，就请参考有关文档，在此就不再重复了。

a.4客户或市场需求

描述一些典型客户的需求，包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。定义了较高层次的关键接口或性能要求，但避免设计或实现细节。把这些要求写在列表中，可以反过来跟踪调查特殊用户和功能需求。

a.5提供给客户的价值

确定产品给客户带来的价值，并指明产品怎样满足客户的需要。可以用下列言辞表达产品带给客户的价值：

•提高生产效率，减少返工。

•节省开支。

•业务过程的流水线化。

•先前人工劳动的自动化。

•符合相关标准和规则。

•与目前的应用产品相比较，提高了可用性或减少了失效程度。

a.6业务风险

总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。

b.项目视图的解决方案

文档中的这一部分为系统建立了一个长远的项目视图，它将指明业务目标。这一项目视图为在软件开发生存期中作出决策提供了相关环境背景。这部分不应包括详细的功能需求和项目计划信息。

b.1项目视图陈述

编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。这里是曾在前面章节讨论过的“化学制品跟踪系统”的简单项目视图陈述的一个实例。

“化学制品跟踪系统”可使科学家查询到化学制品仓库或供应商将提供的化学制品容器。系统可随时了解公司中每一个化学制品容器所处的位置，容器中所剩余的药品剂量，任何时候每个容器所处的位置和用法的历史记录。通过充分利用公司内部的可用化学制品，废弃极少量已使用或过期失效的化学制品，使用标准的化学制品的购买过程等将在化学制品上节省25%开支。“化学制品跟踪系统”还能产生符合政府部门规定所要求的全部报表，包括化学制品的使用、存储和废弃等报表。

b.2主要特性

包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。

b.3假设和依赖环境

在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。如果你把它们都记录下来，并加以评论，就能对项目内部隐含的基本假设达成共识。比如，“化学制品跟踪系统”的开发者假设：该系统可以替代现有的仓库存货系统，并能与有关采购部门的应用相连接。把这些都记录下来以防止将来可能的混淆和冲突。还有，记录项目所依赖的主要环境，比如：所使用的特殊的技术、第三方供应商、开发伙伴或其它业务关系。

c.范围和局限性

当一个化学家发明了可以把一种化学制品转变为另一种化学制品的新的化学变化时，它所发表的论文中包含了“范围和局限性”部分，这一部分描述了这一化学变化所能作和不能作的一种限定。类似地，一个软件项目也必须定义它的范围和局限性，并作为业务需求的一部分。项目范围定义了所提出的解决方案的概念和适用领域，而局限性则指出产品所不包括的某些性能。澄清范围和局限性这两个概念有助于建立各风险承担者所企盼的目标。有时客户所要求的性能太奢华或者与产品所制定的范围不一致。一般客户所提出的需求超出项目的范围时就应当拒绝它，除非这些需求是很有益的。这时，可适当扩大项目范围来适应这些需求（在预算、计划、人员方面也要相应进行变化）。记录这些需求以及拒绝它们的原因，以备日后重新遇到时，有记录可查。

c.1首次发行的范围

总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群（customercommunity）提供预期的成果。如果你的目标集中在开发成果和维持一个可行的项目规划上，应当避免一种倾向，那就是把一些潜在的客户所能想到的每一特性都包括到1.0版本的产品中。这一倾向所带来的普遍恶果是产生软件规划的动荡性和错误性。开发者应把重点放在能提供最大价值、花费最合理的开发费用及普及率最高的产品上。例如，我的同事scott的上一个项目开发小组决定，用户可以用首发版的软件进行包裹传递业务。1.0版本并不要求快速、结构紧凑或易于使用，但该软件必须稳定运行；整个开发小组始终以这一目标为准。首发版的软件完成了基本的系统目标，而随后的版本则包含了附加的特性、选项和使用帮助。

c.2随后发行的范围

如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。

c.3局限性和专用性

明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。

d.业务环境

这一部分总结了一些项目的业务问题，包括主要的客户分类概述和项目的管理优先级。

d.1客户概貌

客户概述明确了这一产品的不同类型客户的一些本质的特点，以及目标市场部门和在这些部门中的不同客户的特征。对于每一种客户类型，概述要包括以下信息：

•各种客户类型将从产品中获得的主要益处。

•它们对产品所持的态度。

•感兴趣的关键产品的特性。

•哪一类型客户能成功使用。

•必须适应任何客户的限制。

d.2项目的优先级

一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员（wiegers1996a）。在所给的项目中，其每一方面应与下面三个因素之一相适应。

•一个驱动（driver）—一个最高级别的目标。

•一个约束（constraint）—项目管理者必须操纵一个对象的限制因素。

•一个自由度（degreeoffreedom）—项目管理者能权衡其它方面，进而在约束限制的

范围内完成目标的一个因素。未必所有的因素都能成为驱动，或所有的因素都能成为约束因素。在项目开始时记录和分析哪一个因素适用于哪一类型，将有助于使每一个人的努力和期望与普遍认可的优先级相一致。

e.产品成功的因素

明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括外部因素。如果可能，可建立测量的标准，用于评价是否达到业务目标，这些标准的实例有：市场股票、销售量或收入、客户满意程度的测量、交易处理量和准确度。

3关联图

软件项目范围的描述为我们正在开发的系统和宇宙万物之间划清了界线。关联图(context

diagram)通过正在开发的系统或正在讨论的问题和外部世界之间的联系来描述这一界线。关联图确定了通过某一接口与系统相连的外部实体（称为“端点”或“外部实体”），同时也确定

了外部实体和系统之间的数据流和物流。我们把关联图作为按照结构化分析所形成的数据流

图的最高抽象层（robertsonandrobertson1994）。可以把关联图写入项目视图和范围文档或软件需求规格说明中，或者作为系统数据流模型的一部分。“化学制品跟踪系统”的简单的关联图如图6-2所示。整个系统被描述成一个简单的循环，所以关联图并不明确提供系统的内部过程和数据。关联图中的流可以用信息（“化学制品请求”）或物理项（“化学制品容器”）来表示。以矩形图示的端点可以表示用户类(“药剂师”)、组织（“采购部门”）或其它计算机系统（“培训用数据库”）。

你可能希望把化学制品的供应商作为一个端点放入关联图中。别忘了，公司总是发购买化学制品的订单给化学制品供应商，并从供应商那里得到装有化学制品的容器和发票，而供应商则得到支票。然而，这些过程发生在“化学制品跟踪系统”范围之外，并作为购买和进货部门日常事务的一部分。关联图明确告诉我们，系统并不直接与供应商订货、进货、或付账。虽然某些端点与所规划的系统没有直接联系，但有时关联图将给出与项目的问题域有关的端点之间的联系（jackson1995）。不是教条地去追求如何绘制“正确”的关联图，而是使用这样的图来确定项目风险承担者之间清晰而精确的关系。

4把注意力始终集中在项目的范围上

在项目视图和范围文档中记录业务需求为防止开发过程范围的扩展(creep)提供了有利的手段。项目视图和范围文档可以使你判断所提出的特性和需求放进项目是否合适。当某些人提出新的需求或改变需求或特性时，你必须问的第一个问题是：“这是否包含在项目范围之内？”所提出的一些建议有时完全在项目范围之外。它们可能是一个好的方案，但这个方案适用于其它项目或将来要发行的产品。另外一些建议很明显是在项目范围定义之内。如果这种建议与已经为某一确定产品所制定的需求相比，具有更高的优先级，则这些新的并符合要求的需求就可以加入到项目中。不过此时你必须作出权衡（tradeoff），决定是延迟还是取消其它已经确定的需求或特性。

第三种可能性是“所提出的新需求在项目范围之外，但这是一个很有价值的方案，此时可以改变项目的范围来适应这一需求。但要求你要修改项目视图和范围文档。当改变项目的范围时，你必须重新商议计划预算、资源及进度安排，也许还有开发人员（特别是在需要新的技术和技巧时）。理想的情况是原先的安排和资源能合理地适应需求变更。然而，你必须在需求变更得到赞同后才重新进行计划安排，除非你原先对需求的预算留有余地。范围扩展存在固有的两个主要问题：1)全部的工作必须重新进行以适应变化。2)当项目的范围增大时，如果没有调整原先所分配的资源和时间，则属性会遭到破坏。一组确定的业务需求可以使项目依照计划正常进行，在市场或业务需要变更时可以合理地调整项目范围的大小；当一些有影响的人企图往有许多约束的项目中添加更多的特性时，可以合理地拒绝这

些要求。