A working map of CPRE Foundation Level: from context to management

How to use this page

This is a lookup article, not an essay. It maps the shape of requirements engineering work as the CPRE Foundation Level (English syllabus v3.2.0, 26 February 2024) expects you to talk about it, with glossary senses from v2.2.0 (1 October 2025). It does not reproduce the syllabus. Chapter numbering is omitted on purpose: if you need the official table of contents, open the PDF.

Use the contents rail. Tables are on the feature track so they can be read. Type is slightly denser than the essay layouts.

The working sequence

The path is pedagogical. Real programmes overlap the steps. The Foundation Level still expects you to know what each activity is for.

System and context

If you cannot name the system under consideration, stop. Elicitation without a boundary produces an unbounded list and a false sense of completeness.

flowchart TB
  subgraph context [Context]
    Clerk
    Ledger
    subgraph system [System]
      Register
    end
  end
  Clerk --> Register
  Register --> Ledger

flowchart TB
  subgraph context [Context]
    Clerk
    Ledger
    subgraph system [System]
      Register
    end
  end
  Clerk --> Register
  Register --> Ledger

Elicitation

Elicitation is obtaining requirements. Sources include stakeholders, documents, and the current system. Techniques are many; the exam cares that you know elicitation is a systematic activity with sources, not a single workshop brand.

Do not treat a well-attended workshop as completeness. Completeness is relative to the agreed context and the agreed level of detail. Both can be wrong.

Documentation

Requirements are documented so they can be communicated, agreed, and later checked. The Foundation Level treats natural language and model-based documentation as complementary, not as a fashion choice.

Natural language needs discipline: defined terms, checkable statements, no unbounded "all" and "quickly" left as if they were measures. Templates help. They are not magic. A filled template with empty meaning is still empty.

Validation, verification, negotiation

Validation asks whether the specified system would be acceptable to the stakeholders. Verification asks whether a work product meets specified criteria. Negotiation deals with conflicts. A document review is usually verification of an artefact. It can feed negotiation. It does not, by itself, complete validation.

Management

Requirements management keeps identity, status, and traceability as the set changes. It is unglamorous and load-bearing. Without it, validation evidence cannot be attached to the statement it was meant to support, and constraints lose their source.

This site’s Phase 1 CMS is not a requirements management tool. It is a publication. Do not confuse a public article with a requirements baseline.

What this page is not

It is not a dump of the syllabus. It is not a claim that English v3.3.0 is current; it is not. German v3.3.0 exists; this page does not treat it as the English source. Onion models, INVEST, RACI, and MoSCoW are external conventions: if they appear in your programme, label them as such.

If a sentence here and the PDF disagree, the PDF wins. That is the only honest rule for a lookup article.

How to use this page during exam preparation — and how not to

Use the TOC as a map of workplace slang you need to unlearn. When a practice question uses "non-functional", translate it before you answer. When a practice question uses "validated", ask whether the stem means inspected or accepted as the right system. When a diagram is called a context diagram, check whether the system under consideration is named. Those translations are the point of a lookup article.

Do not use this page as a substitute for the syllabus PDF. Do not memorise the interactive widgets. They will not be in the exam. Do not treat Kano, MoSCoW, or a numbered chapter list on this site as Foundation Level content. The glossary terms in the popovers are there so you can see a definition next to a working sentence. If the popover and the glossary PDF disagree, the PDF wins.

If you are not preparing for an exam, ignore the exam framing and use the map as a staffing and diagnostic tool. The same collapses appear in programmes that never sit a CPRE paper. The map is useful because it names activities. Named activities can be staffed, skipped, or faked. Unnamed activities can only be faked. If you cannot name the activity, you cannot tell whether you finished it.

Using the map on a live programme

When a programme is already in motion, the map is a diagnostic, not a restart. Ask which activity is currently pretending to be which other activity. The usual collapses:

Elicitation pretending to be validation: a workshop attendance list treated as proof that the specified system is acceptable. Documentation pretending to be management: a published PDF with no identity for each statement and no status. Management pretending to be negotiation: a change log that records outcomes without recording the conflict. Context pretending to be scope: every neighbour drawn, therefore every neighbour assumed in the release.

Pick one collapse and repair it without renaming the others. If you try to "do RE properly" as a single catch-up, you will run a giant review and call it a reboot. That is how this map gets ignored.

A lighter use is staffing. Elicitation needs access to stakeholders and to the current work. Documentation needs time to write checkable statements, which is not the same skill as facilitating a room. Validation needs contact with the work as it is done. Management needs continuity across changes. If one person is all four, the map is still useful: it tells you which hat they are failing to take off. Most overloaded analysts skip documentation quality and validation probes, because workshops and tools are more visible. The Foundation Level split exists in part to make those quieter jobs nameable.

On tools: the syllabus discusses tool support as something that must follow the process, not the other way around. A traceability matrix in a spreadsheet can be honest. A traceability matrix in a platform can be theatre. This page's interactive matrix is a demonstration of a publication, not a recommendation of a vendor.

On models versus text: use whichever makes the statement checkable. A context diagram that does not name the system under consideration is not more rigorous than a paragraph that does. A paragraph that says "the system shall integrate with all relevant systems" is not more rigorous than a blank diagram. The tabbed visual above is the standard: two notations, same claim. If they disagree, fix the claim, not the notation.

If you are studying for the Foundation Level, this map is a companion, not a substitute. Memorise from the PDF. Use this page to notice when workplace slang has replaced the glossary. The slang is how three kinds of requirement become "NFRs", how validation becomes a signature, and how context becomes a hairball. The glossary is how you get out.

Carry a short field card if you like, but keep it short enough to use in a meeting. Context: who and what interacts with the system under consideration. Elicitation: how those sources are heard. Documentation: how the result becomes a checkable statement. Validation and negotiation: whether the specified system is the right one, and what happens when it is not yet agreed. Management: identity, status, and change after the statement exists. If you cannot point to which activity you are in, you are probably mixing two of them. That mix is the usual source of a late surprise. Pointing is not bureaucracy. It is how you know which question you are answering before you spend another afternoon on the wrong one.