Validation and Verification Planning
Purpose of Verification Planning
Verification and Validation (V&V) is a core element of our systems engineering process, ensuring that all requirements defined in the SRD are testable and provable. While the SRD defines what the system must accomplish, the V&V plan outlines how each requirement will be verified through objective, testable verification paths, from component-level checks to full-system integration. We developed our V&V plans in parallel with the SRD. We collaborated with team leads to break down each requirement into concrete verification methods, such as by analysis, inspection, test, or demonstration, and by mapping those to specific milestones and responsible teams.
The purpose of our V&V plans is twofold: to catch design or integration issues early, before they become mission-critical problems, and to give every team a clear, shared understanding of what “ready” looks like. Other departments use the V&V plans as a checklist for testing protocol, to coordinate verification efforts, and ensure clear communication on next-best steps for the team. In the Thermal department, V&V plans are used to clarify the necessity of critical component testing, such as compiling the Thermal requirements and constraints necessary to ensure the functionality of the Pulse-A Satellite. The V&V plans also served to organize team efforts within the Thermal department around sourcing component information, and clearly organize the department objectives. In subsystems like the Ground Control (GC) station, a V&V plan clearly outlines the joint requirements for developing and implementing mission-critical software between the RFGS and OGS, assuring alignment in their key objectives.
Example Verification Plan for Structures Department STR-12:
For STR-12 — The Structure shall maintain the Payload’s optical path lens alignment within 0 mm ± TBD mm after launch — we marked the Level as Performance because we’re assessing how well the structure’s precise tolerance under launch conditions. The key here is that this requirement measures alignment stability after the extreme mechanical stresses of launch, so it’s inherently performance-driven.
In the Requirement Statement, the “0 mm ± TBD mm” tolerance is left TBD because it depends on the Payload requirement PAY-18, which specifies the optical path lens alignment needs. We can’t finalize the exact allowable deviation until the payload team locks that in — but once we have it, this requirement ensures the structure is designed and tested to hold that alignment.
In the Notes, we captured why this matters and how we’ll approach it. We know there will be some inevitable misalignment from vibration and loads during launch, so our job is to define an acceptable tolerance and confirm the structure can stay within it. This means simulating expected launch loads and vibration profiles and checking how the optical alignment shifts. If it fails, we adjust the structure and repeat testing until it meets spec. The note also calls out a practical constraint — we have to know the tolerance before the structure is assembled, because post-assembly fixes will be difficult or impossible without redesign.
For the Verification Method, we chose Testing. This is because analysis alone won’t capture the full mechanical interplay between the structure and payload during launch-like stresses. We’ll simulate vibrational and load conditions equivalent to those expected during launch, then measure post-test alignment to see if we stayed within the tolerance.
The Departments listed — Structures, Payload, and Systems — reflect the cross-disciplinary nature of the test. The payload team provides the tolerance spec, the structures team designs and builds the support, and systems ensures integration and test coordination. Finally, the Compliance Timeline is tied to having this verified before assembly is finalized — practically, this means by CDR or earlier in the build schedule. Waiting later risks expensive or impossible changes if the alignment fails.