# Use case lifecycle

A use case is a **time-bound** effort by a **dedicated team** to deliver **new capabilities** on the platform for a set of **users**.

A use case is not “integrate source system X” or “apply ML technique Y”. Instead, a **use case** focuses on the *capabilities* we need to provide to our users, rather than the implementation details along the way. Framing development work as a use case forces us to confront the value proposition of our project immediately. Whose work life will improve as a result of this new capability? And what can we measure to know whether we have succeeded?

Along the way to building our use case, we will unlock many of the compounding features of Foundry, such as:

* **enriching data** through integration, data science techniques, and business logic;
* structuring a flexible, re-usable **data asset** as a digital twin of our organization and business processes;
* and creating **re-usable user interfaces** that close the operational loop by capturing decisions as data.

Holding our use case(s) and their outcomes as guides, we stay connected to real-world value, even as we get into the complexity of specific implementations throughout Foundry.

## Starting a use case

The craft of developing a use case on Foundry involves decomposing the **functional requirements** of the outcomes and choosing the implementation pattern(s) for each component.

The solution design process described below is an approach to this challenge. It focuses on distilling the use case requirements into a format that informs decisions about interface implementation and data enrichment. These decisions in turn inform the ontology design, which acts as the use case API and abstracts pipeline implementation details from the end user interactions.

In this way, the solution design framework encourages a holistic approach as depicted in the image below:

![data-model](../../../assets/426920ba42b08fb4f5c996c96563a5572087564dae5aaf1692b76504ad0d233b.webp)

Breaking the solution design into buckets around **transforming**, **structuring**, and **interacting** with use case data pivots the development process from purely user-centric requirements into platform-centric components. With this framework, we can then look at:

* Blueprints for commonly encountered patterns,
* Flags that indicate additional development complexity, and
* The default choice between available options and considerations for choosing alternatives.

We can also judge tradeoffs between development complexity and strict adherence to business requirements. Working through the solution design framework should make it possible to reevaluate priorities.

For example, suppose the original business requirement is to render a specific chart and include some specific form input, which may require odd ontology configurations and significant development effort in [**Slate**](../../slate/overview/index.md). If instead we created these functionally-equivalent visualizations and Actions (meet the functional requirement), then we can use Workshop at 1/10th the investment in front-end development and keep a cleaner ontology data structure.

The next section covers capturing a use case description and distilling these functional requirements.