**System Engineering Method for System Design**

Guillaume Auriol, Claude Baron, Vikas Shukla and Jean-Yves Fourniols *CNRS, LAAS, Université de Toulouse, UPS, INSA, INP, ISA, UT1, UTM, LAAS France* 

#### **1. Introduction**

200 Systems Engineering – Practice and Theory

DoD (Dec., 2006), *Capabilities-Based Assessment (CBA) User's Guide*, Ver.2, Sep. 25, 2011, Available from: www.dtic.mil/futurejointwarfare/strategic/cba\_guidev2.pdf DoD (Sep., 2008), *DoDD 7045.20 capability portfolio management*, Sep. 25, 2011, Available from:

DoD (Dec., 2008), *CJCSI 6212.01E Interoperability and supportability of information technology and national security systems*, , Sep. 25, 2011, Available from: https://acc.dau.mil DoD (Aug., 2010), *The DoDAF Architecture Framework*, Ver. 2.02, Sep. 25, 2011, Available

Federal Government (November 2007), *FEA Practice Guidance*, Available from: www.whitehouse.gov/sites/default/files/omb/assets/fea\_docs/FEA\_Practice\_G

ISO (2007), *ISO/IEC 24744 Software Engineering - Metamodel for Development Methodologies*,

Lee, J. & Park, Y. (2009), A Study on the Abstracted Metamodel of DoDAF 2.0 for CBA

Martin, J. (1997), Process concept, In : *Systems engineering guidebook: a process for developing systems and products*, pp. 51-56, CRC, ISBN 0-8493-7837-0, Boca Raton Suh, N. (1990), Design axioms and corollaries, In: *The Principles of Design*, pp.47-48, Oxford

ISO, Retrieved from: www.iso.org/iso/iso\_catalogue.htm

0-7695-3642-2, Daegu, Korea, May 27- 29, 2009

University Press, ISBN 0-19-504345-6, New York

from: http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF\_v2-02\_web.pdf

Methodology Execution, *International Conference on Software Engineering, 2009 10th ACIS Artificial Intelligences, Networking and Parallel/Distributed Computing*, ISBN: 978-

**6. References** 

http://www.dtic.mil

uidance\_Nov\_2007.pdf

The purpose of this chapter is to present some educational materials, the process and the outcomes to teach an engineering approach applied to a practical development case. The starting point is the requirements of an application of remote supervision of a room with several parameters: light, temperature and movement (intrusion into the room or movement of an object within the room). This application is based on wireless terminal nodes composed of a sensor, a microcontroller and a telecommunication module. Several rooms can be interconnected, so it must be possible to use the sensors of each room of a given site simultaneously. Various issues can be raised during teaching on wireless sensor networks (Kotzl & Essien, 2005): electronic design, risks to humans (Brownsell et al., 1999), energy management, telecommunication technologies, etc.

During the course, students have to learn and apply a 'systems engineering' (Ullrich K.T. and Eppinger S.D, 2003), (Terry A. Bahill and Clarck Briggs, 2001) approach based on standards in the field (Martin, 1998), (ISO15288, 2008), (IEEE1220, 2005) to solve a problem with numerous design options. Several off-the-shelf software and hardware components are at the students' disposal: a panel of telecommunication modules, different communication and signalling protocols, etc. They start by studying the requirements to extract an exhaustive list of needs. They must then propose and evaluate functional and architectural solutions, and finally implement the chosen solution in order to validate their 'systems engineering' approach.

Section 2 gives an overview of the method to follow to design a telecom system. Section 3 depicts the application through stakeholder's needs. Sections 4 to 6 detail the four steps of the method with (4) definition of stakeholders' needs and definition of technical requirements, (5) design of functional and (6) physical architectures. Section 7 presents the component realization, the component integration and the system validation. Finally, in the conclusion highlights the educational benefits to use a system engineering method.

#### **2. Overview of the method**

This section presents the main steps of the methodology based on UML diagrams (Bock, 2009), (Weilkiens, 2008) that the students have to follow. In a "V" development cycle, engineering processes cover the usual activities of a top-down process: (1) definition of

Needs Technical requirements Functional architecture Physical architecture System Realization Unit and integration tests Performance qualification Operational qualification Test cases Validation Validation Validation Validation Verification Verification Verification

stakeholders' needs, (2) definition of technical requirements, (3) design of functional and (4) physical architectures (see figure 1).

Fig. 1. Typical "V" cycle development

The *definition of stakeholders' needs* process first consists in identifying what kind of information the customer has given, generally a set of systems specifications which may not be either very well structured or even complete. The problem is then to understand the system in its specific context: define its purpose, mission, objectives and stakeholders, with the help of several operational scenarios. This process produces a document which lists and classifies stakeholders' needs and system constraints in every aspect of the system's use and lifecycle.

The goal of the *definition of technical requirements* process is to translate each need into an expression allowing the design of a feasible solution. It proceeds by refining the system mission and by breaking down the operational modes and scenarios into activities, in order to obtain corresponding technical requirements. This process also leads to complete and precise initial statements. The result is a document containing technical requirements that are coherent, formalized and verifiable (technical or physical features) and that will be useful for the designer.

After this essential step, it remains to build high-level *functional architectures*. The aim of this process is to establish and evaluate several functional architectures that could be candidates and retain one.

The *physical architectures* for the system, describing the chosen solution, as well as its physical interfaces, are given during the physical design processes.

At each step, a *verification process* is invoked, in order to justify the expression of needs, technical requirements, design choices, and to ensure traceability right through the development process.

Finally, a *validation process* is performed to compare technical requirements to performances obtained during in situ tests.

#### **3. Description of the application**

The students have to develop an application for the remote monitoring of several parameters of a room (luminosity, temperature) and of movements (intrusion detection). This application is based on nodes made up of a sensor, a microcontroller and a telecommunication module, in addition to the power module. Several rooms can be interconnected while the sensors inside each room must interact, as illustrated in figure 2. Three categories of nodes are used according to the nature of the data they have to transmit. These data are different by their:


202 Systems Engineering – Practice and Theory

stakeholders' needs, (2) definition of technical requirements, (3) design of functional and (4)

System Realization

The *definition of stakeholders' needs* process first consists in identifying what kind of information the customer has given, generally a set of systems specifications which may not be either very well structured or even complete. The problem is then to understand the system in its specific context: define its purpose, mission, objectives and stakeholders, with the help of several operational scenarios. This process produces a document which lists and classifies stakeholders' needs and system constraints in every aspect of the system's use and lifecycle. The goal of the *definition of technical requirements* process is to translate each need into an expression allowing the design of a feasible solution. It proceeds by refining the system mission and by breaking down the operational modes and scenarios into activities, in order to obtain corresponding technical requirements. This process also leads to complete and precise initial statements. The result is a document containing technical requirements that are coherent, formalized and verifiable (technical or physical features) and that will be

