MODULE 7 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolFormulating Requirements
Formulation transforms raw stakeholder input into clear, structured requirement statements suitable for implementation and validation. AI enhances this by supporting standardisation, maintaining terminological consistency, and decomposing complex requirements into manageable components.
Applying standardised templates
Generative AI can support the use of standardised IEEE templates and phrase templates by automatically structuring requirement statements according to established syntactic patterns and formatting guidelines.
It can take informal stakeholder input or preliminary requirement descriptions and transform them into properly formatted individual requirements following standards such as ISO/IEC/IEEE 29148, ensuring consistent structure and improving overall specification quality.
Module 2 explains why this works so well: requirements templates are among the most repetitive structures in professional writing, so they are exactly what a pattern-matching system reproduces reliably.
Eliminating common pitfalls
AI can suggest appropriate conditional clauses, specify measurable criteria, and help eliminate the classic natural-language pitfalls:
- Passive voice — which hides who is responsible for an action.
- Universal quantifiers — "always", "never", "all", which are rarely true and rarely testable.
- Incomplete descriptions — statements missing a condition, an actor or a measurable outcome.
The syllabus states the benefit in terms of where a Requirements Engineer's attention goes: this automated formatting support enables them to focus on content validation and stakeholder alignment rather than spending time on style corrections.
That is the same argument transcription made about note-taking, and it is worth noticing the pattern. AI's most defensible contribution across this whole chapter is not doing the thinking — it is clearing away the mechanical work that was consuming the attention needed for thinking.
User stories and acceptance criteria
AI can formulate stakeholder input as well-structured user stories following established phrase templates such as the widely used As a [user type], I want [goal] so that [benefit] format.
It does this by analysing stakeholder descriptions, interview transcripts or informal requirement statements to identify user roles, desired functionality and business value, then structuring that information according to user story conventions.
It can further:
- Suggest appropriate acceptance criteria.
- Identify missing story elements.
- Ensure stories maintain focus on user value rather than implementation details.
This is particularly valuable in agile contexts where user stories serve as the primary requirements artefact in product backlogs, and it helps maintain consistency in format and completeness across large story collections.
The third capability is the interesting one. "Focus on user value rather than implementation details" is a quality criterion that is genuinely hard to enforce by hand across a few hundred stories, because the drift is gradual — a story acquires a technical noun, then a mechanism, then a solution, and no single edit looks wrong. A consistency pass over the whole backlog catches the drift that per-story review does not.
Glossaries, synonyms and decomposition
Two further formulation capabilities:
Domain glossaries and synonym tables. AI supports their generation, helping clarify domain-specific terminology and promote consistent language usage across teams, addressing ambiguity in natural-language work products. This continues the glossary work from module 6 into the documentation phase.
Decomposition. AI can identify logical subdivisions within high-level requirements, helping decompose them into actionable sub-requirements, system-level specifications or acceptance criteria that align implementation with business objectives.
The syllabus makes a point about how these phases connect that is easy to miss: formulation work builds upon domain understanding established during exploration, documented insights from transcription, and structured content from extraction. The activities are not independent; each one's output is the next one's context. Which is a restatement, in RE terms, of everything module 3 said about context determining output quality.
The formulation capabilities in this lesson are the most reliable in the entire chapter, because they operate on form rather than substance. That reliability creates a specific trap.
Take a genuine stakeholder statement:
"When someone books, we need to know pretty quickly, especially if it's for today."
An AI applying a phrase template returns something like:
"The system shall notify the practice within 5 minutes of a booking being created for an appointment scheduled on the same day."
This is a well-formed requirement. It uses the template, names an actor, states a condition, and carries a measurable threshold. It would pass any style review.
It also contains a number nobody said. "Pretty quickly" became "5 minutes" somewhere between the stakeholder's mouth and the specification, and the transformation is invisible in the output — the requirement gives no indication that its most important element was invented rather than elicited.
This is false precision from module 4, arriving through a legitimate and useful capability. The formatting was helpful; the specificity was fabricated.
Two practical defences, both of which appear elsewhere in this course. First, instruct the model to mark any value it had to supply rather than derive — an instruction that converts an invisible risk into a visible list. Second, treat every threshold in an AI-formulated requirement as unvalidated until a stakeholder confirms it, which is CPRE principle 6 applied at the level of the individual number.
An AI converts "we need to know quickly about same-day bookings" into a requirement specifying notification within 5 minutes. What should the Requirements Engineer be most alert to?
Formulation
Click to flipStructuring requirements using standardised formats and quality criteria — IEEE-style statements, use cases or user stories — to improve clarity, comparability and traceability.
Click to flip backAI is at its most reliable in formulation, because templates and phrasing are form rather than substance: it applies IEEE and phrase templates, removes passive voice and universal quantifiers, builds user stories with acceptance criteria, maintains glossaries and synonym tables, and decomposes high-level requirements. The trap is that well-formed output can carry invented specifics — ask the model to mark what it supplied, and validate every threshold with the stakeholder who did not state it.