Implementation and Execution
What this domain tests
This domain covers the work of moving from agreed requirements into a delivered solution: communicating requirements, supporting design and build, managing requirement changes, and ensuring traceability. Expect questions on requirement quality, traceability matrices, change control, and the analyst's role during construction and testing.
Concepts to master
- Requirement quality: unambiguous, complete, consistent, feasible, verifiable, and traceable. A requirement that cannot be tested is a defect.
- Traceability: links needs to requirements to design to tests. It supports impact analysis and coverage checks.
- Change control: assess impact on scope, cost, schedule, and risk, then route the decision to the authorized owner. The analyst analyzes; the owner decides.
- Communication: tailor format and detail to the audience, from executives to developers.
- Support during build and test: clarify intent, resolve defects that trace to requirements, and confirm acceptance criteria are exercised.
Common traps
Options that let the analyst approve a scope change are wrong; approval belongs to the accountable owner. Another trap confuses a design preference with a requirement. Also watch for "gold plating," where unrequested features appear without a traced need.
Rule of thumb
If a proposed change cannot be traced to a need and its impact is unassessed, it is not ready for a decision.
Worked example: Mid-build, a stakeholder requests an extra report. The analyst traces the request, estimates impact on effort and schedule, documents it, and presents options to the sponsor, who decides whether to accept, defer, or reject.