软件开发文档

1、概述

1.1、编写软件开发文档的意义

软件文档（document）正是描述系统功能，刻画子系统间的相互关系，提供给开发者的精确、完整的指导资料。软件文档是软件开发者之间的沟通渠道，是具体工作的安排表，是系统的开发标准。

软件文档的编制（documentation）在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护软件文档对于转让、变更、修正、扩充和使用软件文档，对于充分发挥软件产品的效益有着重要意义。

许多软件文档存在以下问题：

• 错误的语法和/或拼错的词语
• 不完整
• 过时或不准确
• 过于冗长
• 未经解释的缩略语或专用术语
• 查找信息困难

一般的规则是，写文档需要团队协作，这样就需要开发人员和文档编写者利用彼此的优点，取长补短。例如，假如预期读者是系统设计师，开发人员需要提供技术细节，然后文档编写者按照正确语法组织和编辑内容。

1.2、软件文档的作用

件文档的本质作用是桥梁，是纽带，连接着软件开发方、管理人员、用户以及计算机，将其构成一个相互影响相互作用的整体。软件开发人员在各个阶段中以软件文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员，并得到必要的支持。管理人员则可通过这些软件文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，这被称为用户文档。

在软件工程中，文档用来表示对需求、工程或结果进行描述、定义、规定、报告或认证的任何文字或图示的信息。它们描述和规定了软件设计和实现的细节，说明使用软件的操作命令。文档也是软件产品的一部分，没有文档的软件就不成为软件。软件文档的编制在软件开发过程中占有突出的地位和相当大的工作量。高质量文档对于转让、变更、修改、扩充和使用文档，对于发挥软件产品的效益有着重要的意义。

软件文档的最主要目标是传达一个系统的技术要素和使用方法。第二个目标是提供软件开发过程中的需求，决策，行为，角色和责任的书面记录。只有实现了这两个目标，软件文档才真正提供了有意义的信息。

1.3、软件文档的分类

1.3.1、可行性研究报告

可行性研究报告的编写目的是说明该软件开发项目的实现在技术、经济和社会条件方面的可行性，评述为了合理地达到开发目标而可能选择的各种方案，说明并论证所选定的方案。可行性研究报告的内容包括可行性研究的前提，对现有系统的分析，所建议的系统，可选择的其他系统方案，投资及效益分析，社会因素方面的可行性和结论。

1.3.2、项目建议书

项目建议书为软件项目实施方案制订出具体计划，包括市场分析，项目的概要介绍，项目的赢利模式，项目的整体框架，各部分工作的负责人员、开发进度、开发经费的开发预算、所需的硬件及软件资源等。项目建议书一般由项目经理根据客户的开发计划来编写，作为整个项目的整体规划，未来的开发工作都基于这个计划来执行。进行可行性分析是一个自我否定的过程，而写项目建议书是一个向别人阐述自己观点的过程。而且项目建议书一般情况下是要去说服你的上司或者投资人来做这个项目，所以一定要非常完善，把所有可能的利弊都分析到。

1.3.3、招投标文件

一般的招标文件内容包括项目招标简介，企业信息化项目需求，咨询与实施需求，售后服务要求和信息系统要求等。投标文件内容包括投标人商务文件构成，投标文件要求和项目建议书的写作要求等。

1.3.4、需求分析书

需求分析书由软件开发人员与客户共同编写，客户用自然语言描述对系统的功能和性能方面的预期效果，开发人员将客户需求转化为文字记录下来，尽可能充分地诱导出客户的需求，使未来开发出来的系统能够真正满足客户的需要，与客户预期的系统相差无几。需求分析书是面向客户的软件文档，包括产品概述、主要概念、操作流程、功能列表和解说、注意事项、系统环境等。对系统进行详细的功能分析（包括客户提出的要求和根据开发经验建议的功能），描述本产品是什么，有什么特殊的概念，包括哪些功能分类，需要具备什么功能，该功能的操作如何，实现的时候必须注意什么细节，系统运行环境的要求等。

1.3.5、概要设计书

概要设计书以需求分析书为基础，包括功能实现、模块组成、功能流程图、函数接口、数据字典、软件开发需要考虑的各种问题等。这些问题都是从概要设计书编写开始，就正式进入计算机领域的软件文档了。由于需求分析书随时都有变更的可能性，所以概要设计书制定出来之后也不是一成不变的，它要随着需求分析书的变更而变化，从需求设计书出发，抽象出系统的功能模块，数据库要求，体系结构等大方向的问题。

1.3.6、详细设计书

