ISO标准软件工程文档模板A.doc

(完整版)ISO标准软件工程文档模板A
软件工程项目文档模板

可行性研究报告（ISO标准）

1．引言
1。1 编写目的
可行性研究的目的是为了对问题进行研究，以最小的代价在最短的时间内确定问题是否可解。经过对此项目进行详细调查研究，初拟系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。明确开发风险及其所带来的经济效益.本报告经审核后，交软件经理审查。
1。2 背景
开发软件名称：机票预订系统.
项目任务提出者：彭纪良老师。
项目开发者：计算机08—03班张承美.
用户:中国国际旅游公司。
运行环境:Windows XP。
开发平台：MyEclipse 7。0 Mysql数据库。
系统架构：该系统采用java+jsp完成。
a.［所建议开发的软件系统的名称；]
b。[本项目的任务提出者、开发者、用户及实现该软件的计算站或计算机网络；]
c.［该软件系统同其他系统或其他机构的基本的相互来往关系。］
1。3 定义
MyEclipse 7。0:J2EE可视化开发工具,开发企业管理软件的工具。
Mysql ：SQL数据库
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1。4 参考资料
《软件工程导论》，张海藩，清华大学出版社。
《实用软件工程》，郑人杰等，清华大学出版社。
《Mysql使用手册》
《Java语言程序设计》马皓等,清华大学出版社。
2．可行性研究的前提
2。1 要求
主要功能：为游客提供机票预定服务，方便旅游局的售票工作，提高旅游局的服务质量和服务效率。
性能要求：机场提供的信息必须及时的反映在旅游局的工作平台上。售票系统的定单必须无差错的存储在机场的主服务器上.对服务器上的数据必须进行及时正确的刷新。
输入要求：能够按照客户端所要求的信息格式进行输入，各项数据明确、完整、可靠.
输出要求：能够以界面的形式显示所有的信息,各项数据简单明了。
安全与保密要求:服务器的管理员享有对机场航班信息库及机票信息库和定票信息库的管。
完成期限：预计两周,即截止2011年09月25日.
2.2 目标
1。系统实现后，大大提高旅客的机票预定服务效率。
2.降低售票服务中的错误发生率，减少信息交流的烦琐过程及其带来的开销.
2.3 条件、假定和限制
建议软件寿命：5年。
经费来源:航空公司。
运行环境:MyEclipse 7.0
数据库：Mysql
投入运行最迟时间：2011/09/26
2。4 进行可行性研究的方法
深入旅客中进行调查,亲身参与其中的部分工作，向相关工作人员询问问题，总结其中存在的问题,并进行分析。
根据实际情况进行系统模型的初步建立.
2。5 评价尺度
经济可行性：该系统用于Windows操作系统，所需要的开发软件以及运行软件都是开源的免费的，所以开发成本低，而能够获得的经济效益高。
技术可行性:应用MyEclipse7。0+Mysql这种开发的平台，技术已经很熟悉，其中很多功能模块可以重用前人的成果。
操作可行性：软件能被原有工作人员快速接受。
3．对现有系统的分析
3.1 处理流程和数据流程
[说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示,并加以叙述.］
3.2 工作负荷
只有各单位之间需要密切合作才能保证机票预订系统的合理准确，而现有系统大部分是人工完成的，方便快捷的计算机没有能够充分利用，因此各单位间不能畅通快捷的传递数据,造成效率低，工作量增大。
3。3 费用开支
各部门主要以手工工作为主，所需人员较多,这样使工资开销较高；各单位所用的办公材料消耗较多，造成成本的提高。
3.4 人员
所需工作人员较多，并要求它们之间密切合作。
3.5 设备
[列出现有系统所使用的各种设备。]
3.6 局限性
1．航班班次统计困难。对一些旅客订票后又想退票，最后提交的统计表单很容易混乱，信息有纰漏，而且有时丢失信息。
2．数据保存能力差。数据类型多，数据信息繁杂，保存数据时容易丢失信息。
4．所建议的系统
4。1 对所建议系统的说明
在旅行社中的终端是安装了Windows NT的PC机，主要目的是向机场的服务器传递数据.当顾客在旅行社进行咨询时,终端向服务器发出查询请求,服务器根据航班信息库的实时数据，向终端发送数据，显示在终端的屏幕上。当顾客向售票员定票时，终端向服务器发出详尽的一份定单，服务器核对后，存入定票信息库，并修改机票信息库.当顾客再次来取票时，终端向服务器发出查询定票请求,服务器接收后,查询定票信息库，核对后，传送机票确认表单,终端打印出机票。
4.2 处理流程和数据流程。
［给出所建议系统的处理流程式和数据流程。］
4.3 改进之处
实现了办公自动化,减少了工作流程，提高了工作效率
4.4 影响
1。对设备的影响

2.对软件的影响

3.对系统运行过程的影响

4。 对开发的影响

5。对经费开支的影响

4.4.1.对设备的影响
要求各部门管理部门配置PC机一台，有畅通的连接到服务器的网络连线。
4。4。2。对软件的影响
需要操作系统使用Windows操作系统，并能够与服务器联网.
4.4.3。对用户单位机构的影响
［说明为了建立和运行所建议系统,对用户单位机构、人员的数量和技术水平等方面的全部要求。]
4.4。4.对系统运行过程的影响
1．要求用户旅客必须存入格式正确的数据。
2．服务器端要求不间断运行一直保持与服务器的连接。
3．服务器定期发送指令使数据库进行备份。
4。4.5。对开发的影响
1．要求航空公司提供其业务信息。
2．能够建立好所有航班信息数据库，并能进行更新。
3．要求进行身份验证才能够操作服务器的管理程序
4。4.6.对地点和设施的影响
[说明对建筑物改造的要求及对环境设施的要求。］
4。4.7。对经费开支的影响
开发软件的费用
名称
金额
购买参考资料
150元
聘请美工人员进行优化系统界面
500元
购买第三方软件
400元
4。5 技术条件方面的可能性
[本节应说明技术条件方面的可能性]
5．可选择的其他系统方案
[扼要说明曾考虑过的每一种可选择的系统方案,包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点.]
5。1 可选择的系统方案1
[说明可选择的系统方案1，并说明它末被选中的理由。］
5。2 可选择的系统方案2
［按类似5。1条的方式说明第2个乃至第n个可选择的系统方案。］
［……］
6．投资及效益分析
6。1 支出
[对于所选择的方案,说明所需的费用，如果已有一个现存系统，则包括该系统继续运行期间所需的费用。]
6。1.1 基本建设投资
[包括采购、开发和安装所需的费用.］
6。1。2 其他一次性支出
6.1.3 非一次性支出
[列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用。]
6。2 收益
[对于所选择的方案，说明能够带来的收益,这里所说的收益,表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括:
6。2.1 一次性收益
[说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述。]
6.2。2 非一次性收益
[说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益,包括开支的减少和避免.]
6.2.3 不可定量的收益
［逐项列出无法直用人民币表示的收益。］
6。3 收益/投资比
[求出整个系统生命期的收益/投资比值.］
6。4 投资回收周期
[求出收益的累计数开始超过支出的累计数的时间。］
6.5 敏感性分析
[是指一些关键性因素与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时，对开支和收益的影响最灵敏的范围的估计.]
7．社会因素方面的可能性
7。1.［法律方面的可行性]
7。2。[使用方面的可行性]
8．结论
[在进行可行性研究报告的编制时，必须有一个研究的结论］

需求分析文档（需求规格说明书（ISO标准版））

当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。这是在软件项目过程中最有价值的一个文档。ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。

1．引言
1.1编写的目的
[说明编写这份需求说明书的目的,指出预期的读者。]
1。2背景
a.待开发的系统的名称;
b.本项目的任务提出者、开发者、用户；
c。该系统同其他系统或其他机构的基本的相互来往关系。
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设备
［列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a。处理器型号及内存容量
b。外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量
c。输入及输出设备的型号和数量,联机或脱机
d.数据通信设备的型号和数量
e。功能键及其他专用硬件
4。2支持软件
［列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等.]
4.3接口
［说明该系统同其他系统之间的接口、数据通信协议等.］
4.4控制
［说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源.］

项目计划书

随着现代软件工程思想的普及,迭代的、增量的开发生命周期已经被认识并付诸实践，针对这样的生命周期，其项目计划的格式也需要做出相应的调整。

1。文档概述
[在此对整个文档进行概要性描述，另外还应列出该计划的目标、范围、定义、术语、参考资料等内容。]
1.1 目标
［在此描述本项目计划的目标。］
1.2 范围
[简要说明该计划所覆盖的范围，以及与其相关的项目，与该文档有联系的事物。]
1.3 定义与术语
[在此列出在该计划中所涉及的所有术语、定义、缩写词的解释，这些信息也可以引用项目词汇表来提供。］
1.4 参考资料
［在此应列出项目计划中引用的文档列表，对于引用的每个文档都应该列出其标题、文档编号、日期，并且指出这些文档的来源，以方便该计划的阅读者查找.]
1。5 概述
［说明该计划其它部分所包含的内容，以及文档的组织方式.］
2。项目概述
2.1项目目标
[指出该项目将会交付什么样的产品，能够帮助客户达到什么目标。］
2。2假设与约束
[列举出制定该计划时所做的所有假设，以及列举出对该项目的解决方案的约束性要求，如特定的操作系统平台、特定的时间、特定的经费范围等。］
2.3项目交付物
[具体列出该项目完成后，将交付哪些东西，并可以列出每个交付时间。]
2.4项目计划更新总结
［建议采用表格的形式,将计划的修订过程列出来.]
3。项目组织
3。1项目组织结构
[建议使用组织结构图的形式，将整个项目团队成员之间的关系与职责明确下来，甚至可以包括管理人员、各种委员会等。]
3。2外部联系人
［列出开发组织之外的,所有与项目相关的外部人员的姓名、联系电话等资料。]
3。3角色与职责
［明确项目开发各个任务的负责人或小组。]
4。项目管理计划
4.1项目估计
[给出关于项目成本、进度的估计值,这些估计值将是项目计划制定的基础,也是今后重新评估、修改计划的基础.你可以采用任何估算技术.］
4。2项目计划
4。2。1 阶段计划
［主要包括工作结构分解（WBS）、显示各个阶段或迭代时间安排的甘特图、主要里程碑与其验收标准.］
4.2。2 迭代目标
［如果你采用的是迭代式的开发方法，那么在此列出每次迭代的计划,以及每次迭代计划实现的目标。]
4。2.3 发行计划
[列出软件开发过程中各个中间版本的发行时间,包括演示版、Alpha版、Beta版等.]
4。2.4 项目进度表
［使用甘特图或PERT图等方法,表示出该项目的进度计划。］
4。2.5 项目资源计划
[在此处应列出项目所需的人员、设备等资源情况.应指明所需人员的数量、技能要求，以及如何获取这些资源,是否要对人员进行必要的培训等.]
4。2。6 项目预算
[根据WBS和阶段计划分配成本,得到本项目的财务预算。］
4.3迭代计划
［根据4.2.2小节的目标，具体列出每次迭代的详细计划.该部分可以视需要将其单列为专题计划.]
4.3.1 迭代一
4。3.1。1 计划
[列出此次迭代的时间线、小型里程碑等。］
4.3。1。2 资源
［列出此次迭代所需的人力、财力、设备等资源。］
4.3.1.3 用例
［列出此次迭代将要实现的用例。]
4.3.1。4 评估标准
［列出此次迭代的各项评测标准，包括功能、性能、容量、质量等。]
4。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。其他计划
8.附录
9.索引

数据要求说明书

如果在你的项目中有大量要求数据存储、数据采集等方面的需求，那么你就应该专门将这些需求进行整理,以数据要求说明书的形式表现出来。

1．引言
1.1编写目的
[说明编写这份数据要求说明书的目的，指出预期的读者。]
1。2背景
a.待开发软件系统的名称;
b.列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站或计算机网络系统；
1.3定义
［列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1。4参考资料
[列出有关的参考资料。]
2．数据的逻辑描述
［对数据进行逻辑描述时可把数据分为动态数据和静态数据。]
2.1静态数据
［列出所有作为控制或参考用的静态数据元素。］
2。2动态输入数据
[列出动态输入数据元素。]
2.3动态输出数据
[列出动态输出数据元素。］
2.4内部生成数据
[列出向用户或开发单位中的维护调试人员提供的内部生成数据。］
2.5数据约定
［说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制。对于在设计和开发中确定是临界性的限制更要明确指出.］
3．数据的采集
3.1要求和范围
［按数据元的逻辑分组来说明数据采集的要求和范围,指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。]
3。2输入的承担者
［说明预定的对数据输入工作的承担者.如果输入数据同某一接口软件有关,还应说明该接口软件的来源。]
3。3预期处理
［对数据的采集和预处理过程提出专门的规定,包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量,要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。]
3。4影响
［说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响.］

概要设计文档

这是ISO提供的规范，是最原始的概要设计说明书的编写格式，其适用于结构化设计思想下的软件设计,不过其中还是有很多具有参考价值的内容。

1．引言
1.1编写目的
［说明编写这份概要设计说明书的目的，指出预期的读者.］
1.2背景
a。［待开发软件系统的名称];
b.［列出本项目的任务提出者、开发者、用户。］
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。］
1.4参考资料
[列出有关的参考资料。］
2．总体设计
2.1需求规定
［说明对本系统的主要的输入输出项目、处理的功能性能要求。包括]
2.1.1系统功能
2。1.2系统性能
2。1。2。1精度
2.1.2.2时间特性要求
2.1.2.3可靠性
2。1.2.4灵活性
2.1.3输入输出要求
2.1.4数据管理能力要求
2。1.5故障处理要求
2。1。6其他专门要求
2.2运行环境
［简要地说明对本系统的运行环境的规定。]
2.2。1设备
[列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能。］
2。2.2支持软件
［列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。］
2.2。3接口
［说明该系统同其他系统之间的接口、数据通信协议等］
2。2。4控制
[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。]
2.3基本设计概念和处理流程
[说明本系统的基本设计概念和处理流程，尽量使用图表的形式。]
2.4结构
[给出系统结构总体框图（包括软件、硬件结构框图），说明本系统的各模块的划分，扼要说明每个系统模块的标识符和功能，分层次地给出各模块之间的控制与被控制关系。］
2.5功能需求与系统模块的关系
［本条用一张矩阵图说明各项功能需求的实现同各模块的分配关系。］

[系统模块1]
［系统模块2］
［……]
［系统模块m］
[功能需求1］
√

［功能需求2］

√

[┇]

[功能需求n]

√

√
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数据结构与程序的关系
[说明各个数据结构与访问这些数据结构的各个程序之间的对应关系。]

[程序1］
［程序2］
[……］
[程序m］
［数据结构1]
√

［数据结构2］
√
√

┇

［数据结构n]

√

√
6．系统出错处理设计
6.1出错信息
[用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。]
6.2补救措施
［说明故障出现后可能采取的变通措施。包括：］
a.后备技术 ［说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术。］
b.降效技术 [说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分,例如一个自动系统的降效技术可以是手工操作和数据的人工记录.］
c.恢复及再启动技术 [说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。]
6.3系统维护设计
[说明为了系统维护的方便而在程序内部设计中作出的安排,包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。］

详细设计文档

概要设计通常是项目中专门的人员完成，是对系统的高层描述，而详细设计的任务则通常由每一个任务实施人来完成，其是对某个具体的模块、类等局部元素的设计描述。该模板是ISO推荐的格式，其仍然是以结构化设计为主要思想。

1.引言
1.1编写目的
［说明编写这份详细设计说明书的目的，指出预期的读者。］
1.2背景
a。 ［待开发系统的名称]
b。 ［列出本项目的任务提出者、开发者、用户]
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（标识符)设计说明
［用类似第3条的方式,说明第2个模块乃至第N个模块的设计考虑。］

模块开发说明

该文档将与模块开发卷宗结合使用，卷宗是对整个系统进行整理，而模块开发说明则是对具体的模块进行说明，其作用于归档阶段。

1．标题
［系统名称和标识符]
[模块名称和标识符]
［程序编制员签名]
［卷宗的修改文本序号］
[修改完成日期］
[卷宗序号］
[编排日期]
2．模块开发情况表
3．功能说明
［扼要说明本模块的功能，主要是输入、要求的处理、输出。可以从系统设计说明书中摘录。同时列出在需求说明书中对这些功能的说明的章、条、款。]
4．设计说明
[说明本模块的设计考虑］
5．硬件部分的设计结果
1） 经项目组调试通过的硬件成品1件
2）设计文件:
《原理图》
《PCB图》
《BOM清单》
《可编程器件及烧录进制文件》
《必要测试点波形图或硬件指标评细说明》
《原理详细说明》
《与系统内其他部分接口软硬件详细说明》
这些文件可以附件的形式列后。
6．软件的设计结果
[要给出所产生的本模块的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源程序代码.]
7．测试说明
[说明直接要经过本模块的每一项测试，包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。］
8．复审的结论
［把实际测试的结果，同需求说明书、系统设计说明书中规定的要求进行比较和给出结论.］

软 件 测 试 报 告

项目编号： 项目名称：
任务编号/序号： 工作名称：
程序(ID）： 程序名称：
编程员： 测试完成日期： 年 月 日
测试工程师： 测试完成日期: 年 月 日
1、 安装:
（1）程序运行环境已经正确设定 □ □
2、 程序代码检查:
（1）程序单位首部有程序说明和修改备注 □ □
(2）变量、过程、函数命令符合规则 □ □
（3)程序中有足够的说明信息 □ □
（4）修改注释符合要求 □ □
（5）类库的使用符合要求 □ □
3、 画面及报表格式检查:
（1）画面和报表格式符合规定需求 □ □
（2）程序命名符合格式需求 □ □
（3）画面和报表的字段位置和宽度与设计文档一致 □ □
4、 功能测试：
（1）多画面之间切换正确 □ □
（2）功能键、触发键、按钮、菜单、选择项功能正确 □ □
（3)数据项关联及限制功能正确 □ □
（4）设计文档规定的其它功能
测试内容：
5、 正确性测试：
(1)读/写/删除操作结果正确 □ □
（2）各种组合条件之查询或报表正确 □ □
（3）设计文档规定的其它操作 □ □
测试内容：
6、 可靠性测试：
（1)非法键容错测试
（2)异常字符容错测试
（3）程序负作用检查
(4）残留文件检查
7、 效率测试：
单用户(机型） □ □ 多用户（终端数）□ □
（1） 输入画面效率测试：
延迟时间： □ □ □ □
（2） 报表及查询效率测试：
最小报表时间：□ □ □ □
最大报表时间:□ □ □ □
8、 多用户测试：
终端数： □ □
（1） 随机测试：□ □
（2） 测试次数：□ □
（3） 共享测试：□ □
（4） 同步测试：□ □
9、 其它测试:
测试内容： □ □
测试备忘：

软件维护报告

该表格用于开发部门对软件所做出的维护性修改,将其记录在案，是十分必要的，防止文档的不一致性带来的维护麻烦。

维护案例的标志:__________________________________________________________

维护活动的标志：__________________________________________________________

维护需求的类型：［ ]改正 ［ ]改编 [ ]调整 [ ］扩充

需要维护的原因和维护后产生的影响:

原 因
影 响
需求定义

设计

软件环境

硬件环境

优化

其它

所有维护过的模块和系统的结果及成本/工作：

模块标志
维护的行数不清
工作
(人小时)
源码
文档
总计

总计

对所做维护工作的注释：

维护人签名：

日期:

软件使用手册

为用户提供一个使用手册，是提升软件可用性的必要措施.用户手册的作用是让用户对整个软件系统有一个宏观的认识。解决安装问题,告知运行环境，介绍主要功能等。
1 引言
1。1 编写目的
[说明编写这份用户手册的目的，指出预期的读者.］
1。2背景
[说明：主要包含：]
[a. 这份用户手册所描述的软件系统的名称]
［b. 该软件项目的任务提出者、开发者、用户(或首批用户）及安装此软件的计算中心]
1.3 定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1。4 参考资料
［列出有用的参考资料，如：］
a. 项目的经核准的计划任务书或合同、上级机关的批文
b. 属于本项目的其他已发表文件
c。 本文件中各处引用的文件、资料，包括所要用到的软件开发标准
［列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够取得这些文件资料的来源。］
2 用途
2.1 功能
[