| 5.2-3-1 Ensure user requirements for the ground segment are reviewed, understood, and captured per the approved requirements development process |
Phase A |
Phase B |
Phase C |
|
Ensure the mission needs document and all user requirements allocated to the ground segment, stated or implied, are captured. Ensure that user key performance parameters are identified. Ensure all external interfaces required, stated or implied, are captured. Ensure user operational concepts are captured. Ensure all captured user requirements and operational concepts are analyzed for completeness and feasibility, and any identified gaps are closed by elicitation from the user community. Ensure all captured user requirements are under configuration control. All internal and external interfaces identified or implied by the user needs documents, should be captured. Ensure applicable steps of the approved requirements development process were followed in accomplishing these tasks.
|
NA
|
System/Segment Specification (SSS); System CONOPS
|
SMC-S-001, SMC Systems Engineering Requirements and Products or equivalent; Writing Quality Requirements, Karl E. Wiegers, www.processimpact.com
|
| 5.2-3-2 Ensure a complete, correct and consistent set of ground segment requirements and system interface requirements are captured and maintained in a system specification and system interface control documents |
Phase A |
Phase B |
Phase C |
|
Ensure the ground segment specification completely addresses all user identified requirements, interfaces and operational concepts. Ensure the language of the system spec requirements meets standards of requirements quality. Ensure the requirements set includes all applicable hardware and software specialty engineering and product assurance requirements. Ensure that for each ground segment parent requirement, the set of ground segment (child) requirements are traceable to the parent requirement as a set, and they completely address and correctly translate the parent to a set of segment requirements that fully satisfy the parent. Examining each requirement in the segment specification, ensure that each requirement has a valid parent; or is justified by analysis, simulation or design considerations traceable to mission needs, or both. There should not be any parent requirement with no identified children in the segment specification, and there should not be any requirement of unknown or unclear origin in the segment specification. Ensure that all segment requirements, both hardware and software, and ground interface requirements have been captured and configuration controlled. Initial allocation of hardware versus software requirements should be complete. All products, including specifications, ICDs, traceability and documentation of all decisions made, should be complete, captured and maintained; and should be reviewed and approved by all internal and external stakeholders.
|
NA
|
System/Segment Specification (SSS); Inter-Segment ICDs; External ICDs
|
SMC-S-001, Systems Engineering Requirements and Products, 12 July 2010 or equivalent; IEEE-STD-1220: For Practical Systems Engineering; ANSI/EIA-632, Processes for Engineering a System; Writing Quality Requirements, Karl E. Wiegers, www.processimpact.com
|
| 5.2-3-3 Ensure a complete, correct, consistent, and maintained set of subsystem, lower level requirements and internal interface requirements are traceable to the ground segment |
Phase A |
Phase B |
Phase C |
|
Ensure every requirement in the system spec (parent) is flowed down to the next level specifications (children requirements) using applicable steps of the approved requirements development process, and that the set of children requirements for each parent is complete (fully covers the parent), technically correct and correct language, and complies with requirements quality criteria. Ensure all interface related parents are similarly flowed down either into the next level specifications, or into appropriate interface requirements documents. Looking at the next level specifications (children), ensure that each child requirement has a valid parent, or is justified by analysis simulation or design considerations traceable to mission needs, or both. There should not be any widow parents without flow down and no children without parents or other valid justification (orphans). At this point in the requirements development, hardware and software requirements experts should be heavily involved in the process. Ensure that all lower level (subsystem and below) requirements, including hardware, software and interface requirements, have been captured, configuration controlled and maintained. All products, including specifications, ICDs, traceability and documentation of all decisions made, should be complete, captured, and maintained; and should be reviewed and approved by all internal and external stakeholders.
|
NA
|
System/Segment Specification (SSS); Inter-Segment ICDs; External ICDs
|
SMC-S-001, Systems Engineering Requirements and Products, 12 July 2010 or equivalent; IEEE-STD-1220: For Practical Systems Engineering; ANSI/EIA-632, Processes for Engineering a System; Writing Quality Requirements, Karl E. Wiegers, www.processimpact.com
|
| 5.2-3-4 Ensure complete, correct bidirectional traceability of all ground segment requirements, and between requirements and baseline architecture elements, is captured, controlled, and maintained |
Phase A |
Phase B |
Phase C |
|
Repeating at each level of specifications, ensure that bidirectional traceability between user and system, between system and lower level requirements, between interface requirements documents and specifications, and between the baseline system architecture and all specification and interface documents, is captured , configuration controlled and maintained. Ensure that the bidirectional traceability for each pair of linked documents is complete, current and correct, and that it has been vetted by all stakeholders in each case. Bidirectional traceability should allow, for any requirement in any document, the easy identification of parent and descendent (children) requirements or architecture elements.
|
NA
|
System/Segment Specification (SSS); Inter-Segment ICDs; External ICDs
|
SMC-S-001, Systems Engineering Requirements and Products, 12 July 2010 or equivalent; IEEE-STD-1220: For Practical Systems Engineering; ANSI/EIA-632, Processes for Engineering a System
|
| 5.2-3-5 Ensure each ground segment and subsystem requirement has at least one vetted method of verification identified |
Phase A |
Phase B |
Phase C |
|
Ensure at least one method of verification is defined, captured and configuration controlled for each segment, subsystem and below, and interface requirement. Ensure each verification method is reviewed and concurred upon by all applicable stakeholders. Verification methods should be by one or more of the following: inspection, analysis, test and demonstration.
|
NA
|
System/Segment Specification (SSS); Verification Cross-Reference Matrix (VCRM)
|
SMC-S-001, Systems Engineering Requirements and Products, 12 July 2010 or equivalent; IEEE-STD-1220: For Practical Systems Engineering; ANSI/EIA-632, Processes for Engineering a System
|
| 5.2-3-6 Ensure a comprehensive ground segment requirements development process is defined, approved and followed |
Phase A |
Phase B |
Phase C |
|
Ensure a requirements development process is defined and documented, based on industry standard guidelines as shown in SMC-S-001 or equivalent; IEEE-STD-1220, the discussion and requirements in ANSI/EIA-632 and CMMI for Development. The process should be comprehensive enough to include all aspects of hardware, software and both internal and external interfaces at each level of development. The CMMI for Development, Requirements Development and Requirements Management process areas be used as a framework for assessing the completeness of the documented process. The process should include development and capture of bidirectional traceability at all levels of specification and ICDs. Ensure that the process is reviewed and approved as required by the contract and program directives. Ensure that the approved process is documented under configuration control, and that it is followed by practitioners at all levels of requirements development, from system/segment, down to the lowest level of specifications.
|
NA
|
Systems Engineering Management Plan (SEMP)
|
SMC-S-001, Systems Engineering Requirements and Products, 12 July 2010 or equivalent; IEEE-STD-1220: For Practical Systems Engineering; ANSI/EIA-632, Processes for Engineering a System; Capability Maturity Model Integration (CMMI) for Development, November 2010, CMU/SEI-2010-TR-033
|