概要设计书从高层着手对系统进行描述，但是，拿着这样一份概要设计书，是无法进行实际编码工作的。详细设计书以概要设计书为基础，对已拆分出来的子系统和功能模块逐个进行设计，这里的设计要详细到每个模块实现的具体步骤，按钮按下完成什么操作，点击某个连接迁移到什么画面，还要绘制出页面原形，提供与数据库的交互方法，数据的表现形式，这些都是要在详细设计书中具体描述的。当然，由于项目复杂度和规模不同，详细设计书的复杂度也会不同，功能简单的系统如果配上复杂的软件文档，只会让软件开发变得更复杂，违背了软件文档建立的目的。相反，如果软件系统复杂度高，参与人员众多，就必须配备详细的软件文档，给不同的角色的人员提供尽可能详细而全面的信息。

成功的详细设计书一旦做成，未来软件系统的实现方法也就确定了，编码人员按照详细设计书就可以开始具体的编码工作了。并且由于很多实现细节的问题都在详细设计中考虑分析过，一些技术难题也已经在前期进行攻关试验并最终得出结论，尽量让问题早发现早解决，不至于延迟到项目后期才发现。通过充分的详细设计过程，可以使编码过程变得简单易行，达到事半功倍的效果。

1.3.7、项目验收总结报告

项目验收总结报告的内容包括对所完成系统的测试，验收和总结。测试的目的是为了将软件产品交付给用户之前尽可能多的发现问题并及时修正问题，不至于等到用户在使用过程中才发现问题。测试计划就是规划整个测试的实施过程，计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。由于测试会细分为单元测试、集成测试、系统测试等几个环节，测试计划书也应该按照阶段制定。在软件系统的实际开发过程中，不仅只有以上所述的7种软件文档，还有维护手册，用户手册等。

1.4、软件文档必备的条件

软件系统配备软件文档不仅对于公司非常有益，而且也能够让客户从中受益。由于软件产品如何使用在某种程度上是要依赖软件文档来进行说明的，因此软件文档必须准确可靠。使用不准确的和已经过时的软件文档对于公司的发展也会产生一定的阻碍，同样也会对客户产生消极的影响。一旦客户发现在他们使用产品的时候遇到了问题，却不能通过求助于伴随软件产品的软件文档的手段进行解决的时候，客户就会对这种软件产品产生怀疑乃至于失去信心，公司的信誉和利益自然而然地就会受到损害。
无论是面向客户的需求分析书、用户手册，还是面向开发者的概要设计书、详细设计书、测试计划书，既然都是软件开发中产生的软件文档，则它们都具有一定的共性，都必须具有完整性、准确性、易用性和及时性。

1.5、软件文档的管理

1.5.1、管理者的作用

软件文档管理的标准是为对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南，目的在于协助管理者在他们的机构中产生有效的文档。管理者需要严格要求软件开发人员和编制组完成文档编制，并且在策略、标准、规程、资源分配和编制计划方面给予支持。

支持有效文档策略的基本条件有以下几点。

• 管理者对文档工作的责任：管理者要认识到正式或非正式文档都是重要的，还要认识到文档工作必须包括文档计划、编写、修改、形成、分发和维护等各个方面。
• 管理者对文档工作的支持：管理者应为编写文档的人员提供指导和实际鼓励，并使各种资源有效地用于文档开发。
• 管理者的主要职责：

1. 建立编制、登记、发布系统文档和软件文档的各种策略。
2. 把文档计划作为整个开发工作的一个组成部分。
3. 建立确定文档质量、测试质量和评审质量的各种方法的规程。
4. 为文档的各个方面确定和准备各种标准和指南。
5. 积极支持文档工作以形成在开发工作中自觉编制文档的团队风气。
6. 不断检查已建立起来的过程，以保证符合策略和各种规程并遵守有关标准和指南。

1.5.2、 文档编制计划

文档计划可以是整个项目计划的一部分或是一个独立的文档。应该编写文档计划并把它分发给全体开发组成员，作为文档重要性的具体依据和管理部门文档工作责任的备忘录。

对于小的、非正式的项目，文档计划可能只有一页纸；对于较大的项目，文档计划可能是一个综合性的正式文档，这样的文档计划应遵循各项严格的标准及正规的评审和批准过程。

编制计划的工作应及早开始，对计划的评审应贯穿项目的全过程。如同任何别的计划一样，文档计划指出未来的各项活动，当需要修改时必须加以修改。导致对计划做适当修改的常规评审应作为该项目工作的一部分，所有与该计划有关的人员都应得到文档计划。

文档计划一般包括以下几方面内容：

• 列出应编制文档的目录。
• 提示编制文档应参考的标准。
• 指定文档管理员。
• 提供编制文档所需要的条件，落实文档编写人员、所需经费以及编制工具等。
• 明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等。
• 绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。此外，文档计划规定每个文档要达到的质量等级，以及为了达到期望的结果必须考虑哪些外部因素。文档计划还确定该计划和文档的分发，并且明确叙述与文档工作的所有人员的职责。

2、软件文档的写作规范

2.1、项目立项阶段文档的写作规范

