Search
Full Menu and site Navigation
A better world through a systems approach

Typical features of Systems Engineering

Systems Engineering considers and balances the business, technical, personal and societal needs of the system’s stakeholders, including customers, beneficiaries, users, owners, and relevant third parties, with the goal of providing a quality solution that is fit for its intended purpose in real-world operation. The scope is the total or “whole system” solution, not just the engineered artifacts that may be key elements of the solution. Business needs deal with the factors that justify expenditure of time and resources on the activities that occur during the various stages of a system.

Systems Engineering (SE) focuses on ten key activities:

  1. establishing stakeholders’ success criteria and concerns, and defining actual or anticipated customer needs and required functionality, early in the development cycle, and revising them as new information is gained and lessons are learned;
  2. investigating the solution space, proposing alternative solution and operational concepts, weighing their value (viability, utility, benefit at cost) and selecting the optimal or most appropriate concept(s);
  3. architecting a solution or set of solutions based on the selected concept(s) while considering potential concepts of employment and usage;
  4. modelling (or otherwise evaluating) the solution at each relevant phase of the endeavour, considering both normal and exceptional scenarios, and an appropriate diversity of viewpoints, in order to:
    a. establish required capability and performance; 
    b. increase confidence that the solution will work as expected and required, while avoiding or minimizing undesirable unintended consequences; 
    c. ensure the solution is resilient and can evolve if required to adapt to anticipated or possible changes in the user needs and operational environments; 
    d. provide ongoing prediction and assessment of system effectiveness and value;
  5. defining and managing the interfaces, both within the system and between the system and the rest of the world (noting that increasingly, systems engineering is conducted in a brown-field rather than a green-field environment, so legacy systems may be a major or key part of the overall solution);
  6. establishing appropriate process and lifecycle models that consider complexity, uncertainty, change and variety, and implementing system management and governance processes for both development and through-life use and disposal;
  7. proceeding with detailed design synthesis, integration, and solution verification and validation (ensuring the solution is fit for the intended purpose) while considering the complete problem (including aspects of dependability such as safety, security, reliability, availability, logistic support, and disaster recovery), all necessary enabling systems and services, and end-of-life processes (e.g. transition to a replacement system, recycling of the retired one, nuclear decommissioning and waste disposal…);
  8. providing the SE knowledge and information required by all stakeholder groups to ensure coherence of the whole endeavour – typically including a vision statement, operational concepts, business drivers, analyses and recommendations for decision support and the business case, architecture definition, organizational policies and processes, required properties and interfaces of the system and its elements (including common standards to ensure interoperability), verification and validation criteria, analysis and interpretation of test and evaluation results, anticipated operational usage, and appropriate system configurations for different scenarios;
  9. supporting transition to use, considering all aspects including people, processes, information and technology;
  10. periodically re-evaluating status, risks and opportunities, stakeholder feedback, observed or anticipated unintended consequences, and anticipated system effectiveness and value, and recommending any appropriate corrective, mitigation or recovery actions to ensure continuing system success. Such activities during the operational phase can include upgrade activities, obsolescence management, maintenance and repair activities, manufacturing changes, changing operational processes, user training, instituting metrics and incentives, assessing information quality and integrity, and making other changes to the system.

SE provides guidance, facilitation and leadership to integrate all the disciplines and specialty groups into a team effort, forming an appropriately structured and coherent development process that proceeds from concept to production (if relevant), operation, evolution and eventual disposal.

SE is essentially collaborative in nature, working with and facilitating collaboration between all contributors to system success, recognizing the need to respect diverse points of view.

  • In some projects and in some organisations, SE may include a strong governance, technical management and resource management component.
  • In other projects and organisations, SE may have an almost entirely technical, advisory and “glue” role, if appropriate management and implementation structures already exist
  • SE may need to be applied at multiple levels of a complex project, programme or enterprise. 
  • The roles, responsibilities and accountabilities of SE, and how SE will interact with its internal and external stakeholders, should be documented in a management plan.

Fundamentally, SE is a learning journey; and the output of SE is information, and shared models. SE synthesizes and provides the information required to describe the solution system, and to enable its successful realization and use.

SE aims to provide effective solutions to complicated, complex and unprecedented problems, integrating the efforts of engineering and other disciplines and specialisations.

A high leverage task in the “systems-engineering” of engineered systems is to establish or confirm the operational concept: how the system will be used to create value, while avoiding negative consequences.

The difference between Complicated and Complex is discussed in, for example, Snowden and Boone (2007), and the INCOSE Complexity Primer (INCOSE, 2015). Complicated systems can be viewed as knowable and deterministic, and once developed their configuration can be “frozen”; whereas complex systems are not fully knowable or deterministic, may be dynamically reconfigurable, and continue to co-evolve with their environment throughout their lifecycle.

Most 20th century engineered systems were complicated; most 21st century engineered systems will be complex. In complex situations, we need to apply SE to the “ecosystem transformation” as well as to individual projects.