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.
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?
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 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.
These flags stand in for common anti-patterns in the requirements phase. Consider if any of these may apply to your use case scoping: