如何制定一份有效的，可行性高的测试规范？（08-09-22）（获奖名单已公布）

默默巫

提高测试团队工作的规范性也是保证软件质量的必要手段，所以每个公司都应该制定自己的测试规范，这份规范应该是贯穿整个软件开发周期的，也是所有开发和测试都应该遵循的，如何制定这样一份规范让大家都愿意遵其行事呢？这样的规范具体应该包含哪些内容呢？



感谢会员xazaj提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	zhuzx	当当购物卡50元	33#
二等奖	archonwang	300论坛积分	2#
	huguxiang		7#
三等奖	baiyuxuan	100论坛积分	18#
	fire83617		32#
	prettyyang		54#

archonwang

占个位置，改天答

=====================================================

【2008-09-25】抽空就该问题做一个简单的说明。


如何制定一份有效的，可行性高的测试规范？

书写一份有效，可行性高的规范，我觉得需要注意以下几个方面：
1. 规范在内容上要系统全面。
关于测试的方式、方法、种类、流程等等我想自然不必再赘述了。但是如何把这些方式、方法、种类、流程串接起来形成一个体系却是值得我们每一个深入思考的问题。一份规范的影响面及其适应的情况毕竟来说还是很局限的。所以，我认为，从体系框架上构建是产生有效且高可行度规范的充分条件，皮之不存毛将焉附？第二，在规范的内容上必须要相对比较全面，至少能涵盖到目前所从事的主要的测试工作。第三，系统性的表述是规范的基本要求--一般我们都是要求使用结构化的语言，框架式进行编写，务必使构成该规范的每个部分都清晰明了。

2. 内容的细分项目要求具备一定的可操作性。
所谓规范的可操作性，即是要求可量化的量化，不能量化的具体化。很多同仁定规范时，对规范所要求的工作内容不够明确，不是雾里看花，就是“空对空”。评审的人一头雾水，执行的人无所适从，当然其可操作性必然不佳。尽量要求规范中的操作步骤明确，实现目标量化或具体化（建议参考SMART原则制定）。

3. 内容中所引用的术语、行业名词必须规范且统一。
很有必要的注意事项，团队内的成员来自不同的地方，每个人对相同的测试事务所持的观点未必相同，规范的作用之一就是尽量减少差异化，以期不同人做相同事能得到一个尽可能一样的结果。所以在制定规范时使用统一的口径是很必要的，以免产生歧义和误差。

4. 制定规范一定要注意适应当前企业的实际和现状。
也许这一点才是对可行性要求的最基本的要素。之前，包括我自己在内，对规范的理解也仅限于从网络上获得一些已成形的内容，到最后发现却根本不合适。比如说，一个只有三两个人的测试团队，就要求做自动化框架体系的构建--往往不切实际是一切规范失效的最根本原因。较好的规范应该是具备可实现性的，能在一定时期内努力后，可达到的目标。

接下来，补充几点说明：
1. 做规范的基本思想就是建立标准，以教育、培训、参照、考评和持续优化，使一切事可控并习惯化，以实现生产力提升，获得企业资源配置最优化与企业利润最大化。所以，将对规范的执行纳入绩效考核体系是必然的。有效无效，可行性高还是不高，我想不是靠几个大脑想就能实现的，最后还是要由实践来检验。
2. 既然是规范，必然有其缺失错漏，所以规范的有效及可行性判断必然是需要经过循序渐进、持续优化的过程，没有一步到位。不同的团队组织，对于规范的态度是积极执行，及时响应与否将决定规范的价值。所以，我想请大家记得这句话：好的规范是整个团队、组织一步一个脚印，不断整理、总结、归纳做出来的，不是拍拍脑袋想出来的。其所谓的有效、可行性也是基于此而言--大家万勿舍本求末。

[ 本帖最后由 archonwang 于 2008-9-25 15:58 编辑 ]

free_xiaoyu

占个沙发

一马平川

版主你这个题目很好，但是感觉离我们很遥远，毕竟我们不是测试经理，唉。。。。。

bzfyhfyh

呵呵，赞成  一马平川  的说法。
期待着精彩的对答。

开心网

到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

huguxiang

