您可以使用检查点对元素进行复审。请只使用会影响工作空间的检查点。
需求检查点
您可以使用“问题”属性来输入要在复审元素时使用的问题。请编写问题,以使回答 Yes 表明元素已获得批准。在复审不同类型的元素(如,需求、使用用例、测试用例和问题报告)时,您可以使用以下检查点。
表 1. 需求检查点示例名称 |
问题 |
唯一性 |
需求的标题和标识是否唯一? |
可理解性 |
读者能否理解这些需求? |
冗余性 |
需求是否并不包含不必要的信息? |
完整性 |
所有属性是否都完整? |
歧义性 |
表述需求时的用词是否清晰明了? |
一致性 |
需求是否不会与其他需求及整体系统需求发生矛盾? |
组织 |
需求的分层级别是否正确? |
可跟踪性 |
需求是否具有源需求和目标需求? |
可测性 |
需求的完整性是否可通过测试、演示、复审或分析来进行验证? |
职责 |
是否已确定需求的负责人? |
语言 |
该需求是否并不包含语法错误以及难以验证的词汇(如,经常、至少和有时)? |
类型 |
该需求是否只是一个需求,而非设计或实施解决方案? |
重复 |
该需求的意义是否唯一? |
分割 |
该需求是否指定了一个定义明确的需求? |
分组 |
该需求是否是独立需求? |
范围 |
该需求是否在此项目的范围内? |
性能 |
是否已确定该需求的性能目标? |
引用 |
该需求的交叉引用是否正确? |
依赖性 |
如果该需求对于其他需求具有依赖性,是否已明确指定这些依赖性? |
使用用例检查点
表 2. 使用用例检查点示例名称 |
问题 |
离散性 |
该使用用例是否是一项独立的离散任务? |
目标 |
该使用用例的目标或可度量值是否明确? |
参与者 |
该使用用例的受益参与者是否已确定? |
级别 |
该使用用例是否是针对基本(抽象)级别(而非作为特定场景)编写的? |
类型 |
该使用用例是否包含设计和实施详细信息? |
处理方法完整性 |
是否已记录了所有的预期备选处理方法? |
异常 |
是否已记录了所有已知的异常条件? |
分割 |
是否存在任何可分割为独立使用用例的通用操作序列? |
歧义性 |
所编写的每种处理方法的对话序列是否都明确、没有歧义且完整? |
针对性 |
使用用例中的每一位参与者和每一个步骤是否都是以完成此任务为目标? |
处理方法可行性 |
使用用例中的处理方法是否可行? |
处理方法可验证性 |
使用用例中的处理方法是否可验证? |
测试用例检查点
表 3. 测试用例检查点示例名称 |
问题 |
输入和输出 |
测试用例中是否包含有关期望的输入和输出的完整描述? |
引用 |
是否已描述了针对该测试用例的所有依赖性? |
重复 |
是否只会对该情况进行一次测试? |
完整性 |
测试用例是否完整? |
歧义性 |
该测试用例是否不会引起歧义? |
再现性 |
该测试用例是否可再现? |
设计 |
该测试用例是否旨在证明存在故障,而非证明不存在故障? |
问题报告检查点
表 4. 问题报告检查点示例名称 |
问题 |
可理解性 |
读者能否理解该错误报告? |
完整性 |
所有属性是否都完整? |
歧义性 |
错误报告的用词是否清晰明了? |
重复 |
是否存在重复的错误报告? |
再现性 |
该错误报告中的错误是否可再现? |