Requirements and Scope Definition
Scope definition converts stakeholder needs into a documented boundary of what the project will and will not deliver. Candidates should understand the components of a scope baseline (scope statement, work breakdown structure, WBS dictionary), the difference between product scope and project scope, and how requirements are elicited, analyzed, documented, and traced. Know the categories of requirements (business, stakeholder, solution, functional, nonfunctional, transition) and the purpose of a requirements traceability matrix in linking requirements to deliverables and tests.
Traps: confusing scope creep (uncontrolled, incremental expansion without approval) with approved change requests (controlled via integrated change control). Another trap is treating gold plating (adding unrequested features) as good practice. Questions often present a stakeholder requesting a small addition; the correct response is to evaluate it through change control, not to silently accept or reject it. Also watch for confusing validation (meets customer needs) with verification (meets documented requirements).
Rule of thumb: no change to the scope baseline without a documented, approved change request that updates the baseline and is communicated to affected stakeholders.
Worked example: A client asks mid-project for an extra report. The project manager documents the request, assesses impact on schedule and cost, and routes it to the change control board; only after approval is the scope baseline updated.