注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
在Foundry中开始新的开发工作之前，先简要描述应用案例。
通常，您的组织已经有一种首选的文档编写方法。如果没有现成的格式，请考虑这些提示作为方向性指导。
总结
应用案例是什么，努力的动机是什么？您将如何向熟悉您的组织但不熟悉此特定过程或团队的外行人解释其价值？
决策
最终决策是什么？中间决策是什么？哪些用户做出哪些决策？
对应方
应用案例的利益相关者是谁？他们从各自的角度关心什么？
功能需求
应用案例解决方案必须提供哪些能力？考虑以以下格式结构化它们：
[用户类型] [界面] [决策] [决策输入] [操作]
例如，一名路线运营分析师（用户类型）查看其负责路线的航班警报收件箱（界面），根据优先级、航班详情和组织影响（决策输入）分类警报（决策），以重新指派、解决或提升（操作）每个警报。
结果和关键绩效指标
可量化和定性的结果是什么？如何衡量结果？
背景和背景
目前这项工作是如何完成的？有哪些限制或痛点？
为协作技术写作和项目规划，考虑使用Notepad创建文档页面，并将其存储在项目的文档文件夹中。
功能需求是应用案例在能力方面必须提供的最详细描述。它是业务需求、用户故事、低保真模型、决策点分析等的提炼。
虽然没有单一的“正确”方法来捕捉这些需求，但以下格式有助于简洁地突出关键细节：
[用户类型] [界面] [决策] [决策输入] [操作]
考虑一个关于监控航线并根据警报改善性能的应用案例：
一名路线运营分析师（用户类型）查看其负责路线的警报收件箱（界面），根据优先级、航班和路线详情以及组织影响（决策输入）分类警报（决策），以重新指派、解决或提升（操作）每个警报。
一名路线分析师（用户类型）在一个临时、点选（界面）工具中对提升的警报进行根本原因分析（决策），根据历史航班模式（决策输入）推荐解决策略（操作）。
一名数据科学家（用户类型）在一个临时、点选（界面）工具中根据历史航班模式（决策输入）提出规则（决策），以生成航线警报（操作）。
一名区域经理（用户）使用总览仪表盘（界面）结合汇总的航班数据和第三方来源及建议（决策输入）识别趋势（决策），以进行战略投资（操作）。
以这种格式收集功能需求有助于理解用户意图，并在选择适合可用平台功能的实现模式时保持灵活性，而不是固定在特定的UI元素上。它还捕捉了生成决策输入（如可视化、指标、建议等）所需的数据丰富化的关键信息，以及用于建模数据和捕捉决策输出的Ontology结构。
这些标志代表需求阶段的常见反模式。考虑这些是否适用于您的应用案例范围界定：