# 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 is no 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](../../notepad/overview/index.md) 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 does not carry through to user decisions