|
A. b, c, e, a, f, d |
||
|
B. c, d, e, b, a, f |
||
|
C. c, a, d, b, e, f |
||
|
D. b, e, c, a, f, d |
||
|
E. a, f, c, d, e, b |
|
A. continues to decline at a steady pace. |
||
|
B. continues to rapidly grow. |
||
|
C. practically remains the same regardless of the size or complexity. |
||
|
D. is not influenced by these factors. |
||
|
E. only increases if the new system is an interplanetary space mission. |
|
A. always performed system functions. |
||
|
B. never failed at the interfaces. |
||
|
C. never experienced cost overruns or schedule delays. |
||
|
D. often resulted in unusable systems. |
||
|
E. always experienced cost overruns or schedule delays. |
|
A. it meets the expectations of the customer and other stakeholders. |
||
|
B. the product accomplishes the intended purpose in the intended environment. |
||
|
C. the product can meet each “shall” statement as proven through performance of a test, analysis, inspection, or demonstration. |
||
|
D. testing is conducted under realistic conditions (or simulated conditions) on end products for the purpose of determining the effectiveness and suitability. |
||
|
E. All of the above |
|
A. it meets the expectations of the customer and other stakeholders as shown through performance of a test, analysis, inspection, or demonstration. |
||
|
B. the product accomplishes the intended purpose in the intended environment. |
||
|
C. the product can meet each “shall” statement as proven through performance of a test, analysis, inspection, or demonstration. |
||
|
D. testing is conducted under realistic conditions (or simulated conditions) on end products for the purpose of determining the effectiveness and suitability. |
||
|
E. A, B, and D |
|
A. relates back to the ConOps document and is conducted under realistic conditions (or simulated conditions). |
||
|
B. relates to determining the effectiveness and suitability of the product for use in mission operations by typical users. |
||
|
C. shows that the product accomplishes the intended purpose in the intended environment. |
||
|
D. relates back to the approved requirements set and can be performed at different stages in the product life cycle. |
||
|
E. All of the above |
|
A. relates back to the ConOps document and is conducted under realistic conditions (or simulated conditions). |
||
|
B. relates to determining the effectiveness and suitability of the product for use in mission operations by typical users. |
||
|
C. shows that the product can meet each “shall” statement as proven through performance of a test, analysis, inspection, or demonstration. |
||
|
D. relates back to the approved requirements set and can be performed at different stages in the product life cycle. |
||
|
E. All of the above |

|
A. (a) – (ii) (b) – (i) (c) – (iii) |
||
|
B. (a) – (i) (b) – (ii) (c) – (iii) |
||
|
C. (a) – (iii) (b) – (ii) (c) – (i) |
||
|
D. (a) – (i) (b) – (iii) (c) – (ii) |
||
|
E. (a) – (iii) (b) – (i) (c) – (ii) |
|
A. i, iii, ii |
||
|
B. iii, i, ii |
||
|
C. ii, i, iii |
||
|
D. ii, iii, i |
||
|
E. i, ii, iii |
|
A. i & iii |
||
|
B. ii & iii |
||
|
C. ii & iv |
||
|
D. i & iv |

|
A. (a) – (i), (ii), (iv) (b) – (iii), (v), (vi), (vii) |
||
|
B. (a) – (i), (ii), (iii), (iv) (b) – (v), (vi), (vii) |
||
|
C. (a) – (i), (ii), (iii) (b) – (iv), (v), (vi), (vii) |
||
|
D. (a) – (i), (ii) (b) – (iii), (iv), (v), (vii) |
||
|
E. (a) – (i), (ii), (v), (vi) (b) – (iii), (iv), (vii) |

