A, Go Steddar

I must create a System, or-be enslav’d by another Man’s William Blake 1 757-1 82 7

ystems have been around from time immemorial and the above quotation typifies today’s dilemma. New systems are needed all the time S to stop competitors gaining some form of

advantage but where do these systems come from? Given that these systems are needed, how and by whom are they designed? The term ‘systems engineer’ is appropriate to introduce at this very early stage as the person ultimately responsible for these functions. What precisely is ‘systems engineering’ and how do we determine who is a systems engineer? Indeed is there yet a separate discipline of systems engineering? These are questions that the engineering profession has yet to tackle.

The engineering profession, for historical reasons, has become structured into traditional disciplines. The result has been that individual professional Institutions rarely accept, as members, those whose qualifications are not ‘in line’ with their specific discipline. Time and time again as engineers mature, during their career, the span of coverage of disciplines increases beyond their original educational bounds. This increase is often coupled with a lessening of current total understanding of their own original discipline. By familiarity and practice are these engineers becoming

their capability? There are many scenarios that can be examined to answer these questions. Behind these questions is the search for the base knowledge for a systems engineer. This article attempts to establish this base knowledge by taking as a scenario: ‘systems engineers work on multi-disciplinary projects ’.

So far I have used the terms ‘system’, ‘engineer(ing)’, and ‘project’ without defining them. This article attempts definitions in such a way that the knowledge and understanding required of a systems engineer can be defined. The structure of this article is to look first at what is a system and pose the answer in a pragmatic way.

systems engineers? Do they possess the knowledge to partition systems into their correct constituent parts? Do they know enough about each discipline, needed in a project, to call in an expert at the right time? These are questions that have been answered by industry in an ad hoc manner but as yet not by the profession.

Where and on what does a systems engineer work? Who would employ them? Why should they be employed? If an engineer only had a systems engineer- ing label would a prospective employer understand

Then to examine what is meant by a project in terms of definable boundaries, and next to look at what is an engineer. In each of these sections points will be highlighted that assist in defining the role of a systems engineer. Finally the article will draw the conclusions together to develop the knowledge and understanding required of a systems engineer.

sysu@ms There are, however, a number of

misconceptions that must be dispelled before starting on any definition. One of these is that all systems are based on computers and that systems engin- eering is closely allied to software

engineering. This view is frequently enhanced by the published papers that rarely attempt to qualify the definition of a system with adjectives to narrow the scope of the system being covered. An initiative by the Institution of Electrical Engineers’ called the Computer Systems Professional Initiative is an exception to this general practice. Indeed the ‘computing’ profession is often guilty of this practice itself by using terms such as systems engineer when more accurate but unfortunately longer terms are more appropriate. In order to be totally

COMPUTING & CONTROL ENGWEERING JOURNAL JUNE 1999 A

‘\ SESTEMS ENGINEERING //

clear, the scope that I adopt for a system is: that any technology can and often does contribute to systems and that a system can be made from one technology but more often than not a range of technologies is used.

There are many ways of looking at a system and attempting to define what it can be, but first let us examine standard texts typified by dictionarie~~.~ and

These yield the following:

0 System:

0 Complex:

0 Thing:

0 Parts: Portion allotted. 0 Connected: Joined in sequence, coherent. 0 Object:

A set of things considered as a connected whole, or complex thing or parts. Consisting of parts, composite, complicated. Whatever is or may be an object of thought.

Person or thing to which action or feeling is directed.

Thus virtually any object can be thought of as being a system whether it has some action or not but it must be able to be conceived as a whole entity by an observer. Unfortunately the above definition would allow objects, such as a flower vase, tea cup etc., to be a system. Normally these objects would not be classified by engineers as systems but more as artefacts as they consume no input nor do they produce output except on the esoteric level. In most cases, however, there is an engineering process employed in the design and fabrication of the artefact. Traditionally artefacts of this

output; examples such as railway buffers, coastal defence etc. can be shown to be energy absorption systems, but the number of outputs for certain models can be considered to be zero. This arrangement can be as shown in Fig. 1.

