02 · Framing the problem
Clarifying requirements
3 min read
A request to build an ML system usually leaves some questions unanswered. Before choosing a model, we need to understand what the system should do and what it must support. Clarifying requirements means asking these questions and agreeing on the answers before starting the design.
Understand what the feature should do
Start with the person using the feature and what they are trying to do. A request such as “suggest books” could mean helping a reader find their next book or helping a shop decide what to stock. These need different inputs and produce different results.
Ask questions that help distinguish between these possibilities. Once the purpose is clear, describe what happens when someone uses the feature, from the information they provide to the result they receive.
- Who will use the result? Find out whether it is meant for a customer, an employee, or another part of the application.
- What should they receive? Agree on whether the result is a number, a category, a list of suggestions, or something else.
- When is the result needed? Find out what triggers the request and whether someone is waiting for the answer.
Agree on what is included
A broad feature can grow into several separate problems. For book suggestions, we might include recommendations based on books a reader has rated, while leaving book search and written reviews outside this design. State these boundaries so the rest of the discussion stays focused.
Missing information should remain visible. If the request does not say whether new readers need suggestions, ask about it. If an answer is unavailable, state the assumption you will use and explain what would change if it turns out to be wrong.
Check the data and limits
Knowing the desired result is only part of the problem. We also need to know what information is available and the conditions the system must work under. At this stage, identify the important limits without deciding how to implement them.
- Available data. Ask what records already exist and whether they can be used. A design based on reader ratings depends on those ratings being available.
- Expected demand. Ask roughly how many people will use the feature and how often. We will work through the estimates in a later topic.
- Response time. Replace words such as fast with an agreed time target when possible. A result needed while a page loads has a different deadline from a weekly email.
- Rules and missing information. Check which results are allowed and what should happen when information is missing. For example, decide whether unavailable books can appear and what new readers should see.
Write a short problem statement
Bring the answers together before moving on. A useful summary names the user, the input, the output, and the main boundaries. Keep confirmed requirements separate from assumptions and questions that still need an answer.
For a small example, suppose we agree to suggest up to ten available books when a reader opens the home page, using their past ratings. Readers without ratings receive a general list. Book search and written reviews are outside the design. We still need to confirm the expected traffic and response deadline.
This gives us a specific feature to design without choosing a model too early. The next topic explains how to define what the model should predict and how to measure whether the feature helps the reader.