第2章 软件文档的写作规范
在第1章介绍的软件文档的背景知识和应用范围的基础上，本章详细阐述软件文档的写作规范，主要讲述可行性研究报告，项目建议书，招投标文件，需求分析书，概要设计书，详细设计书，项目验收报告和项目总结报告的写作规范，包括国家所定义的有关标准。
2.1 项目立项阶段文档的写作规范
一个软件项目从立项到结尾共有几个阶段：立项，投标，需求分析，概要设计，详细设计，软件编码，软件测试，维护，验收。在这几个阶段中，每一个阶段都有各自的文档内容及格式，但是国内目前存在以下一些现状：
1．文档极其简单，相当于没有文档。
2．文档流于形式，没有什么实际的价值。
3．太强调文档的重要性，以至于文档不能改，只能改代码。以上是一些比较极端的现象。
软件项目在立项阶段需要进行市场调查和产品定位等的业务分析，并且形成规范的可行性研究报告、项目建议书和投标文件，论述开发软件产品的充分理由。
2.1.1 可行性研究报告
可行性研究报告的编写目的是说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。
可行性研究报告的编写内容要求如下所述。
1. 引言
1.1 编写目的
说明编写本可行性研究报告的目的，指出预期的读者。
1.2 背景
说明：
a. 所建议开发的软件系统的名称。
b. 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。
c. 该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3 定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4 参考 资料
列出可以使用的参考资料，如：
a. 本项目的经核准的计划任务书或合同、上级机关的批文。
b. 属于本项目的其他已发表的文件。
c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2. 可行性研究的前提
说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。
2.1 要求
说明对所建议开发的软件的基本要求，如：
a. 功能。
b. 性能。
c. 输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象。
d. 输入说明系统的输入，包括数据的来源、类型、数量、数据的组织以及提供的频度。
e. 处理流程和数据流程，用图表的方式表示出最基本的数据流程和处理流程，并辅之以叙述。
f. 安全与保密方面的要求。
g. 同本系统相连接的其他系统。
h. 完成期限。
2.2 目标
说明所建议系统的主要开发目标，如：
a. 人力与设备费用的减少。
b. 处理速度的提高。
c. 控制精度或生产能力的提高。
d. 管理信息服务的改进。
e. 自动决策系统的改进。
f. 人员利用率的改进。
2.3 条件 、假定和限制
说明对这项开发中给出的条件、假定和所受到的限制，如：
a. 所建议系统的运行寿命的最小值。
b. 进行系统方案选择比较的时间。
c. 经费、投资方面的来源和限制。
d. 法律和政策方面的限制。
e. 硬件、软件、运行环境和开发环境方面的条件和限制。
f. 可利用的信息和资源。
g. 系统投入使用的最晚时间。
2.4 进行 可行性研究的方法
说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的。摘要说明所使用的基本方法和策略，如调查、加权、确定模型、建立基准点或仿真等。
2.5 评价尺度
说明对系统进行评价时所使用的主要尺度，如费用的多少、各项功能的优先次序、开发时间的长短及使用中的难易程度。
3. 对现有系统的分析
这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚至是一个人工系统。分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。
3.1 处理流程和数据流程
说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示，并加以叙述。
3.2 工作负荷
列出现有系统所承担的工作及工作量。
3.3 费用开支
列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、材料等项开支以及开支总额。
3.4 人员
列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。
3.5 设备
列出现有系统所使用的各种设备。
3.6 局限性
列出本系统的主要的局限性，例如处理时间赶不上需要，响应不及时，数据存储能力不足，处理功能不够等。并且要说明为什么对现有系统的改进性维护已经不能解决问题。
4. 所建议的系统
本章将用来说明所建议系统的目标和要求将如何被满足。
4.1 对所建议系统的说明
概括地说明所建议系统，并说明列出的要求将如何得到满足，说明所使用的基本方法及理论根据。
4.2 处理流程和数据流程
给出所建议系统的处理流程和数据流程。
4.3 改进之处
按2.2条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。
4.4 影响
说明在建立所建议系统时，预期将带来的影响，包括：
4.4.1 对设备的影响
说明新提出的设备要求及对现存系统中尚可使用的设备须做出的修改。
4.4.2 对软件的影响
说明为了使现存的应用软件和支持软件能够同所建议系统相适应。而需要对这些软件所进行的修改和补充。
4.4.3 对用户单位机构的影响
说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。
4.4.4 对系统运行过程的影响
说明所建议系统对运行过程的影响，如：
a. 用户的操作规程。
b. 运行中心的操作规程。
c. 运行中心与用户之间的关系。
d. 源数据的处理。
e. 数据进入系统的过程。
f. 对数据保存的要求，对数据存储、恢复的处理。
g. 输出报告的处理过程、存储媒体和调度方法。
h. 系统失效的后果及恢复的处理办法。
4.4.5 对开发的影响
说明对开发的影响，如：
a. 为了支持所建议系统的开发，用户需进行的工作。
b. 为了建立一个数据库所要求的数据资源。
c. 为了开发和测验所建议系统而需要的计算机资源。
d. 所涉及的保密与安全问题。
4.4.6 对地点和设施的影响
说明对建筑物改造的要求及对环境设施的要求。
4.4.7 对经费开支的影响
扼要说明为了所建议系统的开发，设计和维持运行而需要的各项经费开支。
4.5 局限性
说明所建议系统尚存在的局限性以及这些问题未能消除的原因。
4.6 技术条件方面的可行性
本节应说明技术条件方面的可行性，如：
a. 在当前的限制条件下，该系统的功能目标能否达到。
b. 利用现有的技术，该系统的功能能否实现。
c. 对开发人员的数量和质量的要求并说明这些要求能否满足。
d. 在规定的期限内，本系统的开发能否完成。
5. 可选择的其他系统方案
扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点。
5.1 可选择的系统方案1
说明可选择的系统方案1，并说明它未被选中的理由。
5.2 可选择的系统方案2
按类似5.1条的方式说明第2个乃至第n个可选择的系统方案。
…………
6. 投资及效益分析
6.1 支出
对于所选择的方案，说明所需的费用。如果已有一个现存系统，则包括该系统继续运行期间所需的费用。
6.1.1 基本建设投资
包括采购、开发和安装下列各项所需的费用，如：
a. 房屋和设施。
b. 数据通信设备。
c. 环境保护设备。
d. 安全与保密设备。
e. 操作系统和应用软件。
f. 数据库管理软件。
6.1.2 其他一次性支出
包括下列各项所需的费用，如：
a. 研究（需求的研究和设计的研究）。
b. 开发计划与测量基准的研究。
c. 数据库的建立。
d. 软件的转换。
e. 检查费用和技术管理性费用。
f. 培训费、旅差费以及开发安装人员所需要的一次性支出。
6.1.3 非一次性支出
列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用，包括：
a. 设备的租金和维护费用。
b. 软件的租金和维护费用。
c. 数据通信方面的租金和维护费用。
d. 人员的工资、奖金。
e. 房屋、空间的使用开支。
f. 公用设施方面的开支。
g. 保密安全方面的开支。
h. 其他经常性的支出等。
6.2 收益
对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括如下内容。
6.2.1 一次性收益
说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述，如：
a. 开支的缩减包括改进了的系统的运行所引起的开支缩减，如资源要求的减少，运行效率的改进，数据进入、存储和恢复技术的改进，系统性能的可监控，软件的转换和优化，数据压缩技术的采用，处理的集中化/分布化等。
b. 价值的增升包括由于一个应用系统的使用价值的增升所引起的收益，如资源利用的改进，管理和运行效率的改进以及出错率的减少等。
c. 其他如从多余设备出售回收的收入等。
6.2.2 非一次性收益
说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益，包括开支的减少和避免。
6.2.3 不可定量的收益
逐项列出无法直接用人民币表示的收益，如服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进，组织机构给外界形象的改善等。有些不可捉摸的收益只能大概估计或进行极值估计（按最好和最差情况估计）。
6.3 收益/投资比
求出整个系统生命期的收益/投资比值。
6.4 投资回收周期
求出收益的累计数开始超过支出的累计数的时间。
6.5 敏感性分析
所谓敏感性分析是指一些关键性因素如系统生命期长度、系统的工作负荷量、工作负荷的类型与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时，对开支和收益的影响最灵敏的范围的估计。在敏感性分析的基础上做出的选择当然会比单一选择的结果要好一些。
7. 社会因素方面的可行性
本章用来说明对社会因素方面的可行性分析的结果，包括：
7.1 法律方面的可行性
法律方面的可行性问题很多，如合同责任、侵犯专利权、侵犯版权等方面的陷阱，软件人员通常是不熟悉的，有可能陷入，务必要注意研究。
7.2 使用方面的可行性
例如从用户单位的行政管理、工作制度等方面来看，是否能够使用该软件系统；从用户单位的工作人员的素质来看，是否能满足使用该软件系统的要求等，都是要考虑的。
8. 结论
在进行可行性研究报告的编制时，必须有一个研究的结论。结论可以是：
a. 可以立即开始进行。
b. 需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行。
c. 需要对开发目标进行某些修改之后才能开始进行。
d. 不能进行或不必进行（例如因技术不成熟、经济上不合算等）。
2.1.2 项目建议书
项目建议书一般是由主策划或者项目经理负责编写的。进行可行性分析是一个自我否定的过程，而写项目建议书是一个向别人阐述自己观点的过程。而且项目建议书一般情况下是要去说服你的上司或者投资人来做这个项目，所以一定要非常完善，把所有可能的利弊都分析到。了解一个项目是如何才能达到立项标准，会加深对策划的进一步认识，避免把精力投入到不能成为项目的狂想中去。一份合理的项目建议书会让上司或者投资人更清楚你的设计思想是否完善，要努力说明这个项目的亮点和创新的地方来打动他们。这也是自己整理思路并说服自己继续做下去的一个书面文件，它会贯穿整个开发过程成为一个纲领性文件，是整个项目开发的大方向。在项目建议书被批准后，项目也就正式立项了。
项目建议书一般包括如下几个部分。
（1）当前市场情况分析：这个部分是给上司或者投资人看的。项目必须适应市场需要，闭门造车的策略是不可行的。必要情况下要先对市场进行调查和分析，利用第一手信息对客户意见进行捕捉，把这些信息合理地加入到建议书中才可以增强说服力。
（2）项目的概要介绍：这是一个向上级描述项目内容的最好方法。平时的报告太长太麻烦，谁都不会有兴趣认真看下去的。而项目建议书决定着这个项目能否进行下去，所以这是一个让上司了解你的想法的最好机会。这里的介绍不能太长，要把你所有的精华部分都罗列在上面，吸引住了上司，立项就确定了一半。对项目策划来讲，如何用最简洁的语言把整个项目的精华表述出来至关重要。项目的主体就是在这时确定的，一旦该项目被批准，那么以后的项目设计都要围绕着它来开展。所以这时项目中的亮点和主要特征都要认真的进行讨论分析，利用好手中的信息展开讨论，并结合其他项目的优缺点分析自己设计中要突出的地方才可能抓住投资人的心。牢记一点：“只有能够带来最大化利润的项目创意才能吸引住投资者的心！”
（3）项目的赢利模式：这部分要对整个开发的成本以及回报进行估算。要分析需要多少人工，设备费用，以及管理费用等。然后就要估算按照什么样的定价卖多少套软件可以回收成本，是否有其他的赢利模式等。
（4）项目的整体框架：这个部分对项目来说是至关重要的。项目要如何划分模块，用什么方式开发，以及模块之间的关系都要确定下来。对于一个大型的软件项目，如果不进行模块划分和良好的整体设计，在实际的开发过程中会陷入无限的混乱中，人员也会很难控制。按照体系进行划分是一个比较有效的划分方法，任何项目都是可以根据自身要求进行模块划分，下面给出一个大体的划分模式，后面会有详细的介绍。
（5）项目开发进度：开发进度是要求产品经理或项目经理根据现有的条件来确定的。对你的上司来说，他最看重的也是这个部分。因为开发周期的长短会直接影响到项目开发的成本，而且何时能够完工也决定着上市能否赶上最好的销售期，所以开发进度很多时候能够直接决定着这个项目是否会被上司否决。
（6）开发人员列表及职责：最后一项，就是对人员进行分工。已经到位了的，直接进行工作安排；还没有到位或者需要招聘的，向人事部门发送申请。报告中要对人力情况进行估算，以及各项费用的评估。费用的评估是需要有丰富经验的市场和管理人员才可以计算的。
在完成了上述各项工作的之后，如果你的预算和公司的计划相符，那么恭喜你，你可以开始下一步的安排了。否则，就只有等机会或者重写你的报告，但这种情况往往是没有结果的。项目建议书并没有一个固定的格式，你的目的就是通过它来说服你的上司。但是这又是不可或缺的一个必要条件，项目建议书分析得越透彻，这个项目可能获得的支持也就越多，最终成功的机会也就越大。
2.1.3 招投标文件
国内的软件项目招投标文件的写作规则并不存在行业标准。许多大型企业的信息化主管在他们的工作中，总是相互传递着一种或多种招标文件的写作规则，而没有多少人关心规则的出处。主管们总是认为，有规则总比没有好，只要能够用，能够把问题说清楚就可以。这里给出一个招投标文件写作规则的参考规范。
招投标文件写作规范
1招标
1.1 总则
本次招标方式为：邀请招标
1.1.1 适用范围
本招标文件条款仅适用于本招标邀请书中所述的信息系统建设项目。
1.1.2 招标项目要求
此次招标项目为一次性买断在招标单位的使用权，在招标单位范围内可自由安装使用，不受安装点数的限制。
投标方应是在中华人民共和国境内注册的国内的独立法人。
投标方必须是所提供软件系统的软件制造商或拥有授权书的合作伙伴。
报价应为人民币含税价。
投标方在投标时，必须提供系统整体解决方案，并按照投标文件中的规则提供详尽内容。
投标方必须提供五份投标书，一份为正本，四份为副本，并加盖印章。
投标方必须具有相应的售后服务能力，提供良好的软件维护和技术培训服务。公司注册地不在本地区的，必须注明其对上述地区的售后服务机构的地址、人员组成及其与投标方的关系。
投标方必须由法人代表或委托代理人参加评标，并解答评标小组提出的问题。
法人代表委托代理人参加评标或签订合同时，必须出具法人代表的授权委托书。
投标方中标后履约过程中，须遵守有关法律，如实提供检查所必须的材料。
投标人应对招标单位所在行业的业务运作有一定的了解，并有三个以上同类大型信息系统项目的成功案例。
1.2 项目 招标简介
1.2.1 招标单位介绍
1.2.2 招标企业资信状况
1.2.3 项目简介
1.2.3.1 项目定位
1.2.3.2 系统建设目标
1.2.3.3 项目涉及范畴
1.2.3.4 项目建设周期
1.2.4 现有信息系统建设现状
1.3 企业 信息化项目需求
1.3.1 企业管理现状
1.3.1.1 管理问题
1.3.1.2 流程问题
1.3.1.3 规则问题
1.3.2 企业业务需求
1.3.2.1 流程
1.3.2.2 制度、规则与算法
1.3.3 企业管理需求
1.3.3.1 高层管理人员需求
1.3.3.2 职能管理人员需求
1.3.3.3 流程管理人员需求
1.3.4 业务功能需求
1.3.4.1 必须满足的功能需求
1.3.4.2 需要考虑的功能需求
1.4 咨询 与实施需求
1.4.1 项目组织需求
1.4.2 进度计划与规则
1.4.3 咨询与实施方法
1.4.4 培训
1.4.5 成功项目咨询与实施的案例介绍
1.5 售后 服务要求
1.5.1 价格约束
1.5.2 时间约束
1.6 信息 系统要求
1.6.1 指导性原则
1.6.2 技术路线
1.6.3 网络与主机体系要求
1.6.4 数据库系统要求
1.6.5 接口开放要求
1.6.6 安全体系
1.6.7 客户化工具与能力
1.6.8 需要支持的技术规范
2投标文件
2.1 投标人商务文件构成
授权委托书
投标报价书
开标一览表
投标保证金
投标人基本情况表
近期完成的类似项目情况表
正在开发的和新承接的项目情况表
拟投入本合同工作的主要人员情况表
响应招标文件商务条款表
商务特殊承诺表
项目建议书
2.2 投标文件要求
2.2.1 投标文件的语言及计量单位
投标人提交的投标文件以及投标人与招标人双方就有关投标事宜的所有来往函电均应使用中文书写（专有名词须加注中文解释），并采用通用的图形符号。如果投标单位提供的文件资料已用其他语言书写，投标单位应将其译成中文，如有差异，以中文为准。
除技术规格中另有规定外，投标文件中使用的所有计量单位均应采用中华人民共和国现行法定计量单位。
2.2.2 投标货币
2.2.3 投标人资质文件
投标人应提交证明其有资格参加投标和中标后有履行协议的能力的文件（包含投标人企业注册背景资料），并作为投标文件的一部分。
投标人提交的资质证明文件应具有一定效力。
投标人应具有履行合同协议所必须的物流、技术和生产能力。
提供至少一个类似项目的简介及联系人。
投标人应填写并提交招标文件所附的各项资格证明文件。
投标人应提供营业执照（副本）复印件。
投标方提供参与本项目的系统设计、开发、实施等部门工程师名单及资格证明文件。
2.2.4 投标文件的密封与标志
投标文件均须投标单位正式授权代表签署，其中投标书必须由投标单位法定代表人签署。投标文件同时须加盖投标单位公章。
投标单位应将投标文件的一个正本、四个副本、电子文档分别包装且加以密封，且在内层包封的显著位置上标明“投标文件正本”、“投标文件副本”、“投标文件电子版本”。之后对投标文件再进行包装与密封。三者如有不同，以正本为准。
投标文件密封口须加盖投标单位公章及法定代表人或其授权代表签字，封皮上注明“XX公司XX信息系统项目投标文件”，并写明投标单位名称、地址、联系方式。
如果投标单位在投标截止期前要求修改投标文件，应当整体替代原投标文件，并在新投标文件的封皮上注明“第几次修改”和修改日期。
2.2.5 递交投标文件的截止日期
投标单位必须在投标邀请书规定的投标截止日期之前，将投标文件专人送达投标邀请书中规定的地点。
2.2.6 投标有效期
投标有效期为自投标截止期起60日。
当招标单位因特殊情况须延长投标有效期时，应在原有效期满7天前书面或电传通知投标单位。
2.2.7 投标文件的修改和撤回
投标文件不得有涂改、增删处，修改错误时，修改处须由投标单位法定代表人或其授权代表签名确认，并加盖单位公章。
在投标截止期前，投标单位可以对已经向招标单位的投标文件进行修正。
投标文件的修正采用整体替代的方式。原投标文件不退回。
修正的投标文件的内容和密封要求与原投标文件要求一致，但必须在封皮上注明“第几次修改”和修改日期。开标时及开标以后，均以最后一次修改的投标文件为准。
投标单位可以在递交投标文件之后，在规定的投标截止日期之前，以书面的形式向招标单位递交撤回投标文件通知。
撤回投标文件通知应当按照对投标文件和规定进行密封，并在封皮上注明“撤回投标文件通知”。
在投标截止期之后，不能修改、修正、撤回投标文件。
2.2.8 投标保证金
投标单位在递交投标文件的同时应提交投标保证金，金额为XX万元人民币，未提交投标保证金的投标文件一概拒收。
投标保证金以支票或汇票的形式提交。
投标单位在投标有效期内撤标，或在招标单位发出中标通知书后中标单位拒绝按招标文件的规定签订合同书、修改投标总金额、不能承担招标文件规定的全部义务，其投标保证金将归招标单位所有。
对于其他投标单位，将在招标单位与中标单位签订合同书30天内退还其投标保证金。
退回的投标保证金一律不计利息。
2.3 项目建议书的写作要求
2.3.1 企业需求理解
2.3.1.1 系统建设目标
2.3.1.2 管理需求
2.3.1.3 管理难题
2.3.1.4 管理流程、规则、算法
2.3.1.5 管理功能
2.3.2 投标方软件（或项目）所能够实现的管理体系
2.3.2.1 软件产品（或项目）的设计的目标
2.3.2.2 所支持的流程、功能、算法
2.3.3 企业需求与软件差异分析
2.3.3.1 管理模型构造差异（软件对组织和核算体系的支持）
2.3.3.2 流程的差异分析
2.3.3.3 功能的差异分析
2.3.3.4 规则的差异分析
2.3.3.5 覆盖地域、处理效率差异分析
2.3.4 客户化复杂度评估
2.3.4.1 客户化范围与深度
2.3.4.2 客户化计划与周期
2.3.4.3 客户化项目管理方法与人员
2.3.4.4 客户化地点
2.3.4.5 客户化测试、验收与交付
2.3.5 技术路线符合程度评估
2.3.5.1 体系结构（C/S，B/S）
2.3.5.2 开发与运行环境
2.3.5.3 服务器、主机、网络
2.3.5.4 电子商务支持程度
2.3.5.5 接口开放程度
2.3.5.6 安全体系
2.3.6 咨询与实施满足度
2.3.6.1 组织与人员
2.3.6.1.1 个人能力考察方法建议
2.3.6.1.2 组织能力考察方法建议
2.3.6.1.3 方法论的掌握能力
2.3.6.1.4 投标方项目管理组织建设思维
2.3.6.2 咨询与实施方法论
2.3.6.2.1 咨询方法流程与结构
2.3.6.2.2 咨询调查与分析方法
2.3.6.2.3 咨询评估方法
2.3.6.2.4 咨询与改进方法
2.3.6.2.5 方法论工具
2.3.6.2.6 方法论文档考察方法建议
2.3.7 培训
2.3.7.1 培训教材完备程度考察
2.3.7.2 培训教材写作规则考察
2.3.7.3 培训教师能力考察
2.3.8 案例考察建议
2.3.8.1 案例考察内容、计划与安排
2.3.8.2 所考察案例的企业规模
2.3.8.3 所考察案例的内容
2.3.9 服务
2.3.9.1 能够提供的标准免费服务
2.3.9.2 能够提供的特殊服务
2.3.9.3 能够提供的有偿服务、价格和支付方式
2.3.9.4 响应距离
2.3.9.5 响应时间
2.3.10 价格
2.3.10.1 软件产品价格
2.3.10.2 客户化价格
2.3.10.3 咨询与实施价格
2.3.10.4 服务价格
2.3.10.5 总价格和调整说明
2.3.11 投标企业状况介绍
2.3.11.1 投标企业人员构成和分布
2.3.11.2 企业总部人员规模
2.3.11.3 企业分支机构分布
2.3.11.4 企业主要财务指标
2.3.11.5 成功大项目列表和案例介绍
以上的内容试图告诉读者一种新型标书的写作方法，而不是一份完整标书。
2.2 需求分析书的写作规范
需求分析是对用户需求全面理解、深入挖掘的过程，其内容主要围绕“需求”二字展开，了解客户为什么要开发该软件系统、希望该软件系统能实现何种功能、希望用什么技术来开发该系统，该系统未来将要实施的环境、甚至是客户希望何时完成该软件系统的开发等，这一系列的问题都应该成为需求分析阶段要讨论的主题。
将需求分析阶段获得的用户的所有需求用文字记录下来，并按照一定的格式规范撰写，就形成了需求分析书。需求分析书是系统功能的界定书，是系统性能要求的量化规定，是开发双方责任与义务的合同书。
标准化无论是对传统的有形产品的生产厂家而言，还是对生产软件这样的无形产品的厂家而言，都具有重要的作用。如果屋子的灯坏了，只要选择和原灯泡具有相同插口的灯泡就可以，不需要考虑它是哪个厂家生产的，因为即使是不同厂家生产的灯泡，他们都遵循统一的标准，正因为遵循了标准才使得产品之间具有互换性。同样，对于软件产品的文档，如果人们都遵循同样的书写规范，不仅利于客户对需求分析书的阅读与理解，也有利于软件开发公司对以前开发过的软件间的比较和分析，为改善软件开发过程提供历史数据，提高未来软件的开发效率。
2.2.1 需求分析书的编制目标
需求分析的基本任务是要准确地定义新系统的目标，为了满足用户需求，回答系统必须“做什么”的问题。获得需求规格说明书。
为了更加准确地描述需求分析的任务，Boehm给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。
对于大中型的软件系统，很难直接对它进行分析设计，人们经常借助模型来分析设计系统。模型是现实世界中的某些事物的一种抽象表示，抽象的含义是抽取事物的本质特性，忽略事物的其他次要因素。因此，模型既反映事物的原型，又不等于该原型。模型是理解、分析、开发或改造事物原型的一种常用手段。例如，建造大楼前常先做大楼的模型，以便在大楼动工前就能使人们对未来的大楼有一个十分清晰的感性认识，显然，大楼模型还可以用来改进大楼的设计方案。
由于需求分析方法不同，描述形式也不同。需求分析一般的实现步骤如下所述。
（1）获得当前系统的物理模型
物理模型是对当前系统的真实写照，可能是一个由人工操作的过程，也可能是一个已有的但需要改进的计算机系统。首先是要对现行系统进行分析和理解，了解它的组织情况，数据流向，输入输出，资源利用情况等，在分析的基础上画出它的物理模型。
（2）抽象出当前系统的逻辑模型
逻辑模型是在物理模型的基础上，去掉一些次要的因素，建立起反映系统本质的逻辑模型。
（3）建立目标系统的逻辑模型
在分析目标系统与当前系统在逻辑上的区别，建立符合用户需求的目标系统的逻辑模型。
（4）补充目标系统的逻辑模型
对目标系统进行补充完善，将一些次要的因素补充进去，例如出错处理。
根据上述分析得知，需求分析的具体任务如下所述。
（1）确定系统的综合要求
确定系统功能要求是最主要的需求，确定系统必须完成的所有功能。确定系统性能要求应就具体系统而定，例如可靠性，联机系统的响应时间，存储容量，安全性能等。确定系统运行要求主要是对系统运行时的环境要求，如系统软件，数据库管理系统，外存和数据通信接口等。将来可能提出的要求对将来可能提出的扩充及修改做预准备。
（2）分析系统的数据要求
软件系统本质上是信息处理系统，因此，必须考虑数据（需要哪些数据，数据间联系，数据性质，结构），数据处理（处理的类型，处理的逻辑功能）。
（3）导出系统的逻辑模型
通常系统的逻辑模型用DFD图来描述。
（4）修正系统的开发计划
通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。
软件驱动着计算机硬件帮助人们完成一个又一个功能，软件没有思想不会思考却能很好地执行人类下达的命令。所以，软件能够做到的事，完全在人类的计划之中，是人类希望借助软件完成功能。于是，一个软件系统最终能给用户提供什么功能，是由软件的开发商决定的。由于将要开发的软件能提供的所有功能被记录在需求分析书中，所以需求分析书的编制目标可以总结为以下3点。
1．限定软件的功能需求
随着软件用途的扩大，现今人们开发出来的无论是通用软件还是特定领域的专业软件，其功能越来越强大，一般不存在只完成一个简单功能的小软件了，这些简单而单一功能往往由模块或者组件来实现，再将这些实现各种功能的模块或组件集成在一个系统中，团结协作共同完成人们希望实现的功能。软件应该具备什么样的功能，会根据各软件开发的目的不同而有所不同，所以首先应该明确的就是客户为什么要开发该系统，紧接着要确定客户为了达到这些目的希望计算机软件做什么。希望软件做的事就成为了客户的需求，客户的所有需求都应该被明确的记录，不能因为有些功能过于简单或者认为某些需求是理所当然的就不被记入需求说明书中。建房屋需要规划用地，做软件也需要明确功能边界。
2．明确开发目标
一个人在一大片空地上想走出一条直线是相当困难的，但是，如果空地上有棵树，以该树为目标径直走过去的话，也许中途会走歪，但是从整体来看，路是直的。软件开发的整个过程中，如果经常拿需求作为目标进行比较，到项目最后结束的时候就会发现，做出来的软件并没有太多的偏离原始要求。开发的过程中也不会因为目标不明确而任意发挥，而盲目乱做，会导致开发过程受阻或者不断返工。
3．提供系统评价标准
软件工程当中有一句很经典的话：“是否做了客户希望你做的事，是否用正确的方法做了客户希望你做的事”，需求分析书恰恰是检验“是否做了客户希望你做的事”最好的方法，系统交付给客户的时候，拿出之前落到纸上的需求分析书，对照其中的每点要求逐条验收，这样就可以检查该系统是否是客户最初设想的系统。
2.2.2 需求分析书的基本要求
需求分析书的基本要求主要有以下3个方面。
1．内容
内容决定文章的深度，是思想结晶的灵魂，适用于文学创作的原则在软件文档的编写方面同样适用。所以我们一定要正确把握需求分析书的内容，以客户的视角去评审需求阶段的文档，不在需求分析书中加入具体设计细节的描述。同时需求分析书的内容应该是完整的，至于需求分析书要包含哪些内容，可以参考国家已经制定的文档规范（GB8567—88），同时也可以按照本公司例行的内部文档标准。其原则应该是，包含客户关心的关于软件的所有问题，涵盖软件开发概要设计阶段关注的问题点。
2．文字
需求分析书的读者是客户和概要设计的参与者。为了让客户能读懂，需求分析书必须用自然语言来编写，力求将计算机领域的问题用浅显易懂的文字描述出来；另一方面，由于需求分析书还必须兼顾下一开发阶段的专业领域的读者，需求分析书又必须是严谨的，自然语言在严谨性上不具备优势，所以需求分析书在容易产生二义性的地方应该使用专业术语，配合适当的图例，达到既照顾了软件开发人员又兼顾客户的目的。
3．布局
科技学术类的文档不像小说，不需要跌宕起伏的情节，周密的布局和引人入胜的文字来吸引读者。科技文档的目的就是把问题说明白，不要悬念、不要倒叙、不要埋伏笔，如何直截了当的进入正题，如何把问题一步一步由浅入深、全方位的阐明才是科技文档的责任。所以，撰写需求分析书不需要花哨的装饰，只要实实在在有用的内容和简单易懂的布局。
2.2.3 需求分析书的适用范围
软件项目一旦被确定要实施之后，撇开项目的立项投标不谈，就进入了软件项目开发实施的第一个阶段——需求分析。
在需求分析阶段，软件系统分析师等高层软件工作者将与客户一起探讨将要开发的软件需要具备的功能、性能等方面的需求。系统分析师们将这些需求用文字的形式记录下来，按照一定的书写规范形成需求分析书，提供给客户审核，客户提出修改意见，系统分析师修改需求分析书，然后再审核再修改，如此反复多次最终定稿。由此可见，需求分析书是需求分析阶段的最终产物，它在需求分析阶段孕育生成，在未来的概要设计阶段发挥至关重要的作用，限定着软件项目的功能范围和性能要求。
从使用者的角度来看，系统分析师是它的创作者，客户是它的读者，概要设计阶段的软件设计者是它的使用者。
2.2.4 需求分析书的编写
按照国家《软件需求说明书GB8567—88》所定义的标准，软件需求分析书的内容如下：
1 引言
1.1 编写目的
1.2 背景
1.3 定义
1.4 参考 资料
2任务概述
2.1 目标
2.2 用户的特点
2.3 假定和约束
3 需求规定
3.1 对功能的规定
3.2 对性能的规定
3.2.1 精度
3.2.2 时间特性要求
3.2.3 灵活性
3.3 输入输出要求
3.4 数据管理能力要求
3.5 故障处理要求
3.6 其他专门要求
4 运行环境规定
4.1 设备
4.2 支持软件
4.3 接口
4.4 控制
以上就是国家制定的需求分析书的标准格式。标准格式为人们提供的是一种向导，第一次写需求分析书不知道需要包含什么内容的时候，可以以标准格式作为我们开始工作的导航。对于软件开发这样具有创造性的工作，标准在提供导航作用的同时，可以被创作人自由地剪裁与编辑。需求分析书虽然是由软件开发人员编写的，但最终的读者却不是软件开发人员，而是委托开发的客户，这些客户大多是熟悉公司业务流程的高层，他们是自己工作领域中的专家，但是对软件却知之甚少。正因为这样，需求分析书可以而且必须在满足标准的前提下，结合客户的实际情况，与客户充分交流积极探讨，力争写出让客户易于理解又无歧义的需求分析书。
2.3 概要设计书的写作规范
《概要设计说明书》又称为《系统设计说明书》，编制的目的是说明对软件系统的设计考虑，包括软件系统的基本处理流程、组织结构、模块划分、功能分配、接口设计、 运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
2.3.1 概要设计书的编制目标
在软件需求分析阶段，已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。进入了设计阶段，要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求，并将设计的结果反映在“设计规格说明书”文档中，所以软件设计是一个把软件需求转换为软件表示的过程，最初这种表示只是描述了软件的总的体系结构，称为软件概要设计或结构设计。
概要设计的基本任务如下。
（1）设计软件系统结构（简称软件结构）
为了实现目标系统，最终必须设计出组成这个系统的所有程序和数据库（文件），对于程序，则首先进行结构设计，具体为：
（a）采用某种设计方法，将一个复杂的系统按功能划分成模块。
（b）确定每个模块的功能。
（c）确定模块之间的调用关系。
（d）确定模块之间的接口，即模块之间传递的信息。
（e）评价模块结构的质量。
根据以上内容，软件结构的设计是以模块为基础的，在需求分析阶段，已经把系统分成层次结构。设计阶段，以需求分析的结果为依据，从实现的角度进一步划分为模块，并组成模块的层次结构。软件结构的设计是概要设计关键的一步，直接影响到下一阶段详细设计与编码的工作，软件系统的质量及一些整体特性都在软件结构的设计中决定。
（2）数据结构及数据库设计
对于大型数据处理的软件系统，除了控制结构的模块设计外，数据结构与数据库设计也是很重要的。
（a）数据结构的设计
逐步细化的方法也适用于数据结构的设计。在需求分析阶段，已通过数据字典对数据的组成、操作约束、数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
（b）数据库的设计
数据库的设计指数据存储文件的设计，主要进行以下几方面设计：
① 概念设计
在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用E-R模型来表示数据模型，这是一个概念模型。
② 逻辑设计
E-R模型或IDEFlx模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构，对于关系型的DBMS来说将概念结构转换为数据模式、子模式并进行规范，要给出数据结构的定义，即定义所含的数据项、类型、长度及它们之间的层次或相互关系的表格等。
③ 物理设计
对于不同的DBMS，物理环境不同，提供的存储结构与存取方法各不相同。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方式、索引的建立。
（3）编写概要设计文档
文档主要有：
（a）概要设计说明书。
（b）数据库设计说明书，主要给出所使用的DBMS简介、数据库的概念模型、逻辑设计、结果。
（c）用户手册，对需求分析阶段编写的用户手册进行补充。
（d）修订测试计划，对测试策略、方法、步骤提出明确要求。
（4）评审
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方案的可行性，关键的处理及内外部接口定义正确性、有效性，各部分之间的一致性等都一一进行评审。
概要设计是软件开发中承上启下的一个重要环节，它决定了软件开发的方向和过程。因为软件开发是个复杂过程，需要考虑方方面面的内容，如果没有一个纲领性的文档来组织管理，那么软件开发必然是一团糟。因此，概要设计书挑起了这个重任。
我们写出来概要设计书应该达到以下4个目标。
1．确定开发方案
如果让十个人拿着需求分析书直接进行软件开发，最后结果很可能是开发出十个风格迥异功能相同的系统。这些系统虽然功能相同，但是实现方法各有千秋，通过互相比较即可知道孰优孰劣。但是对于软件的开发来说，我们不可能同时开发出十个软件然后让客户择一而用，这是时间和金钱的浪费。所以必须在软件开发的概要设计阶段，深入调查、全盘考虑和细致比较之后确定开发方案。
2．刻画软件的全貌
既然概要设计是在宏观层面对软件进行设计，决定系统的体系结构，系统模块划分和采用的技术路线，并指出实现该系统的关键技术难点等。所以在概要设计书中，着重记录软件的运行环境、功能模块划分和相互关系，而不涉及功能的实现细节。
3．实现客户到软件开发者的转移
在软件系统的开发前期，一般只有少数几个资深的系统分析师与客户接触，了解需求，形成需求分析文档之后回到软件公司接着做概要设计。概要设计以及其后的阶段都是由软件从业人员着手进行，这些软件从业人员具有相同的领域知识，相互之间用专业术语来分析说明问题有时候会比用自然语言更容易表达和理解，并且不容易产生歧义。概要设计书担当起了客户与软件从业人员之间的桥梁作用，把客户用自然语言描述的需求转化为软件从业人员容易理解的系统功能说明书。
4．为详细设计阶段提供可加工的素材
所有的详细设计都是基于概要设计中划分出的模块、组件，并且要遵守概要设计中的各项原则。所以，概要设计是详细设计的素材、依据、标准，是开展详细设计工作的起点。
2.3.2 概要设计书的基本要求
我们可以从以下4个方面把握概要设计的基本要求。
1．宏观
概要设计书不是详细设计书，它把握系统的整体方向，起着提纲挈领的作用。在概要设计阶段不能陷入具体的实现细节，不要盲目的追求详尽而失去重点。
2．全面
概要设计书里包括了软件运行的方方面面，只有在项目前期把所有可能遇到的问题、对策方法等，尽早尽多地考虑周全，避免突发事件，避免软件开发过程遭到不必要的阻断。尽量做到一切尽在运筹帷幄之中。
3．逻辑清晰
软件工程是科学、是工程，不需要华丽的修饰和天马行空的想象，它需要的是科学合理的设计和清晰严谨的刻画。逻辑清晰是科技文献的一大要求，也是概要设计书的要求。软件系统如何架构，系统如何划分，子系统之间复杂而烦琐的相互关系，只有靠清晰的逻辑才能让读者更快、更准确地掌握概要设计书的内容。
4．严谨
与需求说明书不同，其读者不再是对计算机领域知之甚少的门外汉，而是要接着进行详细设计的软件设计师。因此，概要设计书在文字上需要严谨而且专业，用UML一类的概要设计利器来帮助系统建模和分析系统，使得概要设计阶段的成果很容易的被详细设计阶段的从业人员理解。
2.3.3 概要设计书的内容
概要设计阶段已经离开客户的角度回到开发者的视角，进入软件系统的实质性开发工作。
每一个软件系统都是由程序和数据组成，所以数据是软件系统的基础，软件就是通过操作数据来完成人类希望的工作。对于当今大多数的系统而言，数据库成为了数据保存的仓库，于是，在概要设计阶段必须完成的工作之一就是数据库设计。明确数据如何存储，以什么结构进行存储，数据的形式一旦被决定下来，接下来的详细设计阶段才能以此为基础展开。所以概要设计书中应该包括初期的数据库设计。
需求分析阶段的最终成果——需求分析书中记录的系统的所有功能，成为概要设计阶段加工的原材料，是系统的组织结构、子系统的划分的依据。一个大的系统应该尽可能地被划分为大小适中、高内聚、低耦合的若干模块，这样做的目的一方面是容易理解，另一方面是便于开发。所以应该在概要设计阶段将软件系统科学合理的分割，将分割后各部门的功能、要求等记录在概要设计书中，为下一步的详细设计做准备。
体系结构、接口设计、出错处理设计、确定开发环境等影响整个软件系统主体结构、性能等大方向的问题，必须在概要设计阶段设计完成。这些问题对于系统而言，就像树干对整棵树的支撑作用一样。
概要设计书中应该包含系统的界面，它可以只是用最简单的哪怕是Excel画出的界面，也可以是用Dreamweaver等工具开发出来的原型。这些原型界面，简单明了的展现了系统的功能和风格，各子系统之间的关系，也成为了未来实现界面设计的布局标准。
在概要设计阶段，我们还需要制定规范，包括代码体系、接口规则、命名规则。这是软件开发的基础，有了开发规范、接口规则、方式方法，开发者就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
2.3.4 概要设计书的编写
按照国家《概要设计说明书GB8567—88》所定义的标准，概要设计说明书的内容如下所述。
1 引言
1.1 编写目的
1.2 背景
1.3 定义
1.4 参考 资料
2总体设计
2.1 需求规定
2.2 运行环境
2.3 基本设计概念和处理流程
2.4 结构
2.5 功能需求与程序的关系
2.6 人工处理过程
2.7 尚未解决的问题
3 接口设计
3.1 用户接口
3.2 外部接口
3.3 内部接口
4 运行设计
4.1 运行模块组合
4.2 运行控制
4.3 运行时间
5 系统数据结构设计
5.1 逻辑结构设计要点
5.2 物理结构设计要点
5.3 数据结构与程序的关系
6 系统出错处理设计
6.1 出错信息
6.2 补救措施
6.3 系统维护设计
一个系统编写一份概要设计书，概要设计书的内容可以完全按照国家规范来写，也可以参照公司以往的概要设计书自由地裁剪。注意编写概要设计书时一定要把握全局、分清楚主次，不盲目深入细节。
2.4 详细设计书的写作规范
有人说，概要设计书是设计图，详细设计书是施工图，这一描述精确而形象地说出了概要设计书和详细设计书之间的区别。概要设计关注系统由几个模块组成，各模块之间的调用关系等大方向的问题，而详细设计关注的是每一个被划分后的模块如何实现等具体问题。概要设计的设计对象是整个软件系统的协调运转，而详细设计的目标是各个模块的功能实现。
2.4.1 详细设计书的编制目标
软件详细设计是软件工程的重要阶段，软件详细设计细化了高层的体系结构设计，将软件结构中的主要部件划分为能独立编码、编译和测试的软件单元，并进行软件单元的设计，并最终将影响软件实现的成败。优秀的详细设计在提高编码质量、保证开发周期、节约开发成本等各方面都起着非常重要的作用，是一个软件项目成功的关键保证。
详细设计书的编制目标主要有以下3方面的内容。
1．设计各模块的实现方法
如果十个人看着概要设计书进行编码，对于同一个功能模块，也很可能会产生十个不同的实现方法，其中有效率高的最优算法，也有基本实现功能的可行算法。为了使我们的系统具有效率高、性能稳定、容错性强等优点，也必须在编码之前确定最优的算法，避免日后因为达不到前期确定的性能要求而返工。于是我们必须在详细设计阶段确定模块功能实现中的最优算法，预见技术难点，分析数据流等，这些问题不应该留待编码遇到的时候才考虑。
2．成为编码人员的指挥棒
我们心目中最理想的详细设计书是这样的，即使是一个对本系统一无所知的编程人员，按照详细设计书中包含的内容，也能很好的完成这部分的编码任务。换句话说，从详细设计书到编码的工作应仅仅是一个翻译工作，而不应存在任何的设计工作，所有设计工作应在编码之前完成。
3．成为单元测试的依据
方法是系统中最小的功能单位，单元测试的着眼点就是这些方法。在详细设计书中写着这些方法的输入参数，输出结果，测试用例就可以根据这些输入参数进行组合，考虑正常值、临界值、无效值，从而形成单元测试的测试用例。
2.4.2 详细设计书的基本要求
1．全面
如果说概要设计书的全面是针对整个软件系统的全面，那么详细设计书的全面就是针对整个模块的全面。整个系统只需要撰写一份概要设计书，但是详细设计书却必须有多份，因为我们需要为每个模块单独撰写详细设计书，即使是简单的功能模块也必须写详细设计书，哪怕是简单地描述该模块的实现，一方面是为了对付人类遗忘的天性，另一方面是为了与下一个接手这个软件系统的人进行平滑的交接。不将所有模块的详细设计都写在一个文档中，这样做避免了文档过大，而且易于查找。详细设计书中应该详尽地写下本模块的处理流程，至于模块的输入、输出、异常处理、响应速度等方方面面也要考虑周全。
所以说，全面，既是指对于该软件系统所有功能模块都要进行详细设计，又是指对于某个模块的设计要全面。
2．深入细节
详细设计书重在“详细”二字，此时就不能像概要设计书那样从高层把握该系统，而应该深入细节。为了实现本模块的功能，初期输入的数据，经过本模块加工之后要输出的数据，对初期数据如何加工，要进行什么类型的数据校验，如何访问数据库等实现细节，都必须在详细设计书中被明确记录下来。
3．严格遵守接口规则
一个系统中几乎不存在完全独立、与其他模块没有关联的孤独模块。又由于详细设计的工作量大，详细设计往往被分配给若干不同的人来共同担当。这样就使得每个人独立设计出来的模块能否平滑连接、协调工作成为问题。不同型号的螺丝螺母无法拧在一起，同样，存在前后调用关系的模块接口不同无法协同工作。概要设计阶段的接口设计就正好解决了个模块之间的连接问题，于是，即使是独立进行详细设计的软件从业人员，必须严格遵守概要设计书中制定出来的接口规则，以期实现系统的顺利衔接。
2.4.3 详细设计书的内容
详细设计书的内容和格式会因为开发企业不同，国家不同而具备不完全相同的内容，但是从本质上来看，既然详细设计书是为编码服务，那么必定要包含编码阶段所关心的所有问题。为了能够快速了解该模块，详细设计书中应该对该功能模块进行简单的功能描述。然后开始对模块进行详细的描述，列举各种参数，介绍模块的性能、使用方法等，让读者了解该模块如何使用。接着展开模块的设计工作，将模块的实现方式一步一步地记录下来，作为编码工作的依据。
我们可以参照2.4.4节的内容，看看详细设计书到底应该包括哪些方面的内容。
2.4.4 详细设计书的编写
按照国家《详细设计说明书GB8567—88》所定义的标准，详细设计说明书的内容如下所述。
1 引言
1.1 编写目的
1.2 背景
1.3 定义
1.4 参考 资料
2程序系统的结构
3 程序1（标识符）设计说明
3.1 程序描述
3.2 功能
3.3 性能
3.4 输入项
3.5 输出项
3.6 算法
3.7 流程逻辑
3.8 接口
3.9 存储分配
3.10 注释设计
3.11 限制条件
3.12 测试计划
3.13 尚未解决的问题
4 程序2（标识符）设计说明
看到以上的国家规范，我们不难发现，其实对于每个功能模块的详细设计书，其关注点都是相同的，都应该包含相同的部分，因为这些部分正是编码人员关心的，是编码的依据。就像之前说过的，功能简单的模块的详细设计书可以写得简练些，一些没有的部分，比如说“尚未解决的问题”等，我们应该根据实际情况灵活的裁剪。
2.5 项目结束阶段文档的写作规范
2.5.1 项目验收报告
这里给出一个项目验收报告的模板。
{项目名称}验收报告
{日期}
目 录
1 项目基本情况
2 项目进度审核
2.1 项目实施进度情况
2.2 项目变更情况
2.3 项目投资结算情况
3 项目验收计划
3.1 项目验收原则
3.2 项目验收方式
3.3 项目验收内容
4 项目验收情况汇总
4.1 项目验收情况汇总表
4.2 项目验收附件明细
4.3 专家组验收意见
5 项目验收结论
5.1 开发单位结论
5.2 建设单位结论
6 附件
6.1 附件一：软件平台验收单
6.2 附件二：功能模块验收单
6.3 附件三：项目文档验收单
6.4 附件四：硬件设备验收单
1 项目基本情况
2 项目进度审核
2.1 项目实施进度情况
2.2 项目变更情况
2.2.1 项目合同变更情况
{记录合同变更情况}
2.2.2 项目需求变更情况
{记录需求变更情况}
2.3 项目投资结算情况
3 项目验收计划
3.1 项目验收原则
（1）审查提供验收的各类文档的正确性、完整性和统一性，审查文档是否齐全、合理。
（2）审查项目功能是否达到了合同规定的要求。
（3）审查项目有关服务指标是否达到了合同的要求。
（4）审查项目投资以及实施进度的情况。
（5）对项目的技术水平做出评价，并得出项目的验收结论。
3.2 项目验收方式
{记录项目验收的组织方式和参与验收工作的人员情况}
3.3 项目验收内容
（1）硬件设备验收。
（2）软件平台验收。
（3）应用系统验收。
（4）项目文档验收。
（5）项目服务响应（如售后服务、问题等相应方面）验收。
4 项目验收情况汇总
4.1 项目验收情况汇总表
4.2 项目验收附件明细
（1）软件平台验收单（见附件一）。
（2）功能模块验收单（见附件二）。
（3）项目文档验收单（见附件三）。
（4）硬件设备验收单（见附件四）。
4.3 专家组验收意见
5 项目验收结论
5.1 开发单位结论
5.2 建设单位结论
6 附件
6.1 附件一：软件平台验收单
验收人：
验收时间：
6.2 附件二：功能模块验收单
验收人：
验收时间：
6.3 附件三：项目文档验收单
验收人：
验收时间：
6.4 附件四：硬件设备验收单
验收人：
验收时间：
2.5.2 项目总结报告
本节主要描述在软件产品或软件项目开发完成时所需编写的项目总结报告应该包含的内容，使得编写的项目总结报告便于软件产品或软件项目日后的维护，交接和代码重用。
以下部分为项目总结报告的模板。
文档编号：第×版
分册名称：第×册共×册项目名称（项目编号）总结报告（部门名称）
生效日期：
编制：
审核：
批准：
1. 引言
2. 项目开发结果
2.1 软件产品或软件项目
2.2 主要功能和性能
2.3 项目规模总结
2.4 项目人员总结
2.5 进度及工作量总结
3. 项目评价
3.1 生产效率评价
3.2 技术方法评价
3.3 产品质量评价
3.4 出错原因分析
4. 经验和教训
1. 引言
说明实际参加人员，时间及工作划分；说明参加本项目的负责人、参加人员，起止时间及实际工作量。按项目开发的阶段划分，细划每位开发人员在各开发阶段所用开发时间及实际工作量。
负责人
起止时间
计划工作量：项目情况，阶段参加人员，工作内容，起止时间，实际工作量，需求分析，系统设计，编码测试，其他，合计，项目开发结果。
2.1 软件产品或软件项目
2.1.1 软件产品或软件项目名称
给出该软件项目或软件产品在项目任务书或开发计划评审等文件中确定的正式的项目名称和项目编号；并给出该软件项目或软件产品正式批准发布的版本标识。
2.1.2 程序量
按模块进行划分，给出该软件项目或软件产品的源程序的存储容量。源代码用代码行来表示、可执行程序及其他程序可用字节来表示、文档可用页或字节来表示。源代码要按模块来统计，模块名称，代码行（千行），字节数（KB），源码模块1，模块2，执行程序。源码不填写字节数，执行程序只填写字节数。
2.1.3 存储介质
给出该软件项目或软件产品正式发布版本的存储介质及所需存储介质及其数量。
2.2 主要功能和性能
（1）描述该软件项目或软件产品所实现的功能，根据需要说明该软件项目或软件产品的有关性能指标。
（2）与最初的需求相比较、给出功能和或性能上的差异并说明原因。
项目规模总结：根据软件开发的各阶段，总结该软件项目或软件产品完成的功能模块数量与计划的对比、给出对比图表，并对比较结果进行分析。计划模块数，完成模块数。
项目人员总结：总结该软件项目或软件产品开发各阶段人员的变化情况与计划的对比、并对比较结果进行分析。计划人数，实际人数，增加人数，减少人数，变动人数总计。变动人数为人员更换数。
进度及工作量总结：总结该软件项目或软件产品实际完成所用的时间及工作量与原计划的对比（用图表来表示）。
从开发人员的角度进行总结：将每位开发人员开发该软件项目或软件产品起止时间和工作量与计划进行比较、给出对比图表，并对比较结果进行分析。
从模块的角度进行总结：将每一模块完成的起止时间和工作量与计划进行比较、给出对比图表，并对比较结果进行分析。模块名称，模块3，模块4。
从开发阶段的角度进行总结：将每一阶段完成的起止时间和工作量与计划进行比较、给出对比图表，并对比较结果进行分析。
从工作量的角度进行总结：将开发该软件项目或软件产品所用工作量与计划进行比较、给出由于软件问题报告所增加的工作量，给出对比图表，并对比较结果进行分析。批复工作量计划增加小计。
从完成情况进行总结：将项目的总体进度和阶段进度与计划进行比较、说明此项目是正常完成，正常但增加工作量，延期但不增加工作量，既延期又增加工作量，并对比较结果进行分析。
结论
以最后一版的开发计划中的开发进度为准，批复工作量包括由于软件问题报告增加的工作量。
项目评价
3.1 生产率评价
评价生产率可以有两种方法：代码行数与人月数比较、或修改BUG数与所用人月数的比较。我们可以采用任何一种。如果采用第一种方法，应以模块为单位进行比较；如果采用第二种方法，应以各测试版本的BUG数，修改的BUG数，修改BUG所用的工作量及修改单位BUG所用的工作量进行比较、总结评价项目的开发效率及相应的原因分析。
3.2 技术方法评价
总结该软件项目或软件产品开发时所采用的各项技术。产品质量评价可参考以下几个方面进行产品质量的评价。历次测试发现的BUG数；同种原因产生的BUG数；同种类型的BUG数；各等级的BUG数；同一BUG出现的次数。出错原因分析分别对以上几种情况绘制图表，进行原因的分析。次数，BUG数原因类型等级，BUG各经验和教训可以从以下几方面总结开发中获得的经验及纠正错误或缺陷等问题的教训。
管理人员的管理水平，开发人员的合理分工，项目软件经理PSM及开发人员的技术水平，开发人员的更换，开发人员的配合及协作，用户的密切配合，需求及设计的更改，开发过程中计划的合理调整等。
本章小结
本章重点讲述了可行性研究报告，项目建议书，招投标文件，需求分析书，概要设计书，详细设计书，项目验收报告和项目总结报告的编写方法和注意事项。在编写文档之前，要明确该文档在开发中的地位和作用，明确各个文档主要表达哪些内容，才能有主有次、逻辑清晰地表达出所需的内容。切忌参照目录如同填空一样地书写。此外，所有文档都应遵守标准格式，阅读此类文档通常都是直接查找所关心的内容，标准的格式有助于读者查找和阅读。
参考文献
[1] 软件需求说明书GB8567—88
[2] 概要设计说明书GB8567—88
[3] 详细设计说明书GB8567—88
[4] 胡红艳，刘咏梅．基于项目管理的软件产品研发管理研究，企业技术开发，2006年第25卷第11期
[5] 林锐．IT企业自主研发产品的立项管理方法，程序员，2006年第3期
[6] 刘瑞芳，谢长生，谭志虎．基于CMM的软件开发过程研究，计算机应用研究，2004年第7期
习题
1．名词解释
（1）评价尺度
（2）工作负荷
（3）项目的整体框架
（4）投标人资质文件
（5）物理模型
（6）体系结构
（7）功能模块
（8）生产率评价
2．问答题
（1）可行性研究报告的编写目的是什么？
（2）项目建议书一般包含哪几个部分。
（3）需求分析的目标是什么？
（4）概要设计的基本要求是什么？
（5）概要设计书和详细设计书之间的区别是什么？
3．论述题
（1）简述概要设计书的内容。
（2）谈谈你对详细设计书的基本要求中“全面”的理解。