After this essential step, it remains to build high-level *functional architectures*. The aim of this process is to establish and evaluate several functional architectures that could be candidates

The *physical architectures* for the system, describing the chosen solution, as well as its

physical interfaces, are given during the physical design processes.

Validation

Validation

Validation

Validation

Unit and integration tests

Operational qualification

Performance qualification

Test cases

physical architectures (see figure 1).

Needs

Verification

Verification

Verification

Fig. 1. Typical "V" cycle development

useful for the designer.

and retain one.

Technical requirements

> Functional architecture

> > Physical architecture


As far as their transfer is concerned, these data have different needs concerning the quality of service. These needs must also be taken into account for the choice of a specific telecommunication technology and during the development of appropriated communication protocols.

Fig. 2. Application of monitoring

### **4. Definition of stakeholders' needs and technical requirements**

#### **4.1 Needs**

This step consists in enumerating the different elements of the context with which the system interacts when in use (physical and functional boundaries). The relationships between the system and these external elements are clearly illustrated in two distinct diagrams: a use case diagram, and an initial class diagram. The use case diagram is obtained by imagining global services showing the main interactions between the elements of the context and the system of interest. For example, in our surveillance application, the system collects energy readings from its environment and reports the collected temperatures to an operator; it is configured and repaired by a maintenance operator. On the basis of the use case diagram, we can draw up an initial class diagram containing the elements of the context and their physical links with the system of interest.

Students have to apply a system engineering (SE) method to design a sensor network. They use this network to validate their solution: choice of a telecommunication transceiver, communication and signalling protocols... suiting to a targeted application. This training includes 7 supervised sessions of practical works (3 hours each); free sessions are also scheduled so that the students can have access to the technical equipment. The starting point is the application specifications. Various items are available: software development tools, sensors (this teaching is synchronized with another one which objective is the development by the students of all the electronic part of the sensors), microcontroller evaluation boards and several kinds of transceiver with a detailed technical documentation. The interface boards between evaluation board and three transceivers are also given from the start.

At the end of this need identification process, they obtained two schemas with the main services provided or required by the system (figure 3) as well as the main components interacting with environment (figure 4).

#### **4.2 Definition of technical requirements**

Next step is to define what are the high-level stages of the system life and, in each one, what are the systems states (also called 'modes'). We usually find three cycles: upstream, utilization, downstream cycles. The upstream cycle includes four classical modes: design, realization, validation and installation. The utilisation cycle depends of the system of interest; for example, in our case, we distinguish maintenance, waking and monitoring states. In the downstream cycle, we usually find the retrieval mode.

Students are essentially involved in upstream and utilization modes. They obtain the general operational modes depicted in figure 5.

The technical requirements express the needs in the language of the project manager, or prime contractor, whereas the needs were previously expressed in the users' language. It is now necessary to complete and refine the information supplied by the users so that they lead to potential solutions. This is the goal of the technical requirements definition process.

This step consists in enumerating the different elements of the context with which the system interacts when in use (physical and functional boundaries). The relationships between the system and these external elements are clearly illustrated in two distinct diagrams: a use case diagram, and an initial class diagram. The use case diagram is obtained by imagining global services showing the main interactions between the elements of the context and the system of interest. For example, in our surveillance application, the system collects energy readings from its environment and reports the collected temperatures to an operator; it is configured and repaired by a maintenance operator. On the basis of the use case diagram, we can draw up an initial class diagram containing the elements of the

Students have to apply a system engineering (SE) method to design a sensor network. They use this network to validate their solution: choice of a telecommunication transceiver, communication and signalling protocols... suiting to a targeted application. This training includes 7 supervised sessions of practical works (3 hours each); free sessions are also scheduled so that the students can have access to the technical equipment. The starting point is the application specifications. Various items are available: software development tools, sensors (this teaching is synchronized with another one which objective is the development by the students of all the electronic part of the sensors), microcontroller evaluation boards and several kinds of transceiver with a detailed technical documentation. The interface boards between evaluation board and

At the end of this need identification process, they obtained two schemas with the main services provided or required by the system (figure 3) as well as the main components

Next step is to define what are the high-level stages of the system life and, in each one, what are the systems states (also called 'modes'). We usually find three cycles: upstream, utilization, downstream cycles. The upstream cycle includes four classical modes: design, realization, validation and installation. The utilisation cycle depends of the system of interest; for example, in our case, we distinguish maintenance, waking and monitoring

Students are essentially involved in upstream and utilization modes. They obtain the

The technical requirements express the needs in the language of the project manager, or prime contractor, whereas the needs were previously expressed in the users' language. It is now necessary to complete and refine the information supplied by the users so that they lead to potential solutions. This is the goal of the technical requirements definition

states. In the downstream cycle, we usually find the retrieval mode.

**4. Definition of stakeholders' needs and technical requirements** 

context and their physical links with the system of interest.

three transceivers are also given from the start.

interacting with environment (figure 4).

**4.2 Definition of technical requirements** 

general operational modes depicted in figure 5.

process.

**4.1 Needs** 

Fig. 3. General service diagram

Fig. 4. Initial class diagram

**Socket**

**<<actor>>**

**MainStation**

**1..2**

**RoomElectricNetwork**

**<<actor>>**

**Operator**

**<<actor>>**

**NodeTransceiver**

**MainStationTransceiver**

**ExternNoise**

**<<actor>>**

**Supervisor**

**OperatorIHM**

**SupervisorIHM**

**<<actor>>**

**MonitoringSystem**

**Gateway**

**1..2**

**ExternEnergy**

**NodeEnergySensor**

**WirelessNode**

**1..64**

**<<actor>>**

**ExternEvent**

**Sensor**

**<<actor>>**

**RoomWhal**

**FixingPart**

**package** **<<actor>>**

**ExternNoise**

Fig. 4. Initial class diagram

**GatewayTransceiver**

**GatewayEnergySensor**

**Components**

**InitialClasses {2/2}**

**<<actor>> ExternEnergy**

#### Fig. 5. Operational modes

An example of technical requirements found by students and obtained by translating need into expressions allowing the design of a practicable/realizable solution is resumed in Table 1. Some previous works (Auriol *et al.*, 2008) explain a way to introduce students to requirement engineering.


Table 1. Example of a need and definition of corresponding technical requirements

#### **5. Design of functional architecture**

The functional design process consists in identifying functional elements and designing functional architectures. The goal is to establish and evaluate several functional architectures that could be candidates and retain one. The identification of functional elements is directly obtained by an analysis of technical requirements: functional, interface and operational requirements, operational scenarios, and a breakdown of expected services. Performance requirements must then be allocated to functions. Once several functional architectures have been obtained, we need to identify and solve any conflicts between the elements of each functional solution (optimization process) and verify that each functional architecture correctly and fully satisfies the technical requirements. An evaluation of the various alternative functional architectures compared according to several parameters (quality, costs, times, performances, risks, etc.) leads to the best trade-off.

