QR18-06 需求评审检查表 CMMI项目管理

合集下载

评审全套检查表CMMI项目管理模板

档案设计检查表
#检查项
1是否符合数据库第三范式要求？
2是否使用了专用设计工具
3实体-关系图是否定义清晰，实体最小定义？
4数据库是否清晰、完全反映了需求信息的逻辑法则，避免罗列？
5是否程序设计人员便于理解和使用？
6是否能够用良好的用户界面和操作过程就能实现模型功能？
7是否合理的使用存储过程、触发器和视图，保证数据库的功能分配和优化8数据库是否具备足够的灵活性，适应性？
9所有数据字段是否定义完全满足数据格式与存储要求，消除冗余？
10每个实体表是否定义了主键，主键是否合理？
11是否定义了外键，保证相关完整性？
12数据库是否定义的完善的索引？
13是否定义清晰必要的约束？
14是否考虑了数据库的所有与权限？。

需求评审检查表.doc

需求评审检查表需求特性检査内容所有定义、实现方法是否清楚地表达了用户的原要求在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要是否有不能理解或造成误解的描述I 是否有一个内容表格，该表格包含了所有需求描述是否所有的图形、表格都进行了标号是否所有的需求项都进行了标号，并提供了索引是否所有需求可以被定义的更细致，或简单对于不清晰的信息是否进行了指岀是否存在有需求让你不舒服是否所有与需求相关的设计约束都包含了是否所有与需求相关的性能都包含了是否所有与需求相关的属性都包含了是否所有与需求相关的外部接口都包含了是否所有与需求相关的通信都被包含了是否所有与需求相关的便件都被包含了是否所有与需求相关的数据库都被包含了是否所有与需求相关的软件都被包含了是否所有与需求相关的输入和输出都被包含了是否所有与需求相关的安装特性都被包含了是否所有与需求相关的维护特性都被包含了是否所有与需求相关的安全特性都被包含了所有对其他需求的内部交叉引用是否正确所有需求的编写在细节上是否都一致或者合适需求是否能为设计提供足够的基础是否包括了每个需求的实现优先级需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有功能需求是否覆盖了所有非正式情况的处理是否对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作了是否对所有功能与时间因素有关的方面都作了考虑是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明了？时间准则的最大、最小执行时间是否都定义了是否标识并定义了在将来可能会变化的需求是否定义了系统所有的输入是否标识清楚了系统输入的来源是否标识岀了系统的输出是否说明了系统输入、输出的值域、单位、格式等是否说明了如何进行系统输入的合法性检查是否定义了系统输入、输出的精度是否定义了系统性能的各个方面在不同负载情况下，是否规定了系统的生产率在不同情况下，是否规定了系统的响应时间是否充分定义了有关人机界面的需求是否对需求定义进行了可行性分析和相关文件（资料）是否已归档是否对影响需求实现的因素进行了调查、调查结果是否已归档是否有商业行为，分析结果是否已归档是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性清晰性/无二义性完整性。

QR18-06 需求评审检查表 CMMI项目管理

用例图上所有角色都定义了吗？是否遗漏了重要的
6.1
角色，例如其他的软件、硬件系统？角色的划分是
否正确？
6.2
用例中是否不包含设计和实现的细节？
6.3
是否确定了对时间要求很高的功能并且定义了它们
的时间标准？
7
文档组织
7.1 所有对于其他需求的内部交叉引用都正确吗？所有需求都是按照一致和恰当的详细程度描述的
8.1 是否已明确阐述了对浏览器的支持（针对B/S系统）
记录编号：
版本号：2 修订号：0
第4页共8页
版本号：2 修订号：0
第5页共8页
版本号：2 修订号：0
第6页共8页
版本号：2 修订号：0
第7页共8页
版本号：2 修订号：0
第8页共8页
1.4
是否对所有预料的错误条件定义了期望的系统行为？
2
正确性
2.1 是否某些需求与其他的需求冲突或者重复？需求里有遗漏的必要信息吗？如果有的话，那些信
2.3 息被标明为“待决定（TBD）”了吗？
版本号：2 修订号：0
记录编号：
缺陷描述
第1页共8页
2.4 任何定义的错误信息都是唯一和有意义的吗？
7.2 吗？
7.3 需求为设计提供了充分的基础了吗？需求是否进行了统一的编号？是否确定了每一个需
7.4 求的优先级？
7.5 是否每个需求都没有内容和语法错误？某些功能需求具有固有的内部算法，这样的算法定
7.6 义了吗？
7.7 是否每个需求都没有内容和语法错误？
8
特殊问题
版本号：2 修订号：0
记录编号：第3页共8页
2.5
需求是否具有歧义？如果需求命名不容易理解，是否给予了足够的描述？

