Fundamentals and Terminology
This domain tests whether you can use lifecycle and quality vocabulary precisely, because every later domain depends on shared definitions. Expect questions on system boundaries, requirement categories, verification versus validation, and configuration baselines.
Core vocabulary
- A system is a set of interacting elements organized to achieve stated purposes; its boundary is defined by interfaces and scope, not by organizational charts.
- Stakeholder needs become system requirements; requirements are functional (what it does) or non-functional (how well: performance, safety, security, usability).
- Verification answers “Did we build the product right?” against specified requirements. Validation answers “Did we build the right product?” against stakeholder needs and intended use.
- A configuration item is any item placed under configuration control; a baseline is a formally approved version that changes only through change control.
- Fault, error, failure: a fault is a latent defect or cause; an error is an incorrect internal state; a failure is an observable deviation from required behavior.
Worked example
A temperature sensor must report within ±0.5 °C of a calibrated reference. In test it reports within ±0.4 °C, so verification passes. Field users then say readings are too slow for their control loop. That is a validation gap: the requirement omitted response time, so the system met the written specification but not the need. The corrective action is to add a measurable response-time requirement and re-validate, not to declare the test invalid.
Traps
- Treating verification and validation as synonyms; exam items often hinge on the reference point: specification versus need.
- Calling a test failure a “fault”; the observable event is a failure, whose root cause may be a fault.
- Assuming a baseline is immutable; it is controlled, not frozen.
- Mixing up a requirement with a design constraint or a solution.