The key purpose of Pre-Phase A is to “produce a broad spectrum of ideas and alternatives for missions from which new P/Ps can be selected” (NASA/SP-2007-6105). The Pre-Phase A period is when users and stakeholders for a project or program are identified, high level requirements are compiled, preliminary design reference mission concepts are composed, possible ConOps developed, key capabilities of the systems are listed, and when request for proposal and contract-related details and deliverables for a future solicitation may be initially considered.
In order to fully appreciate the scope and nature of activities conducted during the Pre-Phase A part of the life cycle, the practitioner must understand SEE processes but also should review the detailed SEE diagram provided as an insert with NASA/SP-2007-6105 (see Table 2.2-1). It is also available online, see the References in Appendix D. An examination of the processes used in Pre-Phase A through Phase B (for Program Formulation) will show that in addition to the four system design processes (NASA/SP-2007-6105 section 4), five product realization processes from NASA/SP-2007-6105 section 5 are also performed, as well as the eight cross-cutting processes from NASA/SP-2007-6105 section 6. In the fold-out diagram, the practitioner will find that the activities listed for each SEE process are tailored to be appropriate for each phase.
Pre-Phase A NASA Systems Engineering Goals
Produce a broad spectrum of ideas and feasible alternatives
Review milestones and Key Decision Points (KDPs) for all phases are defined in section 2.3 of NPR 7120.5E. For Pre-Phase A, the Mission Concept Review (MCR), which supports KDP A for projects, is conducted near the end of Pre-Phase A.
MCR Entrance and success criteria are provided in NPR 7123.1B, Table G-3.
The MCR success criteria are fundamentally a review of the products of the activities conducted in Pre-Phase A. Ultimately it is up to the “Decision Authority” to determine if the P/P is mature and ready to progress to the next phase of the life cycle. For smaller projects, there may be a desire to go straight into Phase A and use the System Requirements Review (SRR) as the first KDP and milestone. In this case, it is strongly advised that an informal concept review be held to ensure that the concept “point of departure” is adequately communicated with stakeholders, domain experts, and team members before proceeding forward to make critical high level design decisions. It is also advised that Pre-Phase A activities and products should not be “skipped.”
It is critical that HSI practitioners actively engage in Pre-Phase A activities, reviews, and decisions to avoid costly revisions due to inadequate consideration of the human component of the P/P. The human-oriented mission goals, concepts, high level requirements, capabilities, and constraints must be clearly defined. Early inclusion of HSI practitioners ensures that the system concept is optimized for the developers, maintainers, trainers, and other system stakeholders in addition to end users. Domain personnel and SMEs can provide best practices and solutions for issues during concept development rather than later in system design when changes are more costly and more difficult to implement.
There are several HSI-related activities that must be initiated or completed during Pre-Phase A.
Per Key Concept #4, listed in section 1.4, getting started with HSI activities early is a best practice and necessary to achieve the cost reductions (avoidance) to LCC. Incorporating HSI early sets the stage for a successful design—one that accommodates humans, rather than forces the humans to accommodate to the design. A list of important HSI activities is provided in this section. These activities are not strictly HSI activities; with a few exceptions, HSI does not typically “own” system-level documents such as the ConOps, SEMP, and domain-specific documents. HSI practitioners generally work inside the SE process to provide inputs for SE products.
The relevant goals for the HSI practitioner during this phase are shown in Table 3.3-1.
Table 3.3-2 Goals and Success Mapping for HSI in Pre-Phase A
Milestone HSI Goals HSI Success Criteria
MCR
Must be identified early in the planning for any system, but try to avoid any “solution bias.”
Develop Operational Concepts
Document HSI factors, such as the number and skills of users, types of human interfaces, logistics infrastructure, maintainability, and training.
Produce HSI Requirements Captured at a high level along with stakeholder expectations
Initiate HSI Planning
Initiated to set up resources to produce key products
(standalone HSI Plan or input into the SEMP) of a concept and drive
considerations for alternative solutions (matured in the next phase)
Operational Concepts, as used above, can be in the form of mission scenarios, which include normal operations, as well as scenarios for emergency “off-nominal” and contingency
3.3.2 Pre-Phase A Process and Products
Most activities in Pre-Phase A flow down from the primary stakeholder “Goals, Requirements, Human Allocation” activities. Performing the Pre-Phase A processes will produce HSI-related products that then support activities in repeated iterations of concept evaluation or in later phases. Figure 3.1-1 is provided as a summary view of processes to be performed. HSI is distinguished from HFE practice in that HSI is “all about process.” All of the SEE processes are important, but some processes involve the HSI practitioner more than others. The relevant processes for the HSI practitioner during this phase are shown in Table 3.3-2. Refer to the SEHB, the SEHB wall chart, and NPR 7123.1B for supporting details. NPR 7123.1B also provides detailed process flow diagrams documenting the activities as well as the inputs and outputs for each activity.
Table 3.3-3 Process-Product Mapping for HSI in Pre-Phase A SEE
Process Process Title Key HSI Activities Major HSI Products Per Milestone
1 Stakeholder Expectations
Establish ConOps and
support strategies for use over the systems’ life, including allocation to humans
MCR: HSI inputs to mission and architecture, and ConOps (initial draft)
Analyze expectations to establish MOEs for customer satisfaction
MCR: initial set of MOEs defined
2 Technical design solutions for context of
use and LCC MCR: HSI inputs to technology and maturation strategies Verify the fully defined design
solution
preliminary inputs to HSI Plan or SEMP, or equivalent
SEE
Process Process Title Key HSI Activities Major HSI Products Per Milestone
17 Decision Analysis
Conduct decision analysis process for identified technical issues including HSI concerns
MCR: Support architecture and mission trade-offs and analysis;
coordinate decisions to allocate functions to humans
Several HSI-related products must be initiated or completed during Pre-Phase A. It should be noted that projects that have a significant human component required to achieve potentially hazardous missions may require multiple “passes” and concept design assessments. This can produce multiple assessment reports, multiple mockup configurations, and launch/landing models with thousands of simulation data runs, just to give a few examples.
These products are developed by executing the steps shown in Figure 3.1-1, Systems
Engineering Engine with HSI Inputs and Outputs, which is based on NASA/SP-2007-6105 and wall chart, with HSI details added.
The process starts with SEE 1, Stakeholder Expectations, to elicit needs, goals, and objectives for the product and mission. The HSI practitioner will be focused on identifying the touch-points, interfaces, and systems where humans are involved or allocated to perform functions.
The primary product from SEE 1 is the operations concept, which is eventually placed into the ConOps document. See chapter 4.4.2 of this document for more information on supporting ConOps development.
The second key product for the HSI practitioner will be to generate candidate measures of effectiveness (MOEs) that involve human participation. See chapter 4.4.5 of this document for developing and using HSI metrics.
Development of requirements using the stakeholder inputs and operations concepts is performed under SEE 2, Technical Requirements. Note: This does not include requirements management, which is SEE 11. As for all of the SEE processes, refer to NPR 7123.1B for detailed steps, inputs, and outputs. For Pre-Phase A, the requirements remain at a high level and the HSI input is focused on function allocation, which will support developing requirements in later phases.
See Table 4.4-2, Function allocation Process, for details on performing function allocation activities with HSI considerations.
Typically, domain participation is ensured through collaboration when developing requirements.
Although an HSI team can be formed during Pre-Phase A for larger Programs, typically the work is performed by domain and subject matter experts. Often the requirements, constraints,
measures of performance (MOPs), and technical performance measures (TPMs), and related products are classified as “candidate” during this phase. See section 4.4.4 for developing HSI-based requirements, and section 4.3.2 for organizing the HSI team.
Some HSI products can be delayed to Phase A for the first draft, but most will have materials produced and planning accomplished in this phase. If the P/P is human rated, then the additional programmatic requirements are levied for compliance (e.g., HSI team stood up by SRR per NPR 8705.2B). Capturing the planning materials produced during Pre-Phase A is important to be able to feed into the HSI Plan, if written, or the SEMP or similar engineering management document.
This activity is performed under SEE 10, Technical Planning, which is a cross-cutting process.
See HSIPG section 4.4.1 on writing the HSI Plan.
The products from SEE 1 and SEE 2, along with other decisional information, will feed SEE 3, Logical Decomposition, activities. During Pre-Phase A, the HSI practitioner should start to identify which mechanisms and models will be used to strategically derive and decompose detailed requirements. These methods can include a variety of human assessments from low-fidelity mockups, task analysis, human constraints and standards, human-centric design
guidance, etc. For a list of these types of resources, refer to the References in Appendix D. See section 4.4.7 for ensuring the usability of systems and section 4.3.4 on identifying human-centered trade-offs.
The Design Solution process, SEE 4, follows next and uses the Pre-Phase A products to develop the set of potential solutions, recommended architectures, and inputs to the technology and maturation strategies. The HSI practitioner participates to ensure the design solution options are validated against the human goals and objectives, and concept documents. Plus the HSI
practitioner can ensure that any LCC analysis includes the full scope of the life cycle, which includes an evaluation of the cost of operational resources and activities for each design
alternative. This work is supported by SEE 17, Decision Analysis, which uses the Pre-Phase-A products as inputs, and provides overall decisional outcomes for the P/P. See HSIPG sections 4.4.9 and 4.4.10 for LCC as it applies to HSI.
While not explicitly listed in Table 3.3-2, the HSI practitioner should also participate in SEE 13, Technical Risk Management, which also includes risk analysis activities.
Prototyping and modeling can be extensive for projects, which combine human habitability, operations, and conducting science such as a crew vehicle or similar manned platform. These physical products are produced in SEE 5, Product Implementation. Figure 3.3-1 is a photograph of a crew vehicle mockup that was used in an HITL to analyze access, reach, and visual
perception. As you can see, a modest investment was made to construct a structurally stable model that could be reconfigured inside. Figure 3.3-2 shows a mockup for an aviation cockpit for evaluation of pilot performance. The pilot is outfitted with an eye-tracking device to gain insight into both the layout and human performance when managing concurrent tasks. While some HITL mockups can and should be elaborate, in many cases prototypes need not be overly detailed or costly to provide valuable design information. The systems engineer should be well
aware that the end product includes not only the final deliverable, but enabling products as well.
A rocket cannot be sent to space without the availability of an integration and assembly facility.
Also, reducing risk is a key component of human space flight; mockups and models are stepping stones along the way to both successful, well-crafted solutions and for ensuring the safety of the operators.
Figure 3.3-1 Example: Crew Vehicle Mockup
Although not explicitly listed in Table 3.3-2, additional product realization processes are
executed as shown in Figure 3.1-1 to verify, validate, and integrate (SEE 6) any products created in SEE 5, Product Implementation. The HSI practitioner may be involved in these processes.
For Pre-Phase A, SEE 7, Product Verification and SEE 8, Product Verification, are usually limited to products produced in the phase, for example mockups and models.
3.4 Phase A: Concept & Technology Development