For example, when students deal with the services found in the first step, they obtain the Activity Diagram depicted in figure 6.

#### **6. Design of physical architecture**

Once a functional architecture for the system has been defined, the goal of the physical design process is to design various physical architectures to support these functions. The effort in this step is focused on identifying classes of components, establishing parameters and choosing criteria to assign the elements of the functional architecture to physical components, and the evaluation of several solutions. The physical architecture design process takes as its starting point the result of the functional design step, and refines it. Indeed, for each architecture, the first task is to decide whether the functional breakdown is sufficient to identify physical components and/or technologies capable of supporting the execution of the end functions of the functional architecture. The objective is then to consider various possible physical architectures and to estimate their feasibility. Once various possible physical architectures have been obtained, it only remains to choose a final architecture. Once this choice has been made, the final task is to fully specify the solution, to validate and justify it.

Students extract the components of the system from the initial class diagram (figure 7) and progressively complete the physical architecture diagram with components according to the functions found during the precedent step (figures 8&9).

At this level of breakdown, students add the available solutions. In this chapter, we only give some details about transceivers and communication protocols. For example, they can choose transceivers among:


The choice of these technologies is driven by the diversity of the services that they offer. To simplify, four technical parameters are retained: cost, range, consumption and access BUS and the embedded Medium Access Control (MAC) layer. During the integration step, students have to refine and to extend these performances

The functional design process consists in identifying functional elements and designing functional architectures. The goal is to establish and evaluate several functional architectures that could be candidates and retain one. The identification of functional elements is directly obtained by an analysis of technical requirements: functional, interface and operational requirements, operational scenarios, and a breakdown of expected services. Performance requirements must then be allocated to functions. Once several functional architectures have been obtained, we need to identify and solve any conflicts between the elements of each functional solution (optimization process) and verify that each functional architecture correctly and fully satisfies the technical requirements. An evaluation of the various alternative functional architectures compared according to several parameters

For example, when students deal with the services found in the first step, they obtain the

Once a functional architecture for the system has been defined, the goal of the physical design process is to design various physical architectures to support these functions. The effort in this step is focused on identifying classes of components, establishing parameters and choosing criteria to assign the elements of the functional architecture to physical components, and the evaluation of several solutions. The physical architecture design process takes as its starting point the result of the functional design step, and refines it. Indeed, for each architecture, the first task is to decide whether the functional breakdown is sufficient to identify physical components and/or technologies capable of supporting the execution of the end functions of the functional architecture. The objective is then to consider various possible physical architectures and to estimate their feasibility. Once various possible physical architectures have been obtained, it only remains to choose a final architecture. Once this choice has been made, the final task is to fully specify the solution, to

Students extract the components of the system from the initial class diagram (figure 7) and progressively complete the physical architecture diagram with components according to the

At this level of breakdown, students add the available solutions. In this chapter, we only give some details about transceivers and communication protocols. For example, they can

choose transceivers among: - a half-duplex FM transmitter, manufactured by Telital, using FSK modulation at 433MHz - a EEE 802.15.4 [9] transmitter with a *ZigBee* [10] stack manufactured by Microchip - a GSM / GPRS modem manufactured by Sagem

The choice of these technologies is driven by the diversity of the services that they offer. To simplify, four technical parameters are retained: cost, range, consumption and access BUS and the embedded Medium Access Control (MAC) layer. During the integration step,

(quality, costs, times, performances, risks, etc.) leads to the best trade-off.

**5. Design of functional architecture** 

Activity Diagram depicted in figure 6.

**6. Design of physical architecture** 

functions found during the precedent step (figures 8&9).

students have to refine and to extend these performances

validate and justify it.

Fig. 6. General activity diagram

Fig. 7. Main components

Fig. 8. Microcontrollers and protocols components

**package System Breakdown0 {1/3} MonitoringSystem**

**WirelessNode <sup>1</sup> .. <sup>64</sup> MainStation <sup>1</sup> .. <sup>2</sup>**

**Gateway 1 .. 2**

**Sensor**

**NodeTransceiver**

Fig. 7. Main components

**Sensor**

**FixingPart**

**NodeEnergySensor**

**NodeTransceiver**

Fig. 8. Microcontrollers and protocols components

**FixingPart**

**NodeEnergySensor**

**GatewayEnergySensor**

**GatewayTransceiver**

**package System Breakdown1 {2/3} MonitoringSystem**

**WirelessNode <sup>1</sup> .. <sup>64</sup> MainStation <sup>1</sup> .. <sup>2</sup>**

**Gateway 1 .. 2**

**GatewayEnergySensor**

**GatewayTransceiver**

**NodeComProtocols GatewayComProtocols MainStationComProtocol**

**NodeMicrocontroller GatewayMicrocontroller MainMicrocontroller**

**MainStationTransceiver**

**MainStationTransceiver**

**Socket**

**SupervisorIHM**

**OperatorIHM**

**Socket**

**SupervisorIHM**

**OperatorIHM**

Fig. 9. Final class diagram

Then, students obtain the schema in figure 10.

Fig. 10. Details of transceiver diagram

Each transceiver studied has specific data transfer and signaling protocol which can be extremely basic, or may include complex embedded applications. The implementation of these services also differs a lot from one device to another. To develop the application of remote monitoring, students must initially understand the need for these services, and then extend them if necessary. Mainly, the retained parameters to characterize the communication protocols concern:


Students obtain the schema of figure 11.

**class Transceivers TransceiversSolutions {1/1} Transceivers**

embeddedProtocol : CommunicationProtocol

**GSMTransceiver** mac=GSM\_GPRS consumption=High range=UnLimited cost=Expensive bus=USART+AT

**<<enumeration>> RANGE**

Each transceiver studied has specific data transfer and signaling protocol which can be extremely basic, or may include complex embedded applications. The implementation of these services also differs a lot from one device to another. To develop the application of remote monitoring, students must initially understand the need for these services, and then extend them if necessary. Mainly, the retained parameters to characterize the



Meters 100Meters UnLimited

**FMTransceiver** mac = FM433MHz consumption=Low range=Meters cost=Cheap bus=USART

> USART SPI USART+AT

**<<enumeration>> BUS**

**<<enumeration>> COST**

Cheap Medium Expensive

mac : MAC

**<<enumeration>> CONSUMPTION**

Low Medium High

Fig. 10. Details of transceiver diagram

communication protocols concern:


or not, periodic or not.

Students obtain the schema of figure 11.

range : RANGE cost : COST bus : BUS

consumption : CONSUMPTION

transmitData ( D : DATA)

Then, students obtain the schema in figure 10.

**802.15.4Transceiver**

mac=ZigBee consumption=Medium range=100Meters cost=Medium bus=SPI

**<<enumeration>> MAC**

