These are just some notes I jotted down while taking an online course, primarily to help me remember the key ideas and valuable takeaways. They’re not meant to cover everything or act as a full summary. If you find them interesting or helpful, maybe they’ll nudge you to check out the course too.
The Fundamentals of Systems Engineering course is offered through MIT’s OpenCourseWare, a free and publicly accessible platform that shares material from thousands of MIT courses, covering the entire MIT curriculum. You can take the course for free and start learning at your own pace. The course is designed to introduce learners to the core principles and practices of systems engineering and provides comprehensive access to lecture notes, reading material, lecture videos and assignments.
Systems Engineering (SE) is the discipline behind designing, building, and managing the world’s most complex systems—from aerospace missions to critical infrastructure. These notes summarise key learnings from the course, highlighting essential concepts covered in the course.
A few notes
- Note 1: Foundations of Systems Engineering – Systems Engineering is a structured, interdisciplinary approach for managing complex systems across their lifecycle, evolving from Bell Labs and NASA projects. The V-Model visualises the process from stakeholder needs to system validation, anchored by major design reviews (SRR, PDR, CDR). Modern SE has adopted Model-Based Systems Engineering (MBSE) to address growing complexity and evolving requirements. Stakeholder analysis and value-based modelling, like the Stakeholder Value Network (SVN), are foundational to effective SE. Standards like ISO/IEC 15288 – Systems and software engineering: System life cycle processes and the INCOSE (International Council of Systems Engineering) define best practices for SE.
The V-Model
- Note 2: Requirements Engineering – Requirements define what a system must do, spanning function, performance, and constraints, and must be verifiable and unambiguous. Requirements are structured hierarchically and refined via System Requirements Review (SRR), with tools like Isoperformance helping determine feasible sub-system allocations. Requirements Margins are used to manage uncertainty early in design. Tools like DOORS (Dynamic Object Oriented Requirements System) help manage thousands of interconnected requirements, especially in large projects. Poor requirements can result in rework, cost overruns, and system failure.
- Note 3: System Modelling – System Modelling Languages like Object Process Methodology (OPM), System Modelling Language (SysML), and Modelica formalise system design and behaviour using structure, semantics, and syntax. MBSE shifts the engineering focus from document-based to model-centric workflows, enabling simulation and consistency across lifecycle phases. OPM is ideal for managing object-process interactions, while SysML supports cyber-physical system modelling. Modelica allows declarative, multi-domain simulation using physical equations and acausal relationships. These tools help manage complexity and improve design reliability.
- Note 4: System Architecture and Concept Generation – System Architecture connects system functions to form through decomposition and interface definition. Early phases address ambiguity and concept creativity, evolving into complexity management. Techniques like brainstorming, morphological matrices, and logical decomposition guide concept generation. Concepts embody working principles and influence all future design choices. Good architecture aligns stakeholder needs with physical design to deliver measurable value.
- Note 5: Concept Selection and Tradespace Exploration – Concept selection relies on structured decision-making using methods like the Pugh Matrix and Utility Analysis. Tradespace exploration identifies Pareto-optimal solutions by analysing trade-offs among competing design criteria. Non-dominated solutions reveal the best-balanced design configurations. Decision makers must consider uncertainty, value judgments, and preferences when ranking options. The Preliminary Design Review (PDR) validates the architecture and justifies design decisions based on evidence.
- Note 6: Design Definition – The Design Definition process transforms conceptual architecture into fully specified, manufacturable designs. Multidisciplinary Design Optimisation (MDO) integrates design inputs from various disciplines using methods like BLISS – Basic Language for Implementation of System Software. BLISS separates shared and local variables and couples subsystems via optimisation cycles. Concurrent Design Facilities (CDFs) accelerate iteration by bringing specialists together in real-time. The Critical Design Review (CDR) is the final gate before production begins.
- Note 7: The V-Model and SE Mindset – Systems Engineering combines technical methods with a holistic mindset, guiding system creation from concept to operations. The V-Model aligns system development with review milestones and maps design to testing phases. Verification checks that specifications are met; Validation ensures the system meets stakeholder expectations. SE supports continuous stakeholder engagement and adaptation through feedback loops. Quantitative analysis and modelling support feasibility assessments and system behaviour prediction.
- Note 8: Interface Management – Interfaces are common failure points and must be explicitly defined and verified throughout development. Interfaces fall into four types: physical, energy, mass, and information, each requiring specific attention. Tools like the Design Structure Matrix (DSM) and Interface Control Documents (ICDs) map and manage these interactions. Integration sequencing affects assembly time, uncertainty, and risk. NASA emphasises robust interface documentation and phased integration to minimise failure.
- Note 9: Verification and Validation – Verification ensures that the system is built to spec, while Validation checks that it performs as intended in the field. SE incorporates extensive testing (e.g., “shake and bake” for spacecraft) and Technical Risk Management using tools like Risk Matrices and the Iron Triangle.
- Note 10: Safety Systems – System safety is increasingly addressed through Systems-Theoretic Accident Model and Processes (STAMP) / System-Theoretic Process Analysis (STPA), which considers interactions, controls, and emergent behaviours—not just failures. STAMP/STPA frameworks focus on interactions and systemic control failures rather than single-point faults. Technical Risk Management involves early identification, probability-impact assessment, and mitigation planning. Lifecycle reviews like Flight Readiness Review (FRR) and Post-Launch Assessment Review (PLAR) finalise readiness and extract lessons post-deployment.
- Note 11: Commissioning and Sustainment – Commissioning includes final system setup, operational training, and validation of expected behaviour. Sustainment requires reconfiguration, spare parts, preventative maintenance, and contingency planning. Designing for robustness in degraded states and smart spare management enhances long-term system availability. Reconfigurability can significantly reduce the logistics burden and improve operational flexibility.
- Note 12: Lifecycle Management – Lifecycle Management spans from concept to decommissioning, with phases for design, operation, upgrade, and retirement. System properties known as “ilities” (e.g., flexibility, robustness, modularity) influence long-term adaptability and performance. These characteristics emerge after initial use and must be planned from the start. Staged Deployment is an adaptive strategy to manage demand uncertainty and optimise investment timing. Failure to incorporate “ilities” can result in costly rework and limited system value.
- Note 13: List of ilities – The properties termed as “ilities” are often used to evaluate long-term value, sustainability, and resilience of systems, and many are interdependent or serve as enablers for others (e.g., modularity enabling adaptability and maintainability).
- Adaptability – Ability of a system to be changed by an internal change agent with intent.
- Agility – Ability to change in a timely fashion.
- Changeability – Ability to alter operations or form at acceptable resource levels.
- Evolvability – Ability of the system to be modified across generations.
- Extensibility – Ability to accommodate new features after the design phase.
- Flexibility – Ability to be changed by an external change agent with intent.
- Interoperability – Ability to effectively interact with other systems.
- Modifiability – Ability to change specified parameters.
- Modularity – Degree to which a system is composed of independent modules.
- Reconfigurability – Ability to reversibly change component arrangement and links.
- Robustness – Ability to maintain function under internal or external changes.
- Survivability – Ability to continue operating despite major failures or disruptions.
- Resilience – Ability to absorb disturbance and still deliver value.
- Maintainability – Ease with which a system can be repaired or updated.
- Supportability – Ability to provide the necessary support across the lifecycle.
- Scalability – Capacity to expand or contract based on demand.
- Note 14: Evolving SE and Stakeholder Value – Modern SE addresses increasing complexity through stakeholder-centric and model-based practices. Stakeholder Value Networks (SVNs) map direct and indirect influence using metrics like Weighted Stakeholder Objective (WSO) and Weighted Value Fulfilment Objective (WVFO). Traditional waterfall assumptions fail under dynamic requirements and legacy constraints. Tools like MBSE and layered abstraction aim to accelerate SE (e.g., DARPA META). The future of SE lies in designing systems with elegant, resilient architectures and measurable value delivery.
- Note 15: Glossary of Terms
