问题历史：
使用用例描述系统的方法论的出现和发展与需要统一和明确的方式来固定复杂解决方案的业务逻辑和用户场景有关。UML语言普及了用例图作为标准，从而提高了开发人员、业务和分析师之间的沟通透明度。
问题：
在实际项目中，简单地绘制方案往往是不够的—必须确保对需求的完整覆盖，场景之间的一致性以及详细到参与者和系统的步骤。大型系统拥有数百种变体、替代和错误，这会导致出现空白和冲突。
解决方案：
系统分析师必须形成用户和角色列表，全面描述他们的目标，识别主要和替代事件流，清楚记录假设并考虑错误处理的变体。为此使用场景表、图表、优先级属性，以及与利益相关者之间的审查工具。
关键特点：
能否仅限于主要场景而不记录替代流？
不能，忽视替代和例外流会导致场景不完整，实施时风险高。
仅处理接口交互是否足够，系统内部行为可以忽略？
不能，系统行为缺乏详细说明（例如，“数据被验证”而没有解释条件）可能导致实现时的误解和模棱两可。
将所有场景描述在一个用例文档中以节省时间是否始终是好习惯？
不是，过度聚合场景降低可读性，难以测试和维护需求。
负面案例：仅描述了主要流（Happy Path），未考虑电商系统中的支付错误。
优点：
缺点：
积极案例：用例详细描述了分支—替代、错误、取消、边界状态。
优点：
缺点：