|
A. (a) – (i), (ii) (b) – (ii), (iii), (iv) |
||
|
B. (a) – (i), (ii) (b) – (iii), (iv) |
||
|
C. (a) – (i), (ii) (iii) (b) – (iii), (iv) |
||
|
D. (a) – (i), (ii), (iii) (b) – (iv) |
||
|
E. (a) – (i) (b) – (ii), (iii), (iv) |
|
A. recognize the need or the discovery of an opportunity and proceed through various stages of development to a final disposition. |
||
|
B. decompose the program/project life cycle into phases and organize the entire process into more manageable pieces. |
||
|
C. establish a cost-effective program that is demonstrably capable of meeting Agency and mission directorate goals and objectives. |
||
|
D. execute the program and constituent projects and ensure the program continues to contribute to Agency goals and objectives within funding constraints. |
||
|
E. devise various feasible concepts from which new projects (programs) can be selected. |
|
A. recognize the need or the discovery of an opportunity and proceed through various stages of development to a final disposition. |
||
|
B. decompose the program/project life cycle into phases and organize the entire process into more manageable pieces. |
||
|
C. establish a cost-effective program that is demonstrably capable of meeting Agency and mission directorate goals and objectives. |
||
|
D. execute the program and constituent projects and ensure the program continues to contribute to Agency goals and objectives within funding constraints. |
||
|
E. devise various feasible concepts from which new projects (programs) can be selected. |
|
A. control gate. |
||
|
B. concept study. |
||
|
C. pre-phase A. |
||
|
D. formulation. |
||
|
E. need for a higher level manager. |
|
A. produce a broad spectrum of ideas and alternatives for missions from which new programs/projects can be selected. |
||
|
B. determine the feasibility and desirability of a suggested new major system and establish an initial baseline compatibility with NASA’s strategic plans. |
||
|
C. define the project in enough detail to establish an initial baseline capable of meeting mission needs. |
||
|
D. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
E. implement important changes based on stakeholder input |
|
A. PDR (Preliminary Design Review) and Safety Review. |
||
|
B. SRR (System Requirements Review), MDR (Mission Definition Review) and SDR (System Definition Review). |
||
|
C. CDR (Critical Design Review), PRR (Production Readiness Review), SIR (System Integration Review) and Safety Review. |
||
|
D. MCR (Mission Concept Review) and Informal Proposal Review. |
||
|
E. TRR (Test Readiness Review), SAR (System Acceptance Review), ORR (Operational Readiness Review), FRR (Flight Readiness Review), System functional and physical configuration audits and Safety Review. |
|
A. complete the detailed design of the system (and its associated subsystems, including its operations systems), fabricate hardware, and code software. |
||
|
B. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
||
|
C. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
D. determine the feasibility and desirability of a suggested new major system and establish an initial baseline compatibility with NASA’s strategic plans. |
||
|
E. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
|
A. PDR (Preliminary Design Review) and Safety Review. |
||
|
B. SRR (System Requirements Review), MDR (Mission Definition Review) and SDR (System Definition Review). |
||
|
C. CDR (Critical Design Review), PRR (Production Readiness Review), SIR (System Integration Review) and Safety Review. |
||
|
D. PLAR (Post-Launch Assessment Review), CERR (Critical Events Readiness Review), PFAR (Post-Flight Assessment Review), System Upgrade Review and Safety Review. |
||
|
E. DR (Decommissioning Review). |
|
A. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
B. implement the systems decommissioning/disposal plan developed in Phase C and analyze any returned data and samples. |
||
|
C. define the project in enough detail to establish an initial baseline capable of meeting mission needs. |
||
|
D. complete the detailed design of the system (and its associated subsystems, including its operations systems), fabricate hardware, and code software. |
||
|
E. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
|
A. PDR (Preliminary Design Review) and Safety Review. |
||
|
B. CDR (Critical Design Review), PRR (Production Readiness Review), SIR (System Integration Review) and Safety Review. |
||
|
C. MCR (Mission Concept Review) and Informal proposal review. |
||
|
D. TRR (Test Readiness Review), SAR (System Acceptance Review), ORR (Operational Readiness Review), FRR (Flight Readiness Review), System functional and physical configuration audits and Safety Review. |
||
|
E. PLAR (Post-Launch Assessment Review), CERR (Critical Events Readiness Review), PFAR (Post-Flight Assessment Review), System upgrade review and Safety Review. |
|
A. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
B. determine the feasibility and desirability of a suggested new major system and establish an initial baseline compatibility with NASA’s strategic plans. |
||
|
C. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
||
|
D. complete the detailed design of the system (and its associated subsystems, including its operations systems), fabricate hardware, and code software. |
||
|
E. implement the systems decommissioning/disposal plan developed in Phase C and analyze any re- turned data and samples. |
|
A. PLAR (Post-Launch Assessment Review), CERR (Critical Events Readiness Review), PFAR (Post-Flight Assessment Review), System upgrade review, and Safety Review. |
||
|
B. DR (Decommissioning Review). |
||
|
C. CDR (Critical Design Review), PRR (Production Readiness Review), SIR (System Integration Review), and Safety Review. |
||
|
D. MCR (Mission Concept Review) and Informal proposal review. |
||
|
E. TRR (Test Readiness Review), SAR (System Acceptance Review), ORR (Operational Readiness Review), FRR (Flight Readiness Review), System functional and physical configuration audits, and Safety Review. |
|
A. implement the systems decommissioning/disposal plan developed in Phase C and analyze any re- turned data and samples. |
||
|
B. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
||
|
C. complete the detailed design of the system (and its associated subsystems, including its operations systems), fabricate hardware, and code software. |
||
|
D. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
E. show the disposal process |
|
A. TRR (Test Readiness Review), SAR (System Acceptance Review), ORR (Operational Readiness Review), FRR (Flight Readiness Review), System functional and physical configuration audits, and Safety Review. |
||
|
B. PLAR (Post-Launch Assessment Review), CERR (Critical Events Readiness Review), PFAR (Post-Flight Assessment Review), System upgrade review, and Safety Review. |
||
|
C. SRR (System Requirements Review), MDR (Mission Definition Review), and SDR (System Definition Review). |
||
|
D. PDR (Preliminary Design Review) and Safety Review. |
||
|
E. CDR (Critical Design Review), PRR (Production Readiness Review), SIR (System Integration Review), and Safety Review. |
|
A. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
||
|
B. complete the detailed design of the system (and its associated subsystems, including its operations systems), fabricate hardware, and code software. |
||
|
C. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
||
|
D. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
E. implement the systems decommissioning/disposal plan developed in Phase C and analyze any re- turned data and samples. |
|
A. SRR (System Requirements Review), MDR (Mission Definition Review), and SDR (System Definition Review). |
||
|
B. PDR (Preliminary Design Review) and Safety Review. |
||
|
C. PLAR (Post-Launch Assessment Review), CERR (Critical Events Readiness Review), PFAR (Post-Flight Assessment Review), System upgrade review, and Safety Review. |
||
|
D. DR (Decommissioning Review). |
||
|
E. MCR (Mission Concept Review) and Informal proposal review. |
|
A. allow for scoping and ConOps exercises |
||
|
B. determine the feasibility and desirability of a suggested new major system and establish an initial baseline compatibility with NASA’s strategic plans. |
||
|
C. assemble and integrate the products and create the system, meanwhile developing confidence that it will be able to meet the system requirements; conduct launch and prepare for operations. |
||
|
D. conduct the mission and meet the initially identified need and maintain support for that need. |
||
|
E. implement the systems decommissioning/disposal plan developed in Phase C and analyze any re- turned data and samples. |
|
A. SRR (System Requirements Review), MDR (Mission Definition Review), and SDR (System Definition Review). |
||
|
B. CDR (Critical Design Review), PRR (Production Readiness Review), SIR (System Integration Review), and Safety Review. |
||
|
C. TRR (Test Readiness Review), SAR (System Acceptance Review), ORR (Operational Readiness Review), FRR (Flight Readiness Review), System functional and physical configuration audits, and Safety Review |
||
|
D. PLAR (Post-Launch Assessment Review), CERR (Critical Events Readiness Review), PFAR (Post-Flight Assessment Review), System upgrade review, and Safety Review |
||
|
E. DR (Decommissioning Review) |
|
A. Critical Design Review |
||
|
B. Preliminary Design Review |
||
|
C. System Definition Review |
||
|
D. System Requirements Review |
||
|
E. Mission Concept Control |
|
A. Preliminary Design Review. |
||
|
B. Critical Design Review. |
||
|
C. System Requirements Review. |
||
|
D. System Definition Review. |
||
|
E. Functional Design Review. |
|
A. system requirements baseline. |
||
|
B. allocated baseline. |
||
|
C. functional baseline. |
||
|
D. preliminary design baseline. |
||
|
E. functional system baseline. |
|
A. Phase A. |
||
|
B. Phase B. |
||
|
C. Phase C. |
||
|
D. Pre-phase A. |
||
|
E. Final phase. |
|
A. a need or the discovery of an opportunity and proceed through various stages of development to a final disposition. |
||
|
B. defining the major NASA life-cycle phases. |
||
|
C. a categorization of everything that should be done to accomplish a program or project into distinct phases. |
||
|
D. establishing a cost-effect program that is demonstrably capable of meeting goals and objectives. |
||
|
E. determining the review criteria for each phase to deliver a cost effective solution. |
|
A. Concept and Technology Development. |
||
|
B. Operations and Sustainment. |
||
|
C. Identity Feasible Alternatives. |
||
|
D. Formulation and Implementation. |
||
|
E. Final Design and Fabrication. |
|
A. the events at which the decision authority determines the readiness of a program/project to progress to the next phase of the life cycle. |
||
|
B. project reviews done at the beginning of each phase to determine the need for that phase. |
||
|
C. are the programmatic gates for going from Pre-Phase to Phase. |
||
|
D. used to determine the timeline and cost of doing a conceptual design. |
||
|
E. tools used by project managers to assess team members’ performance. |
|
A. 3 |
||
|
B. 5 |
||
|
C. 7 |
||
|
D. 9 |
|
A. look at many different concepts to see if they meet the program/project objectives. |
||
|
B. design a system and all of its subsystems so that it will be able to meet its requirements. |
||
|
C. define the project in enough detail to establish a design baseline. |
||
|
D. determine the feasibility of a suggested new system in preparation for seeking funding. |
||
|
E. build subsystems and operations systems and integrate to create a system. |
|
A. a project team cannot proceed from Pre-Phase A to Phase A. |
||
|
B. they are critical for reviewing documents specific to conceptual design. |
||
|
C. NASA projects today are largely multidisciplinary. |
||
|
D. they are a part of the guidelines established during the inception of NASA moon missions. |
||
|
E. they are mechanisms for project review and help determine go/no go decisions, or whether a project should move forward. |
|
A. they are critical for reviewing documents specific to conceptual design. |
||
|
B. a project team cannot proceed from Pre-Phase A to Phase A. |
||
|
C. they are a part of the guidelines established during the inception of NASA moon missions. |
||
|
D. they are an agreed-to set of requirements, designs, or documents that are established after each project/program phase. |
||
|
E. they determine the success of a project. |
|
A. Pre-Phase A |
||
|
B. Phase A |
||
|
C. Phase B |
||
|
D. Phase C |
||
|
E. Phase F |
|
A. Critical Design Review. |
||
|
B. Non-advocate Review/Confirmation Review. |
||
|
C. Flight Readiness Review. |
||
|
D. Post-launch Assessment Review. |
||
|
E. Mission Concept Review. |
|
A. it is the first phase in implementation and when the costs of the project are increasing. |
||
|
B. the team is still reviewing concepts to determine which one best meets the requirements. |
||
|
C. it is a critical time to design a system and all of its subsystems so that it will be able to meet its requirements. |
||
|
D. a critical time to define the project in enough detail to establish a design baseline. |
||
|
E. a critical time to determine the feasibility of a suggested new system in preparation for seeking funding. |
|
A. that which is relevant to your project. |
||
|
B. that which is the goal of your project. |
||
|
C. identifying stakeholders of your project. |
||
|
D. that which is relevant to operational concepts. |
||
|
E. that which involves identifying the project team. |
|
A. The project will be a failure otherwise. |
||
|
B. Because it helps to identify the objectives of the mission. |
||
|
C. Stakeholder expectations translate to defining the scope of a project. |
||
|
D. Stakeholders dictate the success or failure of a project. |
||
|
E. Stakeholders may not be aware of the process involved in successfully executing a space mission. |
|
A. Top level requirements and ConOps |
||
|
B. Mission drivers |
||
|
C. Operational objectives |
||
|
D. Constraints |
||
|
E. Design drivers |
|
A. laying out the Design Reference Missions. |
||
|
B. the process of capturing scope and mission CONOPS. |
||
|
C. the initial process within the SE engine that establishes the foundation from which the system is designed and the product is realized. |
||
|
D. the process of identifying the dimensions of scope. |
||
|
E. the process of identifying all stakeholders for a proposed mission. |
|
A. understanding and defining the mission objectives and operational concepts |
||
|
B. complete and thorough requirements traceability |
||
|
C. clear and unambiguous requirements |
||
|
D. document all decision made during the development of the original design concept in the technical data package |
||
|
E. All of the above |
|
A. need |
||
|
B. vision of a particular stakeholder |
||
|
C. operational objectives |
||
|
D. presidential directive |
||
|
E. an individual within NASA |
|
A. defines the objectives of the mission. |
||
|
B. describes the system characteristics from an operational perspective and helps facilitate an understanding of the system goals. |
||
|
C. identifies customers and stakeholders. |
||
|
D. elaborates on the scope of a mission. |
||
|
E. determines the success or failure of a proposed mission. |
|
A. are four interdependent, highly iterative and recursive processes, resulting in a validated set of requirements and a validated design solution that satisfies a set of stakeholder expectations. |
||
|
B. involve identifying stakeholder expectations through stakeholder expectations definition. |
||
|
C. involve elaborating on the scope of a proposed mission. |
||
|
D. capture the project scope and mission CONOPS. |
||
|
E. define the success or failure of a proposed mission. |
|
A. Phase A through Phase F. |
||
|
B. Phase A through Phase E. |
||
|
C. Pre-Phase A through Phase C. |
||
|
D. Phase D through Phase F. |
||
|
E. Pre-Phase A through Phase F. |
|
A. to identify who the stakeholders are and how they intend to use the product. |
||
|
B. to serve as the basis for subsequent definition documents such as the operations plan, launch and early orbit plan, and operations handbook. |
||
|
C. used to translate the high-level requirements derived from the stakeholder expectations and the outputs of the Logical Decomposition Process into a design solution. |
||
|
D. to transform the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements. |
||
|
E. the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. |
|
A. to serve as the basis for subsequent definition documents such as the operations plan, launch and early orbit plan, and operations handbook. |
||
|
B. used to translate the high-level requirements derived from the stakeholder expectations and the outputs of the Logical Decomposition Process into a design solution. |
||
|
C. to identify who the stakeholders are and how they intend to use the product. |
||
|
D. to transform the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements. |
||
|
E. the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. |
|
A. used to translate the high-level requirements derived from the stakeholder expectations and the outputs of the Logical Decomposition Process into a design solution. |
||
|
B. to identify who the stakeholders are and how they intend to use the product. |
||
|
C. to transform the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements. |
||
|
D. to serve as the basis for subsequent definition documents such as the operations plan, launch and early orbit plan, and operations handbook. |
||
|
E. the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. |
|
A. to transform the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements. |
||
|
B. the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. |
||
|
C. to serve as the basis for subsequent definition documents such as the operations plan, launch and early orbit plan, and operations handbook. |
||
|
D. used to translate the high-level requirements derived from the stakeholder expectations and the outputs of the Logical Decomposition Process into a design solution. |
||
|
E. to identify who the stakeholders are and how they intend to use the product. |
|
A. System requirements and objectives |
||
|
B. Description of major phases, operation timelines; operational scenarios and/or DRM; end-to-end communications strategy; command and data architecture, etc |
||
|
C. Operational power budget |
||
|
D. Link budget |
||
|
E. Launch interface specifications |
|
A. Phase E |
||
|
B. Phase A through Phase F. |
||
|
C. Pre-Phase A through Phase C. |
||
|
D. Phase A through Phase C. |
||
|
E. Phase A and Phase B only. |
|
A. the activity that drives cost. |
||
|
B. a characteristic or statement that captures the understanding of what is to be done, how well, and under what constraints. |
||
|
C. a method that measures performance. |
||
|
D. a baseline of concept of operations. |
||
|
E. a way to analyze the scope of the problem. |
|
A. recursive and iterative. |
||
|
B. linear and non-iterative. |
||
|
C. singular and non-repetitive. |
||
|
D. final and iterative. |
||
|
E. recursive and non-iterative. |
|
A. mission concept. |
||
|
B. stakeholder expectations. |
||
|
C. cost. |
||
|
D. effectiveness. |
||
|
E. gate controls. |
|
A. design and product constraints. |
||
|
B. measures of performance. |
||
|
C. functional and behavioral expectations. |
||
|
D. scope of problem. |
||
|
E. baselined stakeholder expectations. |
|
A. change of priorities. |
||
|
B. new understanding of the difficulties of an implementation approach. |
||
|
C. new requirements being added or discovered. |
||
|
D. measured performance not meeting the requirement performance. |
||
|
E. All of the above |
|
A. presidential directive. |
||
|
B. vision of a particular stakeholder. |
||
|
C. operational objectives. |
||
|
D. stakeholder and customer need statements. |
||
|
E. any or all of the above. |
|
A. design boundary in process activity in requirements. |
||
|
B. typical input needed for the requirements process. |
||
|
C. typical output for the technical requirements definition process. |
||
|
D. measure based on the expectations and requirements that will be tracked. |
||
|
E. approved set of requirements that represents a complete description of the problem. |
|
A. how well the system needs to perform the functions. |
||
|
B. what functions need to be done to accomplish the objective. |
||
|
C. customers and stakeholders. |
||
|
D. costs. |
||
|
E. mission statement. |
|
A. must. |
||
|
B. will. |
||
|
C. may. |
||
|
D. shall. |
||
|
E. can. |
|
A. develop baselines for a system. |
||
|
B. draw objective comparisons and make design decisions. |
||
|
C. define the mission. |
||
|
D. make mission decisions. |
||
|
E. define the process. |
|
A. it supports decisions throughout the systems engineering process. |
||
|
B. to understand the full implications of the goals, objectives, and constraints to formulate an appropriate system solution. |
||
|
C. to address management of problems, nonconformance, and anomalies. |
||
|
D. to determine the advantage of one alternative over another in terms of equivalent cost or benefits. |
||
|
E. None of the above. |
|
A. help to understand the full implications of the goals, objectives, and constraints to formulate an appropriate system solution. |
||
|
B. determine the advantage of one alternative over another in terms of equivalent cost or benefits. |
||
|
C. identify desirable and practical alternatives among requirements, technical objectives, design, program schedule, functional and performance requirements, and life cycle costs are identified and conducted. |
||
|
D. help to address management of problems, nonconformance, and anomalies. |
||
|
E. provide guidance, methods, and tools to support the Decision Analysis Process at NASA. |
|
A. design and product constraints. |
||
|
B. costs. |
||
|
C. functional and behavioral expectations. |
||
|
D. scope of problem. |
||
|
E. measure of effectiveness, or MOE, and measure of performance, or MOP. |
|
A. how well the trade study is conducted. |
||
|
B. how the mission is achieved. |
||
|
C. how well the costs are controlled. |
||
|
D. how well mission objectives are achieved. |
||
|
E. All of the above |
|
A. constraints. |
||
|
B. technical requirements. |
||
|
C. operational objectives. |
||
|
D. stakeholder and customer need statements. |
||
|
E. life cycle cost. |
|
A. quantitative measure. |
||
|
B. qualitative measure. |
||
|
C. single measure. |
||
|
D. functional measure. |
||
|
E. None of the above |
|
A. a tool for cost-benefit analysis. |
||
|
B. a design tool for accommodating system requirements. |
||
|
C. a graphical method of capturing alternatives with multiple variables. |
||
|
D. a method for evaluating a project team. |
||
|
E. an extension for decision based trade studies. |
|
A. alternatives. |
||
|
B. criterion. |
||
|
C. trade studies. |
||
|
D. requirements. |
||
|
E. stakeholders. |
|
A. baselines. |
||
|
B. requirements. |
||
|
C. competing study alternatives. |
||
|
D. criteria. |
||
|
E. risks. |
|
A. People |
||
|
B. Products |
||
|
C. Processes |
||
|
D. Time |
||
|
E. Environment |
|
A. Design |
||
|
B. Hardware |
||
|
C. Creation |
||
|
D. Operation |
||
|
E. People |
|
A. system design. |
||
|
B. product realization. |
||
|
C. technical management. |
||
|
D. scope definition. |
||
|
E. cost benefit analysis. |
|
A. systems engineering. |
||
|
B. product realization. |
||
|
C. technical management. |
||
|
D. project control. |
||
|
E. resource management. |
|
A. An aging workforce |
||
|
B. Skill retention |
||
|
C. Technical performance |
||
|
D. Foregoing the design phase |
||
|
E. Skipping the testing phase to reduce cost |
|
A. key decision points |
||
|
B. top-level architecture |
||
|
C. product baseline |
||
|
D. scope definition |
||
|
E. major project review |
|
A. Potential for wasted effort |
||
|
B. Potential for inconsistent design |
||
|
C. Avoid human labor |
||
|
D. Potential for automated design |
||
|
E. Potential for disciplined systematic approach |
|
A. Transitioning from individual work performance to team performance |
||
|
B. Transitioning from well-defined, bounded problems to ill-defined, ambiguous problems |
||
|
C. Transition from theory-based learning to learning from experience |
||
|
D. Absence of critical thinking |
||
|
E. Absence of supervisors and accountability |
|
A. no individual has all the required knowledge. |
||
|
B. diverse team interaction encourages ingenuity and creativity. |
||
|
C. they can identify and resolve technical subsystems conflicts early. |
||
|
D. there are fewer problems transitioning from engineering to manufacturing to operations. |
||
|
E. an individual can only specialize in one discipline. |
|
A. for career planning and problem solving. |
||
|
B. for team building and enhancing teamwork. |
||
|
C. for hiring and staffing. |
||
|
D. as a leadership tool. |
||
|
E. to determine a successful career path. |
|
A. Preliminary Design Review |
||
|
B. System Definition Review |
||
|
C. System Requirements Review |
||
|
D. Critical Design Review |
||
|
E. Mission Design Review |
|
A. system baseline |
||
|
B. system definition baseline |
||
|
C. preliminary design baseline |
||
|
D. system requirements baseline |
||
|
E. functional baseline |
|
A. needs statements |
||
|
B. contracts |
||
|
C. presidential directives |
||
|
D. announcement of opportunities |
||
|
E. proposals |
|
A. Upper Level Requirements and Expectations |
||
|
B. Top-Level Requirements and Expectations |
||
|
C. ConOps (Concept of Operations) |
||
|
D. Identified Customers and Stakeholders |
||
|
E. Process Activities |
|
A. Upper Level Requirements and Expectations |
||
|
B. Identified Customers and Stakeholders |
||
|
C. Top-Level Requirements and Expectations |
||
|
D. ConOps (Concept of Operations) |
||
|
E. Process Activities |
|
A. Top-level requirements and expectations |
||
|
B. Technical requirements |
||
|
C. Concept of Operations |
||
|
D. Technical Measures |
||
|
E. Process Activities |
|
A. Top-level requirements and expectations |
||
|
B. Technical requirements |
||
|
C. Concept of Operations |
||
|
D. Technical Measures |
||
|
E. Process Activities |
|
A. Technical requirements |
||
|
B. Technical measures |
||
|
C. System architecture model |
||
|
D. End product requirements |
||
|
E. Functional flow block diagrams |
|
A. Technical requirements |
||
|
B. Technical measures |
||
|
C. System architecture model |
||
|
D. End product requirements |
||
|
E. Functional flow block diagrams |
|
A. The system specification |
||
|
B. Technical requirements |
||
|
C. Logical decomposition models |
||
|
D. The end-product specification |
||
|
E. The system external interface specifications |
|
A. The system specification |
||
|
B. Technical requirements |
||
|
C. Logical decomposition models |
||
|
D. The end-product specification |
||
|
E. The system external interface specifications |
|
A. Functional |
||
|
B. Performance |
||
|
C. Regulatory |
||
|
D. Derived |
||
|
E. Constraints |