CMMI-需求管理检查表

需求管理活动
是/否/不适
#
检查项
用
1 客户和项目组成员就客户需求达成共识了吗？
是否所有受客户需求影响的相关组都参与了需求定 2 义？
是否举行评审会，保证所有相关组对需求的理解一 3 致？ 4 需求中是否包括了非功能性需求？ 5 用软件实现客户需求是可行的吗？ 6 是否将客户需求记录在软件需求规格说明书中了？ 7 软件需求规格说明书经过批准了吗？ 8 是否给图片定义了标签 9 项目组是否按照需求变更要求进行变更？ 10 需求功能矩阵是否及时得到了维护？
注释
SCM人员是否按照《需求功能矩阵变更表》对需求功能 11 矩阵进行的维护？
不适用
不适用
是是不适用不适用是是是是
是Hale Waihona Puke 12 需求状态是否在事件驱动条件下进行了统计？
13 矩阵变更表是否得到了项目经理的批准？是否建立了需求基线，并将软件需求规格说明书置于
14 配置管理之下？
不适用是
是
结果统计：是 8 个；否 0 个

需求评审检查表

1．所描述的软件需求与客户需求和系统需求是否一致？
2．所规定的处理及其数据是否与必须完成的功能要求一致？
3．是否有超出范围的功能？
4．文档内部是否存在前后不一致的描述？
正确性
1．是否正确理解和描述了客户对软件的需求？所有错误是否已经排除？
明确性
1．是否存在含混、不清楚和含有二义的描述？
2．图表是否清楚？
可管理性
1．是否所有需求是以一种可管理的方式表达的？一个需求项的改变会不会影响其它很多功能？
问题
编号
问题说明和建议
（如果是针对文档中具体的内容，请标识位置）
1
2
……
n
评审检查结论
（邮件评审时填写此项）
□通过□有条件通过□不通过
说明：
需求评审检查表
项目名称
评委姓名
评审检查日期
评审检查用时（小时）
主要检查内容
意见
完整性
1．是否完整地定义了软件需求规格？
2.是否考虑了数据量和处理量？
3．是否定义了关键的接口和界面？
4．范围内的功能是否都有适当的描述？
5．在定义功能时是否考虑了异常处理ቤተ መጻሕፍቲ ባይዱ例外处理？
6．是否考虑过其它可选的软件需求？
一致性
3．某些信息是否被忽略了或有冗余？
可实施性
1．是否每一项软件需求都存在实现的可能？
2．软件设计是否可行？
3．约束条件是否现实？
4．是否考虑了实现需求的技术风险？
可追溯性
1．是否能够在后续过程中对每一项软件需求进行追溯？
2．是否需求中的每一项都能到用户问题域中找到对应？
相关性
1．是否文档的所有内容都跟要解决的问题相关？无关的内容都要去掉。

02 需求调查表(CMMI模板)

需求调查表
完善的软件需求对要开发的软件的质量和效率是一个首要的问题，为了准确而清晰地了解用户对要求开发软件的需求，请用户尽可能全面地回答本调查表中的各项问题，谢谢！
姓名：职务：
部门：日期：
1．你认为要开发的软件使用什么名称最为合适？
注：角色是指使用软件人的主要任务，例如：数据录入、查询、监督等。

3．你要求软件的工作平台与体系结构是什么？
3．1网络环境：
3．1．1服务器品牌：
3．1．2服务器数量：
3．1．3工作站品牌：
3．1．4工作站数量：
3．1．5局域网数量：
3．2操作系统：
3．2．1服务器操作系统：
3．2．2工作站操作系统：
3．3数据库管理系统：
3．4体系结构：（单机工作、客户/服务器、Intranet等）
4．你要求软件的开发工具是什么？
5．你对软件有哪些功能上的要求（请逐项说明）
5．1日常事务处理
5．2查询
5．3统计
5．4辅助决策
5．5系统维护
5．6通讯
5．7其它
6．你对软件有哪些性能上的要求（请逐项用数量[近似的]说明）
6．1数据库容量, 该软件产品使用的人数多少，用户并发量大概多少，用户组织架构多少人?
6．2访问速度
6．3其它
7．对软件有哪些安全方面的要求（请逐项说明）
7．1用户权限
7．2防止病毒
7．3数据安全
7．4其它
8．你对软件有哪些约束性的要求（请逐项说明）8．1规章制度
8．2使用中可能的风险
8．3软件需求变化的可能与来源
8．4其它
9．你对软件有哪些使用方便的要求（请逐项说明）9．1用户帮助
9．2用户向导
9．3其它。