我觉得测试规范应该包括两部分的规范，第一是测试内容的规范，第二是测试流程的规范。
1.        测试内容的规范
测试内容依我的理解包括文档、程序、数据。
文档规范主要指的是需求说明书的规范和设计说明书的规范，至于这两个文档规范在《软件评测师教程》里面有详细介绍，我把它粘贴出来吧，当然每个公司还可以根据具体的情况特殊考虑。
G:\QQ截图未命名.bmp
上面已经说到了，公司可以根据具体情况特殊考虑，可以删除或增加相关的规范，应该由公司高层、设计师、开发部、测试部分别派代表来开会讨论并制定规范，规范一旦通过评测制定，就由行政部发布执行。有了文档规范之后，测试部根据文档规范评测相关文档。
程序规范，即软件编码规范。这个规范在《软件评测师教程》中也有写到，而且总结得比较好。
A．        源程序文档化 包括以下几方面的规范：符号名的命名、程序的注释、标准的书写格式等
B．        数据说明 包括以下几方面的规范：数据说明的次序、说明语句中变量安排有序化、使用注释说明复杂数据结构等
C．        语句结构 比如:在一行内写一条语句、程序清晰等
D．        输入/输出
等等。。。。。。
   数据规范，一般是基础数据有相当严格的规范，下面举一个我们公司数据规范的例子，如下表所示：
代码        名称
HG001        合格
HG002        不合格
TY001        检验特征项值不符合标准
TY002        检验特征项值超出规定范围
ZM001        褶皱
ZM002        裂纹
ZM003        杂物
ZM004        破损
ZM005        色泽不一致
（注意看代码，是通过设计部统一给名称编码的，现在不能变，以后也不能变，录入数据的时候必须按照这个规范来录）
2.        测试流程规范 测试流程一旦制定了规范就不能经常变动，测试流程的规范也应该由公司高层、设计师、开发部、测试部派出代表开会议定，得到大家认同的规范才能有效的执行。各个行业、每一个公司都有自己独特的流程规范，但是总的应该包括一下几个方面的规范：
A．        测试用例的规范、bug的规范等等------规范测试人员的行为
B．        提交功能界面测试文档规范（一般测试部会发格式文档给开发部填写，开发部发邮件提交功能界面给测试部）、修改bug规范、配置文件规范等等------规范开发人员的行为
。。。。。。
这些一起形成了软件开发周期的规范，如果是刚试用这些规范，可以规定一个月的试用期，看这些规范在实际开发周期中是否适用，什么都要经过一个试验的过程，慢慢就会形成一种风气，大家都会按照这个规范行事。
呵呵 经验之谈 请高手指点

[ 本帖最后由 huguxiang 于 2008-9-24 10:22 编辑 ]

天才精英

我们很期待高手的精彩回答。

测试能手

原帖由 开心网 于 2008-9-23 11:58 发表
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

这个问题确实讲述不是很清楚，建议清晰一下。估计出题人是想知道：测试规范具体应该包含哪些内容？而如何制定揣测不是重点。

翱翔太空

难怪答题的高手较少，呵呵！！！请版主尽快确认，谢谢啦！！！

默默巫

原帖由 开心网 于 2008-9-23 11:58 发表
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

我觉得虽然是两个疑问？但两者之间是紧密结合的，可以并作一起回答．

xazaj

原帖由 开心网 于 2008-9-23 11:58 发表
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

确认“开心网”这位朋友的疑问：
直接回答：“测试规范具体应该包含哪些内容呢？”即可， 其实这两个问题回答的重点是一样。
因为测试规范是测试部门提出，但是执行者可能会包括开发等其他部门，所以可行性也是内容的重点。

锅仔

占个位子，一会回答

sixsigmay

占个位置看答案

inksong

除了有测试规范，应该还有开发规范，因为不仅仅有测试，还有开发，所以这些都是贯穿整个软件工程的。当然作为我门测试的人来说，可能关注的点在测试上面，但是开发我门也不能遗忘。

inksong

按照规范来说，应该还包括开发规范，下面是开发，和测试的规范。

1．项目开发计划的规范
2．概要设计说明书的规范
3．软件需求说明书的规范
4．详细设计说明书的规范
5．可行性研究报告的规范
6．模块开发卷宗的规范
7．数据库设计说明书的规范
8．数据要求说明书的规范
9．文件给制实施规定的实例的规范
10．开发进度月报的规范
11．项目开发总结报告的规范
12．用户手册
13．操作手册的规范
14．测试计划的规范
15．测试分析报告的规范

（一）项目开发计划的规范
。1引言
1.1编写目的
说明：编写这份软件项目开发计划的目的，并指出预期的读者。
1.2 背景
        说明：
a.        待开发的软件系统的名称；
b.        本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c.        该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
        列出本文件中用到的专门术语的定义和外文的首字母组词的原词组。
1.4参考资料
        列出用得着的参考资料，如：
a.        本项目的经核准的计划任务书和合同、上级机关的批文；
b.        属于本项目的其他已发表的文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2项目概述
2.1工作内容
        简要地说明在本项目的开发中须进行的各项主要工作。
2.2主要参加人员
        扼要说明参加本项目开发的主要人员的情况，包括他们的技术水平。
2.3产品
2.3.1程序
        列出须移交给用户的程序的名称、所用地编程语言及存储程序的媒体形式，并通过引用相关文件，逐项说明其功能和能力。