ZigBee FM433MHz GSM\_GPRS

Fig. 11. Details of protocol diagram

#### **7. Integration and validation**

During this step of integration, students connect component via customized boards to the evaluation board of a microcontroller (MCBSTM32 [7] of Keil, processor ARM / ST). This configuration represents a "less embedded" solution than a dedicated electronic board which would have specifically been developed and offers a high flexibility of use and of debug to the students by supplying a multi line LCD screen for display, free zones for oscilloscope measures, series connections for connections to a terminal PC, diodes... The data transfer and signalling protocols are implemented on the microcontroller by means of the environment µVision3 of Keil [8] which offers functions of simulation and transfer towards a microcontroller.

Students have to discover and understand the manipulation of each device taken separately before starting to completely implement the platform to validate their choice of components.

The students follow the evolution detailed below:


in any emission of information. They also note a risk of collision and loss of frames which grows with the transmitter number if they do not use a device offering suitable services or if they do not extend those basic ones proposed by the device.

**Step 3.** the network spreads out. The initial range of the first two modules (FM and *ZigBee*) is not sufficient to cover communication needs on more important distances. It is then essential to set up several modules with a suitable signaling service on intermediate devices.

Gradually, the students thus take into account a more and more complex topology until they consider the complete platform of test compatible with the application of remote monitoring. The objective for the students is to validate their choice of components by the mean of a platform whose technological solution is represented in figure 12. Indeed, this solution appears as the best compromise if all the parameters are taken into account.

Fig. 12. Technological solution

#### **8. Conclusion**

214 Systems Engineering – Practice and Theory

**Step 3.** the network spreads out. The initial range of the first two modules (FM and *ZigBee*)

Gradually, the students thus take into account a more and more complex topology until they consider the complete platform of test compatible with the application of remote monitoring. The objective for the students is to validate their choice of components by the mean of a platform whose technological solution is represented in figure 12. Indeed, this solution appears as the best compromise if all the parameters are taken into

ZB

ZB

GSM/GPRS mobile

Gateway 1

the device.

account.

FM

Sensor 1

Sensor 2

intermediate devices.

FM FM Sensor 3

ZigBee device

Fig. 12. Technological solution

FM 433MHz device

Microcontroller evalboard

FM

in any emission of information. They also note a risk of collision and loss of frames which grows with the transmitter number if they do not use a device offering suitable services or if they do not extend those basic ones proposed by

is not sufficient to cover communication needs on more important distances. It is then essential to set up several modules with a suitable signaling service on

Gateway 2

ZB Gateway 3

FM

Sensor 6

ZB

FM

GSM/GPRS

Main station

FM

FM

Sensor 5

Sensor 4

This chapter describes a teaching experiment during which the students apply a systems engineering approach to design a solution for a complex system when numerous design and implementation options are available. The chosen application is the remote surveillance of several rooms simultaneously taking into account three parameters: light, temperature and movement. This application is based on wireless terminal nodes composed of a sensor, a microcontroller and a telecommunication module. They dispose of a set of off-the-shelf software and hardware components from which they must design the best functional and architectural solutions, by drafting a technical requirements dossier to satisfy the users' needs.

For that, they are guided to progress following the steps of the V cycle. They start by studying the requirements to extract an exhaustive list of needs. Then they propose and evaluate functional and architectural solutions. They finally implement the chosen solution by integrating the different modules of the physical architecture in order to validate their 'systems engineering' approach.

This experiment was positive in that it taught students that even if they had no previous specific knowledge of the field of wireless Personal Area Networks, a formalised systems engineering approach allowed them to develop a solution.

#### **9. Acknowledgement**

A part of the research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) (www.crescendo-fp7.eu) under grant agreement n◦234344.

#### **10. References**


### **Assessing the Capacity for Engineering Systems Thinking (CEST) and Other Competencies of Systems Engineers**

Moti Frank1 and Joseph Kasser2 *1HIT-Holon Institute of Technology, 2NUS-National University of Singapore, 1Israel 2Singapore* 

#### **1. Introduction**

216 Systems Engineering – Practice and Theory

Terry A. Bahill and Clarck Briggs. "The systems engineering started in the middle process :

Ullrich K.T. and Eppinger S.D., "Product design and development", McGraw Hill

Weilkiens T., 2008, *Systems Engineering with SysML/UML: Modeling, Analysis, Design*, Morgan

4(2) pages 156–167, 2001.

International Edition, 2003

320p

A consensus of systems engineers and project managers", Systems Engineering,

Kaufmann Publishers In, 28 March 2008, The MK/OMG Press, ISBN 0123742749,

This chapter introduces a tool for assessing engineers' interest in what is required from successful systems engineers, or in other words, assessing the extent of engineers' systems thinking. What is required from successful systems engineers (the characteristics of successful systems engineers) is commonly called 'competencies of successful systems engineers' and much activity to develop systems engineering competency models has been done in recent years. A summary of several systems engineering competency models is presented in the chapter. The competency model that has been used as the underpinning basis for the developing of the assessment tool presented in this chapter is the CEST (Capacity for Engineering Systems Thinking) model. The main reason for choosing this model is presented in the chapter and then the model itself and several principles for assessing engineers' systems thinking are presented. Finally, the assessment tool is presented as well as the main methods that have been used for validating the tool.

#### **2. Systems thinking and CEST**

Systems thinking is what makes systems engineering different from other kinds of engineering and is the underpinning skill required to do systems engineering" (Beasley & Partridge, 2011). *Systems thinking*, according to Senge (1994), is a discipline for seeing the whole. *Engineering Systems Thinking* is hypothesized as a major high-order thinking skill that enables individuals to successfully perform systems engineering tasks (Frank, 2000; 2002). Systems engineers need a systems view or a high capacity for engineering systems thinking (CEST) to successfully perform systems engineering tasks. Research found that this ability is a consistent personality trait and that it can be used to distinguish between individual engineers (Frank, 2006). CEST may be developed through experience, education and training (Davidz & Nightingale, 2008; Kasser, 2011) and can be assessed (Frank, 2010). Moreover, well designed and taught systems engineering courses may accelerate systems thinking development.

The chapter introduces a tool for assessing engineers' CEST. Since there is no known way for directly 'measuring' thinking skills of individuals, an indirect way is needed, for example, IQ tests are pen-and-paper indirect tests for 'measuring' the intelligence of individuals.

One of the main assumptions made by Frank (2010) is that in order to be a successful systems engineer, one must have both a will and an interest to be a systems engineer.

In addition, as mentioned, successful systems engineers possess a high level of engineering systems thinking (CEST). Thus, the three components discussed here - success in a systems engineering position, an interest in systems engineering positions and CEST- are all interconnected and interrelated. The will and interest to be a systems engineer basically means the desire and interest to be involved with job positions that require CEST. In other words, we may hypothesize that there is a high positive correlation between the engineering systems thinking extent (CEST) of an individual and his/her interest in what is required from successful systems engineers. Figure 1 is a simple concept map that depicts the relationships between these three components:

Fig. 1. the relationships between the desire, successful SE and CEST

If this hypothesis is supported, then it enables developing a method for assessing the extent of CEST of individuals. This is because interests may be assessed by an interest inventory which is a very common and frequently used to help people choose a profession, and as a selection tool (to determine whether a certain individual is suitable for a certain role) in the recruiting process (Anastazi, 1988**).** This chapter introduces a tool for assessing engineers' interest in what is required from successful systems engineers, or in other words, assessing the extent of the engineering systems thinking.

#### **3. Systems engineering competency models**

What is required from successful systems engineers (the characteristics of successful systems engineers) is commonly called 'competencies of successful systems engineers' and much activity to develop systems engineering competency models has been done in recent years. A summary of the following models is presented below:


#### **3.1 INCOSE UK SE competencies framework**

218 Systems Engineering – Practice and Theory

The chapter introduces a tool for assessing engineers' CEST. Since there is no known way for directly 'measuring' thinking skills of individuals, an indirect way is needed, for example, IQ tests are pen-and-paper indirect tests for 'measuring' the intelligence of

One of the main assumptions made by Frank (2010) is that in order to be a successful

In addition, as mentioned, successful systems engineers possess a high level of engineering systems thinking (CEST). Thus, the three components discussed here - success in a systems engineering position, an interest in systems engineering positions and CEST- are all interconnected and interrelated. The will and interest to be a systems engineer basically means the desire and interest to be involved with job positions that require CEST. In other words, we may hypothesize that there is a high positive correlation between the engineering systems thinking extent (CEST) of an individual and his/her interest in what is required from successful systems engineers. Figure 1 is a simple concept map that depicts the

If this hypothesis is supported, then it enables developing a method for assessing the extent of CEST of individuals. This is because interests may be assessed by an interest inventory which is a very common and frequently used to help people choose a profession, and as a selection tool (to determine whether a certain individual is suitable for a certain role) in the recruiting process (Anastazi, 1988**).** This chapter introduces a tool for assessing engineers' interest in what is required from successful systems engineers, or in other words, assessing

Successful systems engineer

characterized possesses

High level of CEST

What is required from successful systems engineers (the characteristics of successful systems engineers) is commonly called 'competencies of successful systems engineers' and much activity to develop systems engineering competency models has been done in recent years.

systems engineer, one must have both a will and an interest to be a systems engineer.

individuals.

Will/Desire to be a systems engineer

relationships between these three components:

the extent of the engineering systems thinking.

 INCOSE UK SE Competencies Framework MITRE Systems Engineering Competency Model

Characteristics of the Ideal Systems Engineer

Systems Thinking Enablers

**3. Systems engineering competency models** 

A summary of the following models is presented below:

Advancing the Practice of Systems Engineering at JPL

Fig. 1. the relationships between the desire, successful SE and CEST

According to the systems engineering competencies framework of the United Kingdom chapter of the International Council on Systems Engineering (INCOSE UK, 2010), systems engineering ability comprises four key elements: competencies, basic skills and behaviours, supporting techniques and domain knowledge. The competencies are grouped into three categories: systems thinking, holistic lifecycle view and systems engineering management. The full document presents the following information for each competency: a description, why it matters and effective indicators of knowledge and experience in four levels awareness, supervised practitioner, practitioner and expert. Examples of basic skills and behaviours are:


#### **3.2 MITRE systems engineering competency model**

The MITRE competency model (Metzger & Bender, 2007) consists of 36 competencies organized into five sections: enterprise perspectives, systems engineering life cycle, systems engineering planning and management, systems engineering technical specialties, collaboration and individual characteristics. For example, the section 'enterprise perspectives' consists of three competencies - comprehensive viewpoints, innovative approaches and foster stakeholder relationships and the section 'collaboration and individual characteristics' consists of nine competencies - building trust, building a successful team, communicating with impact, persuasiveness and influence, facilitating, managing and championing change, high quality standards, results orientation, adaptability and integrity.

#### **3.3 Systems thinking enablers**

According to Davidz and Nightingale (2008), the primary mechanisms that enable systems thinking development include: experiential learning, a supporting environment and certain individual characteristics, such as thinking broadly, curiosity, questioning, being openminded, communication, tolerance for uncertainty, strong interpersonal skills and 'thinking out of the box'.

#### **3.4 Advancing the practice of systems engineering at JPL**

The JPL (Jet Propulsion Laboratory) competency model presented by Jansma and Jones (2006) refers to personal behaviours and processes. The personal behaviours are presented in five groups:


#### **3.5 Characteristics of the ideal systems engineer**

Burk (2008) found that the characteristics of the ideal systems engineer are: systems outlook, customer/user/consumer orientation, inquisitiveness, intuition, discipline, communication and cooperation (but not capitulation).

#### **4. The maturity model framework**

The maturity model for the competency of systems engineers is based on an assessment of an individual's skill against ability in each of three broad dimensions - knowledge (systems engineering and domain), cognitive characteristics (systems thinking and critical thinking) and individual traits. The maturity model is designed in such a manner so as to be a generic maturity model for assessing competency in many practitioner professions simply by changing the knowledge requirements (Kasser & Frank, 2010).

The maturity model is a two-dimensional model. The vertical dimension covers the following three broad areas:


The horizontal dimension is based on Kasser, Hitchins and Huynh (2009) who argue that anecdotal evidence exists for five types of systems engineers:

 Type I. This type is an "apprentice" who can be told "how" to implement the solution and can then implement it.

The JPL (Jet Propulsion Laboratory) competency model presented by Jansma and Jones (2006) refers to personal behaviours and processes. The personal behaviours are presented

 Leadership Skills - has the ability to influence; has the ability to work with a team; has the ability to trust others; communicates vision and technical steps needed to reach

 Attitudes and Attributes - has intellectual self-confidence; has intellectual curiosity; has ability to manage change; remains objective and maintains a healthy scepticism. Communication - advances ideas and fosters open two-way discussions; communicates

Problem Solving and Systems Thinking - manages risk; thinks critically and penetrates

 Technical Acumen - successfully expresses a technical grasp of system engineering at all levels; is a generalist in nature; with proven technical depth in one or two disciplines;

Burk (2008) found that the characteristics of the ideal systems engineer are: systems outlook, customer/user/consumer orientation, inquisitiveness, intuition, discipline, communication

The maturity model for the competency of systems engineers is based on an assessment of an individual's skill against ability in each of three broad dimensions - knowledge (systems engineering and domain), cognitive characteristics (systems thinking and critical thinking) and individual traits. The maturity model is designed in such a manner so as to be a generic maturity model for assessing competency in many practitioner professions simply by

The maturity model is a two-dimensional model. The vertical dimension covers the