QR20-01 代码检查表 CMMI项目管理

版本号：2 修订号：0
开闭原则，软件应该对扩展开放，对修改关闭。也就是说，应该在不修改以前源代码的基础上，改变程序的行为以适应新的需求。
里氏代换原则：假设有两个类，一个是基类Base，一个是派生类Derived，如果一个方法可以接受基类对象b的话：method1(Base b)，同样，这个方法也应该接受派生类Derived的对象d，而不影响方法的行为。里氏代换原则是继承复用的基石。
强制推荐
强制
强制强制强制推荐强制强制强制强制强制强制强制强制强制
推荐
强制
记录编号：第3页共6页
54 55 56 57 58 59 60
61 62 63 64 65
66
67 68
69
版本号：2 修订号：0
注释尽量简洁，尺度没有准确的定义，大部分人能明白即可，可以将自己的代码给同事看看。接口中的方法一定要编写注释。应使用正式的.net风格的xml tag进行注释。代码的版权信息，每个源文件都应包含版权信息。类注释，描述类的主要职责。对于public方法和长方法应进行注释，描述方法是做什么的，如何调用，最好给出调用代码示例。复杂的算法、长方法的实现要编写内部实现注释，从为什么要这么做角度去描述。对已经正式发布版本中的代码进行修改和维护时，应该在修改处进行内部注释并注明修改人、修改时间、修改意图以及应注意问题等。使用行末注释对深层嵌套代码进行注释。所有变量都应该进行初始化。变量在使用前应进行合法性检查。静态变量和方法的使用应保证线程安全。所有异常应该被正确的处理，不应简单的吞掉异常或打印。应该将异常记入日志或者包装后向上层抛出。对于表现层页面，不应该出现程序异常，应该在捕获到异常后进行友好的提示。对于静态方法，应该使用类名去使用，不应该用实例去引用，主要是为了体现更多的语义。对一些基本数据类型和不太可能通过继承进行扩展的类，应声明为readonly，提高效率。

QR18-02 需求调查表 CMMI项目管理

答:
8.xxxx工作频率高吗？每天有多少量？
答:
【4) 针对甲方的IT人员。
调研目的:
1. 确定IT系统环境】
问题：
1.目前的网络拓扑环境是怎样的？内外网时候可以自由访问？如不能，如何解决
答:
2.目前的硬件情况，将来的系统会在什么类型的机器上运行？
答:
3.目前的数据库系统是什么？将来的系统是否在现有的数据库上？目前应用服务器平台是怎样的？
答:
5. 是否有人可能会因为这个项目受害，哪些人？职责分类？有没有职责分配的文档？
答:
6. 本项目所需的数据信息都可以从本单位获得吗？从哪些系统获得？是否需要外部数据，如何获得？
答:
7. 项目是否有一些限制？例如上级规定的上线日期、业务特定的日期限制等。包括进度上的限制，成本上的限制，质量标准的限制，法律限制及其他限制
答:
7.本模块的进入/流出数据需要和哪些系统、部门打交道？
答:
8.你觉得使用新系统会在哪些方面帮助你解决问题？
答:
9.每一种岗位业务熟悉的人的名单和联系方式
答:
【3) 针对甲方的一线人员。
调研目的:
1. 确定详细流程】
问题：
1.请把你的工作做个分类
答:
2.xxxx工作你是怎么开始的？谁触发的，你收到了哪些外部文件或信息吗？
答:
8. 甲方是否有项目负责人，这个人有足够的时间吗？是否被正式任命？联系方式？
答:
9. 甲方有为这个项目成立项目组吗，如果没有，其它的人知道这个项目吗？如果有业务需求描述不一致，谁来决定？
答:
【2) 针对甲方的中层。
调研目的:
1. 总体上确认特定功能的业务流程】

CMMI过程域一览表

