开发文档规范检查.docx
《开发文档规范检查.docx》由会员分享，可在线阅读，更多相关《开发文档规范检查.docx（18页珍藏版）》请在冰点文库上搜索。
开发文档规范检查
Ø采用以下检查表检查软件需求规格文档中需求的清晰性。
（另外整理成分支文档）
序号
问题
1
所有定义、实现方法是否清楚地表达了用户的原始要求？
2
在功能实现过程、方法和技术要求的描述上，是否没有背离了功能的实际要求？
3
是否没有不能理解或造成误解的描述？
Ø采用以下检查表检查软件需求规格文档中需求的完备性。
序号
问题
1
需求定义中是否包含了有关文件（指质量手册、质量计划以及其它有关文件）种所规定的需求定义所应该包含的所有内容？
2
需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？
3
功能性需求是否覆盖了所有非正常情况的处理？
4
是否对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作了规定？
5
是否对所有功能与时间因素有关的方面都作了考虑？
6
是否标识出了所有与时间因素有关的功能？
它们的时间准则是否都说明了？
时间准则的最大、最小执行时间是否都定义了？
7
是否标识并定义了在将来可能会变化的需求？
8
是否定义了系统所有的输入？
9
是否标识清楚了系统输入的来源？
10
是否标识出了系统的输出？
11
是否说明了系统输入、输出的类型？
12
是否说明了系统输入、输出的值域、单位、格式等？
13
是否说明了如何进行系统输入的合法性检查？
14
是否定义了系统输入、输出的精度？
15
是否定义了系统性能的各个方面？
16
在不同负载情况下，是否规定了系统的处理能力？
17
在不同情况下，是否规定了系统的响应时间？
18
是否充分定义了关于人机界面的需求？
19
是否对需求定义进行了可行性分析和相关文件（资料）是否已归档？
20
是否对影响需求实现的因素进行了调查，调查结果是否已归档？
21
是否有经济效益分析，分析结果是否已归档？
22
是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性？
23
是否评估了本项目对用户、其它系统、环境的影响特性？
24
是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序？
Ø采用以下检查表检查软件需求规格文档中需求的兼容性。
序号
问题
1
界面需求是否使软硬件系统具有兼容性？
2
需求定义的文档是否满足项目文档编写标准？
在矛盾时，是否有适当的标准可供选择？
Ø采用以下检查表检查软件需求规格文档中需求的一致性。
序号
问题
1
各个需求之间是否一致？
是否有冲突和矛盾？
2
所规定的模型、算法和数值方法是否相容？
3
是否使用了标准的术语和定义形式？
4
需求是否与其软硬件操作环境相容？
5
是否说明了软件对其系统和环境的影响？
6
是否说明了环境对软件的影响？
7
所采用的技术是否与用户要求的技术一致？
Ø采用以下检查表检查软件需求规格文档中需求的正确性。
序号
问题
1
需求定义是否满足标准的要求？
2
算法和规则是否有科技文献或其它文献作为基础？
3
是否定义了对在错误、风险分析中所标识出的各种故障模式和错误类型所需的反应？
4
是否参照了有关的标准？
5
是否对每一个需求都给出了理由？
理由是否充分？
6
对设计和实现的限制是否都有论证？
Ø采用以下检查表检查软件需求规格文档中需求的可行性。
序号
问题
1
需求定义是否使软件的设计、实现、操作和维护都可行？
2
所规定的模型、数值方法和算法是否对待解决问题合适？
是否能够在相应的限制条件下实现？
3
是否能够达到关于质量的要求？
Ø采用以下检查表检查软件需求规格文档中需求的易修改性。
序号
问题
1
对需求定义的描述是否易于修改（如是否采用良好的结构和交叉引用表等）？
2
是否有冗余的信息？
是否一个需求被定义了多次？
Ø采用以下检查表检查软件需求规格文档中需求的健壮性。
序号
问题
1
是否有容错的需求？
Ø采用以下检查表检查软件需求规格文档中需求的易追溯性。
序号
问题
1
是否可从上一阶段的文档中找到需求定义中的相应内容？
2
需求定义是否明确地表明前阶段中提出的有关需求和设计限制都已被覆盖了？
3
需求定义是否便于向后继开发阶段查找信息
Ø采用以下检查表检查软件需求规格文档中需求的易理解性。
序号
问题
1
是否每一个需求都只有一种解释？
2
功能性需求是否以模块方式描述的？
是否明确地标识出了其功能？
3
是否有术语定义一览表？
4
是否使用了形式化或半形式化的语言？
5
语言是否有歧义性？
6
需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？
是否过分细致了？
7
需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础？
8
需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了？
Ø采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。
序号
问题
1
需求是否可以验证（即是否可以检验软件是否满足了需求）？
2
是否对每一个需求都指定了验证过程？
3
数学函数的定义是否使用了精确定义的语法和语义符号？
Ø采用以下检查表检查软件需求规格文档中的性能需求描述。
序号
问题
是否精确的描述了所有的性能需求和可容忍的性能降低程度？
对每一个性能应包含两方面的内容：
1
a.在最坏情况的执行结果
2
b.本性能失效后，对系统产生的影响
Ø采用以下检查表检查软件需求规格文档中功能需求描述。
序号
问题
1
是否清楚、明确地描述了所有的功能？
2
所有已描述的功能是否是必须的？
是否能满足任务书或系统目标的要求？
Ø采用以下检查表检查软件需求规格文档中的接口需求描述。
序号
问题
1
是否清楚地定义了所有的接口？
3
所有接口是否必须？
各接口间的关系是否一致、正确？
Ø采用以下检查表检查软件需求规格文档中的数据需求描述。
序号
问题
1
在某异常数据（如条件、标志等）下，是否有真正没有考虑到的结果？
2
对异常数据产生的结果是否作了精确的描述？
Ø采用以下检查表检查软件需求规格文档中的可维护性需求描述。
序号
问题
1
需求定义中是否包括了可行的系统维护方法？
2
软件系统间的关系是否是松耦合的（即能否保证在对某部分修改后，产生最小的连锁效应）？
1.1.项目计划文档规范
Ø项目计划以软件的需求规格为基础。
当发生需求更改时，修订开发计划。
说明：
项目计划必须依据需求规格进行制定。
项目计划中的工作产品和工作任务应保证能完全实现需求规格的定义。
当需求更改时，必须考虑需求更改的相关性，修订相应开发计划。
Ø在开发活动中，按照“项目计划”，跟踪项目开发的实际结果和性能
Ø当实际结果和“项目计划”发生偏离时，进行分析，根据分析结果标明纠正措施。
必要的情况下，及时修订“项目计划”。
Ø在项目跟踪监控活动中，定期进行总结和确认，撰写开发状态报告。
Ø每周五提交周报，并确认本周工作内容是否与需求规格说明书一致，是否存在偏差。
Ø在开发各里程碑阶段结束前，进行阶段确认，必要的情况下修订“项目计划”
1.2.概要设计
Ø概要设计要以需求规格为基础，保证需要实现的需求规格已经被设计。
Ø当需求规格发生变更时，修订相关概要设计文档。
Ø在概要设计文档或需求管理文档中，记录、验证需求和概要设计的跟踪关系。
Ø保证概要设计文档和代码的一致性。
当发生设计更改时，修订相应设计文档。
Ø概要设计过程结束前，必须通过签字确认，并保存记录。
Ø设计更改必须经过相关签字确认，并保存记录。
Ø对概要设计文档的正规检视或评审，必须检查概要设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
Ø采用以下检查表检查概要设计文档的清晰性。
序号
问题
1
程序结构，包括数据流、控制流和接口的描述是否清楚？
Ø采用以下检查表检查概要设计文档的完备性。
序号
问题
1
设计目标是否定义？
2
需求规格确认中不完整的需求是否都已经解决?
3
如果以前定义的不完整的需求发生了改变,本设计是否能够支持?
4
是否对不完整需求的影响进行了评估?
Ø采用以下检查表检查概要设计文档的规范性。
序号
问题
1
文档是否符合SHARP模板和写作要求?
Ø采用以下检查表检查概要设计文档的一致性。
序号
问题
1
程序、模块、函数、数据成员的名称是否保持一致？
2
设计是否反映了真正的操作环境?
硬件环境?
软件环境?
3
对系统设计的多种可能的描述之间是否保持一致?
（例如:
静态结构的描述和动态描述）
Ø采用以下检查表检查概要设计文档的正确性。
序号
问题
1
设计在计划、技术上是否可行？
2
逻辑是否正确和完备？
Ø采用以下检查表检查概要设计文档的数据描述。
序号
问题
1
是否对所有的数据成员,参数,对象进行了描述?
2
是否所有需要的数据结构都进行了定义,或者定义了不需要的数据结构?
3
是否所有的数据成员都进行了足够详细的描述?
数据成员的有效值区间是否定义?
4
共享和存储数据的使用是否描述清楚?
Ø采用以下检查表检查概要设计文档的功能性要求。
序号
问题
1
模块的规格是否和软件需求文档中的功能需求和软件接口规格要求保持一致.
2
设计是否能满足模块的所有需求?
Ø采用以下检查表检查设计的接口描述。
序号
问题
1
是否描述了接口的功能特征?
2
接口是否便于查错?
3
接口相互之间、和其他模块、和需求说明书及接口规格书保持一致？
4
对接口的数量和复杂度进行了有效的平衡，使接口数量控制在一个较小数量，每个接口具有可接受的复杂度？
5
是否所有的接口都能描述了必要的类型、数量、质量等信息？
6
操作界面是否考虑了用户（例如：
提供准确、清晰、有用的提示信息）？
Ø采用以下检查表检查设计的详细程度。
序号
问题
1
是否估计了每个子模块的规模（代码的行数）？
是否可信？
2
是否考虑了足够数量及代表性的系统状态？
3
详细程度是否足够进行下一步的详细设计？
Ø采用以下检查表检查设计的可维护性。
序号
问题
1
是否模块化设计？
2
模块是否为高内聚、低耦合？
Ø采用以下检查表检查设计的性能。
序号
问题
1
是否进行了性能模型分析？
2
程序执行过程中的关键路径是否都被标识和经过分析？
Ø采用以下检查表检查设计的可靠性。
序号
问题
1
设计是否考虑了检错和恢复措施？
（例如：
输入检查）
2
是否考虑了异常情况？
3
是否完全准确描述了所有的出错情况？
4
设计是否能够满足所有系统集成方面的要求？
Ø采用以下检查表检查设计的可测试性。
序号
问题
1
设计是否能够被实验、演示或检视以显示它满足了需求？
2
设计是否能够使用以前的测试代码，是否能够进行增量式的测试？
Ø采用以下检查表检查设计的可追溯性。
序号
问题
1
是否每一部分的设计都可以追溯到需求说明书，接口规格说明书、或其他产品文档？
2
对所继承下来的那些特别和不常用的特性对目前设计的影响是否进行了分析？
3
对所继承设计中已知的风险是否进行了定位和分析？
1.3.详细设计
Ø详细设计要以软件需求规格和概要设计为基础，必须保证需要实现的需求规格已经被设计，必须保证概要设计定义的所有模块已经被详细设计。
Ø当需求规格或概要设计发生变更时，修订相关详细设计文档。
Ø在详细设计文档或需求管理文档中，记录、验证需求、概要设计、详细设计的跟踪关系。
Ø必须保证详细设计文档和代码的一致性。
当发生设计更改时，修订相应设计文档。
Ø详细设计过程结束前，必须通过确认签字，并保存记录。
Ø设计更改必须经过确认签字，并保存记录。
Ø对详细设计文档的正规检视或评审，必须检查详细设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
Ø采用以下检查表检查详细设计文档的清晰性。
序号
问题
1
是否所有的单元和进程的设计目的都已文档化？
2
单元设计，包括数据流、控制流、接口描述是否清楚？
3
单元的整体功能是否描述清楚？
Ø采用以下检查表检查详细设计文档的完备性。
序号
问题
1
是否提供了所有程序单元的规格？
2
是否描述了所采用的设计标准？
3
是否列出了单元的所有调用？
4
是否记录了设计继承的历史和已知的风险？
Ø采用以下检查表检查详细设计的一致性。
序号
问题
1
在单元和单元的接口中数据成员的名称是否保持一致？
2
所有接口之间，接口和接口规格书之间是否保持一致？
3
详细设计和概要设计文档是否能够完全描述“正在构建”的系统
Ø采用以下检查表检查详细设计的正确性。
序号
问题
1
是否有逻辑错误？
2
需要使用常量名称的地方是否有错误？
3
是否所有的条件都被处理？
（>,=,<,switchcase）?
4
分支所处的状态是否正确？
（逻辑没有搞反）
Ø采用以下检查表检查详细设计的数据描述。
序号
问题
1
是否所有声明的数据块都已经使用？
2
定位于单元的数据结构是否已经描述？
3
如果有对共享数据、文件的修改，对数据的访问是否按照正确的共享协议进行？
4
是否所有的逻辑单元、事件标记、同步标记都已经定义和初始化？
5
是否所有的变量、指针、常量都已经定义并初始化？
Ø采用以下检查表检查详细设计的功能性要求。
序号
问题
1
设计是否使用了指定的算法？
2
设计是否能够满足需求和目的？
Ø采用以下检查表检查详细设计的接口描述。
序号
问题
1
参数表是否在数量、类型和顺序上保持一致？
2
是否所有的输入输出都已经正确定义并检查过？
3
所传递参数的顺序是否描述清楚？
4
参数传递的机制是否确定？
5
通过接口传递的常量和变量是否与单元设计的相同？
（例如，函数中定义的常量不能在所调用的子过程中被修改）
6
传入、传出函数的参数，控制标记是否都已经描述清楚。
7
是否以度量单位描述了参数的值区间，准确性和精度。
Ø采用以下检查表检查详细设计的详细程度。
序号
问题
1
对模块的所有需求都已经定义？
2
详细程度是否足够开发和维护代码？
Ø采用以下检查表检查详细设计的可维护性。
序号
问题
1
单元是否是高内聚和低外部耦合？
（例如：
单元的改变不会在内部出现不可预见的影响，同时对其他单元的影响最小？
2
是否这种设计是复杂度最小的设计？
3
开始部分的描述是否符合SHARP的要求？
（例如：
目的，作者，环境，非标准特性，开发历史，输入输出参数，使用的文件，数据结构，引用此单元的其他单元，注释。
Ø采用以下检查表检查详细设计的可靠性。
序号
问题
1
初始化时是否使用了默认值，是否正确？
2
访问内存时是否进行了边界检查，以保证地址正确？
（队列，数据结构，指针，等等）
3
对输入、输出、接口和结果是否进行了错误检查？
4
对所有错误情况都安排了有意义的消息反馈？
5
特殊情况下的返回码是否和文档中定义的全局返回码一致？
6
是否考虑了异常情况？
Ø采用以下检查表检查详细设计的可测试性。
序号
问题
1
是否每个单元都可以被测试、演示、分析或者检视，以确认满足需求。
2
设计中是否包括辅助测试的检查点？
3
是否所有的逻辑都是可测的?
4
是否描述了本单元的测试驱动模块，测试用例集，测试结果?
Ø采用以下检查表检查详细设计的可追溯性。
序号
问题
1
是否每一部分的设计都可以追溯到需求？
2
是否每一个设计决策都可以追溯到效益分析？
3
是否所有的设计决策都可以追溯到成本/效益分析？
4
是不是描述了每个单元的详细需求？
5
单元需求是否能够追溯到软件规格文档？
软件规格文档是否能够跟踪到单元需求？
6
是否有到代码的引用或者包括代码本身？
升级会员 