2.3.2文件
        列出须移交用户的每种文件的名称及内容要点。
2.3.3服务
        列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。
2.3.4非移交的产品
        说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。
2.4验收标准
        对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。
2.5完成项目的最迟期限
2.6本计划的批准者和批准日期
3实施计划
3.1工作任务的分解与人员分工
        对于项目开发中需要完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。
3.2接口人员
        说明负责接口工作的人员及他们的职责，包括：
a.        负责本项目同用户的接口人员；
b.        负责本项目同本单位各管理机构，如合同计划管理部门、财务部门、质量管理部门等的接口人员；
c.        负责本项目同个份合同负责单位的接口人员等。
3.3进度
        对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务的预定开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（即所谓“里程碑）。
3.4预算
        逐项列出本开发项目所需要的劳务（包括人员的数量和时间）以及经费的预算（包括办公费、差旅费、机时费、资料费、通讯设备和专用设备的租金等）和来源。
3.5关键问题
        逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。
4支持条件
        说明为支持本项目的开发所需要的各种条件和设施。
4.1计算机系统支持
        逐项列出开发中和运行时所需的计算机系统支持，包括计算机、外围设备、通讯设备、模拟器、编译（或汇编）程序、操作系统、数据管理程序包、数据存储能力和测试支持能力等，逐项给出有关到货日期、使用时间的要求。
4.2需由用户承担的工作
        逐项列出需要用户承担的工作和完成期限。包括需由用户提供的条件及提供时间。
4.3由外单位提供的条件
        逐项列出需要外单位分合同承包者承担的工作和完成的时间，包括需要由外单位提供的条件和提供的时间。
5专题计划要点
        说明本项目开发中需制定的各个专题计划（如分合同计划、开发人员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等）的要点。

inksong

概要设计说明书的规范
1引言
1.1编写目的
说明编写这份概要设计说明书的目的，指出预期的读者。
1.2背景
说明：
a.        待开发软件系统的名称；
b.        列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站（中心）。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考文件，如：
a.        本项目的经核准的计划任务书或合同，上级机关的批文；
b.        属于本项目的其他已发表文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2总体设计
2.1需求规定
说明对本系统的主要的输入输出项目、处理的功能性能要求，详细的说明可参见附录C。
2.2运行环境
简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定，详细说明参见附录C。
2.3基本设计概念和处理流程
说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
2.4结构
用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系.
2.5功能器求与程序的关系
本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系：
        程序1        程序2        ……        程序n
功能需求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数据结构与程序的关系
说明各个数据结构与访问这些数据结构的形式:
6系统出错处理设计
6.1出错信息
用一览表的方式说朗每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。
6.2补救措施
说明故障出现后可能采取的变通措施，包括：
a.        后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；
b.        降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；
c.        恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。
6.3系统维护设计
说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系，可采用如下的矩阵图的形式；

baiyuxuan

原题：
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如何制定一份有效的，可行性高的测试规范？

提高测试团队工作的规范性也是保证软件质量的必要手段，所以每个公司都应该制定自己的测试规范，这份规范应该是贯穿整个软件开发周期的，也是所有开发和测试都应该遵循的，如何制定这样一份规范让大家都愿意遵其行事呢？这样的规范具体应该包含哪些内容呢？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

说实话，这题本身就没有什么太大的价值。

1、所有开发和测试都应该遵循的话规范，是很难制定出来的。开发要遵循的，是研发规范；测试要遵循的，自然是测试规范；前期的需求、规格人员，则是相应的需求、规格分析设计规范；后期的客服，又有客服规范。各个部门的具体职责，情况都是完全不同的，因此想一份规范笼统概述，要么就是大而空，没有实际价值；要么就是过于繁琐细致，以致于失去其“规”的价值。

