Functional Requirements: Examples, Template and How to Write Them

An analyst writes: “The system must quickly and conveniently show the customer the order status and not allow errors.” The developer reads “quickly” as “within a second,” the tester as “no spinner,” the business owner as “customers stop calling support.” All three agree with the sentence and mean different things by it. The argument will start at acceptance, when rework is already expensive.

A functional requirement is one sentence about what the system does, written so that it is understood the same way and verified by one test. Below is the formula for such a sentence, the very line about order status taken through four edits, and a requirements set template you can copy for yourself.

How a functional requirement differs from a business requirement is discussed in detail in the article how business requirements differ from functional ones. This article is about how to word one requirement.

The Formula for One Requirement

When [event or condition], the system shall [action] [object], [result or constraint].

Example: “When a customer opens the order page, the system shall show the current delivery status and the time it was last updated.”

The formula has four parts, and each has its own job. The condition says when the requirement applies; without it, it is unclear what to verify. “The system shall” fixes who acts: not the user, not an employee, but the system. The action and object are the behavior that will be visible from the outside. The result answers the question of how to know that everything worked.

A similar template — EARS, Easy Approach to Requirements Syntax — was created by Alistair Mavin and his colleagues at Rolls-Royce when they were analyzing requirements for a jet engine control system. It was first published in 2009. The idea is the same: a rigid order of parts and a few keywords instead of free text.

Not every requirement has a condition. “The system shall store the history of order status changes” always applies, and it does not need to start with “when.” But if a condition exists and is missing from the text, that is the first thing the tester will ask about.

One Sentence — From Bad to Good

Let’s take the line from the beginning of the article and put it through edits. At each step we remove one mistake.

Original sentence: “The system must quickly and conveniently show the customer the order status and not allow errors.”

Edit 1 — two requirements in one sentence. At least two requirements are hidden here: show the status and not allow errors. They cannot be verified by one test, and they cannot be postponed or cancelled separately. We split them:

• “The system must quickly and conveniently show the customer the order status.”
• “The system must not allow errors when showing the status.”

Edit 2 — evaluation instead of behavior. “Quickly” and “conveniently” are not verifiable: each reader has their own measure. Speed is a separate, non-functional requirement, and it must be written in numbers. “Conveniently” usually hides specific behavior — we ask the business owner which one. It turns out customers want to know how fresh the status is.

• “When a customer opens the order page, the system shall show the current delivery status and the time it was last updated.”

Edit 3 — negation. “Not allow errors” says what must not happen, but does not say what the system does instead. The developer does not know what to build, and the tester does not know what to check. We ask: which error is meant? It turns out that the delivery service sometimes does not respond, and the page shows empty space. We rewrite it into behavior:

• “When the delivery service does not respond, the system shall show the last received status and a note that it may be outdated.”

Edit 4 — implementation instead of behavior. During discussion, the developer suggests clarifying the first sentence: “The system shall request the status from the delivery service every five minutes and save it to the database.” This is not a requirement but a way to fulfill it. In a month, the delivery service will start sending notifications itself, polling will become unnecessary — and the requirement will have to be rewritten, even though nothing has changed for the customer. We keep what is visible from the outside and leave the method to the technical design.

Result: from one vague sentence we got two testable functional requirements and one non-functional requirement, about speed, which is written separately:

1. “When a customer opens the order page, the system shall show the current delivery status and the time it was last updated.”
2. “When the delivery service does not respond, the system shall show the last received status and a note that it may be outdated.”

These four mistakes were not invented for the example. The requirements standard ISO/IEC/IEEE 29148 explicitly lists what to avoid in wording: superlatives, subjective assessments, vague pronouns, comparisons, loopholes like “where possible” and negations. Every guide lists these rules, but one sentence shows how each of them changes the meaning.

Requirements Set Template

A single requirement does not live long if it has nothing to link to. That is why requirements are kept in a table: each has an ID that can be referenced, a source from which it grew, and a verification method.

Select the whole table and paste it into Confluence, Excel, or Google Sheets: the columns will be preserved.

What each column does:

• ID — a short number. It is referenced in tasks, test cases, and disputes: “FR-02 is not done” is clearer than retelling the sentence.
• Statement — one sentence built on the formula above.
• Source — the business requirement for which the function is needed. If the source cannot be found, that is a reason to ask why the requirement is on the list at all. This column supports traceability — how to build it is discussed in the article requirements traceability matrix: example and template.
• Verification criterion — what the tester will do and what they will see. If the criterion cannot be written, the wording needs to be edited again.
• Priority — here MoSCoW: Must, Should, Could, Won’t. Any scale that the team understands the same way will work.

What the template deliberately does not have: document sections, a title page, a glossary. That is document structure, not requirements. Which document is needed for a task is discussed in the article BRD, FRD, and SRS: which document is needed when.

Where a Functional Requirement Ends

If a requirement is written as a user story or a use case, the formula is the same; only the wrapper changes: how to choose between them is discussed in the article user story vs use case: the difference and which one to write.

What remained after edit 2 — “quickly” — is not a functional requirement. It says not what the system does, but how well. Such requirements are written separately and also measurably: response time in seconds, availability percentage.

How It Sounds in an Interview

In our bank of questions from real interviews, functional requirements — what they are and how they differ from business requirements — appear in 15 questions, and 7 of them are tagged as junior. The topic comes up already at the entry level.

A weak answer is a definition and a list of properties: “functional requirements describe what the system does; they must be complete, unambiguous, and verifiable.” True, but anyone who has read a textbook answers that way.

A strong answer shows the process. Take one bad sentence — for example, “the system must quickly and conveniently…” — and within a minute take it through edits: split it, remove the evaluation, replace the negation with behavior, separate behavior from implementation. Name the formula and say that every requirement has a source and a verification criterion. The difference is easy to hear: this person is not repeating a textbook but doing the work.