在业务分析期间，规划计划需要确定项目需求的适当用例格式。 在高端，我们有一个多页的高度监管的要求模板。基础模型是单个演员和基本流程。 之间的是具有复杂流的教科书版本。本文在业务分析规划期间看出这些用例格式和设计对考虑的设计影响。   

使用案例格式

• 简单的流量用例
• 复杂的流量用例
• 高度规定的用例

简单的流量用例描述了单个演员沿一个基本流程的相互作用。 这种格式可以用作更复杂的努力的起点，作为规划目的的占位符，或者作为一个简单项目的最终可交付。 这种格式类似于用户故事，发布条件而不是福利。 

复杂的流量用例包括替代流程，触发器，业务规则，邮政和退出条件。复杂程度应由利益攸关方的需求和观点确定。 对于业务用户，文档必须是可读的，以便他们可以遵循并同意您已正确捕获其需求。 对于架构师和开发人员来说，细节必须足够具体来转化为开发单位。 对于测试团队，文档必须提供成功的清晰输入和输出，以便它们可以制定测试用例。 

高度规定的用例具有多页模板，具有批准的指令来完成每个部分。  有项目需要这样的纪律， 但我也曾在模板成为最终而不是手段的项目上工作， 细节程度减慢了项目并产生了浪费的文档。 

设计因素

使用案例格式将受到影响：

• 资助模式
• 要求复杂性
• 变革率
• 监管环境
• 项目方法论
• 项目阶段
• 建造或购买

资助模式

组织资助模式可能需要在项目开发阶段提前提供详细要求，以便竞争资金。 使用识别所有潜在步骤，备用流，业务规则和使用估算的用例可以有助于帮助成本估算。 紧密资金监督模型将要求更详细的文档而不是开放式型号。

要求复杂性

主要卖家的零售网页由于产品产品提供了很大且复杂，但系统要求本身是重复和可重复使用的，并且使用用户故事或简单的用例来轻松变化。

具有复杂需求的新系统需要比信息网页更详细的文档。   具有许多业务规则的新系统需要详细的文档和要求跟踪，以确保正确的覆盖范围。 集成系统需要一定程度的严格广告可追溯性，以确保前端变化不会破坏上游或下游系统，例如集成的重新订购或递送系统。 

变革率

零售网页是重复的，但需要快速变化以满足需求和营销计划。要求文件无法妨碍快速交付方式。 

从另一个角度来看，可以在变更管理过程中审查的详细要求文件可以帮助减慢急转送和防止令人尴尬的发布。

监管环境

由外部规定管理的系统需要详细的要求通过多个利益相关者读取和理解的详细要求，以便所有受影响的各方都能够理解和批准要交付系统的输入和输出。 收集个人信息的系统必须能够证明正在捕获正确的信息，并将到位适当的安全性以防止这些信息免受误用。

项目方法论

瀑布项目往往需要详细的要求。敏捷项目更倾向于最少的文档，用户故事和简单的使用情况如果有的话。  

项目阶段

文档详细信息可能会在项目阶段扩展或签约。 如上所述，项目可能需要详细的要求文档进行早期可行性和成本分析练习，但随后它们可能会降低到用户故事中的开发和交付。 其他项目可能只需要简单的用例来概述一个概念，然后在需求阶段期间展开用例流量和细节。

建造或购买

如果该项目包括构建或购买决定，那么在比较解决方案选项时，可以将可以转移到接受和评估标准矩阵的简单用例格式将是最有用的。 

概括

用例是有价值的商业分析工具，这些工具有多种味道。 作为业务分析规划的一部分，业务分析师应确定项目和利益相关者所需的严谨程度和细节，并选择在项目期间要使用的适当用例格式。