答案。

问题的历史：

在自动化业务流程的早期阶段，客户常常没有完全理解或遗漏了一些重要的未正式记录的业务规则。这种规则缺乏清晰的记录会导致逻辑错误、不可预测的情况以及业务与IT之间的争议。

问题：

隐藏或隐性的业务规则难以识别：只有经验丰富的员工知道，可能仅在纸面上记录，或者根本没有记录。这增加了出现错误和冲突的风险，复杂了产品的测试和实施。

解决方案：

系统分析师应用：

• 与关键用户和专家的访谈
• 对事件和异常情况的分析
• 研究相关过程的规章、消息记录和邮件
• 通过案例建模和创建BPMN/UML图来识别漏洞

在收集规则后，分析师使用业务规则模板、决策矩阵、状态图和条件进行规范化。在需求变化时，持续更新文档。

关键特点：

• 积极邀请专家验证识别出的规则
• 使用模板格式进行描述（例如，决策表）
• 与客户协商和确认所有业务规则

设问陷阱。

可以认为客户在初始阶段提到的所有规则都是完整的吗？

不，重要的信息通常是隐藏的或被认为是理所当然的。需要深入分析和额外的讨论。

只有某些员工知道的规则一定要在项目中考虑吗？

不，只有在这些规则得到业务方面批准并且不违背战略目标时才可以考虑。否则，这可能会导致矛盾的来源。

仅仅在技术文档中记录业务规则是否足够？

不，还需要与专家进行验证，描述例外情况，协商措辞并纳入测试文档中。

常见错误和反模式

• 漏掉或误解的规则导致重复的修改
• 过于技术化的业务规则描述，没有关联到用户场景
• 缺乏业务客户对文档的批准

生活中的示例

负面案例： 分析师从客户那里记录了业务规则，但没有询问澄清问题和从专家用户那里获得反馈。在生产中遇到了未考虑的例外情况（例如，特殊付款情况）。 优点：

• 快速准备分析文档 缺点：
• 大量错误，紧急修改

积极案例： 分析师与专家用户进行了会议，为所有案例使用了决策表，并与多个利益相关者同步了最终措辞。 优点：

• 完整覆盖场景
• 最小化实施中的冲突 缺点：
• 准备和协调所花费的时间成本高