This system operates inside a world or environment and all interactions are solely with that world; it is the scope of this world that helps to define the model to be used. Kaposi and Pyle7 propounded a theory of system and models with Kaposi and Myers8 expanding that theory. This work has been followed by a first level tutorial book on systems theory by Myers and K a p o ~ i . ~ This work provides some insight into the role of a systems engineer. The concept starts with a referent system observed in its environment and goes on to expand the referent into a series of elements or parts (Fig. 2).

This system is made up from an ordered pair:

where E = {el,ez,. . .efl] is a set of elements*

Re = {rm,rm,. . .rEm} is a set of relations on the elements

I

Fig. 1 A system

type have been the product of ‘Guild Craftsmen’ who work in specific materials to produce works of art rather than functioning objects. These considerations lead me to a basic level definition for a system, as follows:

0 A system can be a product, process or service that

0 Systems engineering is an engineering process used to converts a set of inputs into a set of outputs.

produce a system.

Thus the system must have a function that needs to be specified and it must have inputs (0 to n) and outputs (0 to m) defined. A system in reality can never have zero inputs, but depending on the model used there can be situations where to all intents and purposes there can be no input. An example is an oscillator where the inputs are: power, temperature; electrostatic interference etc. However, if the required oscillator is not materially affected by these inputs it can be considered from a modelling viewpoint to have zero inputs. Similarly for the zero output case systems can be derived that have no

of E

Each of these elements may be a complete subsystem in its own right and as such could be treated as a new system. These elements are or can be considered to be an independent model of the system that assumes certain characteristics of the original referent system. The choice of these elements,

ensuring that all the necessary aspects of the system have been covered, is surely a role for the systems engineer in conjunction with each technologist.

A prime factor in choosing the set of elements (models) is that each element must be bounded by a clear statement of what it must do. In other words the ability to write an element specification that can be tested must be possible. Thus there are two roles for the systems engineer that can be stated

0 The ability to decompose systems into a series of

0 The ability to write technical specifications in subsystems.

conjunction with a technologist.

A further expansion of the Kaposi concept is explored in Fig. 3, where the system, element, part or subsystem has a series of models with each model measuring or

*There may be an infinite set of elements in even the simplest of systems.

A COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1999

examining certain critical features. An interpretation of this model for systems theory is

that the referent can be examined by a number of models and that each model will have its own set of measures to check that it conforms to that part of the referent’s specification. Each model will explore a different set of features and thus needs its own measures. From the systems engineering viewpoint the system being defined would be broken into a series of elements with each being modelled and explored in the technology domain of that model.

The basic concept is that each element must be specifiable in such a way that meaningful measurements can be made. A further test of each model is that if a specification, that is meaningful, cannot be written then either:

0 The model has not been decomposed sufficiently. or 0 The features with the chosen technology cannot be

measured.

If the second case arises, either the wrong technology has been chosen or research and development is needed to explore the feature further. This gives rise to the risk element of the new development. Thus a further task of the systems engineer is added

0 The ability to assess the risk to aproject by the inability of the technology to meet the specification.

EngineerKing3 What is an engineer? There are many interpretations

of this question none of which really moves the debate forward in terms of a systems engineer. However, the dictionaries provide some clues:

e Engineer: Someone who designs or makes or puts to practical use, engines and machinery of any type.

To indicate, draw, plan, contrive, invent and execute. To fashion, frame, construct, compose or form, create, produce etc. A mechanical contrivance, complex piece of machinery in which power is applied to do work; anything used to effect a purpose.

0 Engineering: The art or profession of an engineer. 0 Design:

0 Make:

e Engine:

From all the above the scope of an engineer is very wide. The design and manufacture of any artefact can be classified as an engineer’s remit. The profession is so complex that it has become necessary to have specialists in one field of technology, i.e. electrical, mechanical, civil, marine, software etc. In order to become a Chartered Engineer it is essential to gain a degree in the specific

system environment

Fig. 2 Referent expanded into its elements or parts

field of interest and then to work in a responsible position for a number of years before gaining Member status of an Institution. During this process the engineer learns how to design systems in a chosen field, but the essential ingredients for the design of complex multi-discipline systems have not necessarily been learnt. The engineers produced by this process are, there is no doubt, systems engineers but they are by training and experience in only one specialism.

