在程序员的日常工作中，除了编写代码之外，还免不了需要编写各种技术文档。一个编写良好的技术文档在项目中能够很好地建立沟通与协作，起到很积极的作用。因此，编写技术文档也就成为了程序员技能提升的很重要的一面。
为此，我们特意收集了一些在项目开发过程中经常用到的文档模板，这些模板包括格式和简单的写作说明，相信能够帮助大家编写出更加高效、实用的技术文档。在收集过程中，我们十分注重其实用性，以确保每个模板的价值，而且对于一些重要的文档提供了多个模板。
为了方便大家查找，我们将收录的57模板分为以下几类：
1）&项目及开发管理类：包括立项前的分析，立项后的计划、以及进度跟踪、风险控制方面的文档模板，共计16个；
2）&需求分析类：明确清晰的需求，是项目成功的基础，在此收集了在需求分析过程中所将使用到的文档模板，共计14个；
3）&系统分析与设计类：包括体系结构设计、高层设计、详细设计、数据库设计等6个相关文档模板；
4）&软件质量保证类：软件测试是质量保证的关键活动，在此收集了软件测试相关的11个文档模板；
5）&其它类：除此之外，还收集了关于用户手册、软件维护等方面的10个文档模板，其中还有一个软件过程规范的示例。
另外，值得说明的是，文档模板只是为文档的编写提供一个基础，在实际的编写过程中，你可以根据自己的需要进行必要的剪裁和增补。
一、项目及开发管理类
可行性研究报告(ISO标准)
编者说明：
&&& 在立项时，应该对项目进行综合分析，探讨项目的经济、社会、技术可行性，从而为决策提供基础。该模板为ISO标准文档模板，其不仅适用于软件项目，对于其它的系统项目也适用。
1.1 编写目的
[编写本可行性研究报告的目的，指出预期的读者。]
a.[所建议开发的软件系统的名称；]
b.[本项目的任务提出者、开发者、用户及实现该软件的计算站或计算机网络；]
c.[该软件系统同其他系统或其他机构的基本的相互来往关系。]
&&& &&&&[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1.4 参考资料
&&& &&&&[列出用得着的参考资料。]
2. 可行性研究的前提
&&& [说明对所建议开发的软件的项目进行可行性研究的前提。]
&&& &&&&[说明对所建议开发的软件的基本要求。]
&&&& &&&[说明所建议系统的主要开发目标。]
&&& 2.3 条件、假定和限制
&&& &&&&[说明对这项开发中给出的条件、假定和所受到期的限制。]
2.4 进行可行性研究的方法
[说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的，摘要说明所使用的基本方法和策略。]
2.5 评价尺度
&&& &&&&[说明对系统进行评价时所使用的主要尺度。]
3. 对现有系统的分析
&&& [这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚至是一个人工系统。]
&&& [分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。]
3.1 处理流程和数据流程
[说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示，并加以叙述。]
3.2 工作负荷
&&& &&&&[列出现有系统所承担的工作及工作量。]
3.3 费用开支
&&& &&&&[列出由于运行现有系统所引起的费用开支。]
&&& &&&&[列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。]
&&& &&&&[列出现有系统所使用的各种设备。]
3.6 局限性
&&& &&&&[列出本系统的主要局限性。]
4. 所建议的系统
4.1 对所建议系统的说明
[概括地说明所建议系统，并说明在第2条中列出的那些要求将如何得到满足，说明所使用的基本方法及理论根据。]
4.2 处理流程和数据流程。
&&& &&&&[给出所建议系统的处理流程式和数据流程。]
4.3 改进之处
&&& &&&&[按2.2条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。]
&&& &&&&[说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。]
4.4.1.对设备的影响
&&& [说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改]
4.4.2.对软件的影响
&&& [说明为了使现存的应用软件和支持软件能够同所建议系统相适应，而需要对这些软件所进行的修改和补充。]
4.4.3.对用户单位机构的影响
&&& [说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。]
4.4.4.对系统运行过程的影响
&&& [说明所建议系统对运行过程的影响。]
4.4.5.对开发的影响
&&& [说明对开发的影响。]
4.4.6.对地点和设施的影响
&&& [说明对建筑物改造的要求及对环境设施的要求。]
4.4.7.对经费开支的影响
&&& [扼要说明为了所建议系统的开发，统计和维持运行而需要的各项经费开支。]
4.5 技术条件方面的可能性
[本节应说明技术条件方面的可能性]
5. 可选择的其他系统方案
&&& [扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点。]
5.1 可选择的系统方案1
&&& &&&&[说明可选择的系统方案1，并说明它末被选中的理由。]
5.2 可选择的系统方案2
&&& &&&&[按类似5。1条的方式说明第2个乃至第n个可选择的系统方案。]
&&& [……]
6. 投资及效益分析
[对于所选择的方案，说明所需的费用，如果已有一个现存系统，则包括该系统继续运行期间所需的费用。]
6.1.1 基本建设投资
&&& [包括采购、开发和安装所需的费用。]
6.1.2 其他一次性支出
6.1.3 非一次性支出
&&& [列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用。]
[对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括：
6.2.1 一次性收益]
&&& [说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述。]
6.2.2 非一次性收益
&&& [说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益，包括开支的减少和避免。]
6.2.3 不可定量的收益
&&& [逐项列出无法直用人民币表示的收益。]
6.3 收益/投资比
&&& &&&&[求出整个系统生命期的收益/投资比值。]
6.4 投资回收周期
&&& &&&&[求出收益的累计数开始超过支出的累计数的时间。]
6.5 敏感性分析
[是指一些关键性因素与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时，对开支和收益的影响最灵敏的范围的估计。]
7. 社会因素方面的可能性
7.1.[法律方面的可行性]
7.2.[使用方面的可行性]
[在进行可行性研究报告的编制时，必须有一个研究的结论]
软件项目商业性分析
编者说明：
随着市场经济的不断发展，一个项目的商业价值、市场价值往往是衡量项目价值的最大依据。该文档模板十分适用于产品型项目，当你提出一个新的产品开发方向时，一份商业性分析是说服管理层的一个很好工具。
当然，如果是一些内部项目，也是可以借鉴该文档模板来论证该项目的商业价值。
1.&&文档概述
[该部分主要描述该文档的目的、范围、术语以及参考资料等方面的内容。]
[说明该文档的作用。]
&&& 1.2& 范围
[简要说明该与文档相关的其它事物与资料。]
[列出所有将出现于本文档的新术语、缩略语等。]
1.4&&参考资料
[在此应列出项目计划中引用的文档列表，对于引用的每个文档都应该列出其标题、文档编号、日期，并且指出这些文档的来源，以方便该计划的阅读者查找。]
&&& [本小节说明该文档所包括的内容，以及它的组织方式。]
2.系统说明
[在此简要地说明将要开发的系统，包括其名称、系统所解决的问题以及它的开发价值等，从而使得读者能够有一个直接的了解。并且在这处还应列出与在本文档中出现的缩略词的解释，以便读者更好地阅读。]
3.业务环境
[这一小节主要说明要开发的系统所处于的业务环境。它包括系统所面向的领域、用户。也可以在此指出它是产品型项目，还是用户定制型项目，同时如果该项目与原有的项目有紧密的联系，在此也应该把这些联系列出来。]
4.产品目标
[这一小节则用于深入说明为什么要开发该系统，它有什么价值。最好还应对进度计划、进度风险做一些评估。一个明确确定、表述清晰、可以度量的目标将为今后系统的开发工作打下坚实的基础。]
5.&财务预测
[如果是产品型项目，那么其输出就是一个商业软件产品。对于这样的项目，在此应该包括对该项目的财务预测，最主要应该得出投资回报（ROI）指标。在做ROI分析时，应该针对不同的完成时间做出不同的预测，以让系统开发者对于进度延迟对投资回报的损伤有一个直观的了解。]
[在财务预测中，有一个基点就是对项目工作量、资源使用的估算，在这里还应给出估算的基础技术，当然这里的估算会随着项目的进展而逐步精化，应该这里还是应该估算出一个合理的范围。]
[任何事有利就有弊，在本小节则主要列举执行该项目时会遇到的一个诸如外部接口、标准、认证、特殊的技术等约束，这些约速将会对项目带来很大的执行风险，可能对项目的成本也带来巨大的影响。]
软件开发项目立项表
编者说明：
在许多开发组织中，开发立项请求通常来自市场部门，该表格的设计就是为了更好地理顺两个部门之间的沟通与协调，也使得开发立项流程化，你可以根据自己公司的实际情况，对该表格的格式做一些修改。
软件项目计划(ISO标准)
编者说明：
&&& 拿破仑说过：“没有一场战役是按照计划打的，而胜利的战役没有一个是没有计划的。”，战役尚且如此，软件项目也不例个。一个经过周密考虑，团队协作共同制订的项目计划是成功的关键。本文档模板是ISO标准模板，虽然时间有点久远，但还是十分有参考价值的。
1.1 编写目的
[说明编写这份项目开发计划的目的，并指出预期的读者。]
a.&&&& 待开发软件系统的名称；
b.&&& 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c.&&&& 该软件系统同其他系统或其他机构的基本的相互来往关系。
&&& &&&&[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1.4 参考资料
&&& &&&&[列出用得着的参考资料。]
2. 项目概述
2.1 工作内容
&&& &&&&[简要地说明在本项目的开发中须进行的各项主要工作。 ]
2.2 主要参加人员&&
&&& &&&&[扼要地说明参加本项目开发工作的主要人员的情况，包括他们的技术水平。]
2.3.1 程序&
&&& [列出需移交给用户的程序的名称、所用的编程语言及存储程序的媒体形式，并通过引用有关文件。逐项说明其功能和能力。]
2.3.2.文件
&&& [列出需移交给用户的每种文件的名称及内容要点。]
2.3.3.服务
&&& [列出需向用户提供的各项服务。 ]
2.3.4.非移交的产品&&
&&& [说明开发集体应向本单位交出但不必向用户移交的产品。 ]
2.4 验收标准
&&& &&&&[对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。]
2.5 [完成项目的最迟期限]
2.6 [本计划的批准者和批准日期]
3. 实施计划
3.1 工作任务的分解与人员分工
[对于项目开发中需完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。]
3.2 接口人员
&&& &&&&[说明负责接口工作的人员及他们的职责。]
[对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务的预定的开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件。]
&&& &&&&[逐项列出本开发项目所需要的劳务以及经费的预算和来源。]
3.5 关键问题
[逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。]
4.支持条件
&&& [说明为支持本项目的开发所需要的各种条件和设施。]
4.1 计算机系统支持
[逐项列出开发中和运行时所需的计算机系统支持，包括计算机、外围设备、通讯设备、模拟器、编译程序、操作系统、数据管理程序包、数据存储能力和测试支持能力等，逐项给出有关到货日期、使用时间的要求。]
4.2 需由用户承担的工作
&&& &&&[逐项列出需要用户承担的工作和完成期限，包括需由用户提供的条件及提供时间。]
4.3 需由外单位提供的条件
&&& &&&&[逐项列出需要外单位分合同承包者承担的工作和完成的时间。]
5.专题计划要点
[说明本项目开发中需制订的各个专题计划的要点。]
软件项目计划模板(2)
编者说明：
&&& 大家可能都发现了ISO标准的项目计划缺少实用性，那是因为其未能很好地与WBS、甘特图技术实现良好的结合。该文档模板则充分考虑到这一点，其简单、实用，适用于中小规模项目。
1.1 计划的目的
1.2 项目的范围和目标
1.2.1 范围描述
1.2.2 主要功能
1.2.3 性能
　　&&& 1.2.4 管理和技术约束
2.项目估算
2.1 使用的历史数据
2.2 使用的评估技术
2.3 工作量、成本、时间估算
3. 风险管理战略
3.1 风险识别
3.2 有关风险的讨论
3.3 风险管理计划
&　&&& 3.3.1 风险计划
　　3.3.2 风险监视
　　3.3.3 风险管理
4.1 项目工作分解结构
4.2 时限图(甘特图)
4.3 资源表
5.项目资源
5.2 硬件和软件
5.3 特别资源
6.人员组织&
6.1 组织结构
6.2 管理报告
7.跟踪和控制机制
7.1 质量保证和控制
7.2 变化管理和控制
软件项目计划模板(3)
编者说明：
&&& 如果项目规模较大，除了上一个模板中的内容之外，还应该加入许多分支内容，包括过程计划、组织计划、测试计划、变更及管理计划、文档计划等各多方面的问题，将这些内容的细化，将使项目计划更全面、更周密。
第1部分 概述
&&&&&&& [这部分的目标是总结整个项目计划。]
[简要描述要做的工作。给出所有理解工作环境所需的背景。然后阐述在合同下的项目任务。紧接着，说明项目如何组织。然后，在项目的基础上列出假设和约束。]
[说明项目的总体时间进度。包括项目中的所有主要工作，无论是你能控制的还是不能控制的。如果你计划发布多个版本，要说明如何安排进度。]
第2部分 过程计划
[这部分的目标是对用一系列称为“过程”的时间段对开发活动加以定义，也就是确定该项目的开发将选用什么样的过程模型。]
[定义你的开发生命周期，并且简要说明生命周期的每个过程。]
2.3.1 定义过程
[主要目标：分析问题、制作项目计划、定义接收标准、选择项目工具。]
[次要目标：寻找人员、了解客户、形成试验性的设计思想。]
2.3.2 设计过程
[主要目标：设计操作性程序、设计支持性程序、改进项目计划、进行项目评审。]
[次要目标：准备集成环境、建立变更管理、制作模拟模型、为下一个过程寻找人员、准备程序员培训、出版程序员手册、初步准备系统测试、验收测试、现场测试、建立项目资料库。]
2.3.3 编码过程
[主要目标：详细设计/编码和模块测试、模块集成、文档建立。]
[次要目标：详细地准备系统测试、验收测试、现场测试，准备客户培训、准备移植。]
2.3.4 系统测试过程
[主要目标：根据问题说明书进行系统测试、尽可能地“实况”测试、通过非程序开发人员测试。]
[次要目标：完成验收测试准备、培训客户、更新描述性文档、完成用户文档、再次分配人员。]
2.3.5 验收过程
[主要目标：执行和分析验收测试、签署正式的接收协议。]
[次要目标：完成客户培训、清理文档。]
2.3.6 移植过程
[主要目标：协助进行数据转换、建立数据转换标准、建立全面恢复计划、定义移植顺序、协助接入。]
[次要目标：与受影响组进行联系、支持评审过程。]
2.3.7 运行过程
[主要目标：协助初期运行。]
[次要目标：现场测试、继续维护和调整、评价项目。]
第3部分 组织计划
[这部分的目标是定义项目的组织以及责任分配。]
&&& 3.2 概述
[说明建立组织的基本原因，画出组织内部的主要工作流程图，从问题的分析和设计开始，包括编码、测试、制作文档和交付。]
&&& 3.3 详述
[在每个子部分中，列出基于组织章程的部分以及每个部分的责任，然后再说明在每个过程中组织的结构图。]
3.3.1 部门及责任
[分析和设计部：编写问题说明书、设计说明书、变更管理、数据控制、模拟模型、制作用户文档、协作集成测试。]
[编程部：详细设计、编码、模块测试、集成测试、描述性文档。]
[测试部：制作系统测试说明书、制作验收和现场测试说明书、收集和制造测试数据、选择和获得测试工具、建立测试资料库、安排测试资源进度、执行测试、分析测试结果、制作测试结果文档。]
[行政部：资料管理、计算机时间控制、计划和安装终端和PC、发放程序员手册、培训、特殊技术协助、技术联络、文档控制、报告控制、合同变更管理、提供杂务支持、维护项目历史信息。]
3.3.2 组织章程
第4部分 测试计划
&&& [这部分的目标是定义对软件系统的所有级别测试的工具、过程和责任。]
&&& [简要定义每个测试级别，并说明在一个测试层次上，不同级别如何组合在一起。]
&&& 4.3 详述
4.3.1 单元测试
[在与其它功能模块集成之前，针对单个程序模块的测试。在此应列出单元测试的目标、责任、过程、工具。]
4.3.2 集成测试
[逐步将通过测试的模块集成为更加复杂的集合，并且测试这些集合，直到整个软件都被集合在一起。在此应列出集成测试的目标、责任、过程、工具。]
4.3.3 系统测试
[在尽可能真实的环境下，重新测试完成的软件系统，应由非编程人员完成。在此应列出系统测试的目标、责任、过程、工具。]
4.3.4 验收测试
[在用户认可的条件下，试运行系统以验证系统满足了客户的需求。在此应列出验收测试的目标、责任、过程、工具。]
4.3.5 现场测试
[在不同的运行环境下测试软件系统，以确保运行准备就绪，这并不是每个项目都需要的。在此应列出现场测试的目标、责任、过程、工具。]
4.3.6 共同测试设备
[描述在几个或者所有级别的测试中共同的设备和工具，其中包括系统资料、计算机设备、桌面系统、操作系统、特殊语言、CASE工具、仿真器。]
4.3.7 测试支持程序
第5部分 变更管理计划
&&& [这部分的目标是定义在软件系统开发过程中，变更控制的过程。]
[描述建立你和客户都能够接受的关键基线文档以及控制与这些基线变化相关事件的需求。无论何时发生问题，基线文档都是参考的关键。]
&&& 5.3 详述
5.3.1 基线
[定义哪些文档在你的项目中是基线。]
5.3.2 变更申请
[列出可能会提出变更的人员类别，以及提供相应的变更申请文档。]
5.3.3 研究变更申请
5.3.4 变更的类型
[根据变更的基线影响的程序，设置不同的变更类型。]
5.3.5 变更管理会议
[明确变更管理会议的组成成员、召开时间以及具体的操作办法。]
5.3.6 建议类型
[定义变更建议的类型，通常包括接受和拒绝两种。]
5.3.7 执行变更
[定义执行变更的具体方法，通常包括评估变更成本、对变更进行审批、制作变更文档、对变更后的进度进行重新安排、测试变更结果。]
第6部分 文档计划
[这部分的目标是定义出版周期所要求过程与资源，以及列出基础项目文档组的框架结构。]
[强调所有的项目文档在这部分都列出结构框架。]
6.3.1 发布过程和责任
[通常包括准备和批准、打字输入、校对和编辑、翻印、发放、电子存储等。]
6.3.2 项目文档大纲
[每个文档的都包括以下部分：]
[a.项目标志：用于标识项目文档之用；]
[b.文档名称：标识主题，如问题说明书、设计说明书……]
[c.文档编号：由项目资料员分配给文档的唯一标识；]
[d.批准：在作为正式版本之前，文档所需批准人的姓名。当然也不是所有文档都需要经过批准。]
[e.发行日期]
[f.文档主体：文档的内容。]
6.3.3 文档内容
[列出在该项目中将要使用的文档模板的结构性内容。]
软件项目计划模板(4)
编者说明：
&&& 随着现代软件工程思想的普及，迭代的、增量的开发生命周期已经被认识并付诸实践，针对这样的生命周期，其项目计划的格式也需要做出相应的调整。
1.文档概述
[在此对整个文档进行概要性描述，另外还应列出该计划的目标、范围、定义、术语、参考资料等内容。]
[在此描述本项目计划的目标。]
&&& [简要说明该计划所覆盖的范围，以及与其相关的项目，与该文档有联系的事物。]
1.3 定义与术语
[在此列出在该计划中所涉及的所有术语、定义、缩写词的解释，这些信息也可以引用项目词汇表来提供。]
1.4 参考资料
[在此应列出项目计划中引用的文档列表，对于引用的每个文档都应该列出其标题、文档编号、日期，并且指出这些文档的来源，以方便该计划的阅读者查找。]
&& [说明该计划其它部分所包含的内容，以及文档的组织方式。]
2.项目概述
[指出该项目将会交付什么样的产品，能够帮助客户达到什么目标。]
假设与约束
[列举出制定该计划时所做的所有假设，以及列举出对该项目的解决方案的约束性要求，如特定的操作系统平台、特定的时间、特定的经费范围等。]
项目交付物
[具体列出该项目完成后，将交付哪些东西，并可以列出每个交付时间。]
项目计划更新总结
[建议采用表格的形式，将计划的修订过程列出来。]
3.项目组织
项目组织结构
[建议使用组织结构图的形式，将整个项目团队成员之间的关系与职责明确下来，甚至可以包括管理人员、各种委员会等。]
外部联系人
[列出开发组织之外的，所有与项目相关的外部人员的姓名、联系电话等资料。]
角色与职责
[明确项目开发各个任务的负责人或小组。]
4.项目管理计划
[给出关于项目成本、进度的估计值，这些估计值将是项目计划制定的基础，也是今后重新评估、修改计划的基础。你可以采用任何估算技术。]
4.2.1 阶段计划
[主要包括工作结构分解（WBS）、显示各个阶段或迭代时间安排的甘特图、主要里程碑与其验收标准。]
4.2.2 迭代目标
[如果你采用的是迭代式的开发方法，那么在此列出每次迭代的计划，以及每次迭代计划实现的目标。]
4.2.3 发行计划
[列出软件开发过程中各个中间版本的发行时间，包括演示版、Alpha版、Beta版等。]
4.2.4 项目进度表
[使用甘特图或PERT图等方法，表示出该项目的进度计划。]
4.2.5 项目资源计划
&[在此处应列出项目所需的人员、设备等资源情况。应指明所需人员的数量、技能要求，以及如何获取这些资源，是否要对人员进行必要的培训等。]
4.2.6 项目预算
[根据WBS和阶段计划分配成本，得到本项目的财务预算。]
[根据4.2.2小节的目标，具体列出每次迭代的详细计划。该部分可以视需要将其单列为专题计划。]
4.3.1 迭代一
&&& 4.3.1.1 计划
&&& [列出此次迭代的时间线、小型里程碑等。]
&&& 4.2.1.2 资源
&&& [列出此次迭代所需的人力、财力、设备等资源。]
&&& 4.2.1.3 用例
&&& [列出此次迭代将要实现的用例。]
4.2.1.4 评估标准
&&& [列出此次迭代的各项评测标准，包括功能、性能、容量、质量等。]
项目监督与控制
4.4.1 需求管理计划
[有针对性对制定各类需求元素的管理与跟踪办法。该部分可以视需要将其单列成为专题计划。]
4.4.2 进度控制计划
[说明如何对项目计划执行情况进行监控，将采用什么措施与管理手段。]
4.4.3 预算控制计划
[说明如何对项目的财务预算进行控制，以保证成本最小化。]
4.4.4 质量控制计划
[说明如何保证项目的质量，以及一些应急的应对措施。该部分可以视需要将其单列成为专题计划。]
4.4.5 报告计划
[说明项目开发过程中，整个项目团队的报告机制，什么时候、谁、报送什么数据，从而形成规则。]
4.4.6 评测计划
[制定项目开发过程中将要度量与评测的指标，说明如何评测，如何应对。该部分可以视需要将其单列成为专题计划。]
4.5 风险管理计划
[该部分可以视需要将其单列为专题计划。]
&&& 4.5.1 风险总述
[对项目所涉及的风险进行一个概要性描述。]
&&& 4.5.2 风险管理任务
[简要地说明在该项目中，风险管理所涉及的内容，可以包括用来确定风险的方法、对风险列表进行分析和确定优先级的方式、将采用的风险管理策略、对最严重的风险所计划的降低/规避或预防的策略、监测风险状态的方式、风险复审的时间表。]
&&&&&&& 4.5.3 风险管理的组织和职责
[列出与风险管理相关的个人或小组，并对其职责进行描述。]
&&& 4.5.4 工具与技术
[列出与风险管理将采用的工具软件或技术。]
&&&&&&& 4.5.5 纳入管理的风险项
[列出主要的风险项，并描述其影响以及应急措施。具体可以参考后面的《风险条目跟踪表模板》。]
4.6 收尾计划
[列出在项目后期将要做的事，包括材料存档、汇报总结等。]
5.相关技术
5.1 开发案例
[给出本项目将采用的软件生命周期模型、过程规范等，从而对开发过程给予明确的指导。该部分可以视需要将其单列为一个专题文件。]
5.2 方法、工具和技术
[列出本项目中将运用的方法、工具和技术，并给出适当的工作指南和说明。]
5.3 产品验收计划
[列出本项目验收工作的一些细节计划，本部分内容可以视需要将其单列为一个专题计划。]
6．其它支持过程管理
6.1 配置管理计划
[在此列出该项目所采用的配置管理过程，通常是单列为一个专题。]
6.2 评估计划
[列出本项目评估时所使用的技术、标准、指标和过程。这里的评估包括走查、检查和复审。]
6.3 文档计划
6.4 质量保证计划
6.5 分包商管理计划
7.其他计划
风险条目跟踪表模板
编者说明：
&&& 对于中型以上的项目，风险控制的意义就犹为突出。要控制风险，就应该找到风险，并将风险记录下来，确定相关责任人，对于风险性高的、可能性大的还需要制订相关的应对措施。而最好的方法就是整理成为本模板中的表格，为每个潜在风险备个案。
&风险被识别出的日期&
&撤消风险确定日期&
&以"条件-结果"的形式描述风险&
&风险转变为问题的可能性&
&注：可用0.1(极不可能)~1.0(肯定发生)来表示
&&如果风险变成了事实奖造成的损失&
&注：可用1(无甚么影响)~10(有很深、很大的影响)来表示
&可能性＊影响&
降低风险计划
&一种或多种用来控制、避免、最小化及降低风险的方法&
&解决风险的责任承担者&
&完成降低风险措施的截止日期&
进度计划风险列表
编者说明：
&&& 准确来说，本列表不是一个文档模板，而是一个参考文章。由于风险识别许多人都觉得无从入手，下面就是列出了与进度相关的风险条目，对于风险识别有很大的参考价值。
1.最常见的进度计划风险
1）&功能无限蔓延；
2）&需求镀金或开发人员镀金；
3）&质量不定
4）&计划过于乐观
5）&设计欠佳
6）&银弹综合症
7）&研发导向开发
8）&人员薄弱
9）&签约商失败；
10）研发人员与客户的磨擦。
2.进度计划风险完整列表
2.1 计划编制风险
1）&计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
2）&计划是优化的，是“最佳状态”；
3）&计划忽略了必要的任务；
4）&计划基于使用特定的小组成员，而那个小组成员其实指望不上。
5）&在限定的时间内无法建成已定规模大小的产品；
6）&产品规模比估计的要大一些；
7）&工作量大于估算数；
8）&进度已经拖延的项目在重新评估时过于优化或忽视项目历史；
9）&过度的进度压力造成生产率下降；
10）目标日期提前，但没有相应地调整产品范围或可用资源；
11）一个任务的延迟导致相关任务的连锁反应；
12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
2.2 组织和管理
1）&项目缺乏一个有凝聚力的最高领导人；
2）&由于前期乏力，项目长时间被搁置；
3）&解雇和削减开支导致项目小组能力下降；
4）&仅由管理层或市场人员进行技术决策，导致计划进度延长；
5）&低效的项目组结构降低生产率；
6）&管理层审查/决策的周期比预期时间长；
7）&预算削减打乱项目计划；
8）&管理层做出了打击项目组织积极性的决定；
9）&非技术的第三方的工作比预期延长（如审批，采购等）；
10）计划性太差，无法适应期望的开发速度；
11）项目计划由于压力而放弃，导致开发混乱、低效；
12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。
2.3 开发环境
1）&设施没有及时到位；
2）&设施到位，但不配套；
3）&设施拥挤、杂乱或者破损；
4）&开发工具未能及时到位；
5）&开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工具；
6）&开发工具的选择不是基于技术需求，不能提供计划要求的性能；
7）&新开发工具的学习期比预期的长，内容繁多。
2.4 最终用户
1）&最终用户坚持新的需求；
2）&最终用户对于最后交付的产品不满意，要求重新设计和重做；
3）&最终用户不买进项目产品，无法提供后续支持；
4）&最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。
1）&客户坚持新的需求；
2）&客户对规划、原型和规格的审核/决策周期比预期长；
3）&客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复；
4）&客户答复的时间比预期长（如回答需求中需澄清的问题）；
5）&客户坚持技术决策而导致进度计划延长；
6）&客户对开发进度管理过细，导致实际进展变慢；
7）&客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作；
8）&客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作；
9）&客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低；
10）客户不接受交付的软件，尽管它满足了所有的规格；
11）客户期望的开发速度是开发人员无法达到的。
2.6 承包商
1）&承包商没有按承诺交付组件；
2）&承包商递交的组件质量低下无法接收，必须花时间改进质量；
3）&承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。
1）&需求已经成为项目基准，但变化还在继续；
2）&需求定义欠佳，而进一步的定义会扩展项目范畴；
3）&添加额外的需求；
4）&产品定义含混的部分比预期需要更多的时间。
1）&错误发生率高的模块需要比预期更多的测试、设计和实现工作；
2）&校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。
3）&在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预期；
4）&由于软件功能的错误，需要重新设计和实现；
5）&开发额外不需要的功能（镀金）延长了计划进度；
6）&要满足产品规格与速度要求，需比预期更多时间，包括重新设计和实现的时间；
7）&严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
8）&要求与其他系统、复杂系统或不受本项目控制的系统相连，导致无法预料的设计、实现和测试工作。
9）&要求在不同操作系统下运行将花费比预期更长的时间；
10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题；
11）开发一种对组织全新的模块将比预期花费更长的时间；
12）依赖正在开发中的技术将延长计划进度。
2.9 外部环境
1）&产品依赖政府规章，而规章的改变将是不可预期的；
2）&产品依赖草拟中的技术标准，而最后的标准将是不可预期的。
1）&招聘人员所花时间比预期的长；
2）&作为先决条件的任务不能按时完成（如培训、其它项目）；
3）&开发人员和管理层之间关系不佳导致决策缓慢，影响全局；
4）&项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平；
5）&缺乏激励措施，士气低下，降低了生产能力；
6）&缺乏必要的规范，增加了工作失误与重复工作；
7）&某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言；
8）&项目结束前，合同制人员离开团队，或雇员辞职；
9）&项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；
10）项目组成员不能有效地一起工作；
11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作；
12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性；
13）项目的最佳人选未加入项目组；
14）项目的最佳人选已加入项目组，但因其他原因未能合理使用；
15）没有找到项目急需的具有特定技能的人；
16）关键人物只能兼职参与；
17）项目人员不足；
18）任务的分配与人员技能不匹配；
19）人员工作的进展比预期的慢；
20）项目管理人员怠工导致计划和进度失效；
21）技术人员怠工导致工作遗漏或质量低下，工作需要重做。
2.11 设计与实现
1）&设计过于简单，无法确定主要事件，并导致重新设计和实现；
2）&设计过于复杂，导致一些不必要的工作，影响实现效率；
3）&设计质量低下，导致重复设计和实现
4）&使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误；
5）&产品采用低级语言来实施，导致生产率比预期的低；
6）&一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新库或自选开发所要的功能；
7）&代码和库质量低下，导致需要额外的测试、错误修正或重做；
8）&过高估计了增强型工具对计划进度的节省量；
9）&分别开发的模块无法有效集成，需要重新设计或重做。
1）&大量的纸面工作导致进程比预期的慢；
2）&进程跟踪不准确，导致无法预知项目是否已落后于计划进度；
3）&前期的质量保证行为不真实，导致后期的重复工作；
4）&质量跟踪不准确，导致无法得知影响进度的质量问题；
5）&太不正规，导致沟通不足，质量问题和工作重做；
6）&过于正规，导致过多耗时无用的工作；
7）&向管理层撰写进度报告占用的开发人员的时间比预期的多；
8）&风险管理粗心，导致没有发现重大的项目风险；
9）&软件项目风险管理花费的时间比预期的多。
开发进度月报(ISO标准)
编者说明：
&&& 计划需要跟踪进度来进行适当的调整，因此在开发组织内应该形成良好的进度汇报机制，ISO标准模板也对这一块提供了参考。这一文档格式十分全面，不过也略显繁琐，适合于中型以上项目。
开发中的软件系统的名称和标识符
分项目名称和标识符
分项目负责人签名
本期月报编写人签名
本期月报的编号及所报告的年月
2．工程进度与状态
[列出本月内进行的各项主要活动，并且说明本月内遇到的重要事件，这里所说的重要事件是指一个开发阶段（即软件生存周期内各个阶段中的某一个，例如需求分析阶段）的开始或结束，要说明阶段名称及开始（或结束）的日期。]
[说明本月的实际工作进度与计划相比，是提前了、按期完成了、或是推迟了？如果与计划不一致，说明原因及准备采取的措施。]
3．资额耗用与状态
3.1 资额耗用
[主要说明本月份内耗用的工时与机时。]
&&& 3.1.1 工时
[分为三类：]
&& &[a. 管理用工时&包括在项目管理（制订计划、布置工作、收集数据、检查汇报工作等）方面耗用的工时； ]
&&& [b. 服务用工时&包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时；]
[c. 开发用工时&要分各个开发阶段填写。]
3.1.2 机时
&&& &[说明本月内耗用的机时，以小时为单位，说明计算机系统的型号。]
[说明本月内实际耗用的资源与计划相比，是超出了、相一致、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。]
4&经费支出与状态
4.1 经费支出
&&& 4.1.1 支持性费用
&& &[列出本月内支出的支持性费用，一般可按如下七类列出，并给出本月支持费用的总和：]
&&& [ a. 房租或房屋折旧费；]
&&& [b. 员工工资、奖金、补贴；]
&&& [c. 培训费包括给教师的酬金及教室租金；]
&&& [d. 资料费包括复印及购买参考资料的费用；]
&&& [e. 会议费召集有关业务会议的费用；]
&&& [f. 旅差费；]
&&& [g. 其他费用。]
4.1.2 设备购置费
[列出本月内支出的设备购置费，一般可分如下三类：]
[[a. 购买软件的名称与金额；]
[b. 购买硬设备的名称、型号、数量及金额；]
[c. 已有硬设备的折旧费。]
[说明本月内实际支出的经费与计划相比较，是超过了。相符合、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。]
5．下个月的工作计划
[本月遇到的重要问题和应引起重视的问题以及因此产生的建议。]
开发任务卡
编者说明：
&&& 项目中应该实现责任到人，项目的进度应该是每个项目成员个人进度表的总汇集，而开发任务卡则是项目与项目成员的约定，也是项目管理的一个好办法。大家可以根据自己的实际情况来修改该模板。
项目名：&&&&&&&&&&&&&&&&&&&&&&& &&&&模块/类名：&&&&&&&&&&&&&&&&&&&&&
安排时间：&&&&&&&&&&&&&&&&&& &&&任务承担人：&&&&&&&&&&&&&&&&
相关模块/类情况：
&模块/类名
任务描述：
估计完成时间：_________________&&&& 批准人：_________________
个人开发进度月报
编者说明：
&&& 表格式的进度报表能够节省制作时间，缩短进度误差。对于中型以上项目，特别是成员的任务超过了1个月，那么让每个开发人员填写进度月报就是一个很好的管理办法。当然，如果成员的任务都较小，则无需使用该文档，只需对工作任务卡进行检查就可以了。
项目名称及标识：
子项目名称及标识：
开发阶段：
报告时间：　　　年　　月　　日　至　　　年　　月　　日
报告人：〈签名〉
任务：&任务名&
任务描述：
状态：&& □完成&&&&&&& □未完成
与计划比较：&&& □提前&&&&&& □按期&&&&&& □推迟
推迟原因：
3．资源耗费
总用工时：
加班时间：
上网时间：
硬件平台：
软件环境和工具：
4.下个月工作计划
任务：&任务名&
任务描述：
任务所属项目或子项目：
性质：&& □新&&&&&& □续上月
项目开发进度月报
编者说明：
&&& 项目进度月报是必须的管理机制，而长篇大论不仅浪费了大家的时间，而且也使得进度的收集与实际情况有一些时间上的误差，因而可以采用表格化的报表格式。
项目名称及标识：
子项目名称及标识：
本期月报编写人：〈签名〉
子项目负责人：〈签名〉
本期月报编号：
月报日期：&&&& 年&&&& 月&&&& 日
任务：&任务名&
任务描述：
状态：&&&&□
完成&&&&&&& □未完成
与计划比较：&&& □提前&&&&&& □按期 &&&&&□推迟
推迟原因：
事件：&事件名&
事件标志：
与计划比较： &&□提前&&&&&& □按期&&&&&&& □推迟
推迟原因：
3.资源耗费
&&& 3.1 工时
管理用工时：
服务用工时：
&&& 3.2 机时
计算机类型：
计算机类型：
计算机类型：
总&&&&& 计：
4.经费支出
&&& 4.1 支持性经费支出
工资、奖金、补贴：
&&& 4.2 设置购置费
5.下个月工作计划
&&& 5.1 任务
任务：&任务名&
任务描述：
开发阶段：
性质：&& □新&&&&&& □续上月
&&& 5.2 事件
事件：&事件名&
事件标志：
性质： &□新&&&&&& □旧&&&&&&&
项目进度周报
编者说明：
&&& 月报通常需要较详细，而周报则应该更简洁，每周让项目经理花上1-2分钟将一周的项目进度情况做一个通报是很必要的。本文档模板就是一个例子，供大家参考。
周期：2003年__月__日~2003年__月___日
项目名称：________________________________&项目编号：_______________
项目经理：______________ 项目发起人：____________
项目成员：_______________________________________
项目计划开始时间：_______________&& 项目实际开始时间：_______________
项目预计完成时间：_______________&& 现在预计完成时间：_______________
项目处于：&& £ 初步计划阶段&&& £ 需求分析阶段&& £ 开发阶段
项目状态：&& £ 按计划进度&&&&& £ 超计划进度&&&& £ 进度延迟
项目预计投入人力：____________人/日&& 现在已投入人力：___________人/日
预计共需投入人力：____________人/日
项目遇到的困难和要解决的问题：
_____________________________________________________________________
_____________________________________________________________________
项目开发总结报告(GB标准)
编者说明：
&&& 在项目中犯错误是正常的，但是犯同样的错误则是不可原谅的。因此，我们应该善于在项目中总结、在实践中总结。在项目结束的时候，所有的成员汇集在一起，回顾一下项目的过程，总结出错误，找到解决的办法，总结出经验，将这些经验复用到下一个项目中。然后形成本文档，共享给大家。
1.1 编写目的
&&& [说明编写这份项目开发总结报告的目的，指出预期的阅读范围。]
&&& [说明：]
&&& [ a. 本项目的名称和所开发出来的软件系统的名称；]
&&& [b. 此软件的任务提出者、开发者、用户及安装此软件的计算中心。]
&&& [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
&1.4 参考资料
&&& [列出要用到的参考资料，如：]
&&&&& [a. 本项目的已核准的计划任务书或合同、上级机关的批文；]
&&&&& [b. 属于本项目的其他已发表的文件；]
&&&&& [c. 本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。]
&[列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。]
2．实际开发结果
&& &&[说明最终制成的产品，包括：]
[a. 程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量；]
[b. 程序系统共有哪几个版本，各自的版本号及它们之间的区别；]
[c. 每个文件的名称；]
[d. 所建立的每个数据库。如果开发中制订过配置管理计划，要同这个计划相比较。]
2.2 主要功能和性能
[逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。]
2.3 基本流程
&&&& [用图给出本程序系统的实际的基本的处理流程。]
[列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。]
&&& [列出原定计划费用与实际支出费用的对比，包括：]
&&& [a. 工时，以人月为单位，并按不同级别统计；]
&&& [b. 计算机的使用时间，区别CPU时间及其他设备时间；]
&&& [c. 物料消耗、出差费等其他支出。]
&&& [明确说明，经费是超出了、还是节余了，分析其主要原因。]
3．开发工作评价
3.1 对生产效率的评价
&&& [给出实际生产效率，包括：]
&&&&& [a. 程序的平均生产效率，即每人月生产的行数；]
&&& [b. 文件的平均生产效率，即每人月生产的千字数；]
&&& [并列出原订计划数作为对比。]
3.2 对产品质量的评价
[说明在测试中检查出来的程序编制中的错误发生率，即每干条指令（或语句）中的错误指令数（或语句数）。如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。]
3.3 对技术方法的评价
&&& [给出对在开发中所使用的技术、方法、工具、手段的评价。]
&3.4 出错原因的分析
&&& [给出对于开发中出现的错误的原因分析。]
4．经验与教训
[列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。 ]
模块开发卷宗(GB标准)
编者说明：
&&& 当一个项目完成之后，应该将所有的文档、源程序、可执行文档进行整理打包，统一入库，而模块开发卷宗则是这些文档的封面。有了该文档，就可以使得下次找这些资料时更加方便。
第1章&&& 模块开发情况
模块标识符
代码复查 （日期/签字）
批&& 准&（日期/签字）&&
第2章&&& 功能说明
第3章&&& 设计说明
3.1&& 层次说明
模块标识符
3.2&& 算法 （Ｎ－Ｓ图、ＰＡＤ图或ＰＤＬ语言）
3.3&& 外部数据结构
3.4&& 出错信息
第4章&&& 源代码清单
第5章&&& 测试说明
5.1&& 测试名称1
测试标识符：
5.2&& 测试名称2
…………
第6章&&& 复审结论
6.1&& 与需求说明的比较
6.2&& 与概要设计的比较
6.3&& 与详细设计的比较
6.4&& 一般结论
二、需求分析类
编者说明：
&&& 许多有经验的开发团队在开始需求调查的时候，总会将“软件客户需求权利书”和“软件客户需求义务书”提交给客户，让客户明确其权利与义务，将会对需求调研、分析的工作带来意想不到的效果，你可以一试。
软件客户需求权利书
1.要求分析人员使用符合客户语言习惯的表达；
2.要求分析人员了解客户系统的业务及目标；
3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。
4.要求开发人员对需求过程中所产生的工作结果进行解释说明；
5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度；
6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。
7.描述产品使其具有易用、好用的特性；
8.可以调整需求，允许重用已有的软件组件；
9.当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估；
10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。
软件客户需求义务书
1.给分析人员讲解业务及说明业务方面的术语等专业问题；
2.抽出时间清楚地说明需求并不断完善；
3.当说明系统需求时，力求准确详细；
4.需要时要及时对需求做出决策；
5.要尊重开发人员的成本估算和对需求的可行性分析；
6.对单项需求、系统特性或使用实例划分优先级；
7.评审需求文档和原型；
8.一旦知道要对项目需求进行变更，要马上与开发人员联系；
9.在要求需求变更时，应遵造开发组织确定的工作过程来处理；
10.尊重需求工程中开发人员采用的流程（过程）。
软件项目视图和范围
编者说明：
&& &项目所涉及的内容与所解决的问题都是有限的，而且项目应该是十分有目的性的，是为了实现某个可度量的目标而做的。因此，在需求分析的前期应该将“项目的目标与范围”这一项目的本质文档化，让每一个项目成员对其达成共识。该文档是十分重要，但却又是十分容易被忽视的。该文档模板比较适用于定制开发项目。
1.业务需求
[业务需求说明了提供给客户和产品开发商的新系统的最初利益。不同产品可能会有不同的侧重点。本部分描述了你为什么要从事此项项目的开发，以及它将给开发者和购卖者带来的利益。]
[在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。]
1.2 业务机遇
[描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。认识到目前只能使用该产品才能解决的一些问题，并描述产品是怎样顺应市场趋势和战略目标的。]
&1.3 业务目标
[用一个定量和可测量的合理方法总结产品总结产品所带来的重要商业利润。关于给客户带来的价值在后面阐述，这里仅把重点放在给业务的价值上。这些目标与收入预算或节省开支有关，并影响到投资分析和最终产品的交付日期。]
1.4 客户或市场需求
[描述一些典型客户的需求，包括不满足现在市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。定义了较高层次的关键接口或性能要求，但避免设计或实现细节。把这些要求写到列表中，可以反过来跟踪调查特殊用户和功能需求。]
1.5 提供给客户的价值
[确定产品给客户带来的价值，并指明产品怎样满足客户的需要。可以用下列言辞表达产品带给客户的价值：
Ø&提高生产效率，减少返工；
Ø&节省开支；
Ø&业务过程的流水线化；
Ø&先前人工劳动的自动化；
Ø&符合相关标准和规则；
Ø&与目前的应用产品相比较，提高了可用性或减少了失效程度。]
1.6 业务风险
[总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。]
2.项目视图的解决方案
[文档中的这一部分为系统建立了一个长远的项目视图，它将指明业务目标。这一项目视图为在软件开发生存期中作出决策提供了相关环境背景。这部分不包括详细的功能需求和项目计划信息。]
2.1 项目视图陈述
[编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场企业框架。组织的战略方向和资源局限性为基础。]
[如："化学制品跟踪系统"可使科学家查询到化学制品仓库或供应商将提供的化学制品容器。系统可随时了解公司每一个化学制品容器所处的位置，容器中所剩余的药品剂量，任何时候每个容器所处的位置和用法的历史记录。通过充分利用公司内部的可用化学制品，废弃极少量已使用或过期失效的化学制品，使用标准的化学制品的购买过程等将在化学制品上节省25%开支。"化学制品跟踪系统"还能产生符合政府部门规定所要求的全部报表，包括化学制品的使用、存储和废弃等报表。]
2.2 主要特征
[包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。]
2.3 假设和依赖环境
[在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。如果你把它们都记录下来，并加以评论，就能对项目内部隐含的基本假设达成共识。比如，"化学制品跟踪系统"的开发者假设：该系统可以替代现有的仓库存货系统，并能与有关采购部门的应用相连接。把这些都记录下来以防止将来可能的混淆和冲突。还有，记录项目所依赖的主要环境，比如：所使用的特殊的技术、第三方供应商、开发伙伴及其它业务关系。]
3.范围和局限性
[项目范围定义了所提出的解决方案和概念和适用领域，而局限性则指出产品所不包括的某些性能。如果一般客户所提出的需求超出项目的范围时就应当拒绝它，除非这些需求是很有益的。记录这些需求以及拒绝它们的原因，以待查。]
3.1 首次发行的范围
[总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。应当避免将想到的每一个特性都包括到1.0版本产品中去。开发者应把重点放在能提供最大价值、花花费最合理的开发费用及普及率最高的产品上。]
3.2 随后发行的范围
[如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。]
3.3 局限性和专用性
[明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。]
4.业务环境
[这一部分总结了一些项目的业务问题。]
4.1 客户概貌
[客户概述明确了这一产品的不同类型客户的一些本质特点，以及目标市场部门和在这些部门中的不同客户的特征。对于每一种客户类型，概述要包括：
Ø&各种客户类型将从产品中获得的主要益处；
Ø&它们对产品所持的态度；
Ø&感兴趣的关键产品的特性；
Ø&哪一类型客户能成功使用；
Ø&必须适应任何客户的限制。]
4.2 项目的优先级
[一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。在所给的项目中，其每一方面应与下面三个因素之一相适应。
Ø&一个驱动----一个最高级别的目标；
Ø&一个约束----项目管理者必须操纵一个对象的限制因素；
Ø&一个自由度----项目管理能权衡其它方面，进而在约束限制的范围内完成&&&&& 目标的一个因素。
&&&未必所有的因素都能成为驱动，或所有的因素都能成为约束因素。在项目开始时记录和分析哪一个因素适用于哪一类型，将有助于使每一个人的努力和期望与普遍认可的优先级相一致。]
5.产品成功的因素
[明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括我部素。如果可能，可建立测量的标准，用于评价是否达到业务目标，如：市场股票、销售量及收入、客户满意度、交易处理量和准确度。]
编者说明：
&&& 这个文档模板与“软件项目视图与范围”文档的功能十分接近，只不过该文档更适合于产品型项目。其注重对项目的用户、市场进行分析，紧抓项目相关人员（也叫做风险承担者）的需求的本质。
1.文档简介
[软件需求规格说明书的整个内容还是锁定于整个系统的操作、使用层面之上的功能性需求，只是解决了How的问题，而并未回答Why的问题。这使得系统在开发过程中，开发团队经常陷入知其然，而不知其所以然的困境，造成了不必要的误解与错误。因此，需要一个侧重于对项目的风险承担者、目标用户需要的文档，不仅要了解他们需要的功能，还要找到他们提出这些需求的原因。这就是“项目构想”文档所要描述的重要内容。]
[本节的内容主要是提供项目构想文档的目的、范围、定义、参考资料以及对其的摘要性概述。]
[说明该文档的写作目的。]
[范围主要用来说明该文档描述的项目内容，以及与其相关的其它东西。]
1.3 定义、首字母缩写词和缩略语
[与其它文档一样，该文档也需要将本文档中所涉及的所有术语、缩略语进行详细的定义。还有一种可简明的做法，就是维护在一个项目词汇表中，这样就可以避免在每个文档中都重复很多内容。]
1.4参考资料
[在这一小节中，应完整地列出该文档引用的所有文档。对于每个引用的文档都应该给出标题、标识号、日期以及来源，为阅读者查找这些文档提供足够详细的信息。]
[在本小节中，主要是说明项目构想各个部分所包含的主要内容，就像一个文章摘要一样。同时也应该对文档的组织方式进行解释。]
2.1&商业机会
[如果该项目是一个产品型项目，那么应该在本小节中描述该产品所针对的商业机会。如果是定制开发项目，那么可以省去本小节。]
2.2&问题说明
[使用表格的形式，将该项目将要解决的问题进行概要性地描述：]
存在的问题
[问题的简要说明]
受影响的人群
[该问题对哪些人群带来了影响]
导致的后果
[该问题带来的不利因素]
希望的解决方案
[列出解决方案所能够解决的问题，以及其相应的优点。]
2.3&产品定位说明
[如果是产品型项目，则该小节将以表格的形式对产品的定位进行明确，如果是定制开发项目，可以省略本小节。]
[描述产品目标客户群体]
目标客户需求
[说明客户的需要或者潜在的机会]
[说明该产品属于什么领域]
[描述让目标客户产生兴趣和购买欲的理由]
主要竞争对手
[列出与该产品有竞争的其它厂商的产品]
[针对竞争产品的分析]
[一个具有清晰定位的产品，在开发过程中，团队将更好地理解，更容易开发出满足目标市场的产品，因而该部分内容是十分重要的。]
3.项目相关人员和用户说明
[了解用户、了解所有与该项目相关的人员，是有效地满足他们对系统、产品需求的基础。你应该在本小节中将所有的项目相关人员以及用户收罗在一起，并对他们进行简要的描述，对他们的需求、习惯、角度进行说明。这些内容将有助于开发团队更好的理解用户的需求本质。]
3.1&产品用户分析
[如果是产品型项目，那么你应该本节中对目标客户进行分析。可以在市场调查的基础上，对其市场的规模和增长率进行研究，从而估计其潜在的用户数量。另外，还应结合目标市场的实际情况，分析你的组织是否在该市场上有拓展的优势，如何获得这些优势。如果是定制开发项目，可以省略这一小节。]
3.2&项目相关人员一览表
[使用下面的表格，对项目相关人员进行分析。]
[指明项目相关人员的类别]
[列举该类人员的代表]
[说明其对产品、项目开发的影响]
3.3&用户一览表
&[使用下面的表格，对项目、产品的用户进行分析。]
[指明用户类别]
[简要说明他们在系统中代表的对象和充当的作用]
[列举出代表]
3.4&用户环境
[了解用户在使用环境下使用系统或产品，是十分有意义的事，也是实现产品更好地满足需求，提供更加方便的使用界面的基础。例如：该任务由多少人来完成？是否总在变化？一个任务周期需要多长时间？执行每项活动要用多长时间？是否总在变化？是否有特殊的环境约束：移动、户外、乘机旅行等？目前使用的是哪些系统平台？以后会使用哪些平台？还在使用哪些应用程序？您的应用程序是否需要和这些应用程序集成？他们的计算机硬件系统的环境情况如何？他们都是在什么样的工作环境中使用系统的？]
3.5&项目相关人员的简要说明&
[以下表的形式，将各类项目相关人员的基本情况进行说明，以帮助开发团队更好地了解他们的情况。为每一类人员生成一张表格。]
[列出该类项目相关人员的代表。]
[对该类人员进行简要说明。]
[描述本类人员的技能特长、技术背景以及电脑系统操作的熟练程度（可以分成业务用户、专家用户、熟练用户、初级用户等）]
[描述本类人员对系统开发所承担的职责，以及应享有的利益。]
[描述验证系统是否满足其职责的标准。]
[该类人员是否参与系统开发，如果参与将以什么形式参加。]
[说明该类项目相关人员是否参与项目成果的开发，是否有与其相关的项目成果。]
[列出与该类项目成员相关的问题与建议。]
3.6 用户简要说明
[以下表的形式，将与系统相关的各种用户的信息整理出来，以方便开发团队针对性的工作。要注意的是，用户会有不同的类型，有些用户需要的是灵活性、方便快速操作的高级功能，而有些用户则侧重与用户界面的友好性。这些与该用户的基本情况直接相关，了解用户才能够真正地开发出符合用户习惯和水平的系统。为每类用户生成一张表。]
[列出该类用户的代表。]
[对该类用户进行简要说明。]
[描述该用户的技能特长、技术背景和对计算机系统操作的熟练程度。]
[列出该用户对所开发的系统负有的关键职责，如记录详细信息、撰写报告、协调工作等。]
[描述验证系统符合用户需求的标准。]
[说明该类用户是否参与开发，如何参与。]
[说明是否有依赖于该类用户的项目成果。]
[列出一些该类用户对系统提出的一个意见与建议，并且收集其认为该系统将遇到的问题。]
3.7 关键的项目相关人员/用户需要
[列出项目相关人员提出的针对对于该解决方案的关键问题。对于列出的每个问题，需澄清：为什么会出现这一问题？目前的解决方案是什么？他们需要什么要的解决方案？或者对新的解决方案有什么样的预期？]
[还有一个很关键的内容就是，每个需求的优先级，这将对制定迭代计划时提供有效的基础，而优先级的确定，应该采用分级、累积投票等方法从用户、项目相关人员那里获得。应充分考虑项目客户方的要求。如果是产品型项目，则应该从产品经理、市场调查资料里获得。]
[经过整理后，将内容填入下表：]
目前解决方案
提议的解决方案
3.8 备选方案和竞争
[如果是产品型项目，应在此小节列举出客户除了购买该产品这外的选择，其中包括购买竞争对手的产品、自行设计解决方案甚至是维持现状。对所有潜在的竞争产品做一个列表，并根据客户的实际情况来确认主要优缺点。]
[而如果是定制开发型项目，则应该了解竞争对手提供的解决方案，比在此进行相应的比较。]
4. 产品概述
[本节主要从产品级、系统级的视角，高度概括产品的功能、与其它应用程序的交互以及所需的系统配置等。]
4.1&产品总体效果
[本小节主要将产品话在用户环境、使用环境的角度来介绍。如果是自成一体，则说明用户将如何使用；如果是与其它的应用系统进行交互的，则在此小节说明如何与这些系统进行交互？它们之间采用什么样的通讯方式和接口。在这里最适合的方式是使用UML的部署图，让用户对系统最终的运行环境有一个较宏观的了解。]
4.2&主要功能
[本小节不是对系统或产品所有功能的罗列，而是将能够体现系统、产品主要优点和特性功能在此列出。在内容组织方面，应该直接与“客户能够通过产品获得的好处”相联系，使读者能够将系统的功能与客户的价值直接联系起来，在开发时能够从本质出发，构建出更加符合客户需要的系统。]
4.3&假设与依赖关系
[在此小节中，列出所有会影响该文档中所述特性的各种因素。也就是列举出所有可能让该文档发生变化的假设条件。]
4.4&成本与定价
[该小节主要是对该项目的成本进行核算，对给出相应的定价策略。对于定制开发的项目，其成本主要包括开发的人工成本、公司管理成本、项目额外开支、相关软硬件工具投资等方面。而对于产品型项目而言，还包括分销成本、用户手册制作、CD制作等方面的成本。这里的成本核算为最终的合同价格以及产品的销售价值将提供一个基础的依据，因此也是十分重要的。]
4.5&许可与安装
[该小节中主要列出影响开发工作的一些许可和安装相关的问题。例如是否需要加密，如果验证用户合法性，安装界面的要求是什么。这方面对于产品型项目而言显得更加重要，也是对软件知识产权保护的一个重要措施。]
5.产品特性
[在本节中将列出系统或产品的特性，特性是指实现用户价值的系统功能。每一个特性都是一个所需的服务，通常是通过一系列操作实现预期结果。在FDD中，也就是特征。通常一个特征会由一个或多个用例来实现，通常系统的特性应该进行整合打包，以25-99项为合适。]
[本小节的描述应该能够让用户、操作人员、外部系统直接从系统的外边感受到每项特性，这些特性应该包括功能性说明以及一些可用性问题。但是要注意，在这里不要过早地引入设计的内容，这里说明的是What，而不是How。]
[另外，因在所有特性的描述中，确定其优先级。]
[记录用户、项目相关人员提供出的一些约束条件，以及与其它系统之间的依赖关系，这是制订解决方案时必须考虑到的问题。]
7.质量要求
[对于整个系统的质量要求，如可靠性、可用性、性能、容错等质量要求，在这此节中详细地定义与描述。]
8.其他产品需求
[一些要求符合的标准、硬件基础要求、软件基础要求、环境要求等。]
8.1&适用的标准
[列出产品必须符合的所有标准。其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix 等）以及质量和安全标准（UL、ISO、CMM）。]
8.2&系统需求
[确定支持该应用程序所必需的任何系统需求。其中可能包括操作系统、网络环境、系统配置、内存大小、硬盘大小、外围设备和配套软件。]
8.3&性能需求
[本节用于详细说明性能需求。性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。]
8.4&环境需求
[对于基于硬件的系统，环境因素可以包括温度、振荡、湿度、辐射等。对于软件应用系统，环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。]
9.&文档需求
[列举用户所需的与该系统或产品相关的文档。]
9.1&用户手册
[用户手册的制作说明，例如手册篇幅、详细程序、是否需要图、主要关心的点、要不要建立索引、词汇表，采用教程式还是速查手册式。]
9.2&联机帮助
[联机帮助是一种用户界面友好的服务，它可以为用户提供实时的协助。]
9.3&安装指南、配置文件、自述文件
9.4&标签与包装
10. 功能需求属性
[为了在项目开发过程中，对每个功能需求进行跟踪管理，在此对所有的功能进行一个总体的描述。]
[可以生成一张功能需求属性表，每条记录代表一条功能，每个功能包括以下字段：]
1）状态：标识该功能的最新状态。
Ø&已提出：已经提出来，但是还没有经过正式的复审而确定的需求；
Ø&已批准：已经经过正式的渠道复审而确定，准备实施的需求；
Ø&已加入：已经加入到需求管理基线中的特性。
2）利益：根据客户的态度，确定每个需求的重要程序，也是确定系统开发优先级的基础数据。
Ø&关键：必不可少的特性，缺少这些特性的系统将无法满足客户的要求，这些特性通常会在最早安排到迭代开发中去；
Ø&重要：对于系统来说，该特性是十分重要的，很难以通过其它方式来弥补，如果这些特性没有第一时间实现，将会使得客户满意度大大降低。因此是第二优先实现的特性；
Ø&有用：这些是一些有效，但使用频率较低的功能特性。如果没有在第一时间实现，也不会对客户满意度造成很大的影响；
Ø&无用：对于系统来说是“镀金”需求，有也可以，没有也行的。
3）工作量：根据特性所需的时间和资源进行估算，给出团队开发的工作时间或个人开发的工作时间。也可以估算出代码行数或功能点数，这也将为迭代开发计划的制定提供良好的基础。
4）风险：列出该特性开发的最大风险，可以对这些风险进行级别细分，对于影响较大的风险还应该制定相应的应对措施。
5）稳定性：对该特性需求是否容易变化进行一个预估，以帮助设计人员在设计解决方案时更加有效地避免变化对体系结构的影响，从而节省时间。
6）基线：确定其是否已经纳入基线；
7）职责分配：列出负责实现该特性的团队；
8）原因：列出提出该特性的原因，也可以将与客户交流的记录等资料放在这里，以帮助开发团队更好的理解客户的本意。
需求规格说明书(ISO标准版)
编者说明：
&&& 当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。这是在软件项目过程中最有价值的一个文档。ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。
1.1编写的目的
&&& &&&&[说明编写这份需求说明书的目的,指出预期的读者。]
a.&&&& 待开发的系统的名称;
b.&&& 本项目的任务提出者、开发者、用户；
c.&&&& 该系统同其他系统或其他机构的基本的相互来往关系。
&&& &&&&[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1.4参考资料
&&& &&&&[列出用得着的参考资料。]
2．任务概述
[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。]
2.2用户的特点
[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。]
2.3假定和约束
&&& &&&&[列出进行本系统开发工作的假定和约束。]
3．需求规定
3.1对功能的规定
[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。]
3.2 对性能的规定
&&& [说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。]
3.2.2时间特性要求
&&& [说明对于该系统的时间特性要求。]
3.2.3灵活性
[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。]
3.3输入输出要求
[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对系统的数据输出及必须标明的控制输出量进行解释并举例。]
3.4数据管理能力要求（针对软件系统）
[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。]
3.5故障处理要求
[列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。]
3.6其他专门要求
[如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。]
4．运行环境规定
&&& &&&&[列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a.&&&& 处理器型号及内存容量
b.&&& 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量
c.&&&& 输入及输出设备的型号和数量，联机或脱机；
d.&&& 数据通信设备的型号和数量
e.&&&& 功能键及其他专用硬件]
4.2支持软件
[列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。]
&&& &&&&[说明该系统同其他系统之间的接口、数据通信协议等。]
&&& &&&&[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。]
需求规格说明书(Volere版)
编者说明：
&&& Atlantic System Guild（）公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术，是一个十分实用、完善的SRS模板。其所提供的Volere需求记录卡也十分实用，强烈推荐。
注：从Atlantic System Guild公司网站www.atlsysguild.com上获得，并稍做修改
1.产品的目标
1.1 该项目工作的用户问题或背景
[对引发开发任务的工作和情况的描述。同时也应描述用户希望用将要交付的软件来完成的工作。]
[该节内容为该项目提供了合法的理由，你应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。]
1.2 产品的目标
[用一句话或很少的几句话来说明“我们希望该产品做什么？”换言之，即开发该产品的真正原因。
[项目如果没有一个表述清晰、易于理解的目标，就会迷失在产品开发的沙漠中。产品必须带来某种优势。典型的优势是产品会增加组织在市场上的价值，减少运作成本，或提供更好的客户服务。这个优势应该是可度量的，这样才能够让您确定交付的产品是否达到目标。]
2.客户、顾客和其它风险承担者
2.1 客户是为开发付费的人，并将成为所交付产品的拥有者
&&& [这一项必须给出客户的姓名，三个以内是合理的。]
[客户最终将接受该产品，因此必须对交付的产品满意。如果你无法找到一个客户的姓名，那么也许你就不应该构建该产品。]
2.2 顾客是将花钱购买该产品的人
&&& [也给出姓名和相关的信息]
2.3 其它风险承担者
&&& [其他的一些人或组织的名称，他们或者受到产品的影响，或影响产品。]
1）&经理或项目负责人；
2）&业务领域专家；
3）&技术人员；
4）&系统开发者；
5）&市场人员；
6）&产品经理；
7）&测试和质量保证人员；
8）&审查员，诸如安全审查员或审计人员；
9）&律师；
10）易用性专家；
11）你所处行业的专业人员。
3.产品的用户
3.1 产品的用户
&&& [产品的潜在用户或操作员的列表。针对每种类型的用户，提供以下信息：]
1）&用户分类
2）&用户工作的任务；
3）&主要相关的经验；
4）&技术经验；
5）&其他用户特征：包括身体、智力、工作态度、对技术的态度、教育程度、语言技能、年龄、性别等。
[用户是为了完成工作而与产品交互的人，你了解用户，就越可能提交适合用户工作方式的产品。]
3.2 对用户设的优先级
&&& [在每类用户后面附上一个优先级，这区别了用户的重要性和优先地位：]
1）&关键用户：对产品的后续成功至关重要；
2）&次要用户：他们使用产品，但对产品的长期成功并无影响；
3）&不重要的用户：不常用、未授权和没有技能的用户。
[如果认为某些用户对产品或组织更重要，那么应该写明，因为它会影响你设计产品的方式。]
4.需求限制条件
4.1 解决方案限制条件
[此处明确了限制条件，它们规定了解决问题必须采取的方式。您可以认为它们是指令式的解决方案。仔细描述该解决方案，以及测试是否符合的度量标准。如果可能，您应该解释使用该解决方案的原因。]
[换一句话说，就是要求软件解决方案满足哪些限制条件！]
4.2 实现环境
&&& [此处描述产品将被实施的技术环境和物理环境。]
&&& [该环境也将成为设计解决方案时的限制条件之一。]
4.3 伙伴应用
&&& [此处描述那些不属于产品的一部分，但产品却又必须与其协作的应用程序。]
&&& [此处描述实现产品需求所必须使用的COTS(商业组件)。]
4.5 预期的工作场地环境
[此处描述用户工作和使用该产品的工作场地。此处应该描述任何可能对产品设计产生影响的工作场地特征。]
4.6 开发者构建该产品需要多少时间
&&& [任何已知的最后期限，或商业机会的时限，应在此处说明。]
4.7 该产品的财务预算是多少
&&& [该产品的预算，以金钱的形式或可得资源的形式说明。]
5.命名标准和定义
[定义项目中使用到的所有术语，包括同义词。这里的内容就是一个字典，包括在需求规格说明书中使用的所有名称的含义。这个字典应该使用你的组织或行业使用的标准名称。这些名称也应该反映出在工作领域中当前使用的术语。该字典包括项目中用到的所有名称。请仔细地选择名称，以避免传达不同的、不期望的含义。为每个名字写下简明扼要的定义，这些定义必须经过相应的风险承担者同意。]
6.相关事实
[可能对产品产生影响的外部因素，但不是命令式的需求限制条件。]
[列出开发者所做的假设。]
[将所有的假设列在此的目的是让每一个项目成员都意识到这个假设。]
8.产品的范围
8.1 工作的上下文范围
[上下文范围图用来表示将要开发的系统、产品与其它系统之间的关系，以确定系统边界。]
8.2 工作切分
&&& [一个事件清单，确定系统要响应的所有业务事件。清单包括：]
1）&事件名称
2）&输入和输出
8.3 产品边界
&&& [你可以使用用例图(use-case)来确定了用户与产品之间的边界。]
9.功能性需求与数据需求
9.1 功能性需求
&&& [对产品必须执行的动作的描述。]
&&& [每个功能性需求必须有一个验收标准。]
9.2 数据需求
&&& [与产品/系统有密切关系的主题域相关的业务对象、实体、类的说明书。]
&&& [进行问题域建模，生成相应的类图。]
10.观感需求
[一些与产品的用户界面相关的需求描述。]
11.易用性需求
11.1 易于使用
&&& [描述如何构建符合最终用户期望的产品。]
11.2 学习的容易程序
&&& [学习使用该产品应该多容易的说明。通常是有学习时间来衡量。]
12.性能要求
12.1 速度需求
&&& [明确完成特定任务需要的时间，这常常指响应时间。]
12.2 安全性的需求
&&& [对可能造成人身伤害、财产损失和环境破坏所考虑到的风险进行量化描述。]
12.3 精度需求
&&& [对产品产生的结果期望的精度进行量化描述。]
12.4 可靠性和可用性需求
[本节量化产品所需的可靠性。这常常表述为允许的两次失败之间无故障运行时间，或允许的总失败率。]
12.5 容量需求
&&& [本节明确处理的吞吐量和产品存储数据的容量。]
13.操作需求
13.1 预期的物理环境
&&& [本节明确产品将操作的物理环境，以及这种环境引起的任何特殊需求。]
13.2 预期的技术环境
&&& [硬件和其它组成新产品操作环境的设备的规范。]
13.3 伙伴应用程序
&&& [对产品必须与之交互的其它应用程序的描述。]
14.可维护性和可移植性需求
14.1 维护该产品需要多容易
&&& [对产品作特定修改所需时间的量化描述。]
14.2 是否存在一些特殊情况适用于该产品的维护
&&& [关于预期的产品发布周期和发布将采取的形式的规定。]
14.3 可移植性需求
&&& [对产品必须支持的其他平台或环境的描述。]
15.安全性需求
15.1 该产品是保密的吗？
&&& [关于该被授权使用该产品，以及在什么样的情况下授权等方面的描述。]
15.2 文件完整性需求
&&& [关于需要的数据库和其他文件完整性方面的说明。]
15.3 审计需求
&&& [关于需要的审计检查方面的说明。]
16.文件和政策需求
[本节包括针对社会和政策的因素的规格说明，这些因素会影响产品的可接受性。如果你开发的产品是针对外国市场的，可能要特别注意这些需求。]
[问一下是否产品的目标是你所不熟悉的文化环境，是否其它国家的人或其他类型的组织的人会使用该产品。人们是否有与你的文化不同的习惯、节日、迷信、文化上的社会行为规范。]
17.法律需求
17.1 该产品是否受到某些法律的管制
&&& [明确该产品的法律需求的描述。]
17.2 是否有一些必须符合的标准
&&& [明确适用的标准和参考的详细标准的描述。]
18.Opend问题
[对未确定但可能对产品产生重要影响的因素的问题描述。按照需求分析的术语还说，就是TBD（To Be Define）的问题。]
19.COTS解决方案
19.1 是否有一些制造好的产品可以购买
&&& [应该调查现存产品清单，这些产品可以作为潜在的解决方案。]
19.2 该产品是否可使用制造好的组件
&&& [描述可能用于该产品的候选组件，包括采购的和公司自己的产品。列出来源。]
19.3 是否有一些我们可以复制的东西
&&& [其他相似产品的清单。]
20.1 新产品会在当前环境中带来什么问题
&&& [关于新产品将怎样影响当前的实现环境的描述。]
20.2 新的开发是否将影响某些已实施的系统
&&& [关于新产品将怎样与现存系统协同工作的描述。]
20.3 是否我们现有的用户会受到新开发的敌对性影响
&&& [关于现有用户可能产生的敌对性反应的细节。]
20.4 预期的实现环境会存在什么限制新产品的因素
&&& [关于新的自动化技术、新的组织结构方式的任何潜在问题的描述。]
20.5 是否新产品会带来其他问题
&&& [确定我们可能不能处理的情况。]
21.1 为提交该产品已经做了哪些事
[用来开发产品的生命周期和方法的细节。画一个高层的过程图展示各项任务和它们之间的接口，这可能是沟通这方面信息的最好办法。]
21.2 开发阶段
&&& [关于每个开发阶段和操作环境中的组件的规格说明。]
22.1 我们要让已有数据和过程配合新产品，有什么特殊要求
&&& [一个移交活动的列表，一个实现的时间表。]
22.2 为了新产品，哪些数据必须修改/转换
&&& [数据转换任务清单，同时确定新产品需要转换的数据。]
23.1 当你开发该产品时，要面对什么风险
23.2 你制定了怎样的偶然紧急情况计划
&&& [需求的其他费用是你必须投入到产品构建中去的钱或工作量。当需求规格说明书完成时，你可以使用一种估算方法来评估费用，然后以构建所需的资金或时间的形式表述出来。]
25.用户文档
[用户文档的清单，这些文档将作为产品的一部分交付。]
26.后续版本的需求
[这里记录下一些希望今后版本中实现的需求。]
Volere需求记录卡
编者说明：
正如前面所述，Atlantic System Guild还提供了一个配套的Volere需求记录卡，这个记录卡十分实用。建议大家在需求调查、分析过程中，将需求记录在一系列的Volere需求记录卡上，这个卡让你能够很好的理清需求之间的关系，需求提出的背景，用户对需求的期望，有了这些素材，整理SRS时将变得更加简单。
注：顾客满意度是指完成该项功能顾客满意的程度，而顾客不满意度则是指未实现该功能顾客不满意的程度。
软件需求规格说明书
编者说明：
&&& 如果在需求分析时采用了用例（Use case）技术，那么该需求规格说明书将更加符合你的需要。当然，你也可以结合Volere需求规格说明书对该模板进行必要的修改。
1. 文档概述
[该部分主要是对软件需求规格说明书文档进行基本的描述，包括该文档的目的、范围、术语定义、参考资料以及概要。]
[软件需求规格说明书用来系统、完整地记录系统的软件需求。该软件需求说明书的基础是用例分析技术。因此该文档中应包括用例模型、补充规约等内容。]
[在此小节中，主要对软件需求规格说明书的目的做一概要性说明，通常软件需求规格说明书应详细地说明应用程序、子系统的外部行为，还要说明非功能性需求、设计约束，以及其它的相关因素。]
[系统是有范围的，而不是无限扩展的，对于无限扩展的需求是无法进行描述的。因此，在本小节应该对该说明书所涉及的项目范围进行清晰的界定。指定该规格说明书适用的软件应用程序、特性或者其它子系统分组、其相关的用例模型。当然在此也需要列出会受到该文档影响的其它文档。]
1.3 定义、首字母缩写词和缩略语
[与其它文档一样，该文档也需要将本文档中所涉及的所有术语、缩略语进行详细的定义。还有一种可简明的做法，就是维护在一个项目词汇表中，这样就可以避免在每个文档中都重复很多内容。]
1.4参考资料
[在这一小节中，应完整地列出该文档引用的所有文档。对于每个引用的文档都应该给出标题、标识号、日期以及来源，为阅读者查找这些文档提供足够详细的信息。]
[在本小节中，主要是说明软件需求规格说明书各个部分所包含的主要内容，就像一个文章摘要一样。同时也应该对文档的组织方式进行解释。]
2. 整体说明
[在本节中，将对整个软件需求进行总体性的描述，以期让读者对整个软件系统的需求有一个框架性的认识。也就是说，该节中主要包括影响产品及其需求的一般因素，而不列举 具体的需求。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。]
2.1用例模型
[在本小节中，将列出该软件需求的用例模型，该模型处于系统级，对系统的特性进行宏观的描述。在此应该列出所有的用例和Actor的名称列表，并且对其做出简要的说明，以及在图中的各种关系。]
2.2 假设与依赖关系
[在软件系统的开发过程中，存在许多假设和依赖关系。在本小节中应列举出所有的重要的技术可行性假设、子系统或构件可用性假设，以及一些可行性的假设。]
3. 具体需求
[如果说第二章节是框架，那么本节就是血肉。在本节中，应该详细列出所有的软件需求，其详细程序应使设计人员能够充分理解并且进行设计的要求，同时也应该给予测试人员足够的信息，以帮助他们来验证系统是否满足了这些需求。整个需求的组织可以采用用例描述进行。]
3.1用例描述
[如果你使用用例建模技术，那么你已经通过用例定义了系统的大部分功能性需求和一些非功能性需求。因此，在软件需求规格说明书只需将这些具体的用例描述，整理在一起，全部放在该小节之中。当然也可以将用例描述做为附件，在此列出引用，只是这样做并不利于阅读。建议在组织形式上采用以“软件需求”为线索，在每个需求中，填入对应的1个或几个用例描述。]
3.2补充需求
[由于用例毕竟主要针对功能性需求，因此还会有一些其它的补充需求遗漏，因此在本小节中就是将这些东西补充出来。这些补充需求大部分集中在非功能需求之上，包括以下几个方面的内容：]
1）&易用性：例如指出普通用户和高级用户要高效地执行某个特定操作所需的培训时间；指出典型任务的可评测任务次数；或者指出需要满足的可用性标准（如IBM的CUA标准、Microsoft的GUI标准。
2）&可靠性：包括系统可用性（可用时间百分比、使用小时数、维护访问权、降纸模式操作等）；平均故障间隔时间（MTBF，通常表示为小时数，但也可表示为天数、月数或年数）；平均修复时间（MTTR，系统在发生故障后可以暂停运行的时间）；精确度（指出系统输出要求具备的精密度、分辨率和精确度）；最高错误或缺陷率（通常表示为bugs/KLOC，即每千行代码的错误数目或 bugs/function-point，即每个功能点的错误数目）；错误或缺陷率（按照小错误、大错误和严重错误来分类：需求中必须对“严重”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分功能）。
3）&性能：包括对事务的响应时间（平均、最长）；吞吐量（例如每秒处理的事务数）；容量（例如系统可以容纳的客户或事务数）；降级模式（当系统以某种形式降级时可接受的运行模式）；资源利用情况：内存、磁盘、通信等。
4）&其它：包括用户界面要求、联机帮助系统要求、法律许可、外购构件，以及操作系统、开发工具、数据库系统等设计约束。
4.支持信息
[支持信息用于使软件需求规格说明书更易于使用。它包括：目录、索引、附录等。]
计算机软件需求说明编制指南
编者说明：
&&& 软件需求规格说明是十分重要的文档，因此为开发团队提供一份详细的编制指南是十分有意义和必要的。本文档就是一个编制指南的例子，你可以根据该指南，结合自己的实际情况进行修改。
1.1 目的和作用
本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明（Software Requirements Specifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。
本指南适用对象：
1）软件客户（Customers），以便精确地描述他们想获得什么样的产品。
2）软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。
对于任一要实现下列目标的单位和（或）个人：
1）要提出开发规范化的SRS提纲；
2）定义自己需要的具体的格式和内容；
3