CMMI过程域一览表CMMI-DEV 1.2过程域一览表CMMI-DEV 1.2的22个过程域CMMI等级2级 2级 2级 2级 2级 2级中文名称需求管理项目规划项目监控供应商协议管理度量分析过程和产品质量保证英文名称Requirements Management Project PlanningProject Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance2级 3级 3级 3级 3级 3级 3级 3级 3级 3级 3级 3级 4级配置管理需求开发技术方案产品集成验证确认组织过程焦点组织过程定义组织培训集成化项目管理风险管理决策分析与解决方案组织过程绩效Configuration Management Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational TrainingIntegrated Project Management Risk ManagementDecision Analysis and Resolution Organizational Process Performance4级 5级定量项目管理组织革新与部署Quantitative Project Management Organizational Innovation and Deployment5级原因分析与解决方案Causal Analysis and ResolutionCAR支持QPM OID项目管理过程管理CM RD TS PI VER VAL OPF OPD OT IPM RSKM DAR OPP支持工程工程工程工程工程过程管理过程管理过程管理项目管理工程支持过程管理缩写 REQM PP PMC SAM MA PPQA过程类型工程项目管理项目管理项目管理支持支持。

培训需求调查问卷CMMI项目管理模板

填表日期
2008年培训需求调查问卷
姓名
部门
类
说明：
1、培训时间应具体写到月份，如2008年2月或2008年2-3月
2、培训对象应填写职务名称或人员名单或部门名称；
3、培训方式字段应填写：公司自训（由人力资源部组织的）、引进内训、选派外训、在岗培训（由部门自己组织的）、资格认证培训、学历教育、参观考察、读书小组、专题研讨会、员工自修；
4、培训组织机构字段应填写：公司人力资源部、本部门或其它部门或培训机构；
5、每天课程时数以8小时为标准计算，外聘培训讲师费用均以目前北京市一般企业聘请讲师的行情预估，为RMB1000-2500元/小时，实际执行中以议定价格为准，但不得高于此单价的20%；各事业部申请的计划外培训的相关费用（外聘讲师课酬、外派培训费用等）由各事业部自行承担；
6、一般人员、中基层管理人员和高管人员每年计划内培训时间分别为40小时、50小时和60小时；
7、填写完毕并签字后，请将电子版发送至企管中心培训岗。

评审计划CMMI项目管理模板

项目名称(编号) 审查日期开始时间
工作产品信息
序号 1 2 3 4 5
评审人员
姓名项目组成员1 项目经理项目组成员2 项目组成员3 项目组成员4 项目组成员5 项目组成员6 项目组成员7
评审计划
会议室预期评审速率结束时间
分钟/页
名称
作者项目组成员2
版本大小（页）检查表
标准
角色பைடு நூலகம்
参加
检查准备时间（小时）
相关文档
名称
版本
存档位置
准备完成标准
参加评审人员为3－5人，必须包括：作者，主持人，记录员（可由主持人兼任），评审员。每位评审员必须提前准备问题，定出最小准备时间。如：不得小于5分钟/页（Word）

CMMI-项目管理-SAM-采购验收单模版

采购验收单
文件编号：GZCY_SAM_TEM_PCA
文件类别：模板
密级：机密
版本信息：V1.0
文档修订记录
*变化状态：A——增加，M——修改，D——删除
文档审批信息
采购验收单
3 / 6
4 / 6
【填表说明】
1、请在“验收记录”中相应的验收项打“√”或“Ⅹ”
2、“验收记录”中第一个“验收人”一栏由采购申请人签字，第二个“验收人”一栏由设备调试安装人员签字
3、“验收结论”请填写通过或不通过，如不通过请在“备注”一栏中说明处理方法
4、此表需有采购申请人、采购申请部门行政助理，采购申请部门经理、采购部门采购人共同签字确认；如采购的设备最终转
5 / 6
为公司固定资产，则验收中还需有公司固定资产管理员参与，并最后签字确认。

5、此表中若栏目设置内容在验收过程中不发生，请用“—”划去
6 / 6。

评审检查表

评审检查表
1 / 11
目录
1.项目计划检查表 (3)
2.需求规格说明书检查表 (4)
3.概要设计说明书检查表 (5)
4.详细设计说明书检查表 (6)
5.编码检查表 (7)
6.测试用例检查表 (10)
7.产品验收和发布检查表 (11)
2 / 11
1.项目计划检查表
2.需求规格说明书检查表
3.概要设计说明书检查表
4.详细设计说明书检查表
5.编码检查表
通过结合编码检查表和代码检查单，可以比较清楚地确定代码问题的位置。