Bearing in mind the wide remit of an engineer how is this wide knowledge gained? Is it by experience or could it be taught? If it can be taught, where does one start? What is the base understanding expected from a systems engineer? An accredited Bachelor degree has, by custom and practice, meant that at least 66% of the taught material is pertinent to the discipline required for that Institution, thus leaving 33% for non-technical subjects, such as management, team skills, languages etc. If it were necessary to teach other disciplines as well, the complexity of the course would become impossibly vast for an undergraduate to undertake.

Thus, is the only way to teach systems engineering to first obtain a Bachelor degree, specialising in one discipline? This could then be followed by a Masters

referent model n measures

Fig. 3 Expansion of a system into measured models

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1999

&STEMS ENGINEERING //

course where the technical depth required for systems engineering could be added whilst at the same time adding a further understanding of other disciplines coupled with a cross-disciplinary project,1° thus producing a specially designed Masters degree which provides the extra depth and breadth over a Bachelors degree to be classified as a true Masters as defined in SARTOR. Unfortunately there is no definition of what depth means whereas breadth is relatively easy to add into any course. In a single discipline depth and breadth can be added providing the university research is there to back the specialism. The problem with the systems engineering domain is there would be no original discipline at undergraduate level; the entrants to the course could come from any engineering domain. If a base degree was proclaimed as essential then the systems nature of the course would be modified to become domain specific. Given a truly diverse entrant cadre the unifying content must be systems theory, development and design:"

0 Core subjects that matter in a systems engineering coume must be systems theory, design and develop- ment.

PU@J@GUS In what way does a system compare with a project?

Indeed is there any relationship at all. Perhaps the relationship is as follows:

0 A new system is the product of a project.

This statement is true whether the project is one singleton entity or a series of interlinking perhaps hierarchical projects. Unfortunately this does not help us to define what a project is so that its boundaries can be delineated.

How would an outside observer identify a project? What would they be looking for? Are there clear attributes such that a project can be defined as a single entity? The parameters that are often used to define projects in an industrial context are that the project must have:

0 a specification that controls the attributes of the

0 acontract 0 agreed costs, especially in man hours 0 agreed timescales.

system to be produced

*The educational system used in the USAwhere an initial degree is awarded with major and minor components could be a more attractive solution or the process used in some UK universities where the faculties of engineering have been merged and unified courses are taught. Unfortunately few, if any, of these courses teach systems theory or systems design according to the tenets of this article.

One of the immediate straws to clutch is that of cost or man hours, in other words size. The main question then becomes: are there any boundary conditions on size that define a project either small or large? Unfortunately size does not seem to be a good differentiator as examples can be quoted of very small to extremely large projects.

Take as an example the Channel Tunnel. This was definitely a project, dreamed of in Napoleonic days and finally brought to completion in 1995 by the contractors for the Tunnel Consortium. It was a very complex project predominantly one of civil engineering but containing many complex facets of other disciplines, e.g. electronics and software for the signalling, railway engineering for the transportation, mechanical etc. All these disci- plines played their part in the ultimate completion of the project. A significant part of the overall project was handled by subcontracting parts of the project to others. The Channel Tunnel, however, can clearly be labelled as a project. This single example shows that there is no upper limit on the definition of a project in terms of budget, time or man hours.

There are also numerous examples of small projects that can also clearly be labelled as projects, e.g. the design of a new multimeter, a contracted out item of work from a larger project, the design of a plastic drinking beaker etc. The list of small projects is boundless. The important concern with size is the viewpoint of the person attempt- ing to establish the project. At the small end a project covering a few weeks of work is important to a small company but would not even be classified as a project because of the overheads by a larger concern, whereas a project of note to a large company could completely outrun the resources of a smaller company. Thus size does not seem to be a very good basic indicator of the definition for a project.

The most important aspect from the above is the ability to write a specification for the work that needs to be completed. No matter the size there is always a need to be clear in what is to be achieved. This is as true for a research project as for development. Obviously the nearer to pure research the harder it is to specify what is to be achieved, but it must be possible to write a statement about what work is to be undertaken with codicils for changes if the direction of the research changes. Thus with all sizes of project there is an obligation on the part of the supplier to accept a contract to meet the specification, whether in a real or a virtual sense.

