答案。

最初，分析师单独记录需求，并不总是考虑它们之间的关系。这在小型系统中有效，但在大型IT项目中，需求之间关系的复杂性会急剧增加：数据依赖关系的出现、完整性违反、矛盾和级联变化，从而提高故障风险。

问题 — 需求之间缺乏或不明确的联系会导致遗漏功能模块、缺陷、阻塞任务和团队之间的不协调。常常一个需求发生变化，而相关的需求滞后，造成产品工作的问题。

解决方案 — 使用显式建模和依赖关系追踪的实践 (requirement dependencies mapping)。为此使用图表（例如，追踪矩阵（traceability matrix）、ERD），专用工具（Jama、Jira链接、DOORS），明确记录“父”需求和“子”需求及其对测试场景、架构和用户故事的影响。必须透明地记录所有依赖关系，并在与相关需求相关的每个更改时通知利益相关者。

关键特点：

• 在需求、测试用例和任务之间引入追踪矩阵
• 在更改时使用自动通知（变更影响分析）
• 在图表上可视化需求结构及其关系

隐含问题。

如果在需求中没有指定依赖关系，会发生什么？

回答：可能会遗漏关键连接（例如，一个需求无法在没有另一个需求的情况下实现），将出现阻塞、客户不满、测试负担增加。

在开始时仅一次收集依赖关系图是否足够？

回答：不够。依赖关系图必须在整个项目生命周期内保持最新状态。任何需求的变更都可能影响所有相关需求。

依赖关系只能是直接的（A依赖于B）吗？

回答：不。真实系统中常常存在交叉、循环和事务性依赖关系，以及通过共享资源或集成的影响。

常见错误和反模式

• 忽视显式建模依赖关系（所有事情“在脑海里”）
• 仅建模直接关系，忽视传递关系
• 对团队缺乏需求结构的可视化

生活中的例子

负面案例：在电子商务项目中，未反映不同支付渠道之间的依赖关系。更改一个模块时发生故障 — 部分订单未被处理。

优点：

• 最小的初始建模时间

缺点：

• 系统故障不明显
• 支持的事件数量增加

正面案例：为每个业务需求记录相关的技术需求，并建立追踪矩阵。在变更时自动向所有利益相关者发送通知。

优点：

• 及时识别潜在冲突
• 整个团队的工作透明度

缺点：

• 需要引入和培训新工具
• 维护文档的工作量增加