一个软件项目从立项到结尾共有几个阶段：立项，投标，需求分析，概要设计，详细设计，软件编码，软件测试，维护，验收。

2.1.1 可行性研究报告

可行性研究报告的编写目的是说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。

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 投标文件的密封与标志
2.2.5 递交投标文件的截止日期
2.2.6 投标有效期
2.2.7 投标文件的修改和撤回
2.2.8 投标保证金
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 需求分析书的编制目标

需求分析的基本任务是要准确地定义新系统的目标，为了满足用户需求，回答系统必须“做什么”的问题。获得需求规格说明书。

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）设计软件系统结构（简称软件结构）：
为了实现目标系统，最终必须设计出组成这个系统的所有程序和数据库（文件），对于程序，则首先进行结构设计，具体为：

• 采用某种设计方法，将一个复杂的系统按功能划分成模块。
• 确定每个模块的功能。
• 确定模块之间的调用关系。
• 确定模块之间的接口，即模块之间传递的信息。
• 评价模块结构的质量。

根据以上内容，软件结构的设计是以模块为基础的，在需求分析阶段，已经把系统分成层次结构。设计阶段，以需求分析的结果为依据，从实现的角度进一步划分为模块，并组成模块的层次结构。软件结构的设计是概要设计关键的一步，直接影响到下一阶段详细设计与编码的工作，软件系统的质量及一些整体特性都在软件结构的设计中决定。

（2）数据结构及数据库设计：
对于大型数据处理的软件系统，除了控制结构的模块设计外，数据结构与数据库设计也是很重要的。

• 数据结构的设计：逐步细化的方法也适用于数据结构的设计。在需求分析阶段，已通过数据字典对数据的组成、操作约束、数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
• 数据库的设计：数据库的设计指数据存储文件的设计。主要进行以下几方面设计：① 概念设计：在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用E-R模型来表示数据模型，这是一个概念模型。② 逻辑设计：E-R模型或IDEFlx模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构，对于关系型的DBMS来说将概念结构转换为数据模式、子模式并进行规范，要给出数据结构的定义，即定义所含的数据项、类型、长度及它们之间的层次或相互关系的表格等。③ 物理设计：对于不同的DBMS，物理环境不同，提供的存储结构与存取方法各不相同。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方式、索引的建立。

（3）编写概要设计文档：
文档主要有：

• 概要设计说明书。
• 数据库设计说明书，主要给出所使用的DBMS简介、数据库的概念模型、逻辑设计、结果。
• 用户手册，对需求分析阶段编写的用户手册进行补充。
• 修订测试计划，对测试策略、方法、步骤提出明确要求。

（4）评审：
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方案的可行性，关键的处理及内外部接口定义正确性、有效性，各部分之间的一致性等都一一进行评审。
概要设计是软件开发中承上启下的一个重要环节，它决定了软件开发的方向和过程。因为软件开发是个复杂过程，需要考虑方方面面的内容，如果没有一个纲领性的文档来组织管理，那么软件开发必然是一团糟。因此，概要设计书挑起了这个重任。

概要设计书应该达到以下4个目标：

• 1．确定开发方案：如果让十个人拿着需求分析书直接进行软件开发，最后结果很可能是开发出十个风格迥异功能相同的系统。这些系统虽然功能相同，但是实现方法各有千秋，通过互相比较即可知道孰优孰劣。但是对于软件的开发来说，我们不可能同时开发出十个软件然后让客户择一而用，这是时间和金钱的浪费。所以必须在软件开发的概要设计阶段，深入调查、全盘考虑和细致比较之后确定开发方案。
• 2．刻画软件的全貌：既然概要设计是在宏观层面对软件进行设计，决定系统的体系结构，系统模块划分和采用的技术路线，并指出实现该系统的关键技术难点等。所以在概要设计书中，着重记录软件的运行环境、功能模块划分和相互关系，而不涉及功能的实现细节
• 3.实现客户到软件开发者的转移：在软件系统的开发前期，一般只有少数几个资深的系统分析师与客户接触，了解需求，形成需求分析文档之后回到软件公司接着做概要设计。概要设计以及其后的阶段都是由软件从业人员着手进行，这些软件从业人员具有相同的领域知识，相互之间用专业术语来分析说明问题有时候会比用自然语言更容易表达和理解，并且不容易产生歧义。概要设计书担当起了客户与软件从业人员之间的桥梁作用，把客户用自然语言描述的需求转化为软件从业人员容易理解的系统功能说明书。
• 4．为详细设计阶段提供可加工的素材：所有的详细设计都是基于概要设计中划分出的模块、组件，并且要遵守概要设计中的各项原则。所以，概要设计是详细设计的素材、依据、标准，是开展详细设计工作的起点。

2.3.2 概要设计书的基本要求

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 程序设计说明
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 尚未解决的问题

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 附件四：硬件设备验收单

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. 经验和教训