MODULE 3 · LESSON 3
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolPrompting Techniques, and How They Differ From Patterns
Educational objective 3.2 has two halves. The previous lesson covered the first — the general purpose of patterns. This lesson covers the second: recognising how patterns and techniques differ. That distinction is the single most likely thing to be tested from this unit.
The distinction
Prompting patterns are reusable structures. They prescribe structure.
Prompting techniques are situational ways of phrasing prompts. Unlike patterns, they do not prescribe structure — they influence how the model interprets your request.
A compact way to hold it: a pattern is about the shape of the prompt; a technique is about the evidence you give the model to interpret it. They are not alternatives. The syllabus says they work together, providing a stable structure and situational flexibility.
The three techniques
Zero-shot — a request without providing any examples.
Read the interview transcript below and list every statement that
could be a functional requirement. Do not interpret or expand on
what was said.
Transcript: [transcript]
Zero-shot is the right default when the task is common and well represented in training data, and when you have no strong opinion about the output's exact form.
Few-shot — provide a few examples, then make your request.
Here are two examples of how we convert requirements into user stories:
Requirement: "Search tasks"
User story: As a user, I want to search tasks so that I can find items quickly.
Requirement: "Reset password"
User story: As a user, I want to reset my password so that I can regain access.
Now convert these:
- Assign priorities to a task
- Add comments to a task
- Filter tasks by status
Few-shot is disproportionately effective, and module 2 explains why. The model is highly sensitive to patterns, so a clear example of the output you want shifts the probability distribution towards continuations that match your template and your style.
This gives a specific, practical technique the syllabus recommends: if you need a requirement in a particular style, include a short example and ask the model to match it. You can go further and paste several user stories you wrote in the past, purely to set the tone and structure. You are not teaching the model anything — you are making your house style the most probable continuation.
Template-based — provide a structure the AI must use for its results.
Summarise the workshop notes below. Use exactly this structure:
1. Workshop title
2. Date and participants
3. Main goals (3-5 bullets)
4. Key insights (bullets)
5. Decisions taken (bullets)
6. Open questions and next steps (bullets)
Workshop notes: [notes]
Combining a pattern and a technique
In practice a good RE prompt is usually both. The pattern gives it a skeleton; the technique gives the model evidence about what "good" looks like.
Role: You are a Requirements Engineer working on a hospital
patient-monitoring system.
Task: Convert the stakeholder statements below into requirements
using our house phrase template.
Here is how we write them:
Statement: "Nurses need to know quickly if a reading is abnormal."
Requirement: The system shall alert the assigned nurse within 10
seconds of recording a vital sign outside the configured range.
Statement: "We can't lose data if the network drops."
Requirement: The system shall store readings locally and
synchronise them within 60 seconds of network availability being
restored.
Format: One requirement per statement, no commentary. Mark with
[UNGROUNDED] any requirement whose threshold you had to
invent rather than derive from the statement.
Statements: [statements]
That prompt uses RTF (a pattern) and few-shot (a technique) together. The examples do something no amount of description would achieve: they demonstrate that this team's requirements carry concrete, measurable thresholds. The [UNGROUNDED] instruction then makes visible the exact place where the model will be tempted to invent one.
There is a reason few-shot prompting deserves special attention in Requirements Engineering specifically.
Quality criteria for requirements — testability, unambiguous phrasing, measurable acceptance — are notoriously hard to convey in the abstract. Telling a model "write testable requirements" produces requirements that say they are testable. Showing it three requirements from your own specification that genuinely are testable moves the whole distribution.
The syllabus makes the connected point that you can also simply state the quality criteria you care about, and the model will often honour them, because similar instructions co-occur with those features in its training data. Doing both — stating the criteria and showing examples that exhibit them — is stronger than either alone.
The limitation is worth stating in the same breath. None of this makes the output correct. It makes the output shaped like your correct outputs. Whether the threshold in a generated requirement is the right threshold is a question only a stakeholder can answer, which is where chapter 5's insistence on human curation comes from.
Which statement correctly captures the difference between prompting patterns and prompting techniques?
Prompting technique
Click to flipA situational way of phrasing a prompt. Unlike patterns, techniques do not prescribe structure; they influence how the model interprets the request.
Click to flip backTechniques are situational phrasings that shape interpretation rather than structure: zero-shot asks with no examples, few-shot supplies a handful first, and template-based dictates the output's sections. Few-shot is especially powerful in RE because examples carry quality criteria that descriptions cannot. Patterns and techniques combine — the pattern gives the prompt its skeleton, the technique tells the model what good looks like.