CPRE common mistakes
CPRE · Understand the traps and how to avoid them.
Treating the CPRE exam as a general project-management or business-analysis test, so answers are chosen from intuition about 'good practice' rather than from the requirements-engineering concepts the question is actually testing (e.g., picking 'hold a kickoff meeting' over 'define the system boundary').
Candidates often arrive from PMP, agile, or product-owner backgrounds and default to familiar process language; the CPRE syllabus is narrower and more definitional, with specific terms for elicitation, documentation, validation, and management that do not map onto generic PM vocabulary.
What to do instead
Before answering, classify each stem by which requirements-engineering activity it describes (elicitation, documentation, validation, negotiation, management) and reject options that belong to a different activity even if they sound sensible. Build a one-page map of the syllabus activities and their canonical techniques, and rehearse tagging sample stems to that map until the classification is automatic.
Confusing the terms for requirement types and levels - mixing up stakeholder requirement vs. system requirement, functional vs. non-functional, constraint vs. quality requirement - and choosing an answer that uses the wrong label for the artifact described.
The vocabulary is overlapping and the distinctions are subtle; many candidates have used these words loosely in practice, so they read 'the system shall respond within 2 seconds' as a functional requirement or call a design constraint a non-functional requirement.
What to do instead
Memorise a decision tree: who needs it (stakeholder vs. system), what it does vs. how well it must do it (functional vs. quality), and what is fixed externally vs. chosen by the team (constraint vs. design decision). Practise by writing five examples of each type from a domain you know and checking each against the decision tree, then classify mixed lists of requirements under time pressure.
Choosing the 'most thorough' documentation option - full specification, complete modelling, exhaustive sign-off - when the stem describes an agile, volatile, or safety-critical context where the correct answer is deliberately lightweight or deliberately rigorous depending on risk.
Candidates internalise a single ideal of documentation and apply it uniformly; they miss the exam's emphasis that documentation depth is a function of context, criticality, and regulatory need, so both over-documentation and under-documentation can be wrong.
What to do instead
For every documentation question, first identify the context cues (regulated? safety-related? distributed team? short feedback cycles?) and then select the level of formality those cues justify. Learn the trade-off arguments for lightweight vs. formal documentation and be able to state, in one sentence each, when each is appropriate; drill questions where two options differ only in documentation weight.
Treating elicitation as a single technique and picking 'interview the stakeholder' for every situation, including cases where the stem describes many stakeholders with conflicting views, tacit knowledge, or a need to observe actual work.
Interviews are the most familiar technique, so they become a default; candidates underweight workshops for conflict resolution, observation for tacit or habitual work, and document analysis or prototyping for cases where users cannot articulate needs.
What to do instead
Learn a technique-selection table keyed on the situation: number and diversity of stakeholders, degree of conflict, availability of existing documents, maturity of the domain, and whether needs are tacit. For each practice stem, name the situation cues first, then choose the technique those cues demand, and be able to explain why the two strongest distractors are weaker in that specific situation.
Confusing validation with verification - answering that a review checks 'whether the system meets its specification' when the stem asks whether the right requirements were captured, or vice versa - and selecting the wrong activity (review, prototype, test, acceptance) for the stated purpose.
The words sound alike and are often used interchangeably in industry; candidates remember 'verification = testing' but not the requirement-level distinction between building the thing right and building the right thing.
What to do instead
Anchor on the classic distinction: verification asks whether the product conforms to the specified requirements; validation asks whether the requirements reflect the stakeholders' real needs. For each validation technique (review, prototyping, model checking, acceptance criteria walkthrough), note what it can and cannot detect, and practise sorting stems into 'checks the requirements' vs. 'checks the product against requirements'.
Ignoring requirement attributes and prioritisation schemes - answering that all requirements are equally important or that priority is set once - instead of applying the scheme named in the stem (e.g., MoSCoW, cost-value, risk-based) and recognising that priority changes over time.
Candidates focus on content and forget that the exam tests management knowledge: attributes such as priority, status, owner, source, and rationale, and the fact that prioritisation is a continuing negotiation, not a one-off sort.
What to do instead
Memorise the common prioritisation schemes and what each optimises for, then practise questions that ask which scheme fits a described situation (fixed deadline, high uncertainty, safety context). Also learn the standard attribute set for a requirement and be ready to identify which attribute is missing or misused in a scenario.
Missing the change-management chain - answering that a change is handled by 'updating the document' without tracing impact on related requirements, design, tests, and stakeholders, or without recognising the role of a change control board and baseline.
The exam presents change scenarios where the obvious answer (edit the spec) is incomplete; candidates who have not internalised traceability and baseline concepts choose the simplest action and overlook impact analysis and approval.
What to do instead
Learn the standard change sequence: request, impact analysis via traceability links, decision by the responsible authority, update of baseline and affected artifacts, communication. For each practice scenario, list every artifact the change touches before looking at the options, then pick the option that reflects the full chain rather than the first plausible step.
Misreading the stem's scope - answering about the whole system when the question is about a single requirement, or vice versa - and overlooking qualifiers such as 'first', 'least appropriate', 'except', or 'during elicitation' that change which option is correct.
Exam stems are dense and often contain a scenario plus a qualifier; under time pressure candidates pattern-match to a familiar concept and answer a slightly different question than the one asked.
What to do instead
Adopt a fixed reading routine: underline the qualifier and the activity/phase named in the stem before evaluating options, and restate the question to yourself in one sentence. Practise with sets of near-identical stems that differ only in one qualifier, so the habit of checking the exact wording becomes automatic.
Applying tool or notation knowledge superficially - choosing a diagram or model type because it is familiar rather than because it fits the purpose (e.g., using a use-case diagram to show detailed data structure, or a class model to show process flow) - and confusing what each model can express.
Candidates learn notations as pictures rather than as languages with defined semantics and purposes; they do not connect model choice to the question the model must answer (structure, behaviour, data, state, interaction).
What to do instead
Build a purpose-to-model table: what question does the model answer, what does it show well, what does it omit. For each notation in the syllabus, write one sentence on its purpose and one on its limitation, then practise stems that describe a modelling goal and ask for the appropriate model type, justifying rejection of the nearest alternative.
Answering management-process questions from personal team experience rather than from the standard roles and artifacts the syllabus defines - for example, assigning requirement ownership to the wrong role or skipping the baseline concept when describing status tracking.
Experienced practitioners have seen many local variants of process, and the exam tests a defined reference model; personal experience can conflict with the expected answer, especially around roles, baselines, and traceability direction.
What to do instead
Separate 'what my team does' from 'what the reference model specifies' by studying the defined roles, artifacts, and traceability relationships explicitly, and note where your experience deviates. When a stem describes a process, answer from the reference model and use your experience only to understand the scenario, not to select the option.