序号

类型

内容

1

完整性

²  所描述的需求是否记录了需求的来源和提供者？联系人的姓名、电话、Email等资料是否填写详细？如不是公司人员，是否提供了工作单位、职务等？

²  对需求的详细描述是否具体和完整？

²  所描述的需求是否记录了需求的期望交付时间或者实现版本？是否有性能要求？

²  是否列出了所有与此需求有依赖和矛盾关系的其他需求？

²  是否给每项需求注明了编号

2

正确性

²  所描述的需求是否表达了客户和用户的真实需要？

²  对设计约束的描述是否正确？除此之外的需求是否独立于设计？

²  对用户任务或者操作流程的描述是否正确？

²  需求是否清楚明确、没有歧义

3

一致性

²  所描述的功能是否与应用定位一致？

²  需求与实际操作环境是否一致（包括环境要求的精度、事件的执行顺序等）

4

可测试性

²  每项需求是否清晰并可通过有效的方式验证（评审、原型、测试）？

²  是否说明了需求的验收方式、验收依据？验收标准是否可执行？是否为验收测试建立了明确的通过/失败准则

序号

类型

内容

1

完整性

²  是否反映了所有客户和用户的期望和需要？是否可以清楚地理解需求清单所表达的要求？是否说明了应用定位和操作场景？用户是否有安全性和保密性方面的要求？用户对界面是否有明确的要求？是否已经澄清了用户所有的细节问题？是否遗漏需求？需求是否不完整？

²  是否列出了用户需求的接收准则？是否已经去除多余的、不必要的或混淆的需求？是否明确了不期望的事件？是否描述了系统明确不包含的功能和原因？是否有必要通过原型法了解用户需求？

²  是否列出了需要跟踪的关键技术性能指标？是否已清晰定义关键需求，搞清楚主要的系统设计驱动因素？

²  需求分析是否已经充分而不至于对后续设计工作带来隐患，或者给用户带来意外？

²  操作流程的描述中，是否所有的步骤都是充分必要的？是否已将“必需有的”与“最好有的”需求区分开？

²  文档的编写是否符合模板的要求

2

正确性

²  用户需求的优先级是否正确？

²  涉及资源和性能的需求是否描述了相应的管理方式

3

可行性

²  需求实现的工作量是否与项目的费用、进度预算一致？

²  现有的技术水平是否可以满足需求实现的需要

4

一致性

²  各需求在内容描述上是否一致？所有需求的编写在详细程度上是否都一致或合适？

²  所用术语是否与用户的惯例一致？如果不一致是否可以被正确理解？

²  是否对不同用户的类似要求做了平衡和归一处理，或者做了特殊说明

5

可修改性

²  变更一个需求是否不会对其他的需求有重大影响？

²  是否对有依赖关系的需求进行了标识？

²  是否注明了外部引用的位置，并方便查找？外部引用是否正确、明确

序号

类型

内容

1

功能需求

²  是否详细定义了系统的全部输入/输出（来源、精度、取值范围、出现频率），所有输出格式（Web页面、报表等），硬件及软件的外部接口？

²  是否列出用户想做的全部事情？

²  是否定义了每个任务所用的数据，以及每个任务得到的数据？

²  是否说明了对每个输入的验证措施，并描述了每个输入的属性，如度量单位、边界值、时序要求等

2

非功能需求

²  是否为全部的操作，从用户的角度，详细描述了期望的响应时间？

²  是否详细描述了其他与计时有关的考虑，例如处理时间、数据传输率、系统吞吐量？

²  是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的接口变更能力

3

需求质量

²  需求使用用户语言描写的吗？用户也这么认为吗？

²  每条需求都不与其他需求冲突吗？是否详细定义了相互竞争的特性之间的权衡？

²  需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？需求是否在详细程度上保持相当一致的水平？有些需求应该更详细的描述吗？有些需求应该更粗略的描述吗？

²  每个需求条款都与待解决的问题及解决方案相关吗？能从每个条款上溯到它在问题域中对应的根源吗？

²  是否每条需求都是可测试的？是否可能进行独立的测试，以检验不满足各项需求

4

需求收集反思

²  我们是否已经与目标市场中的主要客户交流过？我们是否考虑了客户的潜在需求和未来的用户需求？正在进行中的访谈中，是否每个访谈的客户都很合适？我们是否收集了组织中会接触客户的每个人的需求？

²  我们学到了什么，是否有重大发现？是否有需要重复做的地方？

²  对于流程我们可以做哪些改进

5

需求收集要点

²  客户试图解决什么问题？顾客目前尚有那些等待解决的问题？客户有什么期望？客户对产品特征、属性、性能认为哪些是必须具备、有更好、可有可无、不需要？还缺什么？

²  什么是客户今天的需求？一年后、两年后、五年后的需求是什么？ 客户认为未来市场的变化趋势会是什么？五年后的市场将是什么样的？客户想怎样增长自己的业务？

²  我们产品最适合的客户群？现在我们给客户带来什么价值？优势和劣势是什么？如果客户重新选择将如何选择？针对本领域的产品客户最大的担忧是什么？

²  谁是我们的竞争对手？客户认为谁是我们的竞争对手（直接和潜在）？客户说我们竞争对手的优势和劣势

6

优先级考虑要素

²  需求是如何体现到产品功能、可用性、可靠性和性能中去的？

²  在进度约束下，需求实现后的效果是否值得？现实下需求是否带来风险？

²  该需求如果实现了，对进行产品维护的能力有什么影响？

²  检查开发进度，是否有时间完成所有高优先级需求

序号

类型

内容

1

需求变更

²  需求变更来源是否是可追溯的，有明确的来源，例如相关标准、规范、市场调研书等，并且代表客户的真实的需要？

²  基线中是否有需求与建议的变更相冲突？

²  建议的变更有哪些负面效应或风险，例如会导致产品单位成本的增加或对性能需求和其他质量属性产生影响？

²  需求是否影响到与其他产品或项目的依赖关系，例如是跨产品的需求变更，这些产品或项目是否分析对自身的影响？

²  从技术条件、员工技能、资源约束的角度看该变更是否可行？

²  建议的变更对项目计划中任务的执行顺序、依赖性、工作量、进度、资源和成本的安排有影响？

²  建议的需求变更是否影响任何市场营销、制造、培训或用户支持计划？

²  需求变更影响评估时是否参考了需求跟踪关系？

²  是否给出变更影响的配置项列表？这些配置项包括但不限于需求文档、设计和实现、测试用例、需求跟踪关系、培训材料、用户文档、帮助文件，并且所有影响分析的结果记录在需求记录表单中。

²  需求变更的流程是否符合要求，文档是否齐全