From Ambiguous Requests to Testable Requirements

Hello! In the previous lesson, you used discovery to examine the work behind “Use AI to answer tickets faster.” You learned that agents may need to check whether a policy is current, that some replies require review, and that “faster” alone is not enough to define success. Those findings are useful, but they do not yet tell an engineer what the system must do—or tell a customer how to decide whether it works.

This lesson turns discovery findings into functional requirements (required system behavior) and acceptance criteria (observable conditions for accepting that behavior). You’ll use the support-assistant case throughout. The aim is a specification that a customer can recognize as their workflow and a delivery team can test, without prematurely prescribing a model or architecture.

Separate the request from the behavior

Consider the original request: “Use AI to answer tickets faster.” It names a possible technology and a desired improvement. It leaves open the essential behavioral questions: Who receives an answer—the agent or the customer? Which tickets qualify? What happens when the policy cannot support a reply? Who can send it?

A user story can preserve the reason for the work:

As a support agent handling a policy-related ticket, I want help preparing a reply based on current approved policy, so I can spend less time searching old answers and checking whether they still apply.

That is a useful statement of intent, not a complete build instruction. A functional requirement describes a capability or response the system must provide. For example: “When an agent requests a suggestion for an eligible ticket, the workspace presents a draft and identifies the approved policy section supporting its policy claims.” An acceptance criterion makes a particular requirement pass or fail against an agreed situation.

Watch how Functional Requirements and Specifications: A Quick Tutorial, from Bridging the Gap - Resources for Business Analysts, distinguishes documentation formats while keeping the focus on required software behavior. The format is less important than a shared understanding between business and technical reviewers.

For an FDE, this distinction prevents two opposite mistakes. “Improve support with AI” is too broad to implement or verify; “use a particular model, database, and prompt” may lock in a design before the customer has agreed on the behavior. Requirements should be specific about what happens at the user and system boundary, while leaving technical choices open unless a confirmed constraint demands them.

Make assumptions visible before writing rules

Discovery notes are not automatically agreed requirements. Suppose follow-up conversations establish the following illustrative pilot decisions:

• The pilot covers tickets marked as policy-related in the existing workflow.
• A policy owner identifies which documents are current and approved for the pilot.
• Agents receive draft replies but retain control over sending them.
• Some tickets are marked as requiring review; a reviewer must approve the final text before it can be sent. If that text changes, it needs approval again.

These are assumptions confirmed for this example, not facts established by the original customer request. Without such confirmation, “current,” “eligible,” and “requires review” would remain open questions. Record who can resolve each question rather than quietly choosing an answer in the specification.

Now write the functional requirements at a level where each describes a recognizable behavior:

Each row answers “What must the system do?” None says how to retrieve policy, generate text, or implement the approval state. Those choices matter later, but making them now would not resolve whether the proposed behavior is right.

There is also an important difference between functionality and the customer’s outcome measure. A pilot might satisfy every row yet fail to reduce handling time. Conversely, a faster reply is not acceptable if it cites an obsolete policy. Keep the functional contract and the broader success measure connected, but do not mistake one for the other.

Use examples to expose what a rule still hides

A requirement can look precise while leaving room for incompatible interpretations. Does “approved policy” include a document that was approved last month but has since been withdrawn? If the system finds an unrelated approved document, should it still draft an answer? Concrete cases expose these gaps.

Cucumber’s Gherkin Rules introduces example mapping: place a story above its behavioral rules, concrete examples below each rule, and unanswered questions alongside them. Read the “Example Mapping” section for the reasoning behind that structure; you do not need the later discussion of Gherkin tooling.

For the support-assistant story, FR-1’s rule might have an example involving an unused item delivered 20 days ago and a current approved policy that permits standard returns within 30 days. FR-2 needs a different example: the only document found was withdrawn, so no supported draft appears. FR-4 needs a case where an approved reply is edited afterward. These are not merely extra descriptions of the happy path; each tests a boundary where the behavior could otherwise be disputed.

A question card might say, “Who marks a document as withdrawn?” Until someone answers, you can still discuss the desired behavior when a document is withdrawn, but you cannot assume the team has all the information needed to implement and test it. Record consequential unanswered questions with an owner. Do not turn guesses into criteria just to make the document look complete.

