| 4.2-4-1 Ensure bus design meets the mission performance requirements |
Phase A |
Phase B |
Phase C |
|
Pre-Phase A, as applicable, ensure the design satisfies the requirements under the conditions specified by the Design Reference Mission. There should be a realistic worst-case scenario to show that the requirements can be met with margin. Phase A onward, the derived CONOPS should be in a particular document (Flight Requirements and Ops documents) or operations working group products. Some mission concepts may not be directly translated to space system requirements in terms of the overall mission operability. The space system must be validated against how the components will be used for that particular application.
|
SFWC 2.1.2
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B
|
| 4.2-4-2 Ensure trade studies were conducted and the design baseline satisfies mission requirements |
Phase A |
Phase B |
Phase C |
|
Ensure that all trade studies are realizable in terms of technology used and conform to space system requirement and physical constraints. Check that viable candidates received appropriate consideration. Ensure the analysis of alternatives has identified the baseline as the best value.
|
SFWC 2.1.2
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.2-4-3 Ensure space system technology readiness and risk burn-down plan have been assessed |
Phase A |
Phase B |
Phase C |
|
Ensure space system technologies, including manufacturing, supplier readiness and programmatic readiness, are mature enough to support the development timeline. Check that the risk mitigation plans are sufficient, funded and conclude at the right time.
|
SFWC 2.1.2
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.2-4-4 Ensure applicable space system hardware and software functions are described in the space system specification |
Phase A |
Phase B |
Phase C |
|
Ensure that descriptive functions for subsystems and units (including software) are detailed enough for new personnel to understand how the unit or subsystem behaves both individually and within the system.
|
SFWC 2.1.2
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.2-4-5 Ensure applicable space system hardware and software is identified as heritage, modified, or new |
Phase B |
Phase C |
|
Ensure heritage qualification adequacy is documented by analysis and test.
|
SFWC 2.1.2
|
NA
|
Objective Criteria for Heritage Hardware Reuse, TOR-2010(8591)-19; Reuse of Hardware and Software Products, TOR-2009(8546)-8604
|
| 4.2-4-6 Ensure all defined contract deliverables and relevant contractor data are complete and accurate to support design reviews |
Phase A |
Phase B |
Phase C |
|
Ensure all relevant data is readily available and delivered to support design reviews and design forums.
|
SFWC 2.1.2
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.2-4-7 Ensure contractor applied a proven system engineering process during design and performed supporting analyses |
Phase B |
Phase C |
|
NA
|
SFWC 2.1.2.1, SFWC 2.1.2
|
NA
|
NA
|
| 4.2-4-8 Ensure contractor applied a proven product engineering process during design which is traceable to applicable system/mission requirements documents |
Phase B |
Phase C |
|
NA
|
SFWC 2.1.2.2, SFWC 2.1.2
|
NA
|
NA
|
| 4.2-4-9 Ensure the specialty engineering functions support design processes |
Phase B |
Phase C |
|
Specialty engineering includes system Safety, PM&P, quality assurance, mass/electrical properties, human factors engineering, EMI/EMC engineering, and contamination control.
|
SFWC 2.1.2.3, SFWC 2.1.2
|
NA
|
NA
|
| 4.2-4-10 Ensure contractor applied "design for manufacturing and assembly" standards during the design process |
Phase B |
Phase C |
|
NA
|
SFWC 2.1.2.4, SFWC 2.1.2
|
NA
|
NA
|
| 4.2-4-11 Ensure contractor applied a well-defined/mature software engineering process during design |
Phase B |
Phase C |
|
NA
|
SFWC 2.1.2.5, SFWC 2.1.2
|
NA
|
NA
|
| 4.2-4-12 Ensure contractor applied "design for test" standards during the design process including by- analysis or by-similarity as appropriate |
Phase B |
Phase C |
|
NA
|
SFWC 2.1.2.6, SFWC 2.1.2
|
NA
|
NA
|
| 4.2-4-13 Ensure that any design-related cross-program systemic issues are submitted to problem alerting processes |
Phase B |
Phase C |
Phase D1 |
Phase D2 |
Phase D3 |
|
Cross-program systemic issues are those that affect more than one program and can result in mission ending or mission limiting impacts to reliability, performance, or functionality.
|
NA
|
NA
|
NA
|
| 4.2-4-14 Ensure that any potentially systemic design issues are considered for a Design Advisory |
Phase B |
Phase C |
Phase D1 |
Phase D2 |
Phase D3 |
|
Any design or architecture issue that has severe, systemic, or widespread consequences is a potential candidate for a Design Advisory. Design Advisories provide the community with timely and interim notification of an important design issue which may ultimately be captured in a specification or standard.
|
NA
|
NA
|
NA
|