软件工程文档规范(11个doc)10优质版

软件工程文档规范-前景文档摘要本文是软件工程文档之一： 前景 （visio） 文档的写作规范， 前景文档以客户的语言描述总体的需求说明，它与需求规格说明书是相互配合的。 。 （2002-10-22 09:00:45）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 竞争对手13. 产品综述这一部分对产品能力、 到其他应用系统的接口以及系统配置等等提供一个高层视图，通常由以下三个部分组成。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.8 原因这一文本域用来跟踪所要求特征的来源。 特征的存在有很多特定的理由。 这个域记录了 特征的解释或对解释的引用。 例如， 引用可以是产品需求规格说明的页号和行号， 或是重要 客户面谈录像带上的一个分钟标志。5. 产品特征这一部分记录产品特征。 特征提供了给用户带来利益所需要的系统能力， 每个特征都提供了一个满足用户需要的服务。 例如， 问题跟踪系统的一个特征可能是“提供走势报告”的能力，趋势报告可能继续支持一个“更好理解项目状态”的需要。因为前景文档是由许多涉及人员审核的而且是达成共识的基础。 所以特征应该用用肪的自然语言描述。特征描述应该简短、精练，通常是1-2 个句子。为了有效管理应用的复杂度，我们建议：对于任何新系统或在原有系统上加强的系统，把能力抽象到较高层次产生大约 25-99 个特征。 这些特征是产品定义、 广度管理和项目管理 的基本基础。每个特征都可以在后面的规格说明中被更详细地说明。在整个这一部分中，每一个特征都应该是用户、操作者或其他外部系统可以感知的。5.1 特征15.2 特征26. 关键用例描述一些关键用例， 可以是对体系结构有意义或最方便帮助读者理解系统如何使用的用例。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 标记和打包当今最新的艺术化的应用系统提供了一个从安装菜单提示的产品打包和装载清单、 炫耀 的屏幕、帮助系统、 GUI 对话等开始的一致的外观和感觉。这一部分定义要集成到代码中的 标记的类型和需要。包括版本和专利说明、公司商标、标准化图标及其他图形无素等。9. 词汇表词汇表定义所有项目特有的术语。 包括所有阅读文档的用户或其他人无法理解的缩写和简写。生活不是等待风暴过去，而是学会在雨中翩翩起舞,不要去考虑自己能够走多快，只要知道自己在不断努力向前就行，路对了，成功就不远了。放弃了，就不该后悔。失去了，就不该回忆。放下该放下，退出那没结局的剧。我们需要一点点的眼泪去洗掉眼中的迷雾，一点点的拥抱去疗愈受伤的心，一点点的休息去继续前行,少壮不努力，老大徒伤悲,每个人的人生都是不一样的，处 同样的位置，也是有人哭，有人笑，有人沉默。穷人缺什么：表面缺资金，本质缺野心，脑子缺观念，机会缺了解，骨子缺勇气，改变缺行动，事业缺毅力世界上最聪明的人是借用别人撞的头破血流的经验作为自己的经验， 世界上最愚蠢的人是非用自己撞得头破血流的经验才叫经验,不要抱着过去不放，拒绝新的观念和挑战,每个人都有退休的一天，但并不是每个人都能拥有退休后的保障。觉得为时已晚的时候，恰恰是最早的时候 ,勿将今日之事拖到明日 ,学习时的苦痛是暂时的，未学到的痛苦是终生的,学习这件事，不是缺乏时间，而是缺乏努力,幸福或许不排名次，学习并不是人生的全部。但既然连人生的一部分学习也无法征服，还能做什么呢 .