上一篇
下一篇
文档编写标准化 开发团队中的文档编写者
作者:Lynn 日期:2009-02-19
在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。
◇ 可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。
◇ 项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
◇ 软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。
◇ 概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。
◇ 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。
◇ 用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。
◇ 测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
◇ 测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。
◇ 开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
◇ 项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。
◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。
◇ 软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。
◇ 软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。
可行性分析报告
1 引言
1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象。
1.2 项目背景：应包括
● 所建议开发软件的名称
● 项目的任务提出者、开发者、用户及实现软件的单位
● 项目与其他软件或其他系统的关系。
1.3 定义：列出文档中用到的专门术语的定义和缩写词的原文。
1.4 参考资料：列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括
● 项目经核准的计划任务书、合同或上级机关的批文
● 与项目有关的已发表的资料
● 文档中所引用的资料，所采用的软件标准或规范
2 可行性研究的前提
2.1 要求：列出并说明建议开发软件的的基本要求，如
● 功能
● 性能
● 输入/输出
● 基本的数据流程和处理流程
● 安全与保密要求
● 与软件相关的其他系统
● 完成日期
2.2 目标：可包括
● 人力与设备费用的节省
● 处理速度的提高
● 控制精度或生产力的提高
● 管理信息服务的改进
● 决策系统的改进
● 人员工作效率的提高
2.3 条件、假定和限制：可包括
● 建议开发软件运行的最短寿命
● 进行显然方案选择比较的期限
● 经费来源和使用限制
● 法律和政策方面的限制
● 硬件、软件、运行环境和开发环境的条件和限制
● 可利用的信息和资源
● 建议开发软件投入使用的最迟时间
2.4 可行性研究方法
2.5 决定可行性的主要因素
3 对现有系统的分析
3.1 处理流程和数据流程
3.2 工作负荷
3.3 费用支出：如人力、设备、空间、支持性服务、材料等项开支
3.4 人员：列出所需人员的专业技术类别和数量
3.5 设备
3.6 局限性：说明现有系统存在的问题以及为什么需要开发新的系统
4 所建议技术可行性分析
4.1 对系统的简要描述
4.2 与现有系统比较的优越性
4.3 处理流程和数据流程
4.4 采用建议系统可能带来的影响
● 对设备的影响
● 对现有软件的影响
● 对用户的影响
● 对系统运行的影响
● 对开发环境的影响
● 对经费支出的影响
4.5 技术可行性评价:包括
● 在限制条件下，功能目的是否达到
● 利用现有技术，功能目的是否达到
● 对开发人员数量和质量的要求，并说明能否满足
● 在规定的期限内，开发能否完成
5 所建议系统经济可行性分析
5.1 支出
5.2 效益
5.3 收益/投资比
5.4 投资回收周期
5.5 敏感性分析：指一些关键性因素，如：
● 系统生存周期长短
● 系统工作负荷量
● 处理速度要求
● 设备和软件配置变化对支出和效益的影响等的分析
6 社会因素可行性分析
6.1 法律因素：如
● 合同责任
● 侵犯专利权
● 侵犯版权
6.2 用户使用可行性：如
● 用户单位的行政管理
● 工作制度
● 人员素质等能否满足要求
7 其他可供选择的方案
逐个阐明其它可供选择的方案，并重点说明未被推荐的理由。
8 结论意见
● 可着手组织开发
● 需等待若干条件具备后才能开发
● 需对开发目标进行某些修改
● 不能进行或不必进行
● 其它
项目开发计划
1 引言
1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象
1.2 项目背景：应包括
● 项目的委托单位、开发单位和主管部门；
● 该软件系统与其他系统的关系。
1.3 定义：列出文档中用到的专门术语的定义和缩写词的原文
1.4 参考资料：可包括：
● 项目经核准的计划任务书、合同或上级机关的批文
● 文档所引用的资料、规范等
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源；
2 项目概述
2.1 工作内容:简要说明项目的各项主要工作，介绍所开发软件的功能、性能等；若不编写可行性研究报告；则应在本节给出较详细的介绍；
2.2 条件与限制: 阐明为完成项目应具备的条件、开发单位已具备的条件以及尚需创造的条件。必要时还应说明用户及分合同承担的工作、完成期限及其他条件与限制。
2.3 产品
2.3.1程序：列出应交付的程序名称、使用的语言及存储形式。
2.3.2文档：列出应交付的文档。
2.4 运行环境：应包括硬件环境、软件环境。
2.5 服务：阐明开发单位可向用户提供的服务。如人员培训、安装、保修、维护和其他运行支持。
2.6 验收标准
3 实施计划
3.1 任务分解：任务的划分及各项任务的负责人。
3.2 进度：按阶段完成的项目，用图表说明开始时间、完成时间。
3.3 预算
3.4 关键问题：说明可能影响项目的关键问题，如设备条件、技术难点或其他风险因素，并说明对策。
4 人员组织及分工
5 交付期限
6 专题计划要点
如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。
软件需求说明书
1 引言
1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。
1.2 项目背景：应包括
● 项目的委托单位、开心单位和主管部门；
● 该软件系统与其他系统的关系。
1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。
1.4 参考资料：可包括
● 项目经核准的计划任务书、合同或上级机关的批文
● 文档所引用的资料、规范等
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
2 任务概述
2.1 目标
2.2 运行环境
2.3 条件与限制
3 数据描述
3.1 表态数据
3.2 动态数据：包括输入数据和输出数据。
3.3 数据库描述：给出使用数据库的名称和类型。
3.4 数据词典
3.5 数据采集
4 功能需求
4.1功能划分
4.2功能描述
5 性能需求
5.1 数据精确度
5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时间、运行时间等。
5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。
6 运行需求
6.1 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。
6.2 硬件接口
6.3 软件接口
6.4 故障处理
7 其他需求
如可使用性、安全保密、可维护性、可移植性等。
概要设计说明书
1 引言
1.1 写目的：阐明编写概要设计说明书的目的，指明读者对象。
1.2 项目背景：应包括
● 项目的委托单位、开发单位和主管部门
● 该软件系统与其他系统的关系。
1.3 定义：列出本文档中所用到的专门术语的定义和缩写词的愿意。
1.4 参考资料：
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
●项目经核准的计划任务书、合同或上级机关的
批文；项目开发计划；需求规格说明书；测试计划（初稿）；用户操作手册
● 文档所引用的资料、采用的标准或规范。
2 任务概述
2.1 目标
2.2 需求概
2.3 总体说明：说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。
2.4 程序说明：说明系统中每一程序、分程序的细节和特性。
2.4.1 程序1的说明
● 功能：说明程序的功能。
● 方法：说明实现方法。
● 输入：说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。
● 处理：处理特点和目的，如：用图表说明程序的运行的逻辑流程；程序主要转移条件；对程序的约束条件；程序结束时的出口要求；与下一个程序的通信与联结（运行、控制）；由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元；程序运行存储量、类型及存储位置等。
● 输出：程序的输出。
● 接口：本程序与本系统其他部分的接口。
●表格：说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括：表的标识符；使用目的；使用此表的其他程序；逻辑划分，如块或部，不包括表项；表的基本结构；设计安排，包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示。
● 特有的运行性质：说明在用户操作手册中没有提到的运行性质。
2.4.2程序2的说明
与程序1的说明相同。以后的其他各程序的说明相同。
3 操作环境
3.1 设备：逐项说明系统的设备配置及其特性。
3.2 支持软件：列出系统使用的支持软件，包括它们的名称和版本号。
3.3 数据库：说明每个数据库的性质和内容，包括安全考虑。
3.3.1总体特征：如标识符、使用这些数据库的程序、静态数据、动态数据；数据库的存储媒体；程序使用数据库的限制。
3.3.2结构及详细说明
● 说明该数据库的结构，包括其中的记录和项。
● 说明记录的组成，包括首部或控制段、记录体。
● 说明每个记录结构的字段，包括：标记或标号、字段的字符长度和位数、该字段的允许值范围。
● 扩充：说明为记录追加字段的规定。
4 维护过程
4.1 约定：列出该软件系统设计中所使用全部规则和约定，包括：程序、分程序、记录、字段和存储区的标识或标号助记符的使用规则；图表的处理标准、卡片的连接顺序、语句和记号中使用的缩写、出现在图表中的符号名；使用的软件技术标准；标准化的数据元素及其特征。
4.2 验证过程：说明一个程序段修改后，对其进行验证的要求和过程（包括测试程序和数据）及程序周期性验证的过程。
4.3 出错及纠正方法：列出出错状态及其纠正方法。
4.4 专门维护过程：说明文档其他地方没有提到的专门维护过程。如：维护该软件系统的输入输出部分（如数据库）的要求、过程和验证方法；运行程序库维护系统所必需的要求、过程和验证方法；对闰年、世纪变更的所需要的临时性修改等。
4.5 专用维护程序：列出维护软件系统使用的后备技术和专用程序（如文件恢复程序、淘汰过时文件的程序等）的目录，并加以说明，内容包括：维护作业的输入输出要求；输入的详细过程及在硬设备上建立、运行并完成维护作业的操作步骤。
4.6 程序清单和流程图：引用或提供附录给出程序清单和流程图。
软件问题报告
1 登记号
由软件配置管理部门为该报告规定一个唯一的、顺序的编号。
2 登记日期
软件配置管理部门登记该报告的日期。
3 问题发现日期
发现该问题的日期和时间。
4 活动
在哪个阶段发现的问题，分为单元测试、组装测试、确认测试和运行维护。
5 状态
在软件配置记录中维护的动态指示，状态表示有：正在复查"软件问题报告"，以确定将采取什么行动；"软件问题报告"已由指定的人去进行处理；修改已完成，并经过测试，正准备交给主程序库；主程序库已经更新，主程序库修改的重新测试沿未完成；做了重新测试，问题再现；做了重新测试，所做的修改无故障，"软件问题报告"被关闭；留待以后关闭。
6 报告人
填写"软件问题报告"人员的姓名、地址、电话。
7 问题属于什么方面
区分是程序的问题，还是模块的问题，或是数据库的问题，文件的问题。也可能是它们的某种组合。
8 模块/子系统
出现的模块名。如果不知是哪个模块，可标出子系统名，尽量给出细节。
9 修订版本号
出现问题的模块版本。
10 磁带
包含有问题的模块的主程序库的磁带的标识符。
11 数据库
当发现问题时所使用数据库的标识符。
12 文件号
有错误的文件的编号。
13 测试用例
发现错误时所使用测试用例的标识符。
14 硬件
发现错误时所使用的计算机系统的标识。
15 问题描述/影响
问题症兆的详细描述。如果可能，则写明实际问题所在。也要给出该问题对将来测试、接口软件和文件等的影响。
16 附注
记载补充信息。
软件修改报告
1 登记号
由软件配置管理部门为该报告规定的编号。
2 登记日期
软件配置管理部门登记"软件修改报告"的日期。
3 时间
准备好"软件修改报告"的日期。
4 报告人
填写该报告的作者。
5 子系统名
受修改影响的子系统名。
6 模块名
被修改的模块名。
7 "软件问题报告"的编号
被"软件修改报告"处理或部分处理的"软件问题报告"的编号。如果某"软件问题报告"的问题只是部分被处理，则在编号后附以p，如1234p。
8 修改
包括程序修改、文件更新、数据库修改或它们的组合。
9 修改描述
修改的详细描述。如果是文件更新或数据库修改，还要列出文件更新通知或数据库修改申请的标识符。
10 批准人
批准人签字，正式批准进行修改。
11 语句类型
程序修改中涉及到的语句类型，包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存取语句类）。
12 程序名
被修改的程序、文件或数据库的名字。
13 老修订版
当前的版本/修订本标识。
14 新修订版
修改后的版本/修订本标识。
15 数据库
如果申请数据库修改，则给出数据库的标识符。
16 数据库修改报告
数据库修改申请号。
17 文件
如果要求对文件进行修改，则给出文件的名字。
18 文件更新
文件更新通知单的编号。
19 修改是否已测试
指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否。
20 "软件问题报告"是否给出问题的准确描述
回答'是'或'否'。
21 问题注释
准确地叙述要维护的问题。
22 问题源
指明问题来自于哪里，如软件需求说明书、设计说明书、数据库、源程序等。
23 资源
完成修改所需资源的估计，即总的人时数和计算机时间的开销。
文章出处：http://www.diybl.com/course/3_program/gcs/2008617/126082_3.html
一般情况下，每一个开发小组都拥有一个或者更多的专业技术文档编写者，这些编写者负责为他们的产品编写出相关的技术文档。然而，并不是所有的公司能拥有专职的技术文档编写者。如果你必须编写出和你的软件产品联系在一起的技术文档的时候，你应该在你的脑子里记住下面的这些必须进行的事情。
需要进行分析
绝大多数技术文档编写者所做的第一件事情就是进行分析，而分析工作又可以分为两种：对象分析以及任务分析。
对象分析
在进行对象分析的时候，你应该明确这份技术文档是针对哪些人的，也就是什么样的人会阅读你的这份技术文档。此外，你是否正在为公司里别的开发小组编写应用编程接口(API)文件么?别的公司的开发人员是怎么样做的?你应该去了解阅读你所编写技术文档的那些人对于产品开发的内部过程了解多少，并且要知道公司内有哪些数据你可以使用，有哪些你不能使用?
有可能你正在为最终使用产品的用户编写技术性文档。你要弄清楚这些用户是使用计算机的菜鸟还是高手。这些用户是否包括各种不同的类型，或者他们的背景是否要不尽相同呢?如果你对这些情况并不确定的话，这里有一些办法能够帮助你确定这些情况。和你公司里的服务组或者技术支持小组的成员就这些问题进行交谈，这能够帮助你通过他们的经验来了解那些用户的情况。阅读有关此产品或者类似产品的新闻组以及邮件列表也可以让你获得有用的信息。你甚至可以在你们的网络站点上进行问卷调查，或者直接把问卷分发到那些注册过的用户手里来了解情况。不过，在这么做的同时要让这些人明白你是在为他们服务，这样才会获得更多的反馈。
任务分析
任务分析包括对读者将会如何使用这些技术文档进行分析。这份技术文档是为了指导用户如何安装软件产品而编写的么?如果是这样，你就要把精力集中在安装过程中每一步骤的上面。是否是为了方便其他编程者而编写的应用编程接口(API)文件?在这种情况下，你可能会需要一种基准格式来把应用编程接口(API)组件分解成逻辑排列的一些形式，这就让需要阅读这份文件的程序开发设计人员能够轻松的从中获得他们所需要的东西。
有些时候，把任务和相关参考文献结合在一起是一种更好的办法。在指导说明中可以包含参考文献部分，并且这是作为独立的内容而附加在指导说明上边的。另一些好办法是在这种指导说明中加入技巧、警告、注释、表、数据以及其它的一些内容，这样你就可以更生动的描述相关的内容，单纯的动用大量的文字很容易让读者产生沉闷的感觉。
在技术文档中加入图形注释
在技术文档中加入技巧和警告内容是非常重要的，这样能够避免让你的读者产生和别的指导说明书或者参考材料混淆的感觉。看一看别人编写的手册或者技术说明书，你就能够获得大量的范例。典型的情况是，在你所添加的技巧和警告周围加上边框，或者用醒目的下划线标注出来，对你的读者来说都是很有帮助的。在文章中加入图形也是一种好办法，尤其是你在向读者对某些事情进行警告的时候，图形化的内容能够让你所警告的东西变得更清晰让能够产生深刻的印象。
注意技术文档的措辞
对于技术性文档来说，另一个重要的方面就是你的措辞。如果你的文档所针对的对象是入门者或者没有技术背景的人，你必须对你的这些读者所拥有的知识进行分析，这是十分基本而且重要的。因为你不知道这些读者对你所引用的缩写词汇是否真的明白。为了避免你的读者对这些词汇感到头疼，一定要使用完整拼写的词汇，或者附加上一份缩写词汇表。有没有更简单的办法呢?公司里负责市场的副总裁很可能并不清楚什么是API，但是如果你把API写成“一套能够帮助软件设计人员让他们开发的软件能够同我们所开发的软件进行对话的工具”，这么写看上去很费笔墨，但是，这样却能够让那些没有技术背景的读者很好的掌握API的含义。
对于那些专业的技术人员来说，你就可以使用那些专业术语了(也就是说，你可以使用堆栈、线程等等词汇了)，并且写出这些词汇的同时，并不需要你再特别的解释一番。不过，如果你比不确定你所使用的一个缩写词是被广泛认可的，那么，一定要在后边把这个缩写词解释清楚，并跟上完成的拼写。不要过分使用那些冗长的词汇以显示你的词汇量。尽量使用简单的能够说明问题的措辞;这么做更能够给读者留些深刻的印象，而不是让你的读者把时间浪费在查字典上。对于专业技术人员以及非专业技术人员来说，你都应该这么去编写文件，这样才能收到良好的效果。
保持文档的前后一致性
最后，让我们来看一看保持文档内容一致性的重要性。你在文章的开始部分就应该决定使用米制长度单位还是使用英制长度单位。一些细微的地方你都应该做到前后统一，比如说，在文章前边使用了5MB，那么在文章后面就不应该出现5 MB;你也得决定是使用5英尺还是使用5'，等等这些问题你必须都要注意。当你使用到变量的时候，会出现这种有趣的情况：在使用变量内容的时候，你是会使用“variable = definition of value”的形式，还是会使用“variable = example value”的形式?
另外一个需要注意的事情是你对字体的使用，因为用户也许会需要做一些输入的工作。一些人会使用等宽字体，例如Courier，来让用户输入资料。还有要统一的是使用“下划线”还是使用“粗体字”。具体使用哪一种形式这可以由你所在职业领域所习惯所决定，但是通常来说，只要在你的文章中保持前后用法的一致性就可以了。在你进行文件编写的时候，边上应该放上一张伸手可及的白纸，以便于你纪录这些前后应该保持一致的用法以便于随后查询。
结论
能够有一位专职的技术文档编写作者来创作你所需要的技术性文档是非常好的事情，然而，有的时候出于某些原因，只有让软件开发设计人员自己动手来编写这些技术文档。虽然不是专业的技术文档编写者，但仍旧应该注意上面提到的那些问题，并且切实的把这些细节和注意事项都应用到技术文档的编写中去，这样才能够为你和你的用户们编写出随时可用并且易于阅读的技术文档。
来源：ZDNet
◇ 可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。
◇ 项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
◇ 软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。
◇ 概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。
◇ 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。
◇ 用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。
◇ 测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
◇ 测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。
◇ 开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
◇ 项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。
◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。
◇ 软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。
◇ 软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。
可行性分析报告
1 引言
1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象。
1.2 项目背景：应包括
● 所建议开发软件的名称
● 项目的任务提出者、开发者、用户及实现软件的单位
● 项目与其他软件或其他系统的关系。
1.3 定义：列出文档中用到的专门术语的定义和缩写词的原文。
1.4 参考资料：列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括
● 项目经核准的计划任务书、合同或上级机关的批文
● 与项目有关的已发表的资料
● 文档中所引用的资料，所采用的软件标准或规范
2 可行性研究的前提
2.1 要求：列出并说明建议开发软件的的基本要求，如
● 功能
● 性能
● 输入/输出
● 基本的数据流程和处理流程
● 安全与保密要求
● 与软件相关的其他系统
● 完成日期
2.2 目标：可包括
● 人力与设备费用的节省
● 处理速度的提高
● 控制精度或生产力的提高
● 管理信息服务的改进
● 决策系统的改进
● 人员工作效率的提高
2.3 条件、假定和限制：可包括
● 建议开发软件运行的最短寿命
● 进行显然方案选择比较的期限
● 经费来源和使用限制
● 法律和政策方面的限制
● 硬件、软件、运行环境和开发环境的条件和限制
● 可利用的信息和资源
● 建议开发软件投入使用的最迟时间
2.4 可行性研究方法
2.5 决定可行性的主要因素
3 对现有系统的分析
3.1 处理流程和数据流程
3.2 工作负荷
3.3 费用支出：如人力、设备、空间、支持性服务、材料等项开支
3.4 人员：列出所需人员的专业技术类别和数量
3.5 设备
3.6 局限性：说明现有系统存在的问题以及为什么需要开发新的系统
4 所建议技术可行性分析
4.1 对系统的简要描述
4.2 与现有系统比较的优越性
4.3 处理流程和数据流程
4.4 采用建议系统可能带来的影响
● 对设备的影响
● 对现有软件的影响
● 对用户的影响
● 对系统运行的影响
● 对开发环境的影响
● 对经费支出的影响
4.5 技术可行性评价:包括
● 在限制条件下，功能目的是否达到
● 利用现有技术，功能目的是否达到
● 对开发人员数量和质量的要求，并说明能否满足
● 在规定的期限内，开发能否完成
5 所建议系统经济可行性分析
5.1 支出
5.2 效益
5.3 收益/投资比
5.4 投资回收周期
5.5 敏感性分析：指一些关键性因素，如：
● 系统生存周期长短
● 系统工作负荷量
● 处理速度要求
● 设备和软件配置变化对支出和效益的影响等的分析
6 社会因素可行性分析
6.1 法律因素：如
● 合同责任
● 侵犯专利权
● 侵犯版权
6.2 用户使用可行性：如
● 用户单位的行政管理
● 工作制度
● 人员素质等能否满足要求
7 其他可供选择的方案
逐个阐明其它可供选择的方案，并重点说明未被推荐的理由。
8 结论意见
● 可着手组织开发
● 需等待若干条件具备后才能开发
● 需对开发目标进行某些修改
● 不能进行或不必进行
● 其它
项目开发计划
1 引言
1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象
1.2 项目背景：应包括
● 项目的委托单位、开发单位和主管部门；
● 该软件系统与其他系统的关系。
1.3 定义：列出文档中用到的专门术语的定义和缩写词的原文
1.4 参考资料：可包括：
● 项目经核准的计划任务书、合同或上级机关的批文
● 文档所引用的资料、规范等
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源；
2 项目概述
2.1 工作内容:简要说明项目的各项主要工作，介绍所开发软件的功能、性能等；若不编写可行性研究报告；则应在本节给出较详细的介绍；
2.2 条件与限制: 阐明为完成项目应具备的条件、开发单位已具备的条件以及尚需创造的条件。必要时还应说明用户及分合同承担的工作、完成期限及其他条件与限制。
2.3 产品
2.3.1程序：列出应交付的程序名称、使用的语言及存储形式。
2.3.2文档：列出应交付的文档。
2.4 运行环境：应包括硬件环境、软件环境。
2.5 服务：阐明开发单位可向用户提供的服务。如人员培训、安装、保修、维护和其他运行支持。
2.6 验收标准
3 实施计划
3.1 任务分解：任务的划分及各项任务的负责人。
3.2 进度：按阶段完成的项目，用图表说明开始时间、完成时间。
3.3 预算
3.4 关键问题：说明可能影响项目的关键问题，如设备条件、技术难点或其他风险因素，并说明对策。
4 人员组织及分工
5 交付期限
6 专题计划要点
如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。
软件需求说明书
1 引言
1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。
1.2 项目背景：应包括
● 项目的委托单位、开心单位和主管部门；
● 该软件系统与其他系统的关系。
1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。
1.4 参考资料：可包括
● 项目经核准的计划任务书、合同或上级机关的批文
● 文档所引用的资料、规范等
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
2 任务概述
2.1 目标
2.2 运行环境
2.3 条件与限制
3 数据描述
3.1 表态数据
3.2 动态数据：包括输入数据和输出数据。
3.3 数据库描述：给出使用数据库的名称和类型。
3.4 数据词典
3.5 数据采集
4 功能需求
4.1功能划分
4.2功能描述
5 性能需求
5.1 数据精确度
5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时间、运行时间等。
5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。
6 运行需求
6.1 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。
6.2 硬件接口
6.3 软件接口
6.4 故障处理
7 其他需求
如可使用性、安全保密、可维护性、可移植性等。
概要设计说明书
1 引言
1.1 写目的：阐明编写概要设计说明书的目的，指明读者对象。
1.2 项目背景：应包括
● 项目的委托单位、开发单位和主管部门
● 该软件系统与其他系统的关系。
1.3 定义：列出本文档中所用到的专门术语的定义和缩写词的愿意。
1.4 参考资料：
● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
●项目经核准的计划任务书、合同或上级机关的
批文；项目开发计划；需求规格说明书；测试计划（初稿）；用户操作手册
● 文档所引用的资料、采用的标准或规范。
2 任务概述
2.1 目标
2.2 需求概
2.3 总体说明：说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。
2.4 程序说明：说明系统中每一程序、分程序的细节和特性。
2.4.1 程序1的说明
● 功能：说明程序的功能。
● 方法：说明实现方法。
● 输入：说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。
● 处理：处理特点和目的，如：用图表说明程序的运行的逻辑流程；程序主要转移条件；对程序的约束条件；程序结束时的出口要求；与下一个程序的通信与联结（运行、控制）；由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元；程序运行存储量、类型及存储位置等。
● 输出：程序的输出。
● 接口：本程序与本系统其他部分的接口。
●表格：说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括：表的标识符；使用目的；使用此表的其他程序；逻辑划分，如块或部，不包括表项；表的基本结构；设计安排，包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示。
● 特有的运行性质：说明在用户操作手册中没有提到的运行性质。
2.4.2程序2的说明
与程序1的说明相同。以后的其他各程序的说明相同。
3 操作环境
3.1 设备：逐项说明系统的设备配置及其特性。
3.2 支持软件：列出系统使用的支持软件，包括它们的名称和版本号。
3.3 数据库：说明每个数据库的性质和内容，包括安全考虑。
3.3.1总体特征：如标识符、使用这些数据库的程序、静态数据、动态数据；数据库的存储媒体；程序使用数据库的限制。
3.3.2结构及详细说明
● 说明该数据库的结构，包括其中的记录和项。
● 说明记录的组成，包括首部或控制段、记录体。
● 说明每个记录结构的字段，包括：标记或标号、字段的字符长度和位数、该字段的允许值范围。
● 扩充：说明为记录追加字段的规定。
4 维护过程
4.1 约定：列出该软件系统设计中所使用全部规则和约定，包括：程序、分程序、记录、字段和存储区的标识或标号助记符的使用规则；图表的处理标准、卡片的连接顺序、语句和记号中使用的缩写、出现在图表中的符号名；使用的软件技术标准；标准化的数据元素及其特征。
4.2 验证过程：说明一个程序段修改后，对其进行验证的要求和过程（包括测试程序和数据）及程序周期性验证的过程。
4.3 出错及纠正方法：列出出错状态及其纠正方法。
4.4 专门维护过程：说明文档其他地方没有提到的专门维护过程。如：维护该软件系统的输入输出部分（如数据库）的要求、过程和验证方法；运行程序库维护系统所必需的要求、过程和验证方法；对闰年、世纪变更的所需要的临时性修改等。
4.5 专用维护程序：列出维护软件系统使用的后备技术和专用程序（如文件恢复程序、淘汰过时文件的程序等）的目录，并加以说明，内容包括：维护作业的输入输出要求；输入的详细过程及在硬设备上建立、运行并完成维护作业的操作步骤。
4.6 程序清单和流程图：引用或提供附录给出程序清单和流程图。
软件问题报告
1 登记号
由软件配置管理部门为该报告规定一个唯一的、顺序的编号。
2 登记日期
软件配置管理部门登记该报告的日期。
3 问题发现日期
发现该问题的日期和时间。
4 活动
在哪个阶段发现的问题，分为单元测试、组装测试、确认测试和运行维护。
5 状态
在软件配置记录中维护的动态指示，状态表示有：正在复查"软件问题报告"，以确定将采取什么行动；"软件问题报告"已由指定的人去进行处理；修改已完成，并经过测试，正准备交给主程序库；主程序库已经更新，主程序库修改的重新测试沿未完成；做了重新测试，问题再现；做了重新测试，所做的修改无故障，"软件问题报告"被关闭；留待以后关闭。
6 报告人
填写"软件问题报告"人员的姓名、地址、电话。
7 问题属于什么方面
区分是程序的问题，还是模块的问题，或是数据库的问题，文件的问题。也可能是它们的某种组合。
8 模块/子系统
出现的模块名。如果不知是哪个模块，可标出子系统名，尽量给出细节。
9 修订版本号
出现问题的模块版本。
10 磁带
包含有问题的模块的主程序库的磁带的标识符。
11 数据库
当发现问题时所使用数据库的标识符。
12 文件号
有错误的文件的编号。
13 测试用例
发现错误时所使用测试用例的标识符。
14 硬件
发现错误时所使用的计算机系统的标识。
15 问题描述/影响
问题症兆的详细描述。如果可能，则写明实际问题所在。也要给出该问题对将来测试、接口软件和文件等的影响。
16 附注
记载补充信息。
软件修改报告
1 登记号
由软件配置管理部门为该报告规定的编号。
2 登记日期
软件配置管理部门登记"软件修改报告"的日期。
3 时间
准备好"软件修改报告"的日期。
4 报告人
填写该报告的作者。
5 子系统名
受修改影响的子系统名。
6 模块名
被修改的模块名。
7 "软件问题报告"的编号
被"软件修改报告"处理或部分处理的"软件问题报告"的编号。如果某"软件问题报告"的问题只是部分被处理，则在编号后附以p，如1234p。
8 修改
包括程序修改、文件更新、数据库修改或它们的组合。
9 修改描述
修改的详细描述。如果是文件更新或数据库修改，还要列出文件更新通知或数据库修改申请的标识符。
10 批准人
批准人签字，正式批准进行修改。
11 语句类型
程序修改中涉及到的语句类型，包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存取语句类）。
12 程序名
被修改的程序、文件或数据库的名字。
13 老修订版
当前的版本/修订本标识。
14 新修订版
修改后的版本/修订本标识。
15 数据库
如果申请数据库修改，则给出数据库的标识符。
16 数据库修改报告
数据库修改申请号。
17 文件
如果要求对文件进行修改，则给出文件的名字。
18 文件更新
文件更新通知单的编号。
19 修改是否已测试
指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否。
20 "软件问题报告"是否给出问题的准确描述
回答'是'或'否'。
21 问题注释
准确地叙述要维护的问题。
22 问题源
指明问题来自于哪里，如软件需求说明书、设计说明书、数据库、源程序等。
23 资源
完成修改所需资源的估计，即总的人时数和计算机时间的开销。
文章出处：http://www.diybl.com/course/3_program/gcs/2008617/126082_3.html
一般情况下，每一个开发小组都拥有一个或者更多的专业技术文档编写者，这些编写者负责为他们的产品编写出相关的技术文档。然而，并不是所有的公司能拥有专职的技术文档编写者。如果你必须编写出和你的软件产品联系在一起的技术文档的时候，你应该在你的脑子里记住下面的这些必须进行的事情。
需要进行分析
绝大多数技术文档编写者所做的第一件事情就是进行分析，而分析工作又可以分为两种：对象分析以及任务分析。
对象分析
在进行对象分析的时候，你应该明确这份技术文档是针对哪些人的，也就是什么样的人会阅读你的这份技术文档。此外，你是否正在为公司里别的开发小组编写应用编程接口(API)文件么?别的公司的开发人员是怎么样做的?你应该去了解阅读你所编写技术文档的那些人对于产品开发的内部过程了解多少，并且要知道公司内有哪些数据你可以使用，有哪些你不能使用?
有可能你正在为最终使用产品的用户编写技术性文档。你要弄清楚这些用户是使用计算机的菜鸟还是高手。这些用户是否包括各种不同的类型，或者他们的背景是否要不尽相同呢?如果你对这些情况并不确定的话，这里有一些办法能够帮助你确定这些情况。和你公司里的服务组或者技术支持小组的成员就这些问题进行交谈，这能够帮助你通过他们的经验来了解那些用户的情况。阅读有关此产品或者类似产品的新闻组以及邮件列表也可以让你获得有用的信息。你甚至可以在你们的网络站点上进行问卷调查，或者直接把问卷分发到那些注册过的用户手里来了解情况。不过，在这么做的同时要让这些人明白你是在为他们服务，这样才会获得更多的反馈。
任务分析
任务分析包括对读者将会如何使用这些技术文档进行分析。这份技术文档是为了指导用户如何安装软件产品而编写的么?如果是这样，你就要把精力集中在安装过程中每一步骤的上面。是否是为了方便其他编程者而编写的应用编程接口(API)文件?在这种情况下，你可能会需要一种基准格式来把应用编程接口(API)组件分解成逻辑排列的一些形式，这就让需要阅读这份文件的程序开发设计人员能够轻松的从中获得他们所需要的东西。
有些时候，把任务和相关参考文献结合在一起是一种更好的办法。在指导说明中可以包含参考文献部分，并且这是作为独立的内容而附加在指导说明上边的。另一些好办法是在这种指导说明中加入技巧、警告、注释、表、数据以及其它的一些内容，这样你就可以更生动的描述相关的内容，单纯的动用大量的文字很容易让读者产生沉闷的感觉。
在技术文档中加入图形注释
在技术文档中加入技巧和警告内容是非常重要的，这样能够避免让你的读者产生和别的指导说明书或者参考材料混淆的感觉。看一看别人编写的手册或者技术说明书，你就能够获得大量的范例。典型的情况是，在你所添加的技巧和警告周围加上边框，或者用醒目的下划线标注出来，对你的读者来说都是很有帮助的。在文章中加入图形也是一种好办法，尤其是你在向读者对某些事情进行警告的时候，图形化的内容能够让你所警告的东西变得更清晰让能够产生深刻的印象。
注意技术文档的措辞
对于技术性文档来说，另一个重要的方面就是你的措辞。如果你的文档所针对的对象是入门者或者没有技术背景的人，你必须对你的这些读者所拥有的知识进行分析，这是十分基本而且重要的。因为你不知道这些读者对你所引用的缩写词汇是否真的明白。为了避免你的读者对这些词汇感到头疼，一定要使用完整拼写的词汇，或者附加上一份缩写词汇表。有没有更简单的办法呢?公司里负责市场的副总裁很可能并不清楚什么是API，但是如果你把API写成“一套能够帮助软件设计人员让他们开发的软件能够同我们所开发的软件进行对话的工具”，这么写看上去很费笔墨，但是，这样却能够让那些没有技术背景的读者很好的掌握API的含义。
对于那些专业的技术人员来说，你就可以使用那些专业术语了(也就是说，你可以使用堆栈、线程等等词汇了)，并且写出这些词汇的同时，并不需要你再特别的解释一番。不过，如果你比不确定你所使用的一个缩写词是被广泛认可的，那么，一定要在后边把这个缩写词解释清楚，并跟上完成的拼写。不要过分使用那些冗长的词汇以显示你的词汇量。尽量使用简单的能够说明问题的措辞;这么做更能够给读者留些深刻的印象，而不是让你的读者把时间浪费在查字典上。对于专业技术人员以及非专业技术人员来说，你都应该这么去编写文件，这样才能收到良好的效果。
保持文档的前后一致性
最后，让我们来看一看保持文档内容一致性的重要性。你在文章的开始部分就应该决定使用米制长度单位还是使用英制长度单位。一些细微的地方你都应该做到前后统一，比如说，在文章前边使用了5MB，那么在文章后面就不应该出现5 MB;你也得决定是使用5英尺还是使用5'，等等这些问题你必须都要注意。当你使用到变量的时候，会出现这种有趣的情况：在使用变量内容的时候，你是会使用“variable = definition of value”的形式，还是会使用“variable = example value”的形式?
另外一个需要注意的事情是你对字体的使用，因为用户也许会需要做一些输入的工作。一些人会使用等宽字体，例如Courier，来让用户输入资料。还有要统一的是使用“下划线”还是使用“粗体字”。具体使用哪一种形式这可以由你所在职业领域所习惯所决定，但是通常来说，只要在你的文章中保持前后用法的一致性就可以了。在你进行文件编写的时候，边上应该放上一张伸手可及的白纸，以便于你纪录这些前后应该保持一致的用法以便于随后查询。
结论
能够有一位专职的技术文档编写作者来创作你所需要的技术性文档是非常好的事情，然而，有的时候出于某些原因，只有让软件开发设计人员自己动手来编写这些技术文档。虽然不是专业的技术文档编写者，但仍旧应该注意上面提到的那些问题，并且切实的把这些细节和注意事项都应用到技术文档的编写中去，这样才能够为你和你的用户们编写出随时可用并且易于阅读的技术文档。
来源：ZDNet
文章来自: 
引用通告: 
Tags: 评论: 0 | 引用: 0 | 查看次数: -
发表评论
