What Is Systems Engineering? Definition, Process and Roles

Full announcement (unchanged)

Systems engineering is the engineering discipline that plans, designs and verifies a complex product as one whole system, so that its hardware, software and other parts work together and meet its users’ needs from concept to retirement. Systems engineers define what the whole system must do, divide that into requirements for each part and each team, and verify that the integrated parts meet those requirements. When one team’s choice constrains another team’s work, systems engineering is how the teams coordinate that decision. On a program with separate hardware, software and test groups, teams often find a mismatch between two subsystems at integration, months after the decision that caused it, when fixing it means reopening design and test work that depended on that decision. What Does Systems Engineering Cover? Systems engineering covers a system’s whole life cycle and the work of every engineering discipline that contributes to it. It is a transdisciplinary and integrative approach to realizing, using and retiring engineered systems with systems principles and with scientific, technological and management methods. In practice, that means developing an operable system that meets its requirements within constraints that often pull against each other. Responsibilities Through Production and Operation Systems engineers stay with a project from the initial idea through development, operation and retirement. During operation, they address upgrades, obsolescence management, maintenance and repair, manufacturing changes and user training. Running production itself is not part of the discipline. Manufacturing engineers run production, while systems engineers assess how production changes affect the system. Coordination and Management Across Disciplines Systems engineering integrates the other engineering disciplines and doesn’t replace them. Systems engineers weigh the contributions of structural, electrical, mechanism, power and human factors engineers against one another, so the result is a coherent whole that no single discipline’s perspective dominates. How much management comes with the role varies by project. On some projects, systems engineering includes strong governance, technical management and resource management, and on others it is an almost entirely technical, advisory and coordinating role where management structures already exist. What Does a Systems Engineer Do Day to Day? A systems engineer spends much of the working day documenting decisions as requirements and checking that the teams downstream can build and verify them. On NASA programs, the role has six responsibilities: • Concept of operations and architecture: The systems engineer usually leads the development of the concept of operations (ConOps) and the system architecture that results from it. A team that captures that architecture in a Systems Modeling Language (SysML) model is practicing model-based systems engineering (MBSE). • Requirements definition and allocation: Systems engineers turn the expectations of customers and users into a complete set of validated technical requirements written as “shall” statements. The systems engineer then allocates those requirements to subsystems and the teams that own them. • Trade studies: Trade studies are performed before decisions are made, so the chosen design can be baselined with confidence. Systems engineers archive the supporting studies for later reference. • Interface management: The systems engineer defines and assesses interfaces, usually through interface control documents (ICDs), and confirms that each ICD has been validated with the parties on both sides of the interface. • Technical reviews: System requirements reviews (SRRs), preliminary design reviews (PDRs) and critical design reviews (CDRs) have entrance criteria that should not be waived. • Verification and validation oversight: The systems engineer oversees verification and validation, which check whether the built system meets its requirements and whether it meets users’ needs in operation. The systems engineer tracks verification in a matrix that lists each “shall” requirement, the document it comes from and how each one is verified. The balance between those tasks shifts as a program matures. Concept work, requirements and trade studies take most of the time early on. Systems engineers spend more time on integration issues, verification closure and change requests later. What Are the Stages of the Systems Engineering Process? ISO/IEC/IEEE 15288:2023 covers the whole system life cycle, including the “conception, development, production, utilization, support and retirement of systems.” The generic life cycle model in the Systems Engineering Body of Knowledge (SEBoK) has six stages, each with its own activities. | Stage | What happens | | Concept | Identify user needs, explore concepts and propose viable designs | | Development | Refine system requirements, create the system description, build the system, and verify and validate it | | Production | Produce the system, then inspect and test it | | Utilization | Operate the system to deliver its intended capability | | Support | Sustain that capability through maintenance and logistics | | Retirement | Store, archive or dispose of the system | Each stage ends at a decision gate where decision makers choose to proceed, remain in the current stage, or terminate or re-scope the work. Once you identify your program’s current stage, you can check what decision makers at the next gate will require. NASA runs its own version, with phases from Pre-Phase A concept studies through Phase F closeout and Key Decision Points (KDPs) marking each transition. Under ISO/IEC/IEEE 15288, teams choose their own life cycle model and can apply its processes iteratively and concurrently to a system and recursively to its elements. With that flexibility, one team can follow a V-model while another manages incremental releases against the same six stages. For the activities inside development, use our guide to the systems engineering process for complex programs. Which Standards and Handbooks Define Systems Engineering? ISO/IEC/IEEE 15288:2023 is the process standard that the International Council on Systems Engineering (INCOSE) handbook and the ISO/IEC/IEEE companion standards build on. It defines four sets of life cycle processes, named agreement processes, organizational project-enabling processes, technical management processes and technical processes. Systems engineers spend most of their time in the last two groups. The technical management processes are project planning, project assessment and control, decision management, risk management, configuration management, information management, measurement and quality assurance. Engineers begin the technical processes with business or mission analysis and the definition of needs and system requirements. The technical processes then run through architecture and design, system analysis, implementation, integration, verification, transition, validation, operation, maintenance and disposal. Alongside 15288, systems engineers use companion documents for requirements engineering, management planning and practice guidance. | Document | Edition and date | What it gives a systems engineer | | ISO/IEC/IEEE 15288:2023 | Edition 2, May 2023 | The process framework and vocabulary for the full system life cycle | | ISO/IEC/IEEE 29148:2018 | Edition 2, November 2018, with a draft revision under development | Processes and required information items for requirements engineering | | ISO/IEC/IEEE 24748-4:2026 | Edition 2, February 2026 | Requirements and guidance for the content of a systems engineering management plan (SEMP) | | INCOSE Systems Engineering Handbook | Fifth edition, July 2023 | Practice guidance that elaborates the 15288:2023 processes | | NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2 | Publication record dated February 17, 2017 | NASA’s practice companion to its NASA Procedural Requirements (NPR) 7123.1 | | SEBoK | Version 2.14, May 2026 | A guide to the systems engineering literature, stewarded by INCOSE, the IEEE Systems Council and Stevens Institute of Technology | | INCOSE Systems Engineering Vision 2035 | 2021 | The strategic direction INCOSE sets for the discipline | You’ll use 15288 for the process names that contracts and audits refer to, and the INCOSE handbook for how to perform those processes. When a contract cites 29148 for requirements engineering, confirm the edition, because ISO is developing a revision to replace the 2018 edition. Read the Handbook Overview How Do Requirements Hold a Systems Engineering Program Together? Engineers use requirements to communicate agreed decisions between disciplines. A systems engineer communicates architecture and trade decisions to hardware, software and test teams through allocated and derived requirements. The program then shows that each requirement is met by tracing it to the design that satisfies it and the test that verifies it. What Allocated and Derived Requirements Are An allocated requirement is a higher-level requirement assigned to a subsystem, function or configuration item. The approved set of allocated requirements is the allocated baseline, which documents the functional, performance and interface characteristics allocated from a higher-level requirements document. A derived requirement is one the team adds because of an architecture choice, a design decision or a constraint the parent implies without stating. Systems engineers repeat that allocation and derivation at every level. Once baselined, the derived and allocated requirements become the high-level requirements for the decomposed elements, and the process begins again. What Bidirectional Traceability Has to Connect Bidirectional traceability is the ability to trace any requirement to its parent requirement and to the child requirements allocated from it. Engineers also link requirements to verification, so each requirement’s record holds a trace to its parent and its system verification method. You can identify different problems by tracing upward and downward. When a requirement has no parent and isn’t an acceptable self-derived requirement, either the traceability process is flawed and should be redone, or the requirement is gold plating and should be eliminated. For link types and matrices, use our requirements traceability chapter. What Breaks When Traceability Is Maintained by Hand When you store requirements in documents and links in a spreadsheet, someone has to update the trace after each change. Without those updates, you have to assess change impact from memory. Managing requirements changes well takes a process that assesses the impact of each proposed change before anyone approves or implements it. Poor requirement traceability can compromise technical products and disrupt milestone reviews such as the SRR and the System Design Review (SDR). For interface changes, integration with the launch vehicle is too late in the development cycle to discover that a spacecraft has an issue with its umbilical interface. Engineers can also miss change impacts when reusing software, as the first flight of Ariane 5 shows. Ariane 5 reused inertial reference software from Ariane 4, including an alignment function whose timing was based on an Ariane 4 requirement and wasn’t required for Ariane 5. After lift-off the function stayed active, and the maiden flight ended in failure on 4 June 1996. The European Space Agency (ESA) Inquiry Board found that the alignment function “was not taken into account in the simulations and that the equipment and system tests were not sufficiently representative.” To check whether a reused function has a reason to run in the new system, engineers can trace it to a parent requirement. What a Requirements Record Has to Hold Each requirement needs enough metadata for someone other than its author to check its source and verification evidence. Four fields make that check possible: • Owner: The owner is the person or group responsible for writing, managing or approving changes to the requirement. Without one, a change request has nobody to approve it. • Version and baseline: Each requirement has a version number for maintenance and belongs to a baseline, an agreed set of requirements, designs or documents whose changes are controlled through formal approval and monitoring. • Links: You record links to a parent, to any interface definition and to the design and tests below it. A “Traced from” field records the relationship between a derived requirement and its parent. • Verification method and status: The method is test, inspection, analysis or demonstration, and the status lets engineers identify open items before a review. The four fields are useful only when they stay current together, and keeping requirements, design and tests linked in one place reduces the manual reconciliation work systems engineers do. Dexcom, which focused on improving traceability and cross-functional collaboration, achieved a 60% productivity boost for their systems engineering team. On regulated programs, auditors also use the same record to trace a requirement back to its source and forward to its verification evidence. How Is Systems Engineering Applied in Regulated Industries? Regulated industries run the same process and add a demand for evidence that every requirement was allocated, implemented and verified. Systems engineers in aerospace and defense, medical device and automotive programs use industry-specific standards to organize that evidence. Aerospace and Defense ARP4754B gives recommended practices for developing civil aircraft and systems, and its current revision dates from 19 December 2023. Its practices include validation of requirements and verification of the design implementation. Under ARP4754B, software development is addressed through DO-178C and airborne electronic hardware through DO-254. RTCA published DO-178C in 2011. The Federal Aviation Administration (FAA) references it in Advisory Circular (AC) 20-115D. DO-178C and DO-254 are civil airworthiness documents that some defense programs also adopt by contract. Because a system-level change can affect both software and hardware, it has to be traced into the software and hardware analyses it affects. Medical Devices FDA’s Quality Management System Regulation (QMSR) has been in effect since 2 February 2026. The QMSR incorporates ISO 13485:2016 by reference. Manufacturers of class II, class III and certain class I devices must meet the design and development requirements in Clause 7.3 of ISO 13485 (21 CFR 820.10(c)). The former design section, 21 CFR 820.30, is now marked Reserved. Manufacturers address the elements formerly called “Design Controls” and “Design History File (DHF)” through those same design and development requirements. Manufacturers must address planning, inputs, outputs, review, verification, validation, transfer and changes (Clause 7.3). Design inputs must be complete, unambiguous, able to be verified or validated, and not in conflict with each other. During planning, manufacturers record roles and responsibilities, traceability methods and the resources needed. Manufacturers also evaluate each design change for its impact on constituent parts and the product. For the move from the old regulation, read our overview of FDA and ISO 13485 harmonization. Automotive ISO 26262:2018 sets the functional safety requirements for road vehicles, and a draft third edition is under development. Engineers perform product development at the system level, including technical safety requirements, the technical safety concept, system architectural design, item integration and testing, and safety validation (Part 4). System-level work builds on the item definition and the Hazard Analysis and Risk Assessment (HARA) that the concept phase produces. Automotive SPICE (ASPICE) assesses the process around that work. The Quality Management Center of the German Association of the Automotive Industry (VDA QMC) released version 4.1 in August 2026, with five system engineering processes named SYS.1 Requirements Elicitation, SYS.2 System Requirements Analysis, SYS.3 System Architectural Design, SYS.4 System Integration and Integration Verification, and SYS.5 System Verification. Assessors look for consistency and bidirectional traceability between the elements of the system architecture and the system requirements (SYS.3).