MODULE 7 · LESSON 2
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolTransforming Requirements Into Other Representations
Transformation is more than translating text from one language to another. It is about moving requirements across formats and stakeholder perspectives. As systems grow more complex and teams more interdisciplinary, transforming requirements effectively becomes essential for clarity, alignment and traceability.
Between text and visual models
AI can convert natural language requirements into visual models such as UML or BPMN diagrams, making system structure, workflows and relationships easier to understand than text alone allows.
It works in the other direction too: AI can describe visual models in structured text, improving accessibility for non-technical stakeholders and supporting documentation.
Beyond general diagrams, AI can generate specific UML artefacts — class, activity or use case diagrams — as well as BPMN workflows that visualise decisions and processes. The syllabus attaches an important constraint to all of it: always focusing on requirements specification rather than detailed design.
That constraint is the whole discipline of this capability. A model asked to diagram a set of requirements will readily produce a class diagram with attributes, types and methods — which has silently crossed from specifying the problem into designing the solution. Module 4's framing applies directly: AI-created visual representations require validation to confirm they sit at an appropriate abstraction level, are aligned with the intended purpose of model-based work products, and do not introduce premature design assumptions.
Prototypes
Generative AI can support the creation of exploratory prototypes by generating wireframes, mock-ups or even functional prototypes from requirements specifications or user stories.
By analysing functional requirements and user interface descriptions, it produces visual representations that help stakeholders understand proposed system behaviour and validate requirements through concrete examples. It can work at different fidelity levels — simple wireframes for early concept validation, or more sophisticated mock-ups demonstrating interaction flows and interface concepts.
The benefit is speed of iteration: rapid generation enables quick collection of stakeholder feedback, supporting validation by giving stakeholders tangible representations of abstract requirements to evaluate and refine.
The ability to generate a polished mock-up in seconds creates a problem that low-fidelity prototyping was specifically designed to avoid.
A hand-drawn wireframe communicates "this is provisional, tell me what is wrong with it." Stakeholders comment freely on structure, flow and missing states, because the artefact visibly is not finished.
A high-fidelity mock-up communicates something different, whether or not anyone intends it. It looks decided. Feedback narrows to surface matters — colours, wording, button placement — because the underlying structure now reads as settled. The very fidelity that makes it impressive suppresses the structural feedback the prototype existed to collect.
Before AI, fidelity cost effort, so the cost naturally rationed it: you only built a polished mock-up when you were ready to. That rationing is gone. A Requirements Engineer can now generate high fidelity accidentally, at the exact stage where low fidelity would serve better.
The syllabus's mention of different fidelity levels is therefore a decision to make deliberately rather than a feature to enjoy. Choose the fidelity that suits the validation question you are asking. If you want to know whether the flow is right, ask for a wireframe — and resist the model's willingness to give you more.
Further transformation applications
The syllabus lists several more, each brief but examinable:
- Creating dynamic visual content — transforming requirements documentation into explainer videos and other dynamic formats.
- Translating technical requirements into simplified language for non-technical stakeholders, and generating targeted summaries for specific audiences such as executives, end users or developers — ensuring information delivery suits its audience while maintaining specification consistency.
- Creating user personas by synthesising stakeholder input, complementing traditional stakeholder identification methods.
- Deriving test cases from requirements to support validation activities.
- Analysing legacy code to extract implicit requirements for documentation efforts.
- Comparing specifications with implemented code to ensure compliance or identify discrepancies — particularly valuable in regulated industries requiring strict traceability.
Two of these deserve a note. Persona creation carries the bias amplification risk from module 4 more directly than anything else in the chapter — personas synthesised from data that reflects historical skew will reproduce that skew, and personas are inputs to design. Legacy code analysis is genuinely valuable for modernisation work, but what it recovers is what the system does, which is not necessarily what it should do: an extracted requirement is a description of existing behaviour, including its bugs and its obsolete business rules.
An AI generates a UML class diagram from a requirements specification, complete with attributes, data types and methods. What is the primary concern?
Transformation
Click to flipMoving requirements across formats and stakeholder perspectives — rewriting in plain language, tailoring summaries for specific audiences, and converting between text and models in both directions.
Click to flip backTransformation moves requirements between formats and audiences: text to UML or BPMN and back, requirements to wireframes and mock-ups, specifications to personas, test cases, plain-language summaries and explainer content, and legacy code back to implicit requirements. Two disciplines apply throughout — generated models must stay at specification level rather than drifting into design, and prototype fidelity must be chosen for the validation question being asked, not accepted because it was free.