怎样写项目视图和范围文档

些潜在的客户所能想到的每一特性都包括到1 . 0版本的产品中。这一倾向所带来的普遍恶果是产生软件规划的动荡性和错误性。开发者应把重点放在能提供最大价值、花费最合理的开发费用及普及率最高的产品上。

例如，我的同事S c o t t的上一个项目开发小组决定，用户可以用首发版的软件进行包裹传递业务。1 . 0版本并不要求快速、结构紧凑或易于使用，但该软件必须稳定运行；整个开发小组始终以这一目标为准。首发版的软件完成了基本的系统目标，而随后的版本则包含了附加的特性、选项和使用帮助。 c.2 随后发行的范围

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

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

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

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

? 各种客户类型将从产品中获得的主要益处。 ? 它们对产品所持的态度。 ? 感兴趣的关键产品的特性。 ? 哪一类型客户能成功使用。 ? 必须适应任何客户的限制。 d.2 项目的优先级

一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性

能、质量、计划、成本和人员（Wiegers 1996a）。在所给的项目中，其每一方面应与下面三个因素之一相适应。

? 一个驱动（ d r i v e r）—一个最高级别的目标。

? 一个约束（ c o n s t r a i n t）—项目管理者必须操纵一个对象的限制因素。 ? 一个自由度（ degree of freedom）—项目管理者能权衡其它方面，进而在约束限制的范围内完成目标的一个因素。

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

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

另外，大多数时候为了确定了通过某一接口与系统相连的外部实体（称为“端点”或“外部实体”），同时也确定了外部实体和系统之间的数据流和物流，我们会绘制一个关联图，我们把关联图作为按照结构化分析所形成的数据流图的最高抽象层（ Robertson and Robertson 1994）。可以把关联图写入项目视图和范围文档或软件需求规格说明中，或者作为系统数据流模型的一部分。如：