SES 405: Exploration Systems Engineering Class Review Exploration Systems Engineering: Class Review
Requirements The Basics Requirements define the problem to be solved and establish the terms by which mission success will be measured. Requirements are the single biggest problem in development projects so attention to detail in creating good requirements is vital. The later a problem is discovered the more costly is the recovery. Requirements are distributed within the system architecture via flow-down, allocation and derivation. Requirements traceability is a technique of tracking the source and connections between requirements. It is used to assess the consequences of potential requirements changes. When a system is decomposed into smaller segments, interfaces are created that must be defined and managed. Exploration Systems Engineering: Class Review 2
Writing Requirements Good requirements Are SMART: Specific, Measurable, Achievable, Relevant and Traceable It is good practice to capture the rationale and preliminary technique for verification when writing requirements. Requirement validation is a process of ensuring that the set of requirements is correct, complete, and consistent. Since the cost of reconciling undefined requirements grows as the project matures, undefined (TBD) and estimated (TBR) requirements should be resolved as early as possible. Exploration Systems Engineering: Class Review 3
The Project Life Cycle A project is divided into distinct life cycle phases. Pre-Phase A: Concept studies Phase A: Concept and technology development Phase B: Preliminary design and technology completion Phase C: Final design and fabrication Phase D: System assembly, test and launch (otherwise known as panic mode) Phase E: Operations and sustainment Phase F: Closeout or disposal These phases are separated by control gates - typically associated with a major project review, such as preliminary design review (PDR). Each project phase has a distinct purpose and set of products. At the end of each phase a new system baseline or an agreed-to set of requirements, designs, or documents is established. A system baseline is the point of departure for the development work in each new phase. Exploration Systems Engineering: Class Review 4
Major Project Reviews Precede Each Key Decision Point Project Phases Pre-A Concept Studies FORMULATION A Concept & Technology Development B Preliminary Design & Technology Completion C Final Design & Fabrication IMPLEMENTATION D E F System Assembly, Test, & Launch Operations & Sustainment Closeout Key Decision Points Major Reviews A B C D E Mission Concept Review Systems Requirements Review Mission/System Definition Review Preliminary Design Review Critical Design Review F Independent Cost Estimates Systems Integration Review Operational Readiness Review Flight Readiness Review Post Launch Assessment Review Decommissioning Review Exploration Systems Engineering: Class Review 5
The Engineering Activities in the Project Life Cycle A Mission Requirements & Priorities Develop System Requirements & System Architecture System Demonstration & Validation Integrate System & Verify Performance Specs E System Level Subsystems Allocate Performance Specs & Build Verification Plan Component Integration & Verification B Design Components Verify Component Performance Components C Fabricate, Assemble, Code & Procure Parts D Time and Project Maturity Exploration Systems Engineering: Class Review
Configuration and Change Management System baselines capture the complete, current system description. System baselines are updated periodically at five major milestone reviews - SDR, PDR, CDR, FRR and ORR. Requirements and configuration changes are inevitable, so a formal process of considering the implications of any changes is mandatory. It is important to have managed baselines, requirements and configurations so that the entire team is working with the same assumptions of what the current system is, and what it must do. Systems engineering is responsible for creating and updating the system baseline, assessing the implications of considered changes and disseminating the news of any accepted changes. Exploration Systems Engineering: Class Review 7
Verification Validation - Did we build the right system? Verification - Did we build the system correctly? Requirements validation - Are the requirements complete, consistent, SMART and do they capture the intent of the system? Requirements verification is about establishing confidence that the system will perform in its intended environment. Requirements are verified by test, demonstration, analysis and inspection. Space systems go through rigorous ground-based tests that simulate the launch and space environment. Using heritage designs can save development time and money, but any heritage design should be validated and verified as if it represented new hardware. Simple procedural errors - like borrowing another project s bolts - can lead to multi-million dollar (or life threatening) accidents. Exploration Systems Engineering: Class Review 8
Technical Reviews Technical reviews are key development milestones used to measure progress, assess project maturity and to infuse lessons from the past. They Provide confirmation of completed effort and readiness to commit additional resources for the next phase. Encourage and establish project discipline with an integrated project team perspective. Identify risks and review mitigation options. Describe plans and priorities for the next phase. There are 11 reviews in the minimum set of technical reviews for a NASA robotic mission. These reviews cover the entire mission life assessing the concepts and designs early; readiness for test, flight and operations in mid-life and plans for disposal at the mission s end. These reviews are held to demonstrate that the appropriate products, accomplishments and plans have been completed before proceeding to the next phase. Appropriate products, accomplishments and plans are based on the lessons of hundreds of past projects (best practices). Exploration Systems Engineering: Class Review 9
Schedule There are different methods for displaying project schedule information. Gantt and Milestone charts relate activities to calendar dates in an easily understood format. Network schedules show the dependencies between activities in a graphical portrayal with activity durations. Critical Path is the sequence of activities that will take the longest to accomplish. Any delay on this path will delay the project. Activities that are not on the critical path have a certain amount of time that they can be delayed until they, too are on the critical path. This time is called float (or slack). There is inherent risk in developing schedules. Probabilistic techniques can be used to assess the risk. For space missions, guidelines exist for determining schedule margin. Schedule information, such as the accomplishment of milestones or the amount of schedule slack, can be used to report project status/progress (as a form of technical performance measures). Exploration Systems Engineering: Class Review 10
Gantt Chart Format aka Bar Charts Gantt and milestone charts are best used for displaying the planned activities and events of a project and the progress in meeting them. This makes them very useful for presenting schedule and program status information in a concise simple format at such things as program or activity reviews. Because of its simplicity and ease of interpretation, it is a particularly good tool for communicating to higher management when information must be presented quickly and efficiently. Exploration Systems Engineering: Class Review 11
Example Milestone Chart Pre-formulation Phase A Phase B Phase C/D Non-Traditional = 0% Complete = 100% Complete FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12 FY13 Flight Test/ Mission Milestones LAS-1 LAS-2 LAS-3 RRF-1 RRF-2 RRF-3 LAS-4 ISS-1 ISS-2 UCM-1 PC-1 PC-2 ISS-3 Program Integration L1 Req Baseline Review Pre-NAR Kickoff L2 SRR Complete Pre-NAR Complete L2 SDR NAR PDR Complete CDR Complete CEV Delivery of Crew & Service Module ATP CEV SRR Contractor 1&2 SRR SDR PDR CDR LAS-1 LAS-2 LAS-3 RRF-1 RRF-2 RRF-3 LAS-4 ISS-1 PC-1 Unpressurized payload structure Delivery of Launch Abort System LAS-1 LAS-2 LAS-3 RRF-1 RRF-2 LAS-4 RRF-3 ISS-1 CLV System Engineering & Integration Gov t Lead SRR Jun PDR Feb CDR Jul First Stage ATP SRR PDR CDR RRF-1 RRF2 RRF3 Del ISS1 to KSC Upper Stage Gov t Lead SRR PDR CDR MPTA Fab, Integ & Test Jul Nov Apr Del for RRF2 RRF3 US ISS-1 to KSC Upper Stage Engine (RS-25d/e) ATP SRR PDR CDR Dev Eng Needed MPTA RRF3 Del for RRF2 ISS-1 Exploration Systems Engineering: Class Review 12
Scoping & ConOps The first step in understanding the mission at hand is defining the scope, where scope is a definition of what is germane to your project. The scope content involves Defining the needs, goals, and objectives Identifying stakeholders Developing operational concepts Understanding constraints A thorough scoping effort leads to organized and informed mission and system requirements. A concept of operations (conops) is a description (often pictorial) of how the system will be operated during the mission phases in order to meet stakeholder requirements. A concept of operations can include many aspects of operations, such as a timeline, a communications strategy, varying operational scenarios, etc. Exploration Systems Engineering: Class Review 13
Exploration Systems Engineering: Class Review 14
System Architecture Creating a system architecture is a systems engineering function that is the first step in translating a defined problem into a solution. Creating an architecture is a recursive, iterative process that begins with the problem statement, creates some candidate solutions, assesses their merits and chooses one. Architecture creation is not a deterministic process, but understanding the strengths, weaknesses and adaptability of heritage or analogous systems is a valuable first step. In working with the stakeholders, the function or performance requirements of the system may be modified to create a better match between the problem statement and the candidate solution. Like many systems engineering functions, architecting is one of balancing competing factors and choosing a preferred solution with uncertain and sometimes ambiguous information. No one view captures an architecture. Many views are used to capture the system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors. Exploration Systems Engineering: Class Review 15
Functional Analysis Functional analysis is a system development tool used to capture required system functions. Functional analysis also supports functional decomposition - the process of describing the sub-functions that are necessary for each function. Functional Flow Block Diagrams (FFBDs) are graphical tools used to capture the functional sequence and functional hierarchy of a system. Time-Line Analysis (TLA) is a tool used to capture the duration, and sequence of system functions. TLA can be used in conjunction with FFBDs. Functional analysis is implementation independent. In other words, all functions are describes in terms of what must be done (and sometimes how well) not how it will be done. This independence ensures that when subsequent trade studies choose how functions will be performed they will be unbiased. Exploration Systems Engineering: Class Review 16
Planetary Defense Level 1 Functional Flow Block Diagram For Threat Detection Ref. 3. Reevaluate Threat (b) 1. Detect Threat 1.4 Determine Composi-on 1.5 Determine Size 1.1 Coordinate Assets 1.2 Monitor Sky 1.3 Confirm Sigh-ng(s) and 1.6 Determine Velocity and 1.8 Run Simula-on(s) 1.9 Establish Level of Threat 1.7 Determine Orbital Elements 1.10 Decide on Ac-on or Ref. 3. Reevaluate Threat (a) Ref. 2. Eliminate Threat Exploration Systems Engineering: Class Review 17
Time Line Analysis Example for Sub-Function of Launch Readiness Example shows the time required to perform function 3.1. Its sub-functions are presented on a bar chart showing how the timelines relate. Note: function numbers match the FFBD. Exploration Systems Engineering: Class Review 18
System Design (1/2) System design produces a physical architecture from the functional architecture. System design is an iterative process in that many subsystem solutions are considered, and the subsequent system merits are assessed before a baseline is established. To assess the merits of candidate subsystems, consider their performance, risks, heritage, technical maturity, and limits of their performance. One way to seek optimal system design is to choose performance and resource allocations to equally stress all subsystems. Share the pain among subsystems. System requirements define a successful solution. Know when to stop trying to improve a design - better is the enemy of good enough. Exploration Systems Engineering: Class Review 19
System Design (2/2) Maintain a decision database and formally review it at each project milestone review. Use performance-resource (utility) curves to identify break points to help develop balanced solutions. Determine the driving requirements. Understand which requirements are the toughest to meet and consider reallocation to manage them. Subsystems with high cohesion, low complexity and low connectivity are good. In other words, keep interfaces simple and similar functions together. In system design decisions, consider robustness a measure of a system s sensitivity to environmental or resource variation. Exploration Systems Engineering: Class Review 20
An Approach to System Design - the steps 1. Begin with the functional architecture, its performance requirements and constraints (from functional analysis). 2. Allocate (or derive) subsystem performance and resource requirements. 3. Define physical subsystem alternatives. 4. Assess technology alternatives and their maturity (heritage etc.) 5. Define physical interfaces. 6. Estimate subsystem and system performance of each combination of alternatives. 7. Use performance-resource curves (utility curves) to identify break points. 8. Determine the driving requirements and consider reallocation. 9. Select a preferred system design. i.e., the physical architecture with subsystem implementation plans and functional and performance allocations and system performance estimates. Exploration Systems Engineering: Class Review 21
Trade Studies Trade studies are common decision-support tools that are used throughout the project lifecycle to capture and help assess alternatives. The steps in the trade study process are: 1. Define the objectives of the trade study 2. Review inputs, including the constraints and assumptions 3. Choose the evaluation criteria and their relative importance 4. Identify and select the alternatives 5. Assess the performance of each option for each criteria 6. Compare the results and choose an option 7. Document the trade study process and its results Trade trees are graphical tools that help manage multivariable options. Exploration Systems Engineering: Class Review 22
Mission Type Cargo Deployment Œ 1988 Mars Expedition 1989 Mars Evolution Ž 1990 90-Day Study 1991 Synthesis Group 1995 DRM 1 1997 DRM 3 1998 DRM 4 1999 Dual Landers 1989 Zubrin, et.al* 1994-99 Borowski, et.al 2000 SERT (SSP) 2002 NEP Art. Gravity 2001 DPT/NEXT M1 2005 MSFC MEPT M2 2005 MSFC NTP MSA Top-level Trade Tree-Example for Mars Conjunction Class Long Surface Stay Human Exploration Of Mars Decision Package 1 Long vs Short Opposition Class Short Surface Stay Pre-Deploy All-up Pre-Deploy All-up Special Case 1-year Round-trip ƒ Mars Capture Method Aerocapture Propulsive Aerocapture Propulsive Aerocapture Propulsive Aerocapture Propulsive Mars Ascent Propellant ISRU No ISRU ISRU No ISRU ISRU No ISRU ISRU No ISRU ISRU No ISRU ISRU No ISRU ISRU No ISRU ISRU No ISRU Interplanetary Propulsion (no hybrids in Phase 1) NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric M2 M2 M2 M1 M1 M1 M2 M2 NTR- Nuclear Thermal Rocket Exploration Systems Engineering: Class Review Electric= Solar or Nuclear Electric Propulsion 23 Chemical 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Ž Œ NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical NTR Electric Chemical
Technology Readiness The Technology Readiness Level (TRL) scale is used to assign maturity levels to technology considered for space flight. Low TRLs, or low technology maturity, correlate with development risk. Early development of enabling, low maturity technologies can reduce the development risk of a system. JWST attempted to reduce the system development risk by developing some low maturity technologies before PDR, like the primary mirror segments. Exploration Systems Engineering: Class Review 24
Technology Readiness Levels System Test, Launch & Operations System/Subsystem Development Technology Demonstration Technology Development Research to Prove Feasibility Basic Technology Research Actual system flight proven through successful mission operations Actual system completed and flight qualified through test and demonstration (Ground or Flight) System prototype demonstration in a space environment System/subsystem model or prototype demonstration in a relevant environment (Ground or Space) Component and/or breadboard validation in relevant environment Component and/or breadboard validation in laboratory environment Analytical and experimental critical function and/or characteristic proof-of-concept Technology concept and/or application formulated Basic principles observed and reported Defining TRL = Figure determining 5. Technology Readiness what was Levels demonstrated and under what conditions. Exploration Systems Engineering: Class Review 25
System Hierarchy A product breakdown structure (PBS) captures the hierarchy of the system and is one representation of the system architecture. Creating a system hierarchy is valuable since it breaks a complex problem into smaller pieces that will be easier to tackle. But this reductionism, or decomposition has a price: New interfaces are created between the pieces (subsystems), so they must be defined and managed. System resources (e.g., mass or power) must allocated to the subsystems and these allocations must be accounted for; and System performance is also allocated to subsystems, so confidence must be established that if all of the subsystems perform as desired that the system will perform as desired. The work breakdown structure (WBS) extends the PBS in that it captures all of the work necessary for a project by adding the non-product work necessary for a successful project (e.g., integration, test, logistics support, systems engineering and management). Exploration Systems Engineering: Class Review 26
Example: NASA s SOFIA Project PBS and WBS PBS Sofia Project Observatory System Ground Support System Airborne Facility Science Instruments Labs/Offices Facility GSE Mission Planning Simulator Aircraft Element Telescope Element Telescope Subsystem Electronics Subsystem WBS Sofia Project Management Systems Engineering Project Integration & Test Operations and Logistics Planning Science Support Mission Assurance Observatory System Ground Support System Exploration Systems Engineering: Class Review 27
Management A Project Manager s roles and responsibilities are different from those of the Project Systems Engineer. The manager is continuously balancing the three project variables of cost, schedule and technical content. The Project Plan documents the project baseline for implementation. It includes the work breakdown structure, the associated activities, the resources required to accomplish the work, and the planned schedule for completing the work. The Systems Engineering Management Plan (SEMP) is the project s guiding technical document. All subordinate technical documents, like a requirements document or test plan, must follow the guidelines of the project SEMP. Companies and government agencies usually use two different approaches to managing their workforce. In-line management means the responsible workforce directly reports to the project manager. Matrix management means the majority of the workforce is assigned temporarily to a project for a fixed period of time for a specified task. Exploration Systems Engineering: Class Review 28
Analytical Hierarchy Process Many decisions are made early in the project life cycle. The decision maker must always choose based on some implicit or explicit evaluation criteria. The basic steps in the decision making process include: 1. Establish evaluation criteria 2. Establish relative importance of evaluation criteria 3. Develop alternative concepts that meet objectives and top-level requirements 4. Evaluate alternatives relative to the established evaluation criteria 5. The alternative that best satisfies the evaluation criteria represents the tentative concept choice. Figures of Merit (FOM) is a metric by which a stakeholder s expectations will be judged in assessing satisfaction with a product or system. The Analytical Hierarchy Process (AHP) is a methodology that determines best through a series of pair-wise comparisons. It can be used to determine attribute weightings as well as alternative scores. One of the benefits of AHP is the use of a standardized process by which to compare alternatives. It can be used with both quantitative and qualitative data. Exploration Systems Engineering: Class Review 29
Interfaces and N 2 Diagrams System external interfaces are defined, distributed and managed like other system requirements. Internal interfaces, since they are created as the system is decomposed, can be optimized by the development team. In developing interfaces group like functions, keep them simple and consider the use of standard interfaces. Since all interfaces run the risk of being ignored as development teams focus on their subsystem responsibilities, explicitly identify the owners of all interfaces. N-squared diagrams the most common interface identification and management tool. They are are used to: Capture the existence and nature of an interface Highlight input and output assumptions and requirements Demonstrate where there are feedback loops between subsystems Identify candidate functional allocations to subsystems Exploration Systems Engineering: Class Review 30
Generic N-squared Diagram as an Interface Artifact N 2 diagram rules: Items or functions are on the diagonal Items or functions have input and outputs Item or function outputs are contained in rows; inputs are contained in columns External Input (to Item or Function 2) Item or Function 1 I 1 I 1 I 1 O 2 O 3 O 4 O 1 I 2 Item or Function 2 I 2 I 2 O 3 O 4 O 1 I 3 O 2 I 3 Item or Function 3 I 3 O 4 O 1 I 4 O 2 I 4 O 3 I 4 Item or Function 4 External Output (from Item or Function 3 I = Input O = Output Exploration Systems Engineering: Class Review 31
Use of Block Diagrams Region 1 Region 2 Region 3 Radiator Heat Switches Contn Ctrl Htrs Cryo Tem p Sensors NIRSpec FGS NIRCam MIRI IRSU NIRSpec FPE /ICE / MCE FGS Guiders FPE Cooling Lines /ICE FGS TF FPE /ICE / TCE NIRCam FPEs /ICE MIRI FPE /ICE ISIM ISIM Command & Data Handling (x2) CCE -PC (x2) CCE -JT (x2) Compressor Assembly Solid State Recoder Command Telemetry Processor Orientation Drive Electronics with Resolver (x2) Coarse Sun Sensors (x4) C&DH S-Band Transponder (x2) Ka-Band Modulator ( x2) Power Control Unit Switches Ka-Band TWTA (x 2) Solar Array Regulators (x2) Telemetry Acquisition Unit M otor Switching Relay EPS Omni HGA Solar Array (3 panels ) (x2) 40 Ah NiH 2 Battery Analog / Bilevel COMM FSM Act Tertiary Mirror Secondary Mirror MIRI FPE Primary Mirror SMSS Deploy Act Hexapod (6 DOF) Hexapod (7 DOF ) x18 DIT CE ( x2) OTE Cold Junction Box Wing Deployment Acts (x 2) & Latch Acts (x8) Actuator Drive Unit Region 3 Tower Actuators Fine Sun Sensors (x2) Sunshield Sunshield Act (x6) Solar Array Act (x2) Inertial Reference Unit (1) Wheel Drive Electronics (x6) High Gain Antenna Act (x2) Star Trackers ( x3) ACS Valve Drive Electronics (x 2) Reaction Wheels (x 6) Propulsion ( Bi-Prop ) MRE -4 STMs (x 8) Secondary Combustion Augmented Thrusters (x 4) Legends : photons S/C -ISIM 1553 B-SI Spacewire RS422 Discrete -pt to pt LVDS Primary Power S/ C 1553 B-S ISIM 1553 B-I Mechanical I /F Region 1-(within Si /OA ) Region 2-(within IEC ) Region 3-(within spacecraft bus) Exploration Systems Engineering: Class Review 32
Margins and Contingency Contingency is the difference between the current best estimate of a resource and its maximum expected value. A margin is the difference between the maximum possible value of a resource and its maximum expected value, but in some sense is unknowable. Estimated resource use for a system in development grows as the design matures. Contingency is used to account for this growth, so the project can predict maximum expected values for each resource. The amount of recommended contingency for a resource is based on historically demonstrated trends and decreases as the design matures. Exploration Systems Engineering: Class Review 33
Technical Performance Measures TPMs are measures of the system technical performance that were chosen because they are indicators of system success. The trends of past, successful projects are used to create contingency guidelines for new projects. Tracking TPMs and comparing them against typical resource growth provides an early warning system designed to detect deficiencies or excesses. TPMs that violate their contingency allocations or have trends that do not meet the final performance should trigger action by the systems engineer. The final, delivered system value can be estimated by extending the TPM trend line and using the recommended contingency values for each project phase. There is a balance between contingency for risk management and allocation for design flexibility. This balance is apparent since contingency allocations shrink as designs mature. Exploration Systems Engineering: Class Review 34
Cost Estimating Methods for estimating mission costs include parametric cost models, analogy, and grassroots (or bottoms-up). Certain methods are appropriate based on where the project is in its life cycle. Parametric cost models rely on databases of historical mission and spacecraft data. Model inputs, such as mass, are used to construct cost estimating relationships (CERs). Complexity factors are used as an adjustment to a CER to compensate for a project s unique features, not accounted for in the CER historical data. Learning curve is based on the concept that resources required to produce each additional unit decline as the total number of units produced increases. Uncertainty in parametric cost models can be estimated using probability distributions that are summed via Monte Carlo simulation. The S curve is the cumulative probability distribution coming out of the statistical summing process. Cost phasing (or spreading) takes the point-estimate derived from a parametric cost model and spreads it over the project s schedule, resulting in the project s annual phasing requirements. Most cost phasing tools use a beta curve. Exploration Systems Engineering: Class Review 35
Risk Risk is inevitable, so risks can be reduced but not eliminated. Risk management is a proactive systematic approach to assessing risks, generating alternatives and reducing cumulative project risk. Fault Tree Analysis is both a design and a diagnostic tool that estimates failure probabilities of initiators to estimate the failure of the pre-determined, undesirable, top event. Failure Mode Effects Analysis is a design tool for identifying risk in the system design, with the intent of mitigating those risks with design changes. Exploration Systems Engineering: Class Review 36
A 5x5 Risk Matrix Provides a Quick Visual Comparison of All Project Risks High risks mission success jeopardized - immediate action required Medium risk review regularly contingent action if does not improve Low risk watch and review periodically Exploration Systems Engineering: Class Review 37
Fault Tree Analysis Fault tree analysis is a graphical representation of the combination of faults that will result in the occurrence of some (undesired) top event. In the construction of a fault tree, successive subordinate failure events are identified and logically linked to the top event. The linked events form a tree structure connected by symbols called gates. Exploration Systems Engineering: Class Review 38
Reliability Reliability is a key attribute of space systems, influencing systems engineering activities such as design, trade studies, modeling, and test. The reliability function, R(t), is determined from the probability that a system will be successful for at least some specified time. The Bathtub curve expresses the failure rate as it depends on the age of the system. Early and late in life of the system (similar to the human body) significantly higher failure rates occur called infant mortality and old age regions. Between these regions normally lies an extended period of approximately constant failure rate. The reliability of systems operating in this region can be simply characterized by an exponential function. Ways to achieve reliability include fault tolerance, functional redundancy and fault avoidance. Block diagrams and event trees are useful tools in calculating reliability. An understanding of probability basics is required. Exploration Systems Engineering: Class Review
General Observations Requirements, Requirements, Requirements! Get them right early Don t change them Oversight and Management of Contractors Human Factors: Overwork The ability to say no Hopeless optimism The impact of outside politics Understand Interfaces, early and often Never assume anything about heritage Never underestimate vendors greed Mistakes will happen be prepared to fess up it will ensure mission success Exploration Systems Engineering: Class Review 40