How To Write App Requirements AI Can Understand

To write clear app requirements, describe what should happen when someone uses each feature. Include the expected result, the rules that apply, and what the app should do when an action cannot be completed.

A requirement is a statement of what the app needs to do or a condition it must meet.

You do not need a long technical document to begin. A few clear statements and examples can remove uncertainty before AI turns your idea into code.

In the previous blog, we chose the smallest complete experience for a personal errands app: enter a task, save it, and find it again later.

Now we need to explain how those capabilities should behave.

Turn Each Feature Into A Clear Description

“Add a task” names a feature. It leaves several decisions open.

Does pressing Add immediately create the task? Is a name required? What appears afterwards? What happens if the app cannot save it?

A clearer description connects the person’s action with the expected result:

“When the person enters a task name and presses “Add”, the app saves the task and displays it in the list.”

This gives AI more direction. It also gives you something specific to assess later.

The difference is useful across many kinds of apps:

• Feature: Search recipes.
• Requirement: When someone searches for an ingredient, show recipes that include it.

Or:

• Feature: Calculate a total.
• Requirement: Add the prices of all items in the basket and display the combined amount.

Each statement explains behaviour instead of simply naming a capability.

Include The Starting Situation

The same action can produce different results depending on what is already happening.

Pressing Add with a task name entered is different from pressing it when the field is empty.

A useful requirement can describe three connected parts:

1. Situation: What is true before the action?
2. Action: What does the person do?
3. Result: What should happen afterwards?

For example:

“When the task name field is empty and the person presses “Add”, no task is created. The app explains that a task name is required.”

This format helps you think through behaviour without needing to describe the code behind it.

Use it where the starting situation makes a difference. There is no need to force every requirement into the same wording.

Make Important Rules Explicit

Rules determine which actions are allowed and how the app handles them.

For our errands app, you might decide:

• A task must have a name.
• A name containing only spaces counts as empty.
• Two tasks may have the same name.
• Newly added tasks appear at the top of the list.

These are design choices for this example. Another app could reasonably use different rules.

What matters is making the choice clear.

Consider duplicate names. A person might enter “Buy groceries” on two separate occasions. If you have not decided whether that is allowed, AI may reject the second task, replace the first, or create another one.

An explicit rule removes that uncertainty:

“Allow tasks with the same name. Adding a new task must not replace an existing task.”

You are describing the behaviour you need. The technical approach can be worked out later.

Explain What Happens When An Action Fails

A requirement should cover ordinary situations in which the intended result cannot be delivered.

For example, saving a task might fail. The app then needs to communicate what happened and leave the person in a useful position.

You could specify:

“If saving fails, explain that the task was not saved. Keep the entered text available so the person can try again.”

That statement addresses connected concerns: accurate feedback, preserving the person’s effort, and providing a next action.

Different situations need different responses:

• An empty field may need an explanation of what to enter.
• A search with no matches may need a clear “no results” message.
• An unavailable service may need a retry option.
• An action still in progress may need a visible indication that the app is working.

You do not need to imagine every possible failure at this stage. Begin with the ordinary conditions that could prevent the central journey from working.

Describe What People Should See And Understand

Requirements also cover how the app communicates its state.

Suppose someone opens the errands app for the first time. There are no tasks yet.

“Display the task list” does not explain what that person will see. A more complete requirement might say:

“When there are no tasks, display a message explaining that the list is empty and show where to add the first task.”

This helps someone understand the screen without needing instructions from you.

Avoid vague wording such as “make it intuitive” when you can describe the intended behaviour. For example:

“Label the task creation button Add task.”

You can still refine the wording or appearance later. The requirement makes the immediate intention understandable.

Record Constraints That Affect The Solution

A constraint is a limit the solution must work within.

For the first version of our example app, you might specify:

“People must be able to add and view their errands without an internet connection.”

That affects which approaches can support the experience.

Other constraints could concern supported devices, accessibility needs, or what information the app may collect. Record those that matter to the agreed scope.

Some constraints may require further research. If you do not yet know which accessibility or privacy requirements apply, record that as an open question rather than allowing an assumption to become a settled decision.

Use Examples To Remove Ambiguity

Examples make a requirement easier to interpret.

For a basket total, “calculate the correct amount” leaves the expected result unstated. A concrete example is clearer:

“If the basket contains one item priced at $10 and another priced at $5, the displayed total is $15.”

You can add examples that reveal an important rule:

“If the basket is empty, display a total of $0.”

These examples provide reference points for later checks. They do not cover every possible situation, but they help establish what the requirement means.

The observable conditions used to decide whether work is complete are often called acceptance criteria. In plain language, they describe what must be true for you to accept the result.

Keep Decisions And Open Questions Separate

You will not know every answer immediately.

A short requirements note can distinguish:

• Decided: Tasks need a non-empty name.
• Decided: Tasks with identical names are allowed.
• Open question: Should there be a limit on task-name length?

This helps AI recognise where it should follow a decision and where clarification or a suggestion is still needed.

You can ask:

“Review these requirements for missing decisions or conflicting rules. List any assumptions you would need to make before building.”

Use the response to improve the description while keeping the first version’s agreed scope in view.

You now have three connected foundations: the result the app should deliver, the experience included in its first version, and the behaviour that experience requires.

In Chapter 3, we will look at the main parts of an app and how they work together to deliver those requirements.