**Knowledge** of systems engineering and the application domain in which the systems

 **Cognitive characteristics**, namely the ability to think, identify and tackle problems by solving, resolving, dissolving or absolving the problems in both the conceptual and

**Individual traits**, namely the ability to communicate with, work with, lead and

The horizontal dimension is based on Kasser, Hitchins and Huynh (2009) who argue that

Type I. This type is an "apprentice" who can be told "how" to implement the solution

implementation; mentors and coaches less experienced systems engineers.

through storytelling and analogies; listens and translates information.

has proven knowledge of systems engineering practices.

changing the knowledge requirements (Kasser & Frank, 2010).

anecdotal evidence exists for five types of systems engineers:

**3.5 Characteristics of the ideal systems engineer** 

**3.4 Advancing the practice of systems engineering at JPL** 

a topic in a methodical manner.

and cooperation (but not capitulation).

**4. The maturity model framework** 

following three broad areas:

physical domains.

influence other people.

and can then implement it.

engineering is being applied.

in five groups:


The two-dimensional maturity model framework shows the assessment of the competency in increasing levels of competency (Type I to V) as presented in the following Table. Declarative knowledge is knowledge that can be declared in some manner. It is "knowing that" something is the case. Describing a process is declarative knowledge. Procedural knowledge is about knowing how to do something. It must be demonstrated; performing the process demonstrates procedural knowledge. Conditional knowledge is about knowing when and why to apply the declarative and procedural knowledge (Woolfolk, 2011). This usually comes from experience. In the Table, where knowledge is required at the conditional level, it includes procedural and declarative. Similarly, where knowledge is required at the procedural level, it includes declarative knowledge.



Table 1. The two-dimensional maturity model

The maturity model may serve both as a competency model and a framework for assessing/comparing other competency models (Kasser et al., 2011).

Other systems engineering competencies models found in the literature include:


#### **5. The CEST competency model**

However, the competency model that has been used as the underpinning basis for the developing of the assessment tool presented in this chapter is the CEST model (Frank, 2002; 2006). The main reason for choosing this model is that in order to assess systems thinking in engineers, it is necessary, first, to elaborate this thinking skill to elements that can be assessed. The CEST Competency Model presents a list of cognitive competencies that are all related to systems thinking and each one of them can be assessed separately.

Eighty-three competencies of successful systems engineers have been found in the studies and these findings were used to create the CEST Competency Model. These 83 competencies were then aggregated into 35 competencies - 16 cognitive competencies, nine skills/abilities (all also related to cognitive competencies), seven behavioural competencies and three related to knowledge and experience.

The 16 cognitive competencies are as follows for successful systems engineers:


The nine skills/abilities that are all related to cognitive competencies of successful systems engineers are the ability to:


The maturity model may serve both as a competency model and a framework for

However, the competency model that has been used as the underpinning basis for the developing of the assessment tool presented in this chapter is the CEST model (Frank, 2002; 2006). The main reason for choosing this model is that in order to assess systems thinking in engineers, it is necessary, first, to elaborate this thinking skill to elements that can be assessed. The CEST Competency Model presents a list of cognitive competencies that are all

Eighty-three competencies of successful systems engineers have been found in the studies and these findings were used to create the CEST Competency Model. These 83 competencies were then aggregated into 35 competencies - 16 cognitive competencies, nine skills/abilities (all also related to cognitive competencies), seven behavioural competencies and three

6. understand systems without getting stuck on details; tolerance for ambiguity and

The nine skills/abilities that are all related to cognitive competencies of successful systems

1. analyze and develop the needs and mission statement, and the goals and objectives of

2. understand the operational environment and develop the concept of operation

assessing/comparing other competency models (Kasser et al., 2011).

Systems Engineering Competency Taxonomy (Squires et al., 2011).

related to systems thinking and each one of them can be assessed separately.

The 16 cognitive competencies are as follows for successful systems engineers:

8. understand a new system/concept immediately upon presentation;

NASA Systems Engineering Competencies (NASA, 2009).

Generic Competency Model (Armstrong et al., 2011).

1. understand the whole system and see the big picture; 2. understand interconnections; closed-loop thinking; 3. understand system synergy (emergent properties); 4. understand the system from multiple perspectives;

7. understand the implications of proposed change;

9. understand analogies and parallelism between systems;

12. (are) innovators, originators, promoters, initiators, curious;

14. are able to take into consideration non-engineering factors;

**5. The CEST competency model** 

related to knowledge and experience.

5. think creatively;

uncertainty;

10. understand limits to growth; 11. ask good (the right) questions;

13. are able to define boundaries;

15. are able to "see" the future; 16. are able to optimize.

engineers are the ability to:

the system;

(CONOPS);

Other systems engineering competencies models found in the literature include:


The seven behavioural competencies of successful systems engineers are as follows:


The three competencies related to knowledge and experience for successful systems engineers are as follows:


In organizations and projects there are many different kinds of job positions that may be included in the systems engineering category. Different positions require different competencies, for example, a systems engineer who works in marketing needs different knowledge, skills and behavioural competences from those of a systems engineer who deals with integration or a systems engineer who deals with verification and validation. In addition, it is unlikely that a successful systems engineer would possess all of these 35 competencies. It is more likely that a certain systems engineer possesses part of the listed competencies and is employed in a position that requires these specific characteristics. Thus, it is not enough to assess CEST by the final score of the assessment tool presented below. Analyzing the answers to each question is important as well.

However, it appears that a set of core competencies do in fact exist, necessary to all systems engineers, independent of their specific position. It is a matter of hierarchy. Every job level requires competencies suitable for the said level. The higher the systems engineering position in the organization/project hierarchy, the higher the level of required cognitive competencies, skill/ability and behavioural competencies, and broader knowledge needed.

### **6. Assessing CEST**

The battery for assessing CEST in its final stages will comprise:

	- *An interest inventory* will be discussed in detail in Section 7 below**.**
	- *A knowledge and skills test*. The present paper does not discuss the knowledge and skills test. Much work in this field has already been done by the International Council on Systems Engineering (INCOSE), the INCOSE Certification of Systems Engineers Exam working group. This exam is based on the INCOSE SE Handbook (INCOSE, 2006).
	- *An aptitude test*. Please see several sample questions in Frank (2007).

### **7. The interest inventory for assessing CEST**

As said earlier, the will/desire and the interest to be a systems engineer (to be involved in systems projects) mainly means the will and interest to deal with situations that require systems thinking. In addition, one of the seven behavioural competencies of a successful systems engineer is a will/desire to be a systems engineer (to be involved in systems projects) - see competency number 6 in the list of the seven behavioural competencies aforementioned in the CEST competency model section. These two findings lead to the conclusion that the will/desire to be involved in positions that require engineering systems thinking predicts success in systems engineering positions. This will/desire can be assessed by an interest inventory. As mentioned above, an interest inventory is a very common tool which is frequently used to help people choose a profession and as a selection tool in the recruiting process (Anastazi, 1988**).** 