2、如何制定测试规范？？
简单而言，结合你所在公司的实际情况，未来的发展规划，业务重点，潜在客户的客观需求，行业的可能发展方向，业界的已有通行规范来制定。
这事说起来当然很简单，但实际实行的时候，就会遇到几个问题：
1）公司的高层的重视、支持程度
如果你所在公司的领导层根本不重视测试，或者对测试没有什么想法，那么你测试规范制定得再好，再完美，也等于废纸，甚或在现在的电子化办公时代，连废纸都不如。而很不幸，在国内而言，测试的受重视程度，在绝大多数公司，都是嘴上喊得响亮，行动上拖拖拉拉，毫无效率与目标，也就是说，你没有高层的真正的实际支持，你之后所作一切，都将是白费。那么具体应该有什么样的支持？我个人从业经验而言，觉得需要以下几点：
（1）权
足够的执行权力，领导权力，约束权力，推行权力，奖惩权力，是测试规范在制定后能真正贯彻、有效切实实施的保证
（2）人
合理的，有用的，实际的人力资源，是制定、贯彻、实施、监控、监督、改进测试规范的实际保障
（3）物
包括各类软件、硬件的支持，这里包括下载、购买相应的参考标准、参考资料、注册参加某些特定的会员、对内部人员的培训等等，都属于物力上支持
当然，我说从权、人、物上获得支持，并不是制定测试规范，包括后续的贯彻、实施、监控、改进等，是无限制的支持，本身的监管和限制，也都是矛盾对立统一的，是相辅相成的。
2）情况的不明确
很多公司，在制定这样那样的规范（不局限于测试规范）时，总是想着一下子覆盖所有的情况，满足所有的条件，解决所有的问题，结果造成了大而空，细而乱的规范，最后无法执行、实施、监控、改进而形同废弃。进而导致高层领导从此对此类规范失去信心，只相信人本位管理。在制定规范之前，需要先明确当前的自身状况，问题，为什么要制定这规范，制定这规范是为了解决什么问题，预期能够解决到什么程度，可能需要投入哪些资源、成本，预期如何实施等。说实话，制定规范并不是一蹴而就的事情。
3）制定者本身的能力问题
规范的制定者本身的能力、经验、甚至资历的不足，会限制、约束、甚至直接摧毁整个规范的制定。通常而言，应该是建立一个规范制定小组，由至少一个高层领导参与（不管是直接参与，还是作为名誉参与，作用在于起到对规范制定小组或委员会的权威性的认可），所有相关部门最低限度，至少派出 1 名代表，直接相关主要部门不少于 3 名代表。代表的应选择从业经验丰富，技术全面，思维敏捷，细致的人。如情况允许，可以邀请、聘请相关的咨询、管理专家，甚至你的主要大客户的代表参与到这个规范制定小组中。

当然，仅就规范的制定而言，会遇到的问题还很多很多，以上列举的也只是常见的。顺便说一句，在规范制定时的争吵现象是不可避免的，此时通常的做法有几类，表决式，少数服从多数式，领导一票决定式，外来和尚念经式，这个一般取决于具体企业的企业文化。

3、这样的规范具体应该包含哪些内容呢？
这个，我只能先 -_-!!! 真正要说具体的内容，请 Google 或 Baidu “测试规范”关键字，然后你会获得大量的范例
具体包含的内容，简单而言，就是指导、规定、约束、限制。
指导：就是指导相应的人员如何操作，完成相应的工作，任务。
规定：就是要求相应的人员必须履行的职责。
约束：就是对相应的人员的工作中可能出现的问题的提前预防针。
限制：就是对相应的人员的禁止性措施。
其实，具体规范应该的包含内容，还是与具体公司的实际情况相挂钩的。A 公司可能完全限制人员连接 Internet， B 公司就变成有条件的限制， C 公司则完全不限制。

规范制定完成之后，具体的实施、监督、监控、监管、对实施过程中出现的问题和收集到的建议/意见的改进，才是真正的难点和麻烦之处。

[ 本帖最后由 baiyuxuan 于 2008-9-24 11:20 编辑 ]

inksong

软件需求说明书的规范
1引言
1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
1.2背景
说明：
a．        待开发的软件系统的名称；
b．        本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c．        该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3需求规定
3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对：
a．        响应时间；
b．        更新处理时间；
c．        数据的转换和传送时间；
d．        解题时间；等的要求。
3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．        操作方式上的变化；
b．        运行环境的变化；
c．        同其他软件的接口的变化；
d．        精度和有效时限的变化；
e．        计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．        处理器型号及内存容量；
b．        外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．        输入及输出设备的型号和数量，联机或脱机；
d．        数据通信设备的型号和数量；
e．        功能键及其他专用硬件
4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

inksong

详细设计说明书的规范
1引言
1.1编写目的
说明编写这份详细设计说明书的目的，指出预期的读者。
1.2背景
说明：
a．        待开发软件系统的名称；
b．        本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。
1.3定义
列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2程序系统的结构
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。
3程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。
3.1程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发处理等）。
3.2功能
说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。
3.3性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4输人项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3.5输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。
3.6算法
详细说明本程序所选用的算法，具体的计算公式和计算步骤。
3.7流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
3.8接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。
3.9存储分配
根据需要，说明本程序的存储分配。
3.10注释设计
说明准备在本程序中安排的注释，如：
a．        加在模块首部的注释；
b．        加在各分枝点处的注释；
c．        对各变量的功能、范围、缺省条件等所加的注释；
d．        对使用的逻辑所加的注释等等。
3.11限制条件
说明本程序运行中所受到的限制条件。
3.12测试计划
说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。
3.13尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
4程序2（标识符）设计说明
用类似F．3的方式，说明第2个程序乃至第N个程序的设计考虑。
......