Systems Engineering: The generic concept

What is Systems Engineering?

Back in the late 90’s, I remember taking a two-semester course at the University called “Systems Analysis and Design”. This course described how to define and design a software application in order to develop it afterwards.

Summarizing the course, it all started by defining who our customers where and clarify exactly what kind of application to develop. Once the stakeholders were clear, then, we would setup a series of interviews and surveys with them to obtain the requirements. These requirements where then the basis to define how we would implement our software and then to start in what we would called: ”The design phase”.

On the design phase, we would describe our software using diagrams. One diagram was to explain the interfaces to our system, both internally and externally. Just to give some examples: reports generated, people who needed such reports, means of generation, etc. This would help on the definition of the kind of user profiles needed, the kind of security access required and so on.

The second kind of diagram was to define which function interacted with another, which parameters were needed, which function was calling other and under which circumstances. You could say, it was a high description of how the software was expected to work.

Once the design phase was done, we would move to the implementation phase... If you are familiar with this process, for sure you have already been in touch in one way or another with Systems Engineering.

Systems Engineering is widely used on the Automotive or Aeronautical Industry, and its purpose is to help a proper product development. INCOSE describes systems engineering as follows:

Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Performance, Test, Manufacturing, Cost & Schedule, Training & Support, Disposal.

The methodology that supports product development

Since the purpose of this article is just to give a general idea of what systems engineering is and what it does, I will start by showing the V-Model which represents the steps that represent the development cycle.

Customer requirements are the ones received from the customer. There is whole elicitation process and a way to analyze them in order to identify what our customer wants for a system to be developed. (Although I am saying here customer requirements, in reality we call them Stakeholder requirements, because it involves all type of requirements needed for the proper system functionality)

System requirements:

These requirements define what the systems is expected to do. System requirements are written by systems engineers which translate the customer requirements into specific functionality of the system and non-functional behavior. Functional behavior means what kind of functions our system will perform to achieve its mission.

Non functional-behavior are characteristics of our system that are needed, but do not influence the mission of the system we are developing. An example of a non-functional behavior can be self-diagnostics. The system is not providing any special functionality to achieve its purpose, it is just an internal activity needed in case of failure.

System Architecture: If we say that requirements describe what the system is expected to do, the system architecture describes how the system is expected to behave and how it is expected to be implemented:

• Logical architecture: Defines how a function will interact with another, in which order and at which times. This is, it describes how it will logically work our system.
• Physical architecture: Defines which elements are going to be used on the system to accomplish its mission.

Once a system has been defined in terms of its high level functionality, sometimes it needs to be further decomposed into smaller pieces. This can be done by developing the specific sub-system requirements that describe what each system element is doing. After that, the process can continue in the same manner until the subsystem is simple enough to be developed accordingly.

System Integration:

System integration is the step where several system elements are placed together (assembled) and tested to ensure they properly work together. System integration is in this sense a test that satisfies the described functionality by the system architecture.

System Verification:

System Verification tests whatever the system requirements described. Several test cases are developed and implemented to verify that the system does its expected behavior.

System Validation:

This kind of testing is done to finally prove the final product is doing its mission.

Is systems engineering about documenting?

Systems engineering is about designing the overall concept prior to its development. It is not a documentation tool. Its relevance relies on the fact of defining what is going to be developed, how is going to be developed, how is it expected to work, how is it going to be tested and how is it going to be integrated into its final environment.

By executing systems engineering at the appropriate timing, the initial time invested on properly developing and setting-up a project, reduces the costs and executions during later phases.

As this article is only providing a bird’s eye view, if someone is further interested on this topic. There are several organizations such as INCOSE, and training both online and face to face which can be easily accessed.

Twitter: CGHdz