Prompt Patterns for Requirements Work: Six Patterns I Reuse Weekly

Prompt patterns for requirements work are reusable structures, not magic sentences. Six carry almost all the load: grounded extraction, format contract, adversarial review, gap interrogation, traceability check, and rewrite to testable. Every one of them specifies the sources, the output shape, and what to do when the source does not answer.

A prompt pattern is a reusable prompt structure with four fixed slots: the grounding sources, the transformation to perform, the exact output format, and the refusal behavior when the sources do not settle the question. Six patterns cover most requirements work: grounded extraction pulls requirements out of raw input, format contract forces the output into your template, adversarial review attacks your own document, gap interrogation finds what you left undefined, traceability check tests whether every requirement has a downstream artifact, and rewrite to testable converts loose statements into acceptance criteria. They work because they turn generation, which language models do unreliably, into transformation and criticism, which they do well.

I want to be direct about why the patterns matter more than the model. An analyst with a strong pattern and mediocre tooling produces a usable draft spec; an analyst with the newest assistant and a one-line prompt produces confident filler that a senior reviewer will shred. The whole game is in how much structure you impose. These patterns are the structure I actually reuse, and they are the backbone of The Technical BA Prompt Toolkit if you want the full set with worked banking examples.

Pattern 1: Grounded extraction

The foundation pattern. Every other pattern assumes it.

The structure: attach the source text, forbid outside knowledge, require a citation per output line, and define what happens when the source is silent.

Sources: the attached workshop transcript, the attached data dictionary.

Task: extract every functional requirement stated or implied in the
transcript.

Rules:
- Use only the attached sources. Do not use general knowledge of
  payments systems.
- Use only field names that appear in the data dictionary. If a
  field is discussed but not in the dictionary, name it as
  "UNMAPPED: <as spoken>".
- Every requirement must quote the transcript line it came from.
- Anything discussed but not decided goes in an OPEN QUESTIONS
  section. Do not resolve it.

Output: numbered requirements, each with a Source: quote.

The citation rule is the enforcement mechanism, and it is why this works. An invented requirement has no line to quote, so the instruction makes fabrication structurally awkward rather than merely discouraged. The UNMAPPED convention does the same job for field names: it forces the model to surface its uncertainty in a form you can scan.

The refusal behavior is the part analysts forget. A model with no instruction for silence will fill silence, because producing plausible continuation is what it does. Tell it explicitly that “undefined” is a valid and expected output, and you get the open-questions list that is worth more than the requirements themselves.

Pattern 2: Format contract

The structure: give one complete worked example of the output you want, then ask for the same shape applied to new input.

Describing a format in prose produces approximate compliance. Showing one filled-in example produces near-exact compliance, and exact compliance is what makes the output pasteable into your document instead of reformattable by hand.

Here is one requirement written exactly as our template requires:

  REQ-PAY-014
  Trigger:   An inbound pacs.008 fails creditor account validation.
  Behavior:  The system rejects the message and emits a pacs.002
             with status RJCT and reason code AC01.
  Data:      AC01 is written to the status event and the audit log.
  Excludes:  Messages already in REPAIR state, see REQ-PAY-021.

Now write REQ-PAY-015 through REQ-PAY-030 in exactly this shape,
from the attached spec section. Same fields, same order, same
labels. If a field has no content from the source, write
"Not defined in source".

Two details matter. The example must be a real one from your own documents, because a generic example teaches generic output. And “Not defined in source” must be permitted per field, otherwise the model completes the shape by inventing the missing line. The template library these examples come from is in Real-World BA Deliverables, and the underlying document structure is covered in the functional specification template.

Pattern 3: Adversarial review

The structure: attach your finished document, assign a hostile role, and ask for the attack.

This is the pattern I would keep if I could only keep one, because criticism does not require the model to supply facts it does not have. It only requires it to notice what your document fails to say, and that is a text-comparison task it is genuinely good at.

Three roles I rotate:

Role: a senior developer who has to implement the attached spec and
who will not ask clarifying questions. List every place where you
would have to guess, and state what you would guess. Be specific
about fields, states, and error paths.

Role: a tester who must write automated tests from this spec. List
every statement you cannot turn into a pass or fail assertion, and
say what is missing to make it assertable.

Role: a compliance auditor reviewing this design for a payments
regulator. List every decision the system makes that the spec does
not require to be logged, and every point where data is transformed
without an audit record.

The developer role finds ambiguity, the tester role finds untestable statements, and the auditor role finds the logging and traceability holes that are expensive to retrofit. I run the developer role on every spec before I issue it, and it typically returns four to eight legitimate gaps. Some are pedantic. Two or three usually matter, and they are the ones that would have come back as clarification tickets in sprint two.

