软件工程文档模板(完整规范版)

软件工程文档模板(完整规范版)篇一：软件工程文档模板目录 一、需求分析报告 . 1 1 引言 .1 编写目的 * . 1 项目来源 .1 项目风险 .1 文档约定 .1 预期读者和阅读建议 . 2 产品范围 .2 参考文献 * . 2 2 综合描述 .3 产品的状况 . 3 产品的功能 * . 3 用户类和特性 * . 4 运行环境 * . 4 设计和实现上的限制 . 4 假设和约束(依赖) . 5 3 外部接口需求 .5 用户界面 * . 5 硬件接口 .6 软件接口 .6 通讯接口 .7 4 系统功能需求 .7 说明和优先级 * .8 激励/响应序列 .8 输入/输出数据 * .8 5 其它非功能需求 . 9 性能需求 * . 9 安全措施需求 . 9 安全性需求 * . 10 软件质量属性 . 10 业务规则 . 10 用户文档 . 10 6 词汇表 * .117 数据定义 * .11 8 分析模型 * .12 9 待定问题列表 * . 12 二、概要设计报告 . 13 1 引言 .13 编写目的 * . 13 预期读者和阅读建议 . 13 参考文献 * . 13 2 设计概述 * .14 限制和约束 .14 设计原则和设计要求 . 14 3 系统逻辑设计 .15 系统组织设计 * . 15 系统结构设计 * . 16 系统接口设计 * . 18 系统完整性设计 . 19 4 系统出错处理设计 . 20 系统出错处理表 * . 20 维护处理过程表 . 21 5 技术设计 *（本部分的,的标题可删除） . 22 系统开发技术说明表 . 23 开发技术应用说明 . 24 6 数据库设计 * .24 7 词汇表 * .24 8 进度计划 * .24 三、详细设计报告 . 25 1 引言 . 25 编写目的 * . 25 文档约定 . 25 预期读者和阅读建议 . 25 参考文献 * . 26 2 支撑环境 .26 数据库管理系统 * . 26 开发工具、中间件以及数据库接口 * . 27硬件环境 * . 28 网络环境 * . 28 多种支撑环境开发要点 . 28 3 部件详细设计 * . 29 4 词汇表 * .30 5 部件表格式 * . 31 6 界面表格式 * . 31 四、数据库设计报告 .33 1 引言 .33 编写目的 * . 33 文档约定 . 33 预期读者和阅读建议 . 33 参考文献 * . 34 2 数据库命名规则 * . 34 3 数据库设计说明 . 34 数据库逻辑设计 * . 34 数据库物理设计 * . 35 数据库分布 * . 35 基表设计 * . 36 视图设计 . 37 索引设计 . 38 完整性约束 . 39 授权设计 * . 40 触发器设计 . 40 存储过程设计 . 41 数据复制设计 .42 4 词汇表 * .43 5 历史数据处理 * . 43 五、软件测试大纲 . 45 1 引言 .45 目的 * .45 术语 * .45 参照标准 * . 45 2 测试日期安排 .463 测试小组及成员 . 46 4 测试具体内容 .46 合法性检查 * . 46 软件文档检查 . 46 软件代码测试 * . 48 软件系统测试 * . 49 5 测试总结报告 .51 六、用户操作手册 . 52 1 引言 .52 编写目的 * . 52 预期读者和阅读建议 * . 52 参考文献 * . 52 2 软件概述 .52 目标 .52 功能 * .52 性能 * .52 3 运行环境 * .52 硬件 .52 支持软件 . 53 4 使用说明 * .53 安装和初始化 . 53 主要功能使用举例 . 53 出错和恢复 . 53 5 运行说明 .54 运行表 .54 运行步骤 * . 54 6 非常规过程 .54 7 操作命令一览表 * . 55 8 词汇表 * .55 七、项目开发总结报告 * .56 一、需求分析报告1 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 编写目的 * 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 项目来源 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：? 任务提出者； ? 软件开发者； ? 产品使用者。 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ? 正文风格； ? 提示方式； ? 重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈 篇二：软件工程文档规范-前景文档软件工程文档规范-前景文档 摘要 本文是软件工程文档之一：前景(visio)文档的写作规范，前景文档以客户的语言描述总体的需求说明，它与需求规格说明书是相互配合的。 。(XX-10-22 09:00:45) By 风过留枫 1. 介绍 这一部分应该提供整个前景文档的概述，它包含以下几部分： 前景文档的目的 文档目的是收集、分析、定义高层用户需要和产品特征。集中于目标用户所需要的能力以及为什么存在这些需要。有关系统如何满足这些需要的特定需求应该放在“软件需求规格说明”和“用例规格说明”中。 产品综述 陈述该应用系统的目的、版本以及要交付的新特征。这一部分应该做以下几件事： 1）确定要创建或增强的产品或应用系统； 2）提供有关产品将做什么以及需要时不做什么的一般性描述； 3）描述产品的应用，包括与相关的利益、目的、目标。 参考 这一部分应该做以下几件事： 1）列出在前景文档中引用的其他文档的清单； 2）标明每个文档的题目、报告号（如果有的话） 、日期和出版机构； 3）指定该参考获取的来源； 4）这个信息可通过引用附录或其它文档来提供。 2. 用户描述 为了有效地提供满足客户需要的产品和服务，理解完成这项工作时所面对的挑战是很有必要的。这一部分应该剖析应用系统的用户和限制用户生产的关键问题。这一部分不能用于陈述特定需求，而是提供有关为什么需要第 5部分指定的需求的背景和理由。 用户/市场统计 总结激励产品决策的主要市场统计；描述和定位目标；利用潜在用户数量或客户愿意花在试图满足你的产品或增强所完成的需要上的钱的数量来预测市场的大小和增长率；回顾主要的行业趋势和技术；回答以上战略问题：你的机构在这些市场中的声誉如何？你希望它做成什么样？这个产品或服务如何支持你的目标？ 用户剖析 描述系统中每个不同的用户。用户的类型可能是从权威到新手差距很大。例如，权威可能需要一个复杂、灵活的支持跨平台工具，而一个新手可能需要一个易于使用、用户友好的工具。对用户的全面剖析覆盖每种用户的以下题目： 1）技术背景和复杂程度； 2）主要职责； 3）为谁提交用户产品； 4）使用户的工作更容易或更困难的趋势； 5）影响成功的问题； 6）目标用户对成功的定义以及用户如何等到回报。 用户环境 目标用户的工作环境的详细描述。以下是一些建议： 1）完成该任务涉及多少人？是否会变化？ 2）任务的周期是多长？其中每项活动需要多少时间？是否会变化？ 3）是否有一些独特的环境约束：移动的、室外的、飞机上的，等等？ 4）现在正在使用哪种系统平台？未来的平台是什么？5）正在使用其他什么应用系统？你的应用系统是否能与这些系统集成？ 关键用户需要 列出用户认为的关键问题或需要。为每个问题澄清以下内容： 1）这个问题的原因是什么？2）现在是怎么解决的？ 3）用户预期的解决方案是什么？ 重要的是理解用户对解决每个问题所放的相对重要性。分级和累积投票技术可以说明必须解决的问题以及每个问题强调的事物。 替代品和竞争对手 确定用户认为目前可得到的替代品。可包括购买对手的产品、构建一个全部是自己的解决方案或者维持现状。列出所知的已有的以及即将得到的竞争对手的产品。包括最终用户所理解的每位对手的强项和弱项。 竞争对手 1 3. 产品综述 这一部分对产品能力、到其他应用系统的接口以及系统配置等等提供一个高层视图，通常由以下三个部分组成。产品前景 这部分应该合理地把该产品与其他相关产品及用户的需求放在一起。如果产品是独立的而且是完全独立的，就在这里说明它；如果产品是一个大型系统的组件之一，那么这一部分应该说明系统之间如何交互而且应该确定相关的接口。一种展示大型系统主要组件、互连及外部接口的简单方法就是利用框图。 产品定位陈述 提供一个整体陈述，从最高层次总结产品在市场上的独特定位。Moore（1991）称此为产品定位陈述，并推荐以下格式： 产品定位陈述向所有相关人员说明了应用系统的意图以及项目的重要性。能力总结总结产品将提供的主要优点和特征。例如，客户支持系统的前景文档可能会使用这一部分强调问题建档、路电和状态报告不提及各个功能需求的细节。 组织特征，以便清单能够被客户或所有第一次阅读文档的人理解。一个简单的表列出主要的优点及其所支持的特征。 客户支持系统 假定和相关条件列出所有一旦变更将影响整个产品前景的假设条件。例如，某个假定条件可能指出，指定用于软件产品的硬件可得到某个特定的操作系统，如果该操作系统得不到，则前景必须变更。 成本和定价 对于将销售给外部客户的产品以及许多机构内使用的应用系统，成本和定价将直接影响应用系统的定义和实现。在这一部分，把所有成本和相关的定价约束记录下来。例如，分销成本（磁盘、CD-ROM、CD 母盘的编号）或者其他货品销售成本（手册、打包）根据应用的性质对于项目的成功可能无关也可能有实质性影响。 4. 特征属性 与需求一样，特征也有属性，提供附加的项目信息，用于评估、跟踪、划分优先级、管理为实现提出的项。这一部分陈述所有建议在前景文档中使用的属性，描述所选择的属性及其意义，使各方都能更好地理解每个特征的背景。 状态 在项目管理团队协商和评审之后确定。状态信息在项目基线定义过程中跟踪进程。 1）建议的（proposed）：描述正在对该特征进行讨论，但还没有得到“正式渠道”的审核与采纳， “正式渠道”可以是一个由项目团队、产品管理、用户或客户团队的代表组织的工作小组； 2）批准的（approved）：它的能力被断定是有用和可行的，得到正式渠道的认可并加以实现； 3）收编的(incorporated)：已经在某个特定时间收编入产品基线的特征；优先级 产品优先级是由营销人员、产品经理或商业分析人员设置的。根据特征对最终用户的相对优先级把它们划分等级打开了一个与客户、分析人员以及开发团队成员之间的对话。优先级用于管理广度和确定开发优先级。一种优先级划分模式如下： 1）关键的（critical）：本质特征。实现的失败意味着系统将不能满足客户的需要。所有关键的特征必须在发布中实现，否则进度将推迟。 2）重要的（important）：对于大多数应用的系统效率和效力都重要的特征。该功能无法容易地用其他方式实现。如果缺少重要的特征，可能影响客户或用户的满意程度，甚至影响收益，但发布不会因此而推迟； 3）有用的（useful）：在不太典型的应用中有用的特征，但不经常使用或者有其他合理的有效变通。如果发布中没有这类特征也不会对客户满意程度或收益造成重大的影响 工作量 由开发团队设置，用于管理广度和确定开发优先级。由于有些特征比其他特征要求更多的时间和资源，因此对各特征采用团队数量或人周、代码行、功能点等等进行评估将是预测复杂度的最好办法，从而可对在给定时间范围内能完成什么不能完成什么有一个预期。 风险 由开发团队设置，设置的依据是项目经历意外事件的可能性，如成本过高、进度延迟甚至项目被撤消等。许多项目经理发现，把风险分为