Turn rules into pass-or-fail acceptance criteria

Atlassian’s Acceptance Criteria Explained defines criteria as conditions for completion, focused on results rather than implementation. Read its definition and quality guidance before examining the support example below.

One way to express a criterion is Given–When–Then: establish the starting conditions, identify an action, and state the observable result. Watch the scenario-oriented portion of Acceptance Criteria: How to Meet User Expectations from AltexSoft for the pattern. It is a writing aid, not a requirement to adopt a test framework.

Here is a compact set of criteria for the illustrative pilot. The test fixtures—a sample ticket, policy document, and review status—would be agreed with the customer before testing.

FR-1: A supported suggestion appears.

Given an eligible ticket asks whether an unused item delivered 20 days ago may be returned, and the current approved “Returns policy” permits standard returns within 30 days of delivery, when the agent requests a suggestion, then the workspace displays a draft addressing that question and identifies the document and “Standard returns” section.

Displaying a citation is not, by itself, proof that the citation supports the answer. For the agreed acceptance tickets, a policy reviewer should also be able to locate support for each policy claim in the cited section; an unsupported claim fails this criterion. This combines a check of the visible result with informed review of its meaning.

FR-2: An unsupported suggestion is withheld.

Given an eligible ticket for which no current, approved document contains a relevant policy, when the agent requests a suggestion, then the workspace displays no draft and states that no supported draft is available and the ticket needs manual handling.

Use a separate test fixture in which a withdrawn document contains a relevant answer. It should produce the same result. That case checks whether “current” has meaning in practice, rather than being a reassuring word in the requirement.

FR-3: The agent controls the outgoing reply.

Given a suggested draft is visible, when the agent edits its text, then the edited text is displayed for the agent to check and no reply is sent merely because a draft was generated or edited.

An explicit send action belongs to the workflow; generating a suggestion must not silently become customer communication.

FR-4: Approval applies to the text that is sent.

Given a ticket requires review and its reply has not been approved, when an agent attempts to send it, then the workspace blocks sending and shows that approval is required.

Given a reviewer has approved a reply for that ticket, when the agent changes its text, then the reply again requires approval before it can be sent.

The final case matters because “a reviewer approved this ticket” and “a reviewer approved these words” are different rules. The latter is what the illustrative pilot decision requires.

Check that the specification is usable by both sides

Before treating these criteria as ready for delivery, trace each one back to a discovery finding or an explicitly agreed pilot decision. Then read them from two perspectives. Could an agent or policy owner say whether the behavior fits their work? Could a tester construct the starting conditions, perform the action, and observe a pass or fail? If either answer is no, refine the wording with the relevant people.

A useful review catches several recurring defects:

• Subjective result: “The assistant gives a helpful answer.” Specify the kind of ticket, the supporting policy, and what the reply must address.
• Unstated boundary: “Use approved documents.” Add cases for no relevant document and a withdrawn document.
• Hidden design decision: “Search a vector database before calling the model.” Unless that mechanism is a confirmed constraint, keep it in technical design rather than user-facing acceptance criteria.
• False certainty: “All replies are reviewed.” Verify which replies require review and who sets that status.
• Unverifiable ambition: “The AI never makes a mistake.” Agree on representative test cases and a review method instead of claiming that a finite test proves perfection.

The resulting artifact need not be long. A story, a small set of numbered behavioral requirements, linked acceptance examples, and a visible list of unresolved questions can be more useful than a large document whose broad claims cannot be tested. It should also be revisable: if customer review changes the pilot boundary, update the requirements and their tests together.

Conclusion

An ambiguous request becomes deliverable when you distinguish intent from required behavior, then illustrate that behavior with pass-or-fail cases. For the support assistant, that meant specifying not only when a sourced draft appears, but also what happens without a valid source, who initiates sending, and how approval applies to edited text. Keep unconfirmed choices visible, and have customer and technical reviewers agree on the same observable outcomes.

The next lesson asks which of these requirements to tackle first. You’ll use impact, risk, effort, and dependencies to decide what belongs in an initial deployment rather than assuming every agreed requirement must be built at once.