Embedded Files
Requirements Introduction Sub-Series
Requirements Introduction Sub-Series
Requirements
Requirements
The core of the space systems engineering process are requirements, an agreement between stakeholders to deliver a working product that meets mission goals and expectations. The project team initially reviews stakeholder requirements [1][2], expectations, and goals, using these documents as an initial baseline for the team to interpret as mission requirements. These requirements are reviewed and interpreted by subsystem leads to further decomposed into subsystem requirements. Figure 1 provides an overview of how requirements and verification activities are decomposed and organized.
Project requirements are initially created during Pre-Phase A, and provide guidance to the Iris's technical design. Requirements undergo a continuous process of updating to ensure that the design is achievable. On a quarterly basis, the project team reviews existing requirements to ensure that the team is undertaking work using the same interpretation and understanding of requirements.
Figure 1: Requirements Hierarchy and Decomposition
Figure 1: Requirements Hierarchy and Decomposition
Figure 2: Iris V-Model
Figure 2: Iris V-Model
Verification and Validation
Verification and Validation
Verification activites are used to demonstrate that the CubeSat conforms to mission requirements. One useful approach to plan verification activitivies is to use the V-Model shown in Figure 2. The V-Model provides the project team a useful method to plan and execute verification activities during the AIT phase, enabling the team to demonstrate that the CubeSat design will work.
The final step of the V-Model is through stakeholder validation through successful operations. Because there is no ethical or commercially available method to return an in-flight CubeSat, first time success will be the main method of validating project definition.
Note that verification activities can be undertaken as early as Phase B through review of technical design and documentation. Incorporating early and frequent verification activities creates many opportunities to identify design flaws, missing features, or other potential non-conformances.
Page updated
Google Sites
Report abuse