From the above discussion the clear factor that emerges is that contracting is used at all sizes of the project spectrum. The contract will specify what work needs to be done, when by, for how much and to what standard of quality. Thus from the four factors mentioned above the presence of some form of contract seems to be the only true definable boundary for a project.

Exploring this concept further, what does a contract encompass that helps to delineate these boundaries? First the contract will need to refer to a requirements

A COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1999

specification+ issued by the contractor and agreed by the supplier. This requirements specification will list the required attributes of the system without restricting how the system is to be designed. There are, however, certain occasions where an already existing system will control what can or cannot be done by the new system. The currently existing environment is already set by existing systems. Indeed it is rare that a totally green field situation arises in today’s world. Generally the require- ments specification is issued to the supplier with a document called an ‘intent to purchase’ (ITP). This ITP details intent of the company towards the contractors and future development of the system.

The supplier will respond with a quotation for the work which could include, depending on the ITP, skills of the workforce, detailed breakdown of costs, manpower rates, work breakdown, capital equipment needed etc. This response and the specification will form the basis of a legally binding contract between the contractor and the eventual supplier. In large organisations there are normally many different departments involved in a contract. The prime two are: a contracts department that handles the legal aspects and a development department to handle the technical aspects. Frequently the technical and legal in the same organisation are at loggerheads over the restrictions and clauses before the opposing party has even seen the documentation. All too frequently this is because neither side understands the problems of the other and unfortunately does not have the time to find out. A role for the systems engineer is to act as a moderator able to understand both sides of the debate and help to resolve difficulties. This role will continue into the contract letting and running with the supplier, thus a new role is added

9 To be able to understand national and international legal terms, arguments and debates.

Systems development A system, being a complex whole, possesses many

attributes that change as the life of the system develops. Life starts with conception, continues through birth into adolescence, maturity, obsolesence, until death. All of these stages are in themselves complex processes and each could be the subject of a contract to progress from one stage to the next. Each stage can be considered to be a phase* in the life of a system.

+To avoid confusion I use the words requirements specification as a specific form of a specification. Other types of specifications are: design, test, architectural etc. Each has a specific role and delineates an activity within the contract.

*I have deliberately chosen a set of names to describe the phases of the life of a system that are dissimilar to those used in software engineering. This is an attempt to avoid confusion with software engineering, a discipline that has done more than most to define lifecycles of ‘systems’.

Any system must be conceived. There must be a starting point. This point may be the result of research, marketing or business needs. The common feature is that the embryonic new system is to satisfy a new niche or need that was previously unsatisfied. The outcome of this phase would be a loose description of the capability of the new system, as yet unrefined without too much form and needing extensive development. Following the birth of the system the description could contain data on what the system has to do as well as how it may be achieved.

The birth of the system can be regarded as the very first prototype where the realisation of the system can be gauged in readiness for further development. Its functionality is limited and its features could be considered as being uncontrolled or undefined but it will have potential. An example of this birth style prototype was the ‘Flying Bedstead’” of the early 1950s. It was powered by two Rolls-Royce Nene engines for vertical and sideways movement. This was followed by the Short SC.1I2 that flew in 1957 powered by five RE3108 turbojet engines. Each of these prototypes demonstrated a different approach to vertical takeoff and manoeuvring. The final prototype was the Hawker Siddeley P112712 later known as the Kestral, which flew in 1960. The final prototype showed that a single jet engine could be used to provide not only vertical thrust but also horizontal movement. After many developments the production version emerged as the ‘Harrier Jump Jet’ of the 1980s. Even after initial production the aircraft underwent many changes for various roles and for various airforces.

Thus development of a system starts during con- ception and finishes a short while before death. At all phases of life development takes place, but as the system gets older its adaptability becomes less. Most of the dramatic developments take place in the initial years of life. Thus during these years the development is fast with new models appearing frequently but as the system matures and settles new models become more infrequent and sometimes no changes are instigated at all. In this case the system has become obsolete.

