|
我的同事K a r e n已经在她的公司里成功地引入软件需求文档的正式评审。她已经注意到在评审会议上所提出的许多问题都与项目所设定的范围有关。参与评审的的专家经常难以理解项目所设定的范围，并且在项目的最终目标上所持的看法各不相同。因此，他们发现在哪一个功能需求应该列入软件需求规格说明的问题上很难达成一致的意见。正如我们在第1章所叙述的那样，业务需求代表了需求链中最高层的抽象：他们为软件系统定义了项目视图（ v i s i o n）和范围（s c o p e）。软件功能需求必须根据用户的需求来考虑，且要与业务需求所设定的目标相一致。对不利于实现项目业务目标的需求应该排除在外。一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。项目管理者联盟
如果一个项目缺乏明确的规划和良好的信息交流途径，那将是十分糟糕的。如果项目的参与者持有不同的目标和优先权，那么他们只能各抒己见，无心工作。如果项目的风险承担者在产品所能满足的业务需要和产品所能提供的利益问题上不能达成一致的意见，那么需求决不会稳定。一个清晰的项目视图和范围过于分散在多个地方开发，在这样的项目中，地理位置上的分离使项目开发组成员必须天天进行相互沟通才能保证他们之间能进行更有效的合作。业务需求中某些特性最初被列入规格说明，而后又被删除，最后又加入，则说明此业务需求未完全定义好。在确定详细的功能需求之前，必须很好地解决项目的视图和范围问题。对范围和局限性的明确说明将在很大程度上有助于对所建议特性的探讨和最终产品的发行。一个明确定义了项目视图和范围的文档也可以为所建议的需求变更的决策提供参考。
项目管理者联盟
通过业务需求确定项目视图项目管理者联盟
www.mypm.net
项目视图可以把项目参与者定位到一个共同和明确的方向上。项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能。相反的，范围描述了产品应包括的部分和不应包括的部分。范围的说明在包括与不包括之间划清了界线，当然，它还确定了项目的局限性。项目的业务需求在视图上和范围上形成文档，这些必须在创建项目之前起草。开发商业软件的公司经常编写市场需求文档，其实这种文档也是为了类似的目的，但这种文档较为详细地涉及关于目标市场部分的内容，这是为适应商业的需要。视图和范围的文档为项目的主办者或具有同等地位的人所拥有。业务需求是从各个不同的人那里收集来的，这些人对于为什么要从事该项目和该项目最终能为业务和客户提供哪些价值有较清楚的了解。它们包括主办者( s p o n s o r )、客户、开发公司的高级管理人员及项目的幻想者( v i s i o n a r y )，例如产品的代表和市场部门人员。
来自各个渠道的业务需求可能会发生冲突。比如，考虑具有嵌入软件的售货亭管理系统，项目管理者联盟
它将卖给零售店并由零售客户使用。售货亭管理系统的开发者有如下的业务目标：项目管理者联盟
• 向零售商发行并销售售货亭产品。项目管理者联盟
• 通过售货亭软件向客户销售消费品。bbs.mypm.net
• 吸引客户对商品的兴趣。项目管理者联盟
• 改变原有的开发者—客户的关系。项目管理者联盟
项目管理者联盟
零售亭业务对如下方面感兴趣：项目管理者联盟文章
• 通过客户使用售货亭软件而获利。项目管理者联盟
• 吸引更多的客户来商店购买。training.mypm.net
• 如果售货亭软件替代了人工操作，就可节省钱。talent.mypm.net
项目管理者联盟
开发者可能要为客户建立高科技系统，并且引导客户紧跟新的发展方向。而零售商则需要一个简易、方便使用的系统，客户需要便利和良好的性能。这三者在目标、限制和费用因素上的不同将导致业务需求的冲突，这必须在售货亭管理系统的软件需求说明制订之前予以解决。也可以利用业务需求对使用实例及与它们相关的功能需求设置实现优先级。例如，业务需求的确定可以从售货亭软件产生最大收益考虑，这意味着软件性能的最初实现是与销售更多的产品或对客户服务有直接关系，而不是去强调只吸引少量客户的软件性能。业务需求不仅决定了应用程序所能实现的业务任务（使用实例）的设置（所谓的应用宽度），还决定了对使用实例所支持的等级和深度。支持的深度可以从一个很小的实现细节到具有许多辅助功能的完全自动化的操作。对于每个使用实例都必须决定其宽度和深度，并编写出文档。如果业务需求帮助你确定一个在应用范围之外特殊的使用实例，那么此时，你正在确定产品的应用宽度。业务需求还可以帮助你确定哪一个使用实例需要健壮的、综合的功能实现，哪一个仅需要一般实现，至少需要初始实现。service.mypm.net
项目视图和范围的文档项目管理者联盟
项目管理者联盟
项目视图和范围的文档（vision and scope document）把业务需求集中在一个简单、紧凑的文档里，这个文档为以后的开发工作奠定了基础。项目视图和范围文档包括了业务机遇的描述、项目的视图和目标、产品适用范围和局限性的陈述、客户的特点、项目优先级别和项目成功因素的描述。这必须是一个相对简短的文档，也许只有3～8页纸，这取决于项目的性质和大小。项目管理者联盟
图6 - 1描述了一个对项目视图和范围文档的推荐模板，文档模板对公司项目所创建的文档结构进行了标准化。就像其它模板一样，必须对图6 - 1所示的模板图进行改写来满足你项目的需要。www.mypm.net
下面介绍这个模板的每一个部分。项目管理者联盟
项目管理者联盟
a. 业务需求项目管理者联盟
项目管理者联盟
业务需求说明了提供给客户和产品开发商的新系统的最初利益。不同的产品，例如信息管理系统，商业软件包，系统捆绑软件将有不同的侧重点。然而，项目开发的投入是由于人们坚信：有了新产品，世界将变得更加美好。本部分描述了你为什么要从事此项项目的开发，以及它将给开发者和购买者带来的利益。项目管理者联盟
a . 1背景项目管理者联盟
在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。项目管理者联盟
a.2 业务机遇转自项目管理者联盟
描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。认识到目前只能使用该产品才能解决的一些问题，并描述产品是怎样顺应市场趋势和战略目标的。项目管理者联盟
a.3 业务目标pmp.mypm.net
用一个定量和可测量的合理方法总结产品所带来的重要商业利润。关于给客户带来的价值在本模板a . 5的项目视图和范围文档中阐述，这里仅把重点放在给业务的价值上。这些目标与收入预算或节省开支有关，并影响到投资分析和最终产品的交付日期。如果这些信息在其它地方已叙述，就请参考有关文档，在此就不再重复了。项目管理者联盟
a.4 客户或市场需求项目管理者联盟
描述一些典型客户的需求，包括不满足现有市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。定义了较高层次的关键接口或性能要求，但避免设计或实现细节。把这些要求写在列表中，可以反过来跟踪调查特殊用户和功能需求。项目管理者联盟
a.5 提供给客户的价值项目管理者联盟文章
确定产品给客户带来的价值，并指明产品怎样满足客户的需要。可以用下列言辞表达产品带给客户的价值：pmp.mypm.net
• 提高生产效率，减少返工。项目管理者联盟
• 节省开支。项目管理者联盟
• 业务过程的流水线化。项目管理者联盟
• 先前人工劳动的自动化。项目管理论坛
• 符合相关标准和规则。项目管理者联盟
• 与目前的应用产品相比较，提高了可用性或减少了失效程度。项目管理者联盟
a.6 业务风险项目管理培训
总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。项目管理者联盟
项目管理者联盟
b. 项目视图的解决方案转自项目管理者联盟
项目管理者联盟
文档中的这一部分为系统建立了一个长远的项目视图，它将指明业务目标。这一项目视图为在软件开发生存期中作出决策提供了相关环境背景。这部分不应包括详细的功能需求和项目计划信息。www.mypm.net
b.1 项目视图陈述项目经理博客
编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。这里是曾在前面章节讨论过的“化学制品跟踪系统”的简单项目视图陈述的一个实例。www.mypm.net
|