5.1. 代码检查表
5.2. 代码检查内容
备注：
1）激活：本列标注Y 的为激活的项目，表明这些项目必须被明确地自查（其他问题处于“顺便被检查”的状态），在运行编码检查的时候，前期几乎所有项都要在激活状态；后期稳定后，保持8~10 个（或遵从当前规范）激活的检查项。

为了醒目，可以像此表这样将当前的激活项用亮黄色表示。

10~40 50~100
3) 检查项：所有检查项均为一般疑问句，当发现回答为“否”时，即存在一个缺陷。

6.测试用例检查表
10 / 11
7.产品验收和发布检查表
11 / 11。

项目管理体系内部审核检查表

1
局项目管理手册、试验检测规章制度
GB/T19001
6.2
6.3
7.5.1
7.6
8.2.4GB/T24001GB/T45001
6.1.2
①试验室检测设备和人员（人员数量、持证率和能力等）的配备是否满足要求？②有无试验工作计划？配合比的优化及结果？③试验检验状态的控制情况。原材料、混凝土强度等的试验频次是否符合规范要求？质量情况？④商混的交货检验是否符合要求。⑤局、公司今年主题活动的落实情况？对外委试验机构是否进行了评价，有无评价资料。⑥有无不合格品台账及不合格品的处理资料。
项目管理体系内部审核检查表
受审核单位：部门：审核员：
审核依据：GB/T19001—2016、GB/T50430—2017、GB/T24001—2016、GB/T45001-2020.局体系文件、审核日期：
规,
上制度、通知规定等
序号
部门手册、制度
标准条款
检查内容
检查方法
检查轻微
12.2
①试验室房间布局及仪器摆放是否合理，仪错摆放是否整齐、室内是否干净整洁。②各种试验仪器台座尺寸是否按照规范要求垒砌。标养室存放试块摆放是否规范，温度和湿度是否满足要求。
③危险源和环境因素的识别和控制情况（试验机防护罩、集水池护网、废水废液的处理等）。
④工地试验室是否取得母体授权和质监局备案证书，并在有效期内。⑤母体试验室检查记录（每年不少于2次）留存是否齐全。
⑦实体混凝土回弹强度、钢筋保护层厚度合格率？
外资料、现场核查
2
检测设备管理办法
GB/T50430
8.1
8.2
8.3
8.4
11.5
①对项目（含劳务协作单位）检测设备的登记、标识、使用等情况？是否有损坏生锈等现象？

06 需求评审检查单(CMMI模板)

是否识别并定义了在将来可能会变化的需求
需求定义是否使软件的设计、实现、操作和维护都可行？
2、干系人管理(是否采用、是否合理，模板里的要点)
项目干系人识别是否完整
项目干系人是否进行后续跟踪及采取相应措施
是否使用到干系人分析技术
3、功能需求的逐个检查
1)相关描述是否准确、易理解、无歧义（描述与描述之间是否一致）
需求评审检查单
项目名称
检查人
文档名称
版本号
检查内容
检查结果
1、总体检查
是否采用ቤተ መጻሕፍቲ ባይዱ定的原型工具编制原型
是否符合公司制定的模板
术语定义是否完整、清晰、符合行业规范和惯例
参考资料是否完整，是否符合时效性的要求
系统用户分类是否符合用户需求(用户需求包括行业标准、合同约定、目标用户群的普遍共识、目标用户的个性化需求等，下同)
2)相关描述是否符合用户需求
3)输入、输出的描述是否完整
4)正常业务处理流程是否合理
5)异常状况是否列举充分，相应的容错处理是否合理
6）约束条件的设定是否合理
7) 兼容性和扩展性是否得到了必要的考虑
8）易验证性：定义的需求是否是能够得到验证的？
4、非功能需求检查
1)是否对负载和环境的不同组合进行了必要的枚举，组合条件的假设是否合理，相应的系统执行效率描述是否准确、合理
系统功能边界与分类是否正确、清晰，是否存在重复，是否符合用户需求
系统功能的重要性和优先级设定是否合理
系统环境定义是否完整(硬件平台与配置、操作系统、数据库系统、中间件)，是否符合用户需求
设计与实现上的限制是否符合用户需求
易追溯性：需求定义是否便于后续文档、产品、代码的对应与跟踪？