需求内容已经变了，版本列表里却找不到预期的记录，先要弄清楚发生了什么操作。修改字段、转换状态、添加关联和发表评审意见，并不一定都以同样方式进入版本历史。Jama Connect提供版本与活动两类记录：前者适合对照保存过的内容，后者用于追查操作经过。把两边结合起来看，往往比只盯着版本号更容易找到原因。

　　一、Jama Connect如何查看需求项版本历史

　　从需求项本身进入历史，能减少看错对象的情况。打开后先核对ID和所在项目，再选择版本；名称相同的复用项，可能拥有各自的修改过程。

　　1、打开版本面板与历史内容

　　版本记录可以查看修改人、时间、自动生成的变更说明及用户填写的备注，还能找到包含相应版本的基线和评审。备注为空，只能说明没有填写这部分说明，不能据此认定没有保存记录。

　　①从项目树选择目标需求，进入单项视图，点击侧边工具栏中的【Versions】。

　　②在需求名称附近的【Version】下拉菜单中选择旧版本，查看当时保存的字段内容。

　　部分界面将入口称为版本历史，具体名称随部署版本变化。若入口没有出现，应检查当前项类型的组件配置；历史版本只供查看，不能直接在旧版本上编辑。

　　2、选择两个版本核对差异

　　查一次具体修改，宜先比较相邻版本。直接把最早版本与当前版本放在一起，能看到累计差异，却不容易判断每次修改发生在哪一步。

　　①在【Versions】面板的【From】列选择起始版本，在【To】列选择结束版本，点击【Compare】。

　　②在比较窗口中，按需点击【Hide Details】，切换到不显示逐字增删标记的并排视图。

　　起始版本在左侧，结束版本在右侧。默认内联比较中，删除文字以红色标示，新增文字以绿色及下划线标示。关闭细节后，页面主要突出有差异的字段，不宜把它当成完整的逐字修改记录。

　　二、Jama Connect历史版本缺少修改记录如何追溯

　　先记下有疑问的需求ID、字段及大致修改时间，再判断缺的是内容版本、操作记录，还是修改原因。这三种情况需要查的入口不同。

　　1、版本号没变，先查活动记录

　　添加关联、编辑、删除和恢复等操作，可以从活动历史中追查。若只在版本面板寻找，容易把“没有新增版本”误认为“没有记录”。

　　同时清除搜索词和活动类型限制，避免记录已经存在，却被当前筛选挡住。时间范围也应适当放宽，尤其是多人协作或通过集成工具更新时。

　　①回到需求当前版本，点击【Activity history】，查看相关时间段的操作。

　　②清除活动搜索及类型过滤，选择可疑记录，对照操作者和需求ID。

　　2、缺少状态变更版本，核对工作流设置

　　状态转换是否生成新版本，可以由工作流配置控制。若采用不随状态变化生成版本的设置，状态已经改变，版本号也可能保持不变。

　　这类问题应由组织管理员检查对应项类型的配置。当前配置只能帮助解释规则；若怀疑设置曾被调整，还需结合当时的配置依据，不能直接用今天的设置推断过去。

　　①由组织管理员点击【ADMIN】→【Organization】→【Workflow】。

　　②找到对应项类型，点击【Config】，检查【Versioning】下采用的是【Version on status】还是【Do not version on status change】。

　　3、确认是否在查另一个对象的历史

　　复用、同步或迁移后，文字相同的需求未必是同一个对象。原需求上的修改，不应仅凭名称就认为一定出现在复用项中。迁移数据也需要确认导入了哪些历史信息，不能默认原系统的全部修订已经带入。

　　旧部署还可能存在关闭自动版本记录的配置。若缺失集中发生在初始化或批量整理阶段，应由管理员结合当时版本和配置排查。现在重新启用记录，并不会自动补出过去没有生成的版本。

　　①点击【Synchronized items】，核对当前需求与其他复用项的对应关系。

　　②打开相关需求的【Versions】，按ID分别检查，避免把不同对象的记录拼在一起。

　　三、怎样把追溯结果核实清楚

　　找到一条操作，还不等于知道修改前后的完整内容。接下来应把操作时间、字段差异和当时的评审依据对应起来，缺少哪一部分就明确留下待查项。

　　1、利用基线和评审核对当时采用的版本

　　例如需要确认“评审时是否已经修改”，重点应是评审包含的需求版本，而非当前正文。版本面板中关联的基线、评审，可以帮助定位相应节点。

　　①在【Versions】面板找到目标版本，打开与其关联的基线或评审记录。

　　②返回【From】、【To】选择待核查的版本，点击【Compare】，对照争议字段。

　　评审意见提出了修改建议，并不代表建议已经写入需求。正文版本与讨论记录应分别核实，再判断后续是否完成修改。

　　2、保留证据，避免用恢复操作代替调查

　　若版本与活动中都没有找到足够信息，应整理需求ID、疑似时间段、操作者及字段，交由管理员结合导入或集成任务记录继续核查。有备份时，也应在受控环境中检查，避免覆盖现有数据。

　　单纯追溯时，不需要执行Make Current。该操作会把所选旧版字段内容作为一个新版本恢复为当前内容，并不会补回缺失的原始操作记录。

　　①在【Version】下拉菜单中选择需要核实的历史版本。

　　②回到当前版本，打开【Activity history】，保存与该次调查相关的记录及时间信息。

　　总结

　　历史里少了一条预期记录，未必意味着数据丢失，也可能是操作类型、工作流规则或对象身份不同。追溯结论应说清楚查的是哪条需求、确认了哪些字段变化，以及还有什么依据尚未找到。资料不足时，不宜仅凭版本号补写修改经过。希望这些方法能帮大家更准确地还原变更过程，减少重复查找。如有相关需求，欢迎联系交流。