One of the essential features of the earliest development phase is to structure the system; normally once set this structure frequently becomes impossible to change due to prohibitive costs. This phase is frequently completed as part of some form of contract with the structure being the prime concern of the supplier. Partitioning the system into its constituent parts or sub- assemblies and deciding which technology should be used and where is a major role of the initial contract. If the ‘engineer’? achieves a non-optimum partitioned solution costs of development and operation will rise. Similarly choosing the wrong technical solution in a critical area

?Again I have avoided using titles that will cause confusion with software engineering as this may prejudice the case I am attempting to put forward.

A COMPUTING & CONTROL ENGINEERING JOURNAL 1999

could, at worst, cause complete failure of the project or at best escalation of costs. This ‘engineer’ must also be expert in the environment that surrounds the system, i.e. the environment that it operates within. Thus some of the skills of this ‘engineer’ from the supplier’s situation are becoming apparent; they must be knowledgeable in:

0 A range of disciplines to a sufficient level to choose the

0 The impact and eflect of the system on its environment. appropriate technology

Similarly, in the contractor’s case the ‘engineer’ employed needs to understand the decisions being made and how they will affect the environment of the new system. Thus a very similar set of requirements exists for the contractor as for the supplier.

It is also obvious that these two engineers will need to converse with each other and understand the impact their decisions will have on the business of the contractor. Thus further skills are defined in that they must under- stand:

0 team relationships 0 communication skills 0 business risk assessment.

siysuem aoesngm System design is that part of any development where

a new contract can be considered, either for a brand new system or for an extension to an already existing system. The new development would start with a statement of requirements, but how are these requirements to be derived? Requirements capture has become an important feature of software and information systems engineering and these disciplines have pioneered procedures that can be used to determine the best method of capturing requirements. These methods will not be discussed here except to mention Norris et all3

where an insight into requirements capture methods can be found. At present no single method appears to be the best, and it falls to the systems engineer to devise or adapt a process to suit their needs. It is, however, important to state at this point that the statement of requirements should, theoretically, contain no indication of how the system is to work. Practically, however, the existing environment may force some ‘how’ considerations to be incorporated.

During requirements capture it is essential that risk analysis is started to focus the minds of the managers and engineers onto the important problems. Risk analysis is the process whereby at any stage in the development the manager can assess the risks to the project completing on time, to budget, and at the appropriate quality. In essence the analysis becomes a checklist that continuously evolves during the development. The manager can then use this checklist to fine tune where their efforts should be put in. In other words it determines the manager’s,

and hence the development’s, immediate problems and priorities. It could be argued that to start risk analysis at requirements is too early, on the grounds that there is insufficient data to form opinions. Norris et all3 contradict this statement and state that risk analysis starts immediately, is a continuous operation, and finishes when the development concludes.

On completion of a requirements specification the systems engineer in conjunction with the technical experts can start the process of choosing the system solution in terms of technology and partitioning. This point has already been alluded to in the section on development and will not be further explored.

The final task of the systems engineer is to devise the testing methods and the suite of test scripts, either as final product integration tests or as customer acceptance tests.

Thus the systems engineer should be versed in the arts O f

0 requirements capture 0 risk analysis 0 test strategies.

SMoWnoOEil~ This article has attempted to define three principal

areas: firstly, what is a system, secondly, what is a project, and thirdly, what is an engineer. In the process salient points have been extracted that provide an insight into what knowledge a systems engineer must possess.

The result of the discussion of what constitutes a project rules out a number of areas that are normally considered as defining parameters, especially by industry; they are cost, time and whether the project is specifiable. The only area that stands a more rigorous examination is the ability to let a contract. This then leads to the necessity to have secondary level definitions of specification, budget and time in order to complete the contract letting process.

The examination of projects and systems reached the conclusion that:

0 a new system is the product of a project

and subsequently that systems engineering is:

0 an engineering process to produce a system.

The salient points extracted from the discussion when collected together show the depth of knowledge needed by a systems engineer and in summary they are:

Technical 0 The ability to decompose systems into a series of

subsystems. 0 The ability to assess the risk to a project by the

inability of the technology to meet the specification.

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1999

0 A range of disciplines to a sufficient level to choose the

The impact and effect of the system on its environ-

Test strategies. 0 At least one specialist discipline.

appropriate technology.

ment.

