The AI Toolkit: Five Families, Not One Chatbot

The AI4RE syllabus opens with a warning disguised as a heading: not every AI is a chatbot. That sentence is the whole educational objective EO 1.1, and it is worth taking literally, because the most common mistake in AI-supported Requirements Engineering is reaching for a conversational interface when the task calls for something else entirely.

Artificial intelligence, in the syllabus's framing, covers all methods that let computers perceive, reason or act in a way we would label intelligent. Different authors carve that space up differently, but five families appear in almost every taxonomy.

The five families

Machine learning and deep learning. Algorithms that learn patterns directly from data rather than from rules a human wrote down. Classic machine learning predicts a number or a category — this loan will default, this ticket belongs to the billing queue. Deep learning uses neural networks to handle messier inputs: language, images, control policies. The quality of the output rises with the size and the relevance of the training set. A model trained on a decade of house sales can predict the price of a house that has not sold yet; the same model knows nothing about your requirements specification.

Computer vision. Turning raw pixels into structured facts. Modern vision networks detect objects, read text out of an image, and estimate spatial depth. The example everyone carries in their pocket is face unlock on a phone. In RE, computer vision is what lets you photograph a whiteboard covered in sticky notes at the end of a workshop and get back structured text instead of a photograph nobody will ever open again.

Natural language processing. Everything that turns speech or text into meaning and back again. NLP spans a wide range: rule-based parsers at one end, speech-to-text and text-to-speech modules in the middle, and today's Large Language Models at the other end. LLMs are a subset of NLP, which is itself a subset of what AI covers — a hierarchy worth keeping straight, because the exam can test it.

Robotics. Sensor fusion (combining data from several sensors), mapping (building a representation of the environment), path planning (deciding how to move) and feedback control (adjusting based on what the sensors report), combined so a machine can navigate and manipulate the physical world. Warehouse pickers, autonomous drones, the vacuum cleaner that learns the shape of a living room. Robotics rarely touches RE work directly, but it appears in the syllabus's list and therefore in the exam's scope.

Expert systems. Human expertise captured as explicit rules and ontologies, producing auditable, deterministic answers. Expert systems are old technology that never went away, because in some domains — tax law, medical triage — transparency beats probability and there is no acceptable error rate. Modern tax software still leans on this approach, increasingly with AI components analysing the documents that feed the rules.

Why this matters for a Requirements Engineer

The syllabus makes a practical point behind the taxonomy: matching the task to the right AI technology is what produces a good result, and knowing the available options is what lets you use the full potential of AI. A Requirements Engineer who only knows chatbots will solve every problem by typing into one.

Consider three tasks that look similar and are not:

1. "Summarise this two-hour stakeholder workshop." The recording has to become text first — that is speech-to-text, an NLP task with its own accuracy characteristics, speaker-identification features and failure modes. Only then does a language model summarise it. Handing the raw audio to a chatbot that cannot process audio simply fails; handing it to a multimodal model that can is a different pipeline with different costs.

2. "Find every requirement in our backlog that duplicates this one." This is a similarity search over embeddings, not a generation task. You do not want the model to write anything. You want it to rank existing items by semantic distance. Asking a chatbot to "find duplicates" in a backlog it cannot see produces confident, fictional answers.

3. "Check whether this specification satisfies our internal coding standard clause 4.2." If the standard is a fixed rulebook, an expert system or a deterministic checker gives you an auditable yes or no. An LLM gives you a plausible paragraph that may or may not be correct, and cannot show its working in a way an auditor accepts.

The boundaries are blurring

The syllabus adds an important caveat. Capabilities like meeting transcription (speech-to-text) and interface analysis (computer vision) are increasingly delivered through a single interface. That happens two ways: by combining specialised models behind one product, or by using a single multimodal model that handles text, images and audio natively.

For a Requirements Engineer this has a practical consequence. The fact that one tool accepts an audio file, a screenshot and a written question does not mean one technology is doing all three jobs, and the failure modes of each remain different. When the transcription drops a speaker or the diagram reader misplaces an arrow, the cause is in that component, not in "the AI".