Systems Engineering

- Overview

Systems engineering is defined as a methodical, multi-disciplinary approach for the design, realization, technical management, operations, and retirement of a system. 

A “system” is the combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose; that is, all things required to produce system-level results.

The results include system-level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected. 

It is a way of looking at the “big picture” when making technical decisions. It is a way of achieving stakeholder functional, physical, and operational performance requirements in the intended use environment over the planned life of the system within cost, schedule, and other constraints. 

It is a methodology that supports the containment of the life cycle cost of a system. In other words, systems engineering is a logical way of thinking.

- Systems Engineering Objectives

Systems engineering is the art and science of developing an operable system capable of meeting requirements within often opposed constraints. 

Systems engineering is a holistic, integrative discipline, wherein the contributions of structural engineers, electrical engineers, mechanism designers, power engineers, human factors engineers, and many more disciplines are evaluated and balanced, one against another, to produce a coherent whole that is not dominated by the perspective of a single discipline. 

Systems engineering seeks a safe and balanced design in the face of opposing interests and multiple, sometimes conflicting constraints.

Systems engineers are well-versed in the art and science of balancing organization, cost, and technology interactions in complex systems. Systems engineers and support organizations are critical to providing accurate, timely cost and schedule information for technical activities to support planning and project planning and control (PP&C). 

Systems engineering is about trade-offs and compromises; it uses a broad cross-cutting view of the system rather than a single-disciplinary view. Systems engineering is about looking at the "big picture" and not only making sure they get the design right (meeting requirements), but also making sure they get the right design (achieving operational goals and meeting stakeholder expectations) 

[University of Chicago]

- The Evolution of Systems Engineering

The twenty-first century provides an exciting opportunity for systems engineering. New advances in our understanding of the traditional discipline continue to emerge. At the same time, new forms of systems engineering have developed to address the engineering challenges of systems-of-systems (SoS) and enterprise systems. 

Even at this point in their evolution, these new forms display their own principles, processes, and practices. Some are different in degree than engineering at the system level, while others are different in kind. 

While it's impossible to predict how the traditional and new forms of systems engineering will evolve, however, a robust future lies ahead. Increases in technological complexity result in new challenges in architecture, networks, hardware and software engineering, and human systems integration. 

At the same time, the engineering scale for systems exceeds levels that could have been imagined only a short time ago. As a consequence, all forms of systems engineering will be needed to solve future engineering challenges, sometimes separately - yet increasingly - in combination.

- V-Model of Systems Engineering Lifecycle

The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model and the US government standard.

The V-model summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework, or project life cycle development. It describes the activities to be performed and the results that have to be produced during product development.

The left side of the "V" (the diagram above) represents the decomposition of requirements, and creation of system specifications. The right side of the "V" represents integration of parts and their validation. However, requirements need to be validated first against the higher level requirements or user needs. 

Furthermore, there is also something as validation of system models. This can partially be done at the left side also. To claim that validation only occurs at the right side may not be correct. 

The easiest way is to say that verification is always against the requirements (technical terms) and validation always against the real world or the user needs. 

[More to come ...]