Preface
This book was written to update systems engineering for the 21st century. It fills some of the gaps in the existing literature. For example, when I was teaching systems engineering to master’s degree students, I often heard myself saying, ‘and you won’t find that in the textbooks’. This book:
1. Is written to provide that missing information as well as the standard systems engineering knowledge.
2. Will change the way you think for the better.
3. Will challenge your underlying assumptions.
4. Teaches the systems approach, integrating tools and techniques currently used as well as introducing new tested tools and techniques and explaining how to apply them together with current tools and techniques.
5. Contains a mixture of theory and reports on how the theory worked in practice and where and when it was modified.
6. Discusses the perennial problem of poor requirements, defines the grammar and structure of a requirement, provides a template for a good imperative instruction statement and the requirements for writing requirements.
7. Provides examples of bad and questionable requirements and explains the reasons why they are bad and questionable.
8. Explains how to apply systems thinking to improve your systems engineering.
9. Introduces new concepts such as direct and indirect stakeholders and the Shmemp!
10. Challenges the status quo in the current mainstream systems engineering paradigm and suggests ways to improve parts of systems engineering. After reading and inwardly digesting the contents of this book and practising what you learn, you will be a better and more successful systems engineer.
1 Introduction
Twenty-first-century civilization increasingly depends on complex socio-technical systems that are difficult to acquire and maintain in a cost-effective and timely manner. There is a growing perception around the world that systems engineering is the best way to tackle this problem and this situation has caused an unprecedented demand for system engineers, which has in turn caused a demand for training and education to create these system engineers. The problem posed this demand may be framed using the problem formulation template (Section 3.7.1) as follows:
1. The undesirable situation: after almost 70 years, systems engineering is still demonstrating the characteristics of a discipline in its early stages, namely it contains defects, myths, and debates in which the participants speak but do not listen.
2. The assumptions: (1) such disciplines do not begin to fulfil their promises until they develop fundamental principles or frameworks that allow the knowledge to be organized in a useful manner. (2) So as long as systems engineering remains in this situation, useful knowledge published in conferences, symposia and journals will continue to fail to migrate from the publications into practice because there is no framework in which to anchor the new knowledge and begin to build the basic discipline knowledge.
3. The feasible future conceptual desirable situation (FCFDS): the outcome is a framework, or perhaps more than one framework, so that these debates and rediscovery activities can stop and the discipline can move forward and deliver its promise of managing the development and operation of complex systems (Jenkins 1969).
4. The problem: was to define and develop one or more frameworks that can be used to anchor the knowledge.
5. The solution: was a program of research to examine systems engineering from different perspectives and sort the findings into the descriptive holistic thinking perspectives (HTP) (Section 1.6.4) to develop the product; one or more frameworks which can be used to anchor the knowledge.
The initial research showed that there seemed to be no unique body of knowledge to systems engineering and that all of the activities performed by system engineers, apart from possibly requirements and interface management, were also performed by other types of engineers (Kasser 1996). The paper concluded with, ‘systems engineering is a discipline created to compensate for the lack of strategic technical knowledge and experience by middle and project managers in organizations functioning according to Taylor’s Principles of Scientific Management’. In addition, the literature on systems engineering seemed to be confusing and contradictory, so instead of answering questions it raised even more questions. The original and additional questions included (Kasser 2015):
1. What is systems engineering?
2. Why are there different opinions on the nature of systems engineering?
3. Why does systems engineering succeed at times?
4. Why does systems engineering fail at other times?
5. Why does systems engineering seem to overlap project management and problem-solving?
6. Why do the textbooks about systems engineering cover such different topics?
7. What do system engineers actually do in the workplace?
8. Is systems engineering an undergraduate course or a postgraduate course?
9. Which come first, functions or requirements?
10. Why is there no standard definition of a system?
11. How to accelerate teaching systems engineering?
It took more than 20 years of research to achieve satisfactory answers to all of the questions. The research which delved into systems engineering, systems engineering tools, operations research, process improvement, project management, innovation and systems engineering’s attempts to manage complexity produced a mass of semi-organized perceptions of, and insights about, systems engineering. These were published in a number of peer-reviewed publications from 1995 to 2015; the 1995 to 2007 papers were updated and published as an anthology in 2007 (Kasser 2007) and the second edition, published in 2013, added updated papers published between 1995 to 2013 (Kasser 2013).
Trying to making sense of the different views of systems engineering in the literature and unify them is a complex well-structured problem. When faced with a problem it is always useful to use the copycat systems thinking approach and find out if anyone has faced the same or a similar problem and understand their approach to remedy their problem (Kasser 2018: Section 11.5). One example was Mendeleev, who when faced with the problem of making sense of the relationships between chemical elements and their properties, sorted the elements into a table. His contribution was to create a framework, the periodic table of elements, and populate it with the known elements, leaving gaps which represented unknown elements.
Using a similar approach to Mendeleev, the perceptions of systems engineering from the research were extracted from the publications, sorted and grouped into the HTPs (Section 1.6.4). These perceptions are summarized in Chapter 2. The conceptual thinking tools used in systems engineering and project management were condensed and published in a desktop reference (Kasser 2018). The systemic and systematic uses of many of those tools in project management was published (Kasser 2019). This book discusses the systemic and systematic uses of many of the tools in systems engineering.