Usually, the items in interest inventories deal with preferences, specifically likes and dislikes regarding a diverse group of activities, jobs, professions or personality types. Likewise, the items included in the tool discussed in this chapter refer to ranges of likes and dislikes regarding systems engineering activities, various disciplines and knowledge required from systems engineers, systems engineering activities and types of people involved in projects.

In its present version the tool consists of 40 pairs of statements. For each pair, the examinee has to choose between the two statements according to his/her preference. The examinee checks answer "A" if he/she prefers the first statement or answer "B" if he/she prefers the second statement. In order to improve the questionnaire's reliability, questionnaire items were reorganized, so in some cases "A" represented the systems thinking answer and in other cases "B" represented the systems thinking answer. Each "A" answer receives 2.5 points, while each "B" answer receives no point. Thus, the range of the scores is 0-100.

Several examples of the questions in the tool are presented below. The following three sample questions are based on the finding that successful systems engineers understand the whole system and see the big picture - see competency number 1 in the list of the cognitive competencies of successful systems engineers aforementioned in the CEST competency model section.

#### *Sample question No. 2*

224 Systems Engineering – Practice and Theory

However, it appears that a set of core competencies do in fact exist, necessary to all systems engineers, independent of their specific position. It is a matter of hierarchy. Every job level requires competencies suitable for the said level. The higher the systems engineering position in the organization/project hierarchy, the higher the level of required cognitive competencies, skill/ability and behavioural competencies, and broader knowledge needed.

 *A knowledge and skills test*. The present paper does not discuss the knowledge and skills test. Much work in this field has already been done by the International Council on Systems Engineering (INCOSE), the INCOSE Certification of Systems Engineers Exam working group. This exam is based on the INCOSE SE Handbook

 *Field tests*. In the field test the examinee will be asked to develop and present a functional flow block diagram that describes the functional (logical) and physical

 *Lab test*. In the future, the possibility of adding a lab test will be considered. In this lab test the capability for global processing by the right hemisphere will be tested (Evert &

As said earlier, the will/desire and the interest to be a systems engineer (to be involved in systems projects) mainly means the will and interest to deal with situations that require systems thinking. In addition, one of the seven behavioural competencies of a successful systems engineer is a will/desire to be a systems engineer (to be involved in systems projects) - see competency number 6 in the list of the seven behavioural competencies aforementioned in the CEST competency model section. These two findings lead to the conclusion that the will/desire to be involved in positions that require engineering systems thinking predicts success in systems engineering positions. This will/desire can be assessed by an interest inventory. As mentioned above, an interest inventory is a very common tool which is frequently used to help people choose a profession and as a selection tool in the

Usually, the items in interest inventories deal with preferences, specifically likes and dislikes regarding a diverse group of activities, jobs, professions or personality types. Likewise, the items included in the tool discussed in this chapter refer to ranges of likes and dislikes regarding systems engineering activities, various disciplines and knowledge required from systems engineers, systems engineering activities and types of people involved in projects. In its present version the tool consists of 40 pairs of statements. For each pair, the examinee has to choose between the two statements according to his/her preference. The examinee checks answer "A" if he/she prefers the first statement or answer "B" if he/she prefers the

Kmen, 2003). The field test and the lab test are not in the purview of this chapter.

The battery for assessing CEST in its final stages will comprise:

*Paper-and-pencil tests*. These tests will include three inventories:

architecture of a system that meets a given specification.

**7. The interest inventory for assessing CEST** 

*An interest inventory* - will be discussed in detail in Section 7 below**.**

*An aptitude test*. Please see several sample questions in Frank (2007).

**6. Assessing CEST** 

(INCOSE, 2006).

recruiting process (Anastazi, 1988**).** 


#### *Sample question No. 3*


#### *Sample question No. 4*


The following sample question is based on the finding that successful systems engineers understand systems without getting stuck on details - see competency number 6 in the list of the cognitive competencies of successful systems engineers aforementioned in the CEST competency model section.

#### *Sample question No. 6*


The following sample question is based on the finding that successful systems engineers understand interconnections - see competency number 2 in the list of the cognitive competencies of successful systems engineers aforementioned in the CEST competency model section.

#### *Sample question No. 11*


The following sample question is based on the finding that successful systems engineers possess interdisciplinary and multidisciplinary knowledge - see competency number 2 in the list of the competencies related to knowledge and experience aforementioned in the CEST competency model section.

#### *Sample question No. 17*


The following sample question is based on the finding that successful systems engineers are able to analyze and develop the needs and mission statement, and the goals and objectives of the system - see competency number 1 in the list of the abilities and skills of successful systems engineers aforementioned in the CEST competency model section.

#### *Sample question No. 22*


The following sample question is based on the finding that successful systems engineers are innovators, originators, promoters, initiators and curious - see competency number 12 in the list of the cognitive competencies of successful systems engineers aforementioned in the CEST competency model section.

#### *Sample question No. 39*


The following sample question is based on the finding that successful systems engineers possess management skills - see competency number 3 in the list of the behavioural competencies of successful systems engineers aforementioned in the CEST competency model section.

#### *Sample question No. 30*


#### **8. Validity of the interest inventory**

Four types of validity have been checked in a series of studies (Frank, 2010) - content validity, contrasted groups validity, concurrent validity and construct validity.

#### *Content Validity*

