Scope Definition, Requirements, and Design Basis
Domain 2 tests how scope is defined and protected: the scope statement, the work breakdown structure, the requirements traceability chain, the design basis, and integrated change control. Most security projects fail here rather than in installation.
The scope baseline
- Scope statement - deliverables (device counts, locations, functions), boundaries and explicit exclusions, acceptance criteria, and constraints carried forward from initiation.
- WBS - deliverable-oriented decomposition: design, procurement, infrastructure, installation, programming, testing and commissioning, training, closeout. Work packages must be estimable and assignable. A WBS is not an org chart and not a schedule.
- Scope baseline = scope statement + WBS + WBS dictionary. Changes only through integrated change control, with impact assessed on cost, schedule, risk, and quality.
Requirements and design basis
- Operational requirements come from users and security operations: what must be seen, recorded, controlled, alerted, retained, and reported.
- A requirements traceability matrix links each requirement to a design element, a test, and an acceptance criterion, so nothing is designed but untested, or accepted but never required.
- The design basis records standards, assumptions, and calculations behind the design: pixel density at identification distance, door-held-open timing, fail-safe versus fail-secure, storage sizing for retention.
- Privacy and regulatory requirements are requirements too: notice/signage, retention limits, who may view recordings, consent for biometrics.
Worked example
A 40-door access control upgrade is in design when a stakeholder requests video intercom at six doors. Reasoning: (1) is it in the operational requirements? If not, it is a change, not a clarification. (2) Assess impact - six intercoms need network drops, power, programming, and roughly two extra weeks on the critical path. (3) Submit a change request with cost and schedule impact, obtain the sponsor decision, and if approved update scope statement, WBS, traceability matrix, and baseline. Absorbing it silently destroys both baselines.
Traps
- Building the WBS from the schedule or the org chart instead of deliverables.
- Acceptance criteria such as "system works as designed" - untestable.
- No exclusion list, so stakeholders assume coverage of areas never priced.
- Gold-plating beyond requirements, creating cost with no requirement to justify acceptance.