答案。

历史上，需求收集的方法被认为是线性的：分析师与不同的利益相关者进行沟通，形成愿望清单，并将其整理成规范。实际上，项目越大，越难以识别和追踪不同利益相关者的需求之间的交叉、重复和直接矛盾的任务。

问题

在大规模系统中，通常会出现：

• 不同部门之间的需求矛盾（例如，安全性 vs 便利性）；
• 重叠和重复（不同团队从不同角度希望得到相同的东西）；
• 隐藏的依赖关系（一个变更会引发其他变更）。

在分析阶段的错误可能导致实施时的冲突、工期延长、无效机制或模块无法集成。

解决方案

专业的系统分析师不得不使用以下技术：

• 构建依赖关系矩阵（例如，"需求追踪矩阵"）和模型（UML图，ER图）；
• 在对立的利益相关者组之间举办工作会议和审查会；
• 使用“需求冲突解决”技术（例如，促进会议）；
• 引入追踪工具，使每个阶段都能看到需求之间的关系（例如，API需求和针对相同操作的安全需求）；
• 定期更新和优先级设定需求。

关键特点：

• 矩阵和图表在复杂项目中是必不可少的。
• 冲突解决是分析师的责任。
• 隐含依赖通过建模和沟通被揭示。

有陷阱的问题。

需求优先级设定是否是解决矛盾的一种方式？

不是，优先级设定是实现顺序的排列。矛盾必须在将其放入待办事项列表之前通过协商、妥协或重新审视需求来解决。

是否可以仅通过自动化工具识别所有关系？

不可以，自动化（例如，追踪工具）有帮助，但嵌套的商业含义、过程的细微差别和隐藏的冲突只能通过与真实的利益相关者讨论来固定。

需求的交叉是否意味着其中一个必定是多余的？

不是，需求在表述上可能重叠，但有不同的最终目标。需要检查含义并寻找聚合或展开的机会。

常见错误和反模式

• 匆忙合并矛盾的需求（删除一个便会打破业务场景）。
• 不固定关系 — 在补充时，旧的需求被“丢失”和破坏。
• 仅依赖文档而不进行实时沟通。

生活中的例子

负面案例： 在银行的CRM系统中，两个部门独立要求实施“快速客户搜索”。需求分别实现，没有发现重复 — 导致了两个不同的搜索和混乱的场景。

优点：

• 每个部门单独满意

缺点：

• 界面不一致
• 支持增长
• 项目成本增加

正面案例：分析师组织了与关键需求片段的研讨会，建立了依赖关系矩阵，逐步与客户和执行者协调场景。

优点：

• 减少了错误数量
• 可预测的结果
• 跨职能的场景

缺点：

• 更复杂和耗时的分析阶段
• 需要促进技巧