The proposed tool was developed and the content validity was achieved by basing the items of the interest inventory discussed here on a literature review including the INCOSE SE Handbook Version 3 (INCOSE, 2006), laws of the fifth discipline and systems archetypes (Senge, 1994), systems thinking principles (Kim, 1994; Waring, 1996; O'Connor and McDermott, 1997; Sage, 1992), some principles of systems dynamics (Sweeney and Sterman, 2000; Ossimitz, 2002), the seven 'thinking skills' of systems thinking (Richmond, 2000) and on the findings of a Ph.D. study presented in Frank (2002).

#### *Contrasted Groups Validity*

226 Systems Engineering – Practice and Theory

The following sample question is based on the finding that successful systems engineers possess interdisciplinary and multidisciplinary knowledge - see competency number 2 in the list of the competencies related to knowledge and experience aforementioned in the



The following sample question is based on the finding that successful systems engineers are able to analyze and develop the needs and mission statement, and the goals and objectives of the system - see competency number 1 in the list of the abilities and skills of successful

The following sample question is based on the finding that successful systems engineers are innovators, originators, promoters, initiators and curious - see competency number 12 in the list of the cognitive competencies of successful systems engineers aforementioned in the

The following sample question is based on the finding that successful systems engineers possess management skills - see competency number 3 in the list of the behavioural competencies of successful systems engineers aforementioned in the CEST competency

Four types of validity have been checked in a series of studies (Frank, 2010) - content

The proposed tool was developed and the content validity was achieved by basing the items of the interest inventory discussed here on a literature review including the INCOSE SE Handbook Version 3 (INCOSE, 2006), laws of the fifth discipline and systems archetypes (Senge, 1994), systems thinking principles (Kim, 1994; Waring, 1996; O'Connor and

fields may lead to sciolism (to know a little about many subjects).

systems engineers aforementioned in the CEST competency model section.




validity, contrasted groups validity, concurrent validity and construct validity.



**8. Validity of the interest inventory** 

CEST competency model section.

knowledge in several fields.

*Sample question No. 17* 

*Sample question No. 22* 

*Sample question No. 39* 

model section.

*Content Validity* 

*Sample question No. 30* 

CEST competency model section.

This type of validity is determined by comparing the grades of two contrasted groups. In one study it was found that systems engineers achieved significantly higher scores, as compared to other engineers. In another study the contrasted group validity was checked by comparing the tool's CEST scores of four groups - senior Electrical Engineering students, senior Technology Management students, systems engineers and other engineers. Statistical analyses revealed that: (1) the systems engineers achieved significantly higher scores than the other engineers, (2) the systems engineers achieved significantly higher scores than the Technology Management students and the Electrical Engineering students, while (3) the senior Technology/Engineering Management students achieved significantly higher scores as compared to the senior Electrical Engineering students. This result is not surprising because Technology/Engineering Management students are trained to look at problems holistically.

#### *Concurrent Validity*

This type of validity is the correlation between the scores obtained by two assessment tools. In one study, the concurrent validity was checked by calculating the correlation between the participants' scores using the proposed tool and the appraisal of their supervisor. It was found that the Pearson Correlation Coefficient was close to 0.4 (p<0.05). This result is very similar to the predictive validity of other selection tools. In another study the concurrent validity was checked by calculating the correlation between systems engineers' scores using the tool and the appraisal of their supervisor. The supervisor had been familiar with the participants' systems thinking capabilities for many years. The subjective assessments were all made by the same senior supervisor to decrease bias. It was found that the Pearson Correlation Coefficient between the participants' scores and the supervisor assessments was 0.496 (p<0.05).

#### *Construct Validity*

Construct validity indicates the extent to which the tool measures a theoretical construct or characteristic (Anastasi, 1988). The construct validity was checked by factor analysis. The analysis revealed five factors that may be labelled as follows: seeing the big picture, implementing managerial considerations, using interdisciplinary knowledge for conceptualizing the solution, analyzing the needs/requirements and being a systems thinker. These results are compatible with the factors found in an earlier study (Frank, 2006).

#### **9. Some possible implementations of the assessment tool**

Every enterprise strives to fill positions in the organization with employees who have the best chance to succeed. Employees are also interested in entering positions that fulfil their aspirations. Selection and screening processes can help match the interests of both parties, thus contributing both to the organization and the individual.

Many studies show that individuals do not behave and function in the same way in every organizational environment. The meeting point between the characteristics of an individual and the specific environment of his/her workplace often determines the quality of the functioning of the individual. Hence, the goal of the selection process is to help find the optimal meeting point and match the right employee to the right job within an organization.

The selection process for systems engineering positions should reliably predict those employees who can succeed and reject those who are likely to fail. Out of the employees who can succeed as systems engineers, it is necessary to choose those who have the highest chance of succeeding. Since no selection process is perfect, two types of errors are possible choosing candidates that fail after they have been placed and rejecting candidates who might have succeeded. These errors have an influence on both the organization and the individual.

From the organization's point of view, rejection of candidates who might have succeeded in systems engineering positions can be critical, especially under conditions of an everincreasing shortage of systems engineers. Likewise, placing engineers who later fail in systems engineering positions is also an expensive error, taking into consideration the necessary training which will be invested and the subsequent damage which might be caused to the projects in which they are involved. The tool presented in this chapter may be used for selection, filtering, screening of candidates for systems engineering job positions and for placing the 'right person to the right job'.

#### **10. References**


Many studies show that individuals do not behave and function in the same way in every organizational environment. The meeting point between the characteristics of an individual and the specific environment of his/her workplace often determines the quality of the functioning of the individual. Hence, the goal of the selection process is to help find the optimal meeting point and match the right employee to the right job within

The selection process for systems engineering positions should reliably predict those employees who can succeed and reject those who are likely to fail. Out of the employees who can succeed as systems engineers, it is necessary to choose those who have the highest chance of succeeding. Since no selection process is perfect, two types of errors are possible choosing candidates that fail after they have been placed and rejecting candidates who might have succeeded. These errors have an influence on both the organization and the

From the organization's point of view, rejection of candidates who might have succeeded in systems engineering positions can be critical, especially under conditions of an everincreasing shortage of systems engineers. Likewise, placing engineers who later fail in systems engineering positions is also an expensive error, taking into consideration the necessary training which will be invested and the subsequent damage which might be caused to the projects in which they are involved. The tool presented in this chapter may be used for selection, filtering, screening of candidates for systems engineering job positions

Beasley, R., & Partridge, R. (2011). The three T's of systems engineering - trading, tailoring

Evert, D.L., & Kmen, M. (2003). Hemispheric asymmetries for global and local processing

Frank, M. (2000). Engineering systems thinking and systems thinking. *INCOSE Journal of* 

Frank, M. (2002). Characteristics of engineering systems thinking - A 3-D approach for

Frank, M. (2006). Knowledge, abilities, cognitive characteristics and behavioral competences

Frank, M. (2007). Toward a quantitative tool for assessing the capacity for engineering

*INCOSE Journal of Systems Engineering,* vol. 9, no. 2, pp. 91-103.

and thinking. Paper presented at the 21st Annual Symposium of the International Council on Systems Engineering (INCOSE). Denver, CO, USA. June 20-23, 2011. Davidz, H.L., & Nightingale, D.J. (2008). Enabling systems thinking to accelerate the

development of senior systems engineers. *INCOSE Journal of Systems Engineering*,

as a function of stimulus exposure duration. *Brain Cognition,* vol. 51, no. 1, pp. 42-

curriculum content. *IEEE Transaction on System, Man, and Cybernetics*, vol. 32, no. 3,

of engineers with high Capacity for Engineering Systems Thinking (CEST).

systems thinking. *International Journal of Human Resources Development and* 

an organization.

individual.

**10. References** 

115.

and for placing the 'right person to the right job'.

vol. 11, no. 1, pp. 1-14.

Part C, pp. 203-214.

*Systems Engineering,* vol. 3, no. 3, pp. 163-168.

*Management,* vol. 7, no. 3/4, pp. 240-253.


http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/38979/1/05-3271.pdf


Waring, A. (1996). *Practical systems thinking*. Boston, MA: Thomson Business Press. Woolfolk, A. (2011). *Educational psychology* (3rd ed.). Boston, MA: Allyn & Bacon.
