用户需求规格说明书评审检查单_V1.0
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目名称
项目编号
项目经理
文档编号
文档版本
V1.0
编制
审批
EPG
修订记录：
版本号
修订人
修订日期
修订描述
V1.0
创建
用户需求规格说明书评审检查单
项目名称
项目编号
项目经理
检查者
文档名称
文档版本
检查日期
说明:
1.本检查单用于提供评审《用户需求规格说明书》时要关注的主要检查点，各项目在使用时也可根据项目特点在评审前对检查单进行裁剪。
3.
是否从用户角度定义了所有的外部接口的需求?
4.
是否列出用户想要系统做的全部事情?
5.
是否定义了每个任务所用的数据，以及每个任务得到的数据?
[评审每个任务本身所用到的数据是否明确定义，例如任务所用的数据表格等]
6.
是否从用户的角度，全面详细地描述了期望的响应时间、处理时间、数据传输率、系统吞吐量?
2.检查结论包括3种:
是：满足检查项要求；否：不满足检查项要求；免：该检查项对本项目不适用。
3.如果结论为否或免，需填写结论补充说明
4.本检查单用于评审《用户需求规格说明书》，主要的使用者有（不限于）业务部门、项目经理、系统架构师等，具体使用者请参考具体项目的计划确定
[说明：模板中以蓝色斜体显示的文本，用于向使用者提供指导，评审内容不局限于此部分]
序号
检查项
结论
说明
1.
是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率、验证措施等?
[评审人员根据《用户需求说明书》评审系统的全部输入方面的需求是否得到定义，同时评审《用户需求规格说明书》中提取后的这些需求是否有了详细定义，并由业务部门评审确认]
2.
是否详细的定义了系统的输出报表，等等）等?
[例如某项目中的非功能性需求包括“按钮操作少而明确”和“功能操作不超过三级菜单”可能会存在权衡]
11.
是否避免了在需求规定设计方案?
[《用户需求规格说明书》是对用户需求的提取，如果用户没有对设计的约束需求，则不能在《用户需求规格说明书》中存在设计方案，例如用户需求如果没有明确说明使用Oracle，则不能在《用户需求规格说明书》中出现]
7.
是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其它软件的接口变更能力?
8.
需求使用用户语言描写的吗？用户也这么认为吗？
[业务部门对《用户需求规格说明书》评审并给出评审意见；其他角色评审确认需求是否使用的是用户语言描写]
9.
每条需求都不与其它需求冲突吗？
10.
是否详细定义了相互竞争的特性之间的权衡?
12.
需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？
13.
需求是否在详细程度上保持相当一致的水平？有些需求应该更详细的描述吗？有些需求应该更粗略的描述吗？
14.
每个条款都有编号吗？
15.
需求是否可验证
[是否每条需求都是可测试的？是否可能进行独立的测试，以检验不满足的各项需求？]
16.
是否在全文档中表述一致？
[例如，《用户需求规格说明书》全文中相同含义的用词要一致；用例与用例不要重叠等]
17.
参考文档是否充分必要？
项目编号
项目经理
文档编号
文档版本
V1.0
编制
审批
EPG
修订记录：
版本号
修订人
修订日期
修订描述
V1.0
创建
用户需求规格说明书评审检查单
项目名称
项目编号
项目经理
检查者
文档名称
文档版本
检查日期
说明:
1.本检查单用于提供评审《用户需求规格说明书》时要关注的主要检查点，各项目在使用时也可根据项目特点在评审前对检查单进行裁剪。
3.
是否从用户角度定义了所有的外部接口的需求?
4.
是否列出用户想要系统做的全部事情?
5.
是否定义了每个任务所用的数据，以及每个任务得到的数据?
[评审每个任务本身所用到的数据是否明确定义，例如任务所用的数据表格等]
6.
是否从用户的角度，全面详细地描述了期望的响应时间、处理时间、数据传输率、系统吞吐量?
2.检查结论包括3种:
是：满足检查项要求；否：不满足检查项要求；免：该检查项对本项目不适用。
3.如果结论为否或免，需填写结论补充说明
4.本检查单用于评审《用户需求规格说明书》，主要的使用者有（不限于）业务部门、项目经理、系统架构师等，具体使用者请参考具体项目的计划确定
[说明：模板中以蓝色斜体显示的文本，用于向使用者提供指导，评审内容不局限于此部分]
序号
检查项
结论
说明
1.
是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率、验证措施等?
[评审人员根据《用户需求说明书》评审系统的全部输入方面的需求是否得到定义，同时评审《用户需求规格说明书》中提取后的这些需求是否有了详细定义，并由业务部门评审确认]
2.
是否详细的定义了系统的输出报表，等等）等?
[例如某项目中的非功能性需求包括“按钮操作少而明确”和“功能操作不超过三级菜单”可能会存在权衡]
11.
是否避免了在需求规定设计方案?
[《用户需求规格说明书》是对用户需求的提取，如果用户没有对设计的约束需求，则不能在《用户需求规格说明书》中存在设计方案，例如用户需求如果没有明确说明使用Oracle，则不能在《用户需求规格说明书》中出现]
7.
是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其它软件的接口变更能力?
8.
需求使用用户语言描写的吗？用户也这么认为吗？
[业务部门对《用户需求规格说明书》评审并给出评审意见；其他角色评审确认需求是否使用的是用户语言描写]
9.
每条需求都不与其它需求冲突吗？
10.
是否详细定义了相互竞争的特性之间的权衡?
12.
需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？
13.
需求是否在详细程度上保持相当一致的水平？有些需求应该更详细的描述吗？有些需求应该更粗略的描述吗？
14.
每个条款都有编号吗？
15.
需求是否可验证
[是否每条需求都是可测试的？是否可能进行独立的测试，以检验不满足的各项需求？]
16.
是否在全文档中表述一致？
[例如，《用户需求规格说明书》全文中相同含义的用词要一致；用例与用例不要重叠等]
17.
参考文档是否充分必要？