答案。

问题的背景：

常见的问题是用户场景的描述不完整或不结构化，这导致开发/测试团队多次将任务退回分析师，因为缺少转移、角色、错误处理条件的考虑。

问题：

用户流程和场景通常以任意风格描述，往往不是结构化的，也不是详尽的。结果是业务期望与实际实施之间存在不一致，而“返工”的任务推迟了进度。

解决方案：

系统分析师采用以下方法：

• 通过 用例模板 形式化场景：“主流程”、“替代流程”、“异常情况”。
• 使用 视觉图示：流程图、活动图、线框图/模型确保所有步骤的可视化一致。
• 定期进行演示和“现场演练”场景与团队。
• 记录每个场景的 验收标准，包括边界条件和非标准情况。
• 开发人员和QA的反馈影响场景的最终结构。

关键特点：

• 使用符号模板（用例，Gherkin场景），为描述提供结构。
• 对复杂分支和交互的可视化是必须的。
• 整个流程在记录到文档之前与业务、架构和开发进行一致性确认。

有陷阱的问题。

仅凭文本描述场景而不使用图示可以吗？

不可以，文本描述没有图示不方便理解和验证——通常会遗漏分支和替代流程。文本与图示的结合是经过验证的实践。

仅记录happy path（主成功场景）是否足够？

不够，大多数错误恰恰发生在替代和异常路径上。需要全面分析“如果……会怎样”。没有这些，无法实现稳定的解决方案。

可以在没有QA和开发人员参与的情况下编写用户流程吗？

不可以，缺少技术和测试方面可能会遗漏关键细节，这些问题会在后期浮现并需要返工。用户流程的工作是跨职能的任务。

常见错误和反模式

• 忽略场景中的排除情况和错误（仅关注成功路径）。
• 在分析用户流程之前就转向处理模型。
• 用户流程与验收标准之间缺乏联系。

生活中的例子

负面案例： 在电商项目中，分析师仅使用标准路径描述用户流程、购买流程——没有退货、取消和超时。在测试过程中出现了大量问题，需返工。

优点：

• 快速获得启动工作的文档。

缺点：

• 由于返工导致的期限延误。
• 重新编写场景。

正面案例： 在类似的项目中，分析师处理了分支和异常，绘制了每个操作的流程图，并定期收集QA和开发的反馈。

优点：

• 检查和场景接受过程快速通过。
• 最少的返工。

缺点：

• 初始处理需要更多时间。