The reason this pattern outperforms generation is worth stating plainly: you are asking a question whose answer is entirely contained in the document you supplied. That is the safe zone for this technology.

Pattern 4: Gap interrogation

The structure: attach the document and ask what a specific reader would still not know.

Attached: the functional spec for the repair queue.

Task: list the questions a new analyst joining this team next week
would still not be able to answer after reading this document.
Group them as: behavior gaps, data gaps, and operational gaps.
Do not answer the questions.

This differs from adversarial review in a useful way. Adversarial review asks what is wrong; gap interrogation asks what is absent. Absence is harder for a human author to see, because you know the answers and your brain supplies them while reading.

The instruction “do not answer the questions” is load-bearing. Left to itself the model will helpfully answer, and the answers will be invented, which pollutes a genuinely useful list with noise you then have to filter. The same approach applied to system knowledge instead of one document is how I keep my second brain honest.

Pattern 5: Traceability check

The structure: attach two artifacts and ask for the unmatched items in both directions.

Attached: (A) the requirements list, (B) the test case export.

Task: produce two lists.
1. Requirements in A with no test case in B that references them.
2. Test cases in B that reference no requirement in A.

Match on requirement ID only. Do not infer matches from similar
wording. If an ID is malformed, list it separately.

Bidirectional matching on identifiers is mechanical, tedious, and error-prone by hand across a few hundred rows. The instruction not to infer matches from wording is what keeps the output trustworthy: fuzzy matching is where a model will quietly pair a requirement with an unrelated test because both mention “validation,” and a false match in a coverage report is worse than a missing one.

This is the automatable core of the requirements traceability matrix. The matrix itself remains your artifact and your accountability; the model just tells you which rows are empty. For the full discipline of getting from business intent to traceable requirements, that is the ground From Vague BR to Functional Requirements covers end to end.

Pattern 6: Rewrite to testable

The structure: ask for each requirement rewritten with a trigger, an observable outcome, and a threshold, then ask for the test that would prove it.

For each attached requirement, rewrite it with exactly three parts:
- Trigger: the specific condition that starts the behavior
- Outcome: the observable result, stated as something a tester can
  see in a response, a database row, an event, or a log line
- Threshold: the measurable limit, where one applies

If a requirement cannot be rewritten this way from the source text,
output it unchanged with "NOT TESTABLE FROM SOURCE" and say what is
missing.

Then the second step, which is the one that actually finds the problems:

For each rewritten requirement, write the single test that would
prove it: the setup, the action, and the exact assertion.

Never ask a model whether a requirement is testable in the abstract; it will say yes. Ask it to write the test, and then read the test. When the assertion comes out as “verify the payment is processed correctly,” you have found a requirement with no observable outcome, and that discovery is the point of the exercise. This is the same principle that governs acceptance criteria for AI systems: an assertion you cannot execute is not a criterion, whatever it looks like on the page.

How should you store and improve your prompts?

Keep them as files in version control, one per pattern, alongside the notes they feed on. Three lines of metadata at the top of each: what artifact it produces, which sources it needs attached, and one note about the failure you fixed last time you used it.

This matters because prompting only compounds if it is written down. A pattern in a file gets improved deliberately, shared with a team, and re-run on a new document in nine months. A prompt typed into a chat window, tuned over four attempts, and closed with the tab teaches nobody anything, including you. Version-controlled prompts also make the improvement visible in git log, which is the same reason the second brain lives in git. Once a pattern is stable and you use it weekly, the next step is packaging it as tooling rather than a file you paste from: see Claude Skills for analysts.

Two operating rules that keep the whole practice safe. Mask data before it leaves your boundary: no customer names, account numbers, transaction references, or staff identifiers in any prompt, and know which tooling your organization has actually approved. And verify every factual claim in the output against the system, because these patterns reduce fabrication substantially without eliminating it. A pattern is a discipline, not a guarantee.

The takeaway

Six patterns cover requirements work: grounded extraction for pulling requirements out of raw input, format contract for making the output pasteable, adversarial review for attacking your own spec, gap interrogation for finding what is absent, traceability check for coverage, and rewrite to testable for acceptance criteria. Each one names its sources, fixes its output shape, and defines what to do with silence.

Start with adversarial review on the next spec you were about to issue. It costs two minutes and it will find something. Then build grounded extraction into your workshop routine. The full pattern set with banking and payments worked examples is in The Technical BA Prompt Toolkit, and the artifacts they produce have templates in Real-World BA Deliverables. Everything is at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Artificial Intelligence, Requirements, Prompt Engineering, Software Testing