软件工程文档规范--前景文档
软件工程文档规范--前景文档 摘要 　　本文是软件工程文档之一：前景(visio)文档的写作规范，前景文档以客户的 语言描述总体的需求说明，它与需求规格说明书是相互配合的。。(2002-10-22 09:00:45) [pic] By 风过留枫 1. 介绍 　　这一部分应该提供整个前景文档的概述，它包含以下几部分： 　　1.1 前景文档的目的 　　文档目的是收集、分析、定义高层用户需要和产品特征。集中于目标用户所需要的 能力以及为什么存在这些需要。有关系统如何满足这些需要的特定需求应该放在“软件需 求规格说明”和“用例规格说明”中。 　　1.2 产品综述 　　陈述该应用系统的目的、版本以及要交付的新特征。这一部分应该做以下几件事： 　　1）确定要创建或增强的产品或应用系统； 　　2）提供有关产品将做什么以及需要时不做什么的一般性描述； 　　3）描述产品的应用，包括与相关的利益、目的、目标。 　　1.3 参考 　　这一部分应该做以下几件事： 　　1）列出在前景文档中引用的其他文档的清单； 　　2）标明每个文档的题目、报告号（如果有的话）、日期和出版机构； 　　3）指定该参考获取的来源； 　　4）这个信息可通过引用附录或其它文档来提供。 2. 用户描述 　　为了有效地提供满足客户需要的产品和服务，理解完成这项工作时所面对的挑战是 很有必要的。这一部分应该剖析应用系统的用户和限制用户生产的关键问题。这一部分 不能用于陈述特定需求，而是提供有关为什么需要第5部分指定的需求的背景和理由。 　　2.1 用户/市场统计 　　总结激励产品决策的主要市场统计；描述和定位目标；利用潜在用户数量或客户愿 意花在试图满足你的产品或增强所完成的需要上的钱的数量来预测市场的大小和增长率 ；回顾主要的行业趋势和技术；回答以上战略问题：你的机构在这些市场中的声誉如何 ？你希望它做成什么样？这个产品或服务如何支持你的目标？ 　　2.2 用户剖析 　　描述系统中每个不同的用户。用户的类型可能是从权威到新手差距很大。例如，权 威可能需要一个复杂、灵活的支持跨平台工具，而一个新手可能需要一个易于使用、用 户友好的工具。对用户的全面剖析覆盖每种用户的以下题目： 　　1）技术背景和复杂程度； 　　2）主要职责； 　　3）为谁提交用户产品； 　　4）使用户的工作更容易或更困难的趋势； 　　5）影响成功的问题； 　　6）目标用户对成功的定义以及用户如何等到回报。 　　2.3 用户环境 　　目标用户的工作环境的详细描述。以下是一些建议： 　　1）完成该任务涉及多少人？是否会变化？ 　　2）任务的周期是多长？其中每项活动需要多少时间？是否会变化？ 　　3）是否有一些独特的环境约束：移动的、室外的、飞机上的，等等？ 　　4）现在正在使用哪种系统平台？未来的平台是什么？ 　　5）正在使用其他什么应用系统？你的应用系统是否能与这些系统集成？ 　　2.4 关键用户需要 　　列出用户认为的关键问题或需要。为每个问题澄清以下内容： 　　1）这个问题的原因是什么？ 　　2）现在是怎么解决的？ 　　3）用户预期的解决方案是什么？ 　　重要的是理解用户对解决每个问题所放的相对重要性。分级和累积投票技术可以说 明 　　必须解决的问题以及每个问题强调的事物。 　　2.5 替代品和竞争对手 　　确定用户认为目前可得到的替代品。可包括购买对手的产品、构建一个全部是自己 的解决方案或者维持现状。列出所知的已有的以及即将得到的竞争对手的产品。包括最 终用户所理解的每位对手的强项和弱项。 　　2.5.1 竞争对手1 3. 产品综述 　　这一部分对产品能力、到其他应用系统的接口以及系统配置等等提供一个高层视图 ，通常由以下三个部分组成。 　　3.1 产品前景 　　这部分应该合理地把该产品与其他相关产品及用户的需求放在一起。如果产品是独 立的而且是完全独立的，就在这里说明它；如果产品是一个大型系统的组件之一，那么 这一部分应该说明系统之间如何交互而且应该确定相关的接口。一种展示大型系统主要 组件、互连及外部接口的简单方法就是利用框图。 　　3.2 产品定位陈述 　　提供一个整体陈述，从最高层次总结产品在市场上的独特定位。Moore（1991）称此 为产品定位陈述，并推荐以下格式： | | |　　为了 （目标客户） | |　　谁 （陈述需要或机遇） | |　　产品名 是一个（产品分类） | |　　它 （对主要优点的陈述，即驱动购买的原因） | |　　不像 （主要竞争替代品） | |我们的产品 （对主要区别的陈述） | 　　产品定位陈述向所有相关人员说明了应用系统的意图以及项目的重要性。 　　3.3 能力总结 　　总结产品将提供的主要优点和特征。例如，客户支持系统的前景文档可能会使用这 一部分强调问题建档、路电和状态报告—不提及各个功能需求的细节。 　　组织特征，以便清单能够被客户或所有第一次阅读文档的人理解。一个简单的表列 出主要的优点及其所支持的特征。 　　客户支持系统 | | |　　客户收益 支持特征 | |收益1 特征 | |收益2 特征 | |收益3 特征 | 　　3.4 假定和相关条件 　　列出所有一旦变更将影响整个产品前景的假设条件。例如，某个假定条件可能指出 ，指定用于软件产品的硬件可得到某个特定的操作系统，如果该操作系统得不到，则前 景必须变更。 　　3.5 成本和定价 　　对于将销售给外部客户的产品以及许多机构内使用的应用系统，成本和定价将直接 影响应用系统的定义和实现。在这一部分，把所有成本和相关的定价约束记录下来。例 如，分销成本（磁盘、CD- ROM、CD母盘的编号）或者其他货品销售成本（手册、打包）根据应用的性质对于项目的 成功可能无关也可能有实质性影响。 4. 特征属性 　　与需求一样，特征也有属性，提供附加的项目信息，用于评估、跟踪、划分优先级 、管理为实现提出的项。这一部分陈述所有建议在前景文档中使用的属性，描述所选择 的属性及其意义，使各方都能更好地理解每个特征的背景。 　　4.1 状态 　　在项目管理团队协商和评审之后确定。状态信息在项目基线定义过程中跟踪进程。 　　1）建议的（proposed）：描述正在对该特征进行讨论，但还没有得到“正式渠道”的 审核与采纳，“正式渠道”可以是一个由项目团队、产品管理、用户或客户团队的代表组 织的工作小组； 　　2）批准的（approved）：它的能力被断定是有用和可行的，得到正式渠道的认可并 加以实现； 　　3）收编的(incorporated)：已经在某个特定时间收编入产品基线的特征； 　　4.2 优先级 　　产品优先级是由营销人员、产品经理或商业分析人员设置的。根据特征对最终用户 的相对优先级把它们划分等级打开了一个与客户、分析人员以及开发团队成员之间的对 话。优先级用于管理广度和确定开发优先级。一种优先级划分模式如下： 　　1）关键的（critical）：本质特征。实现的失败意味着系统将不能满足客户的需要 。所有关键的特征必须在发布中实现，否则进度将推迟。 　　2）重要的（important）：对于大多数应用的系统效率和效力都重要的特征。该功 能无法容易地用其他方式实现。如果缺少重要的特征，可能影响客户或用户的满意程度 ，甚至影响收益，但发布不会因此而推迟； 　　3）有用的（useful）：在不太典型的应用中有用的特征，但不经常使用或者有其他 合理的有效变通。如果发布中没有这类特征也不会对客户满意程度或收益造成重大的影 响 　　4.3 工作量 　　由开发团队设置，用于管理广度和确定开发优先级。由于有些特征比其他特征要求 更多的时间和资源，因此对各特征采用团队数量或人周、代码行、功能点等等进行评估 将是预测复杂度的最好办法，从而可对在给定时间范围内能完成什么不能完成什么有一 个预期。 　　4.4 风险 　　由开发团队设置，设置的依据是项目经历意外事件的可能性，如成本过高、进度延 迟甚至项目被撤消等。许多项目经理发现，把风险分为高、中、低就已经足够了，尽管 还可以再细一些。风险通常可以通过度量项目团队进度预测的不确定性（范围）进行间 接地评估。 　　4.5 稳定性 　　由分析人员和开发团队设置，设置的依据是特征变更的可能性或团对变更特征的理 解。这个信息有助于建立开发优先级或确定下一步中哪些附加启发是适当的。 　　4.6 目标当布 　　记录特征将首先出现在哪一个产品版本中。这个域可用于把特征分配到特定的基线 版本中。当把目标版本与状态域结合起来时，团队可以建议、记录和讨论该版本的各个 特征，而不必把它们提交给开发。只有一些状态被设置为“收编的”特征并且其目标版本 被定义的特征才能实现。在发生广度管理时，目标版本的版本号会不断增加，于是该项 仍然存在于前景文档中，但被安排到以后的版本中去。 　　4.7 分配给 　　在许多项目中，把特征分配给“特征团队”，负责进一步启发、书写软件需求和实现 。这个简单清单将帮助所有项目团队成员更好地了解自己的职责。 　　4.8 原因 　　这一文本域用来跟踪所要求特征的来源。特征的存在有很多特定的理由。这个域记 录了特征的解释或对解释的引用。例如，引用可以是产品需求规格说明的页号和行号， 或是重要客户面谈录像带上的一个分钟标志。 5. 产品特征 　　这一部分记录产品特征。特征提供了给用户带来利益所需要的系统能力，每个特征 都提供了一个满足用户需要的服务。例如，问题跟踪系统的一个特征可能是“提供走势报 告”的能力，趋势报告可能继续支持一个“更好理解项目状态”的需要。 　　因为前景文档是由许多涉及人员审核的而且是达成共识的基础。所以特征应该用用 肪的自然语言描述。特征描述应该简短、精练，通常是1-2个句子。 　　为了有效管理应用的复杂度，我们建议：对于任何新系统或在原有系统上加强的系 统，把能力抽象到较高层次产生大约25- 99个特征。这些特征是产品定义、广度管理和项目管理的基本基础。每个特征都可以在 后面的规格说明中被更详细地说明。 　　在整个这一部分中，每一个特征都应该是用户、操作者或其他外部系统可以感知的 。 　　5.1 特征＃1 　　5.2 特征＃2 6. 关键用例 　　描述一些关键用例，可以是对体系结构有意义或最方便帮助读者理解系统如何使用 的用例。 7. 其他产品需求 　　7.1 可应用标准 　　列出产品必须符合的标准，如法律和规章（FDA、FCC）、通信标准（TCP/IP、ISDN ）、平台兼容标准（Windows、UNIX）以及质量和安全标准（UL、ISO、CMM）。 　　7.2 系统需求 　　定义支持应用所必须的所有系统需求。包括支持的主机操作系统、网络平台、配置 、内存、外设以及软件。 　　7.3 许可和安装 　　许可和安装问题对于开发工作有直接影响。例如，支持序列号、口令安全或网络许 可证的需要必须创建其他开发过程中必须考虑的附加的系统需注。安装需求也会影响编 码或者产生开发独立安装软件的需求。 　　7.4 性能需求 　　性能问题包括用户负载因素、带宽或通信能力、吞吐量、准确度、可靠性或在某些 负载条件下的响应时间等。 8. 建档需求 　　这一部分描述所有支持成功地部署系统必须开发的文档 　　8.1 用户手册 　　描述用户手册的目的和内容。讨论其需要的长度、详尽程序、索引和词汇表的需要 、指南及参考手册策略，等等。还要指定格式和打印约束。 　　8.2 在线帮助 　　许多应用系统都提供一个在线的帮助系统来辅助用户。这些系统的本质是应用系统 开发所特有的，因为它们把编程（如超链接）和技术书写（如组织和表示）结合起来。 许多人发现在在线帮助系统是项目中的项目，它从广度管理和计划活动中直接受益。 　　8.3 安装指南、配置和自述文件 　　对于一个全面的解决方案来说，有一个包括安装指令和配置指南的文档非常重要， 而一个自述（Read Me）文件也通常作为标准组件而存在。自述文件中可能包括一个“本版本的新增内容”部 分以及一个与以前版本的兼容问题的讨论。许多用户还希望在自述文件中说明所有已知 的错误和变通方法。 　　8.4 标记和打包...
软件工程文档规范--前景文档