回答。

问题背景： 在大型项目中，需求紧密相连：一个元素的变更会影响其他元素。分析师必须确保所有的依赖关系都被识别和管理，以避免在实施阶段出现意外故障。

问题： 经常会错过商业功能之间的隐藏联系（例如，报告与交易处理之间的关系），这可能导致错误、重复、未履行服务级别协议（SLA）和维护中的困难。

解决方案：

• 建立需求、用例、模块和测试用例之间的追踪矩阵（Traceability Matrix）。
• 使用依赖映射：通过图表可视化需求之间的关系（例如，需求关系图）。
• 与团队定期进行需求的联合审查： 在需求变更时，审查尤其关键。

关键特点：

• 依赖矩阵成为变更时的统一协议点。
• 联系不仅记录在需求之间，也记录在商业目标、架构模块和测试用例之间。
• 使用形式化减少主观错误的可能性。

陷阱问题

“仅用文本链接描述需求之间的依赖关系是否足够？”

不，文本链接不够直观，容易错过联系。重要的是使用图形或表格格式。

“在初步识别依赖关系后，是否可以不再进行审查？”

不，任何需求变更时都需要重新审视依赖关系——新的联系经常出现，旧的联系消失。

“依赖矩阵的存在是否意味着需求之间的冲突不可能？”

不，矩阵只是可视化工具；它有助于理清关系，但并不排除冲突，必须在会议和审批中手动解决。

常见错误和反模式

• 缺乏统一的依赖记录点（分散的文档）。
• 关系细节不足。
• 忽视依赖关系的可视化。

生活中的例子

负面案例： 在一个物流自动化项目中，规划路线和成本计算的依赖需求分别记录，导致在修改时发生冲突。

优点：

• 启动时分析节省时间。

缺点：

• 隐藏的错误，修正时浪费大量时间。

正面案例： 在类似项目中，分析师构建了追踪矩阵，并在专用仪表板上展示了关系。

优点：

• 变更影响透明，减少冲突。

缺点：

• 需要额外时间来更新追踪矩阵。