Managerial The ability to wr i te technical specifications in conjunc-

0 To be able to understand national and international

Team relationships. Communication skills. Business skills. Legal contract issues (possibly including international legal law on contracts). Requirements capture.

0 Risk analysis.

tion with a technologist.

legal terms, arguments and debates.

These statements, when collected together, could form the basis of a systems engineering syllabus which could be used as a matching section for a Bachelor degree, or part of a Masters Degree. The correct placement for the syllabus must, however, be at the discretion of the course

designer and only with a firm mission statement for the course can the place of the above areas be fully tested.

BBeBC?UC?UDCC?S 1 Computer Systems Professional Initiative, IEE 2 The Chambers Dictionary, Chambers 3 FOWLER, H. W.: The Concise Oxford Dictionary (Oxford at the

4 Mirriam Webster, Collegiate Dictionary, Tenth Edition 5 Encyclopaedia Britannia CD 6 Oxford Junior Encyclopaedia (Oxford) 7 KAPOSI, A., and PYLE, I.: ‘Systems are not only software’, Software

Engineering Journal, Jan. 1993,8, pp.31-39 8 KAPOSI, A., and MYERS ‘Systems models and measures’ (Springer-

Verlag, 1994) 9 MYERS and KAPOSI, A.: ‘A first systems book for technology and

management’ (Kaposi Associates, 1997) 10 STODDART, A.: ‘Definition of a master of engineering’, As yet

unpublished 11 GREEN, W., and CROSS, R.: ‘The jet aircraft of the world’ (Mac-

donald, London, 1955) 12 GREEN, W., and CROSS, R.: ‘The aircraft of the world’ (Macdonald,

London, 1965) 13 NORRIS, M., and RIGBY, P.: ‘Software engineering explained’ (Wiley,

1992) 14 CASSY, D. A.: ’Risk management for software project managers’,

Thesis for Engineering Diploma 1993, University of York, Dept. of Computer Science

Clarendon Press)

0 IEE 1999

Alan Stoddart may be contacted at ‘Marralomena’, Boyton, Woodbridge, Suffolk IP12 3LW, UK. He is an IEE Fellow.

Karen M. Gardner, Alexander Rush, Michael K. Crist, Robert Konitzer and Bobbin Teegarden, with foreword by James J. Odell Cambridge University Press

lSBN 0 52164 998 6 1998, 231pp., €22.95

Patterns may be defined as any reusable architecture that experi- ence has shown to solve a common problem in a particular context. Cognitive patterns, which is the subject of this book, are generic descriptions of how humans think in order to solve problems.

The book itself is divided into three sections. Part 1 serves as an excellent introduction to the world of cognitive patterns and objects. The second part is concerned with the practical side of object model development covering knowledge elicitation, mapping from cognitive patterns to a standard object modelling language and other uses of the work. The third part covers best

practice using cognitive models and provides a detailed case study of applying the work.

The work presented in the book is the output of almost ten years of EU- funded research and, as such, the background and theory of the work are very well detailed. The main aim of the book is to provide a set of templates that may be used as an aid for object- oriented design to improve efficiency and understandability. The ideas are backed up by frequent real-world examples and case studies which validate the results.

This book is clearly aimed at practising designers and provides a framework for allowing design work to be more rigorously defined. The cognitive patterns themselves de- scribe the thought processes involved in many everyday design tasks, such as: verification, correlation, predic- tions and design. The most valuable part of the book, for anyone wishing to apply cognitive patterns to their

design procedure, is the appendices that contain templates for 21 common cognitive patterns.

The book is let down slightly by a lack of continuity, with several chapters repeating definitions. Per- haps the weakest part of the book is the transition from the author’s own graphical representation of cognitive patterns to the UML (Unified Modelling Language). There is a lack of cohesion between the two representations with frequent mismatching of names, which gives the impression that this part of the book has been rather rushed. This is especially disappointing bearing in mind the excellent pedigrees of the authors in object-oriented analysis and design. However, these criticisms are really only slight and should not deter anyone from reading this book which, overall, is well written and concerns a very interesting and useful subject.

Dr. J. D. HOLT UNIVERSITY OF WALES, SWANSEA

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1999