答复。

问题背景：

在传统和敏捷项目中，对分析文档的要求不同：有些需要详细的规范和类图，有些则只需简单的表格/草图。许多组织都有自己的模板，但文档的实际价值取决于其相关性和适用性。

问题：

缺乏标准文档集导致混乱（“什么时候画什么？”），而过多的文档则导致官僚主义和陈旧的文档，团队不再使用。分析师经常在没有与开发人员和测试人员协商的情况下创建“看似必要”的文档。

解决方案：

一个合格的系统分析师：

• 与团队和客户进行启动会议，了解他们的痛点和方便的文档格式。
• 制定文档的责任矩阵（RACI）：谁需要什么文档，谁负责维护，在哪个阶段。
• 与架构师和负责人协商，决定在哪里需要使用类图（用于复杂逻辑），而在其他情况下仅需BPMN流程或原型。
• 在项目进行过程中不断明确和审视文档的集合——相关性高于完整性。

关键特点：

• 没有通用的文档集合：不同项目需要不同的文档。
• 沟通和共同协商是成功的基础（共享所有权）。
• 每个文档应解决特定问题，保持活力并得到维护。

反向提问。

是否可以在所有情况下仅使用一种类型的图表（例如，仅使用BPMN）？

不可以，每种图表或文档揭示了系统的不同方面：BPMN用于流程，UML用于对象和交互，表格用于目录。组合使用是最佳实践。

是否总是需要详细的需求规范文档？

不一定。在初创公司、试点项目和敏捷项目中，简单的文档并结合backlog可能就足够了——重要的是团队理解任务。

分析师是否可以要求团队遵循其文档模板？

不可以。文档的格式和模板应该在与团队和客户的讨论和协商中产生，必须对所有参与者都方便。

常见错误和反模式

• 从其他项目机械地复制完整的文档包。
• 为了创建文档而创建文档。
• 忽视团队反馈，拒绝使用相关文档。

生活中的例子

负面案例： 系统分析师在企业项目中为每个流程实施了6种不同的图表。团队陷入文档的海洋，没人阅读它们，都是根据口头任务工作。

优点：

• 渴望高层次地规范系统。

缺点：

• 时间浪费，混乱。
• 实施时文档不准确。

正面案例： 在另一个项目中，分析师只记录了BPMN图和短表格，定期根据与开发人员的会议结果进行更新和调整。

优点：

• 最低限度所需的文档集合。
• 文档被团队实际使用。

缺点：

• 有时外部审计员需要额外的报告和图表。