一条需求修改过几轮后，只看当前内容，很难判断是哪一次调整了描述或状态。Jama Connect可以比较同一工作项的两个版本。如果对比窗口里少了预期的记录，先确认那次改动发生在需求字段、关联关系，还是评审中，再到对应位置查找。

Jama Connect可以把项目中的需求导出为Word、Excel或PDF，也可以通过Office Template整理成固定格式的需求报告。导出后发现Description、自定义字段、负责人或关系信息没有出现时，先要区分使用的是普通导出、Office Template还是Velocity报告，因为这几种方式对字段的读取和模板控制不同。把导出范围、当前视图字段和模板字段逐项核对，通常就能找到缺失位置。

Jama Connect中的需求审批通常由条目状态流程和Review Center配合完成。状态流程负责规定需求可以从哪个状态切换到哪个状态，以及哪些用户有权执行切换；Approval Review负责收集评审意见、批准结果和电子签名。需求已经完成评审，却仍停在In Review或其他中间状态时，可以分别检查【Workflow】配置、【Approval Review】参与者状态和【Transition Permissions】，确认审批动作与需求状态转换是否真正关联。

在Jama Connect里，发起一次评审并不难，麻烦往往出现在评审进行之后：有人看到的还是旧版本，有人的评论只停留在Review Center，项目条目中却没有同步显示。Jama Connect评审中心怎么发起评审、Jama Connect评审意见没有同步是什么原因，需要从评审范围、参与角色、评论设置和修订发布几个环节逐一核对。

在项目进行需求评审的时候，或者在进行合规审查、问题追溯的时候，大家经常会碰到“Jama Connect审计记录怎么查看，Jama Connect审计记录导出不完整怎么办”这种问题；因为在Jama Connect系统里面，审计的信息并不是集中放在一个地方的，这些信息通常会分散在项目的活动流、单条工作项的活动记录、管理员的活动流、评审活动、基线活动以及电子签名记录里面；一般来说，普通用户平时只能看到工作项和项目的活动，只有项目管理员或者组织管理员，他们才可以查看到偏向配置变更的管理类审计记录。

在进行需求验证、测试覆盖以及追溯审查的时候，Jama Connect覆盖率怎么统计，Jama Connect覆盖率数据不一致怎么排查，这些问题经常会被碰到，在Jama Connect这个软件里面，覆盖率并不是靠单独填一个百分比数字来决定的，而是由用户设置的需求、测试用例、测试运行、上下游关系还有关系规则，它们共同组合来决定的，通常来说，判定一条需求是不是被“覆盖”到了，需要去查看这条需求有没有对应的验证项、测试用例或者别的下游关联内容，不能只看需求正文里面写没写测试说明。

怎么对Jama Connect的工作项进行批量修改呢，要是批量修改了之后字段却没更新要怎么处理呢，这都是大家平时在整理那些需求啊、测试用例、风险项或者评审条目的时候，很容易碰到的问题，其实在Jama Connect里面，工作项就是项目内容的最基础单位，看着只是改几个字段挺简单的，但是这里面会受到好多东西的影响，像是工作项的类型、对字段的权限、是不是被锁定了、工作流走到哪一步了，还有你是怎么导入进来的，不过系统里是支持在List View里面去对好多个同类型的工作项一起编辑的，也能用Batch edit的功能，一次性把好多个工作项的字段、下拉选项和标签给更新掉。

当需求、缺陷、测试用例还有变更项这些东西都被放到同一个项目里去之后，要是工作项的类型没有提前梳理好，等到要新建内容的时候，就很容易把模板给挑错了。在Jama Connect这款工具里面，所谓的Item Type，其实指的就是工作项的类型，它会直接决定一条条目的名称、里面包含哪些字段、显示什么样的图标、类型的编码是什么，以及它是拿来干嘛用的。一般来说，建立和修改类型这件事，是由组织管理员来负责的，而各个项目里到底能看见哪些类型，则由项目管理员去决定。并且需要留意的是，工作项的类型属于组织这一层级的配置，不能只针对某一个项目去单独改动它的结构。

需求、测试用例还有评审文档，经过好几轮改来改去之后，光靠把文件导出来再去人工一行一行地找差异，是很不现实的。想要把Jama Connect里的版本对比搞清楚，得先弄明白怎么操作版本对比这件事，以及版本之间的差异到底从哪里去查看，动手之前先得确认一下，我们这次要比较的对象到底是一条单独的需求、一整组用基线管起来的需求集合，还是某一次评审专用的版本。Jama Connect本身会给内容留下版本记录，它也可以通过基线把某一个时间点上的对象状态和它们之间的关联关系存下来，这个能力很适合在需求冻结、评审快要完成，还有版本快要发布之前，拿来做差异核对。

在Jama Connect里，测试不是一上来先建测试计划，而是先把测试用例作为item建出来，再把它们组织进测试计划、测试组和测试周期。官方帮助把这条链路写得很清楚：测试用例先创建并直接关联到要验证的需求，再创建测试计划，把测试用例加入计划并按组组织，之后在测试计划里创建一个或多个测试周期，系统会为周期里的每个测试用例自动生成test run，测试结果再回卷到test case status。