原件：
项目风险分类
1. 需求
需求没有文档化
[1] 是否仅有未成文的需求？
如果项目的需求只是通过口头表达，则需要考虑风险。
需求不稳定
[2] 需求是否正在变化或是已经确定下来了？
如果需求正在被增加、变更或是没有被确定下来，则需要考虑风险。
需求不完全
[3] 需求中所有项目是否都有详细说明？
如果需求中有未列出详细说明的项目，则需要考虑风险。
需求可读性差
[4] 需求文档的可读性如何？
如果需求文档的可读性差，则需要考虑风险。
需求不清晰
[5] 你是否可以理解需求，如同作者想要表达的？
如果关键的需求是模糊的、不明确的，则需要考虑风险。
需求进度紧张
[6] 进度中是否安排了足够的需求分析时间？
如果需求分析阶段的进度紧张，则需要考虑风险。
需求分析能力有限
[7] 需求分析人员的能力是否有限？
如果需求分析人员的能力有限，则需要考虑风险。
需求无经验可借鉴
[8] 项目需求的关键部分是否有以往的经验可以借鉴？
如果需求的关键部分无法借鉴以往项目的经验，则需要考虑风险。
需求不可行
[9] 是否存在在实现时有技术困难的需求？
如果不能确定某一项需求在所用的开发语言环境中实现的方法，则需要考虑风险。
需求不可跟踪
[10] 是否有计划在设计、编码和测试阶段对需求进行跟踪？
如果需求与开发过程出现偏差，或是在各个阶段没有被把握住，则需要考虑风险
2. 设计
设计的算法有问题
[11] 是否存在没有满足需求或是仅仅部分满足需求的算法？
如果算法有可能是错误的、不完整的，或是太复杂，则需要考虑风险。
设计难度大
[12] 是否存在难于设计的需求或是功能？
在某些时候，如一个复杂的树的查询可能需要很多的精力来设计，则需要考虑风险。
设计难度偏大过偏小
[13] 设计中的任何一部分是否是基于不切实际的或是乐观的假设？
如果对需求的设计太乐观或者太悲观，则需要考虑风险。
设计的接口定义不完全
[14] 是否内外部接口都已经很好的定义了？
如果在系统内部或是系统间存在复杂的、大量的联系，则需要考虑风险
设计不易测试
[15] 软件是否易于测试？
如果在测试产品时有很大的复杂性，则需要考虑风险。
设计有硬件约束
[16] 开发或是运行硬件是否对满足需求有限制？
如果在硬件速度、容量、可用性和功能方面有限制，则需要考虑风险
设计有软件复用性要求
[17] 是否存在软件复用？
需要考虑复用软件时的修改可能导致比设计新软件更多问题的风险。
3. 编码和单元测试
编码和单元测试的可行性
[18] 产品中是否有某些部分没有在设计说明书中被完全定义？
如果没有在设计时跟踪需求就编码，则需要考虑风险。
[19] 设计说明书是否有足够的细节描述代码？
如果设计处于太高的层次，则需要考虑风险。
编码进度偏差
[20] 是否存在充分的时间进行编码？
如果在进度表中没有安排充分的时间进行编码，则需要考虑风险。
[21] 是否对项目组在编码时间和工作量方面的估计有意见？
如果过于低估你的工作量，则需要考虑风险。
[22] 编码的实际进度是否与计划相比有比较大的偏差？
如果编码的实际进度与计划相比有比较大的偏差，则需要考虑风险。
测试进度偏差
[23] 是否存在充分的时间进行全部的单元测试？
如果在进度表中没有安排充分的时间进行测试，则需要考虑风险。
[24] 如果进度出现问题，是否会妥协，对单元测试进行调整？
考虑谁将妥协，在什么模块，考虑什么可能被遗漏。
[25] 是否对项目组在编码时间和工作量方面的估计有意见？
如果过于低估你的工作量，则需要考虑风险。
[26] 测试的实际进度是否与计划相比有比较大的偏差？
如果测试的实际进度与计划相比有比较大的偏差，则需要考虑风险。
编码工具问题
[27] 开发语言是否适合开发的软件产品？
如果开发语言不适合开发的软件产品，则需要考虑风险。
[28] 项目组是否在开发语言、开发平台或是开发工具方面有足够的经验？
如果项目组在开发语言、开发平台或是开发工具方面没有良好的开发经历，则需要考虑风险。
编码缺乏配置管理
[29] 是否有代码的配置管理计划？
如果没有版本控制或是代码修改不受控，则需要考虑风险。
4. 集成和测试
集成和测试硬件支持不足
[30] 是否有足够的硬件做充分的集成和测试工作？
如果没有足够的硬件资源，则需要考虑风险。
集成和测试进度紧张
[31] 是否有足够的产品集成方面的说明，是否安排了充分的时间做集成工作？
需要考虑满足进度和足够测试覆盖率要求的风险。
5. 验收和维护
产品验收标准不一致
[32] 是否对全部需求的验收标准都已经达成一致？
如果不确切明了什么是用户所期望得到的，则需要考虑风险。
产品的可维护性不好
[33] 产品设计和相关文档是否可以充分满足另外一个组维护代码的要求？
如果产品设计和相关文档不能充分满足另外一个组维护代码的要求，则需要考虑风险。
6. 团队
员工经验不足
[34] 在项目组中是否有很多新员工？
如果新员工比较多，则需要考虑风险。
[35] 项目经理和开发组长的工作经验是否丰富？
如果项目经理或开发组长在以往没有相应的工作经验，则需要考虑风险。
员工流动性大
[36] 项目组成员在项目结束前是否有流动的可能性？
如果项目组成员在项目结束前有流动的可能性，则需要考虑风险。
内部缺乏交流
[37] 在项目组中是否缺乏方便的、有效的交流？
如果进度表与项目会议冲突，则需要考虑风险。
[38] 是否和上级缺乏有关项目的方便、有效的交流？
在缺乏完整的信息情况下，需要考虑工作产品的质量风险。
项目组内部合作缺乏氛围
[39] 项目是否以前合作过？
如果项目组不能很好的合作，或是以前没有很好合作的经历，则需要考虑风险。
[40] 项目组是否对任务有清楚的认识？
如果项目组内存在分歧，则需要考虑风险。
7. 成本
缺乏成本管理和跟踪
[41] 是否对成本有测量和跟踪？
如果没有对成本进行测量和跟踪，则需要考虑风险。
[42] 预算偏差
如果实际成本和预算有比较大的出入，则需要考虑风险。
8. 组织和管理
组织缺乏管理
[43] 组织是否有专门的人员负责管理？
如果组织没有人负责管理，则需要考虑风险。
决策者能力有限
[44] 管理层是否有威信，是否果断，决策人是否有很高的素质？
如果管理层没有威信，处理事务优柔寡断，素质不高，则需要考虑风险。
