Process Designer, Integrator and Quality Reviewer

Two of the four expanded roles the syllabus describes are covered here. Both are about the Requirements Engineer moving upstream — from consuming AI output to shaping the process that produces it.

AI process designer, integrator and technical collaborator

In this role, the Requirements Engineer:

Contributes to the selection of AI tools. Not merely accepting whatever the organisation licensed, but assessing suitability for specific RE tasks — classification, summarisation, quality checks.
Defines their integration into the RE process. Where in the workflow the tool sits, what it receives, what happens to what it produces.
Collaborates closely with technical teams — AI developers, data scientists, IT — to ensure tools are properly configured, trained and maintained.
Aligns input and output formats with the team's modelling and documentation standards.

Example from the syllabus: selecting an LLM for removing duplicate requirements, integrating it with the team's repository, and defining the rules for how duplicates are flagged and reviewed.

That example repays a second look, because the third clause is the one people skip. Selecting a tool is a decision. Integrating it is engineering. But defining how duplicates are flagged and reviewed is process design, and it is the part that determines whether the tool helps or quietly damages the baseline. A duplicate-detection tool that silently merges requirements is a different product from one that raises a flag for a human to adjudicate — and the difference is not in the model, it is in the rules the Requirements Engineer wrote around it.

Notice too that this role requires knowing what you learned in module 1. Deciding whether duplicate detection is an embeddings problem or a generation problem is tool selection. A Requirements Engineer who cannot make that distinction cannot perform this role.

Prompt designer and quality reviewer

In this role, the Requirements Engineer:

Crafts and refines prompts that guide AI towards relevant, precise and context-aware outputs.
Critically evaluates those outputs against domain knowledge, stakeholder needs and quality criteria.

And then the rule that sits under everything: this ensures that AI suggestions are never adopted without human verification.

Example from the syllabus: designing a prompt template for generating acceptance criteria that explicitly includes performance thresholds, and rejecting any AI-generated requirement that is not testable.

Again the second half carries the weight. Designing the prompt is the visible work. Rejecting output that fails a quality criterion is the responsibility. A Requirements Engineer who writes an excellent prompt and then accepts whatever comes back has performed half the role, and it is the half that does not protect anyone.

The two roles in this lesson meet in a single artefact: a prompt that the team owns, versions and improves.

Treating a prompt as a work product changes what you do with it:

It has an owner. Somebody is responsible for it being right, the way somebody owns a template or a checklist.
It has acceptance criteria of its own. "Generates acceptance criteria that always include a measurable threshold" is a testable property of a prompt, and you can check it against a set of known inputs.
It gets reviewed when its output degrades. If the same prompt starts producing weaker results — a plausible symptom of model drift, or of a provider changing a model behind the same name — the prompt is the artefact to inspect and adjust.
It encodes the quality criteria the team cares about, so those criteria are applied consistently instead of depending on who happened to type the request.

This is the practical form of the syllabus's methodological benefit from module 3. It is also what distinguishes a Requirements Engineer governing an AI-supported process from an individual who is good at using a chatbot.

🔗 Match the Pairs

Assessing whether a tool suits classification or summarisationDrop here

Defining how flagged duplicates get reviewedDrop here

Working with data scientists on tool configurationDrop here

Writing a prompt template that demands measurable thresholdsDrop here

Rejecting a generated requirement that is not testableDrop here

❓ Knowledge Check

A Requirements Engineer designs a careful prompt template for generating acceptance criteria, then adds the resulting criteria to the backlog unchanged because the prompt was well-designed. What is wrong with this?

📚 Flashcards1 / 4

Term

Governor of AI-supported processes

Click to flip

Definition

The syllabus's framing of the Requirements Engineer's expanded role: ensuring AI outputs are relevant, trustworthy, explainable and compliant with applicable rules and ethical standards. AI broadens and deepens the role rather than replacing it.

Click to flip back

💡Key Takeaway

AI moves the Requirements Engineer upstream. As process designer and integrator, they select tools, define where those tools sit in the workflow, set the rules for how output is flagged and reviewed, and work with technical teams on configuration. As prompt designer and quality reviewer, they craft the prompts and then reject what fails the quality criteria — because the defining rule of the role is that AI suggestions are never adopted without human verification.