Systems Engineering Basics Tutorial

- a summary guide or tutorial about the basics of what is Systems Engineering, giving details of what the process is and how it may be used.

Systems engineering can be defined in many ways. However most definitions for systems engineering define it along the lines of an interdisciplinary approach encompassing the entire technical effort required to develop and verify an integrated and total life cycle balanced set of system, people, and process solutions that satisfy customer needs.

With many electronics, wireless and RF systems now involving may disciplines, it is necessary to adopt a systems engineering approach from the outset.

Beginnings of Systems Engineering

The basic concepts of systems engineering have been in existence for many years. Some of the first projects using what could be termed systems engineering processes were undertaken at Bell Laboratories in the 1940s.

With engineering systems becoming much larger and with the need to involve more disciplines, it was necessary to adopt a more formalised system to ensure that all the stages of the project were undertaken in unison by the different disciplines.

In the 1990s the National Council on Systems Engineering - NCOSE - was founded to develop excellence in systems engineering and to educate and spread best practice in systems engineering.

Around this time, and number of modelling and general systems engineering tools were developed - UML, USL, QFD, etc.

In 1995, NCOSE changed its name to International Council of Systems Engineering - INCOSE - to reflect the growing international interest in systems engineering techniques and standards.

Systems engineering basics

There are many requirements placed on the system engineering process. The systems engineering process should ensure that the customer and stakeholder needs are satisfied in a high quality, trustworthy, cost efficient and within the schedule needed.

To achieve this there a several steps or tasks that are adopted. These can be remembered using the acronym "SIMILAR":

  • State the problem:   Before embarking on any development, it is necessary to discover what is required. This is a key element of the systems engineering process and it is normally in the form of a problem statement - this may extend to very many pages, and it will start with a top level description of the functions along with a mission statement. The requirements are then elaborated to define exactly what is needed.

    It is advisable that mandatory (i.e. those requirements that must be incorporated in the design) and preference (i.e. those requirements that are preferred to be incorporated) requirements should be traceable to the main problem statement.

    Once the design is complete all mandatory requirements should be met, however it may be possible to undertake trade-offs with the preference statements to provide a system that is more usable or cost effective.

    It is important to note that the problem statement should be in terms of what must be done, and not how to do it as expressing how it may be achieved limits the development process.

    There are many ways in which the problem statement or requirements may be expressed. It may be defined in words or as a model. The inputs should come from interested parties and may include end users, operators, maintainers, suppliers, acquirers, owners, regulatory agencies, sponsors, manufacturers and other stakeholders.
  • Investigate alternatives:   As no single solution is likely to fully meet all the requirements, it is necessary to undertake a stage in the systems engineering process in which various options are tested and evaluated before they are incorporated into the design. These should also be re-evaluated as more data becomes available.

    To gain the optimum perspective, models of the alternatives should be constructed (either hardware or software) and evaluated; simulation data should be derived; and prototypes should be built and measured. This can be undertaken with as much concurrency as is deemed sensible to speed time while reducing risk. Finally, tests should be run on the real system. Alternatives should be evaluated against the requirements.
  • Model the system:   A model of the system is constructed. This uses the preferred alternatives from the investigation stages of the system engineering process. The model is then used throughout the development process.

    Models may be of two forms:

    • Product:   The product models are normally what would be expected within a development process. These models provide a platform later stages including integration and testing. These models also assist in trade-off studies and the management of risk.
    • Process:   These models can be used to study scheduling changes and the effects of delays, etc on the overall end dates. Having process models within the systems engineering activities also reveals items such as bottlenecks and other activities which may be fragmented, etc..
  • Integrate:   The integration phase within the systems engineering process is one of the most difficult as it exposes difficulties as the subsystems and sub-projects come together to create the overall finished system. The integration element of the systems engineering process involves bringing the different elements together so that they work as a whole. This activity can often take considerably more time than is expected.
  • Launch the system:   The launch activity within the systems engineering process involves running the system and producing outputs, i.e. enabling the system do what it was intended to do
  • Assess:   During this phase of the systems engineering process, the system is assessed to ensure it meets its requirements. Measurements / metrics are key to provide a real assessment of whether the system is performing correctly.
  • Re-evaluate:   Even when the system has been assessed, further re-evaluation is always required to ensure that the system meets the changing requirements and performs correctly in the different scenarios into which it may be placed. Additionally it may be that some of the original requirements were not correct, or they have changed and as a result it is necessary to continue to re-evaluate the system.

It is worth noting that the systems engineering process is not totally sequential. Rather the functions are undertaken in a parallel and iterative fashion to ensure that development is undertaken in a speedy fashion, while also being structured.

By Ian Poole

. . . .   |   Next >

Share this page

Want more like this? Register for our newsletter

What makes e-paper the best display technology for Makers? Scott Soong | Pervasive Displays
What makes e-paper the best display technology for Makers?
Scott Sonng or Pervasive Displays discusses how e-paper technology is contributing to the world of makers rather than just major companies enabling makers to utilise its advantages in projects based around Raspberry Pi and other single board computers.
Acquiring an Analog Signal: Bandwidth, Nyquist Sampling Theorem & Aliasing
In this white paper from National Instruments learn all you need to know about analog signal sampling: bandwidth, amplitude error, rise time, sample rate, Nyquist Sampling Theorem, aliasing & resolution.

More whitepapers
 is operated and owned by Adrio Communications Ltd and edited by Ian Poole. All information is © Adrio Communications Ltd and may not be copied except for individual personal use. This includes copying material in whatever form into website pages. While every effort is made to ensure the accuracy of the information on, no liability is accepted for any consequences of using it. This site uses cookies. By using this site, these terms including the use of cookies are accepted. More explanation can be found in our Privacy Policy