Distilling functional requirements（提炼功能需求）¶
Before starting a new development effort in Foundry, write a quick description of the use case.
Often, your organization already has a preferred approach to this type of documentation. Consider these prompts as directional guidance if there isn’t a format in place.
Use case overview template¶
Summary
What is the use case and motivation for the effort? How would you explain its value to a layperson familiar with your organization but not this specific process or team?
Decisions
What is the ultimate decision being made? What are the intermediate decisions? Which users go with which decisions?
Counterparts
Who are the use case stakeholders, and what do they care about from their perspectives?
Functional Requirements
What capabilities must be provided by the use case solution? Consider structuring them in the following format:
[User Type] [Interface] [Decision] [Decision Inputs] [Action]
e.g. A route operations analyst (user type) reviews a flight alert inbox (interface) for their responsible routes and triages alerts (decision) based on priority, flight details, and organizational impact (decision inputs) to re-assign, resolve, or escalate (action) each alert.
Outcomes and KPIs\ What are the quantifiable and qualitative outcomes? How is the outcome measured?
Background and Context\ How is this work currently accomplished? What are the limitations or pain points?
:::callout{theme="success" title="Capturing technical documentation"} For collaborative technical writing and project planning, consider Notepad to create documentation pages and storing them in a Documentation folder in your Project. :::
Functional Requirements¶
Functional requirements are the most granular description of what a use case must provide in terms of capabilities. It is the distillation of business requirements, user stories, low-fidelity mocks, decision point analysis, etc.
While there is no single “right” way to capture these requirements, the following format helps highlight the key details succinctly:
[User Type] [Interface] [Decision] [Decision Inputs] [Action]
Consider a use case around monitoring flight routes and improving performance based on alerts:
A route operations analyst (user type) reviews an alert inbox (interface) for their responsible routes and triages alerts (decision) based on priority, flight and route details, and organizational impact (decision inputs) to re-assign, resolve, or escalate (action) each alert.
A route analyst (user type) performs root cause analysis (decision) on escalated alerts in an ad hoc, point-and-click (interface) tool based on historical flight patterns (decision inputs) to recommend resolution strategies (action).
A data scientist (user type) proposes rules (decision) in an ad hoc, point-and-click (interface) tool based on historical flight patterns (decision inputs) to generate route alerts (action).
A regional manager (user) identifies trends (decision) using an overview dashboard (interface) with rolled up flight data and 3rd party sources and recommendations (decision inputs) to make strategic investments (action).
Collecting functional requirements in this format encourages understanding of the user intent and leaves flexibility to choose implementation patterns that fit available platform functionality, rather than anchoring on specific UI elements. It also captures key information to understand the data enrichment needed to produce the decision inputs like visualizations, metrics, recommendations, etc. as well as the ontology structure to model the data and capture decision outputs.
Flags¶
These flags stand in for common anti-patterns in the requirements phase. Consider if any of these may apply to your use case scoping:
- Insufficient investigation into current pain points
- Requirements anchored on specific UI elements
- Focus on too narrow a set of users
- Scoping doesn’t carry through to user decisions
中文翻译¶
提炼功能需求¶
在 Foundry 中开始新的开发工作之前，请先快速描述用例。
通常，您的组织已有偏好的文档编写方式。若尚未建立固定格式，可将以下提示视为方向性指导。
用例概览模板¶
摘要
该用例是什么？开展此项工作的动机是什么？如何向了解您组织但不熟悉此特定流程或团队的非专业人士解释其价值？
决策
最终需要做出什么决策？中间有哪些决策环节？不同用户对应哪些决策路径？
相关方
用例的利益相关者是谁？他们从各自角度关注哪些问题？
功能需求
用例解决方案必须提供哪些能力？建议按以下格式组织：
[用户类型] [界面] [决策] [决策输入] [操作]
例如：航线运营分析师（用户类型）在航班预警收件箱（界面）中查看其负责航线的信息，基于优先级、航班详情和组织影响（决策输入）对预警进行分类处理（决策），最终重新分配、解决或升级（操作）每条预警。
成果与关键绩效指标\ 可量化与定性的成果有哪些？如何衡量成果？
背景与现状\ 当前如何完成此项工作？存在哪些限制或痛点？
:::callout{theme="success" title="技术文档记录"} 如需进行协作式技术写作和项目规划，可考虑使用 Notepad 创建文档页面，并将其存储在项目中的 Documentation 文件夹内。 :::
功能需求¶
功能需求是对用例必须提供的能力最细粒度的描述。它是业务需求、用户故事、低保真原型、决策点分析等内容的提炼。
虽然记录这些需求没有唯一的"正确"方式，但以下格式有助于简洁地突出关键细节：
[用户类型] [界面] [决策] [决策输入] [操作]
以监控航线并根据预警改进绩效的用例为例：
航线运营分析师（用户类型）在预警收件箱（界面）中查看其负责航线的信息，基于优先级、航班与航线详情、组织影响（决策输入）对预警进行分类处理（决策），最终重新分配、解决或升级（操作）每条预警。
航线分析师（用户类型）在临时性、点击式（界面）工具中，基于历史航班模式（决策输入）对升级的预警进行根因分析（决策），以推荐解决方案（操作）。
数据科学家（用户类型）在临时性、点击式（界面）工具中，基于历史航班模式（决策输入）提出规则（决策），以生成航线预警（操作）。
区域经理（用户）通过概览仪表盘（界面），利用汇总的航班数据、第三方来源及建议（决策输入）识别趋势（决策），以做出战略投资决策（操作）。
以此格式收集功能需求，有助于理解用户意图，并为选择符合平台功能的实现模式留出灵活性，而非局限于特定 UI 元素。同时，它还能捕获关键信息，以理解生成决策输入（如可视化、指标、建议等）所需的数据增强，以及用于建模数据和捕获决策输出的本体结构。
警示标志¶
以下标志代表需求阶段常见的反模式。请考虑这些情况是否适用于您的用例范围界定：
- 对当前痛点调查不足
- 需求局限于特定 UI 元素
- 用户范围过窄
- 范围界定未延伸至用户决策