This guide was originally produced in 1990/91 by John Boarder, Derek Hitchins and Patrick Moore. John, a software expert, Patrick, an engineer businessman, and Derek, an engineering management professor, formed a subcommittee within the IEE’s systems engineering executive committee.
Over a period of nearly a year, they managed to boil their understanding of systems engineering down to its essence, which they put into the guide that follows.
They identified that systems engineering was invariably about two systems – a creating system, and a created system. The created system was the one to be delivered to some customer and user. The creating system was the one that existed inside the organization or enterprise, and it was this creating system that delivered the goods on time and within budget, i.e., made a profit for the business – or not.
This was, and is, an insightful observation. According to where we may live, work and operate in some organization or culture, we might call the creating system a project, or a business, or even a lean volume supply system, while the created systems might be ships, aircraft, motor vehicles, white goods, brown goods, etc. It really doesn’t matter. There is always a creating system and a created system. And they are always matched and balanced if they are to interoperate successfully.
And the Guide? Well, it was never officially published. The upper echelons of the Institute of Electrical Engineers saw fit to suppress it. Allegedly, one John Parnaby declared that his systems engineering company did not operate according to anything like this guide or code of practice, therefore the Guide was invalid.
So much for progress. The IEE went from being in the vanguard of UK systems engineering to being, well, not in front, almost overnight. I have no reports on John Parnaby’s company...
Derek Hitchins 2005Guide to the Practice of Systems Engineering
Glossary of Terms
Closed. Unable to interchange with any other system. Complementary system. A system with inflows and outflows corresponding to the outflows and inflows of an SOI, respectively.
Contained. A system within a system. Container/containing. A system containing systems within itself.
Emergent property. A property of a system as a whole which cannot be completely at- tributed to any particular part of that system.
Entropy. The degree of disorder in a system or set of systems. Environment. That which mediates the interchange between systems. Total environment is the sum of all such mediations. Function. A system activity or set of activities which cannot be wholly undertaken by any one part of the system. Hard. Clearly defined or definable and with evident purpose. Hierarchy. The levels of organization epitomized by contained and containing systems. Hierarchy is perceived through emergence; interacting systems which display emergent properties as a set are contained. Homeostasis. Maintenance of the status quo. The provision of an environment within a system suitable for the function of its contained systems. The ability of a system to maintain a stable internal environment although the external environment may change.
Method. A set of techniques linked through a process to achieve some purpose. Mundane. Of an emergent property, that it may be accrued by progressive summation e.g. all-up weight is an emergent property, but its origin is evident, hence mundane.
Open. Interchanging or free to interchange with other systems. Parent. Containing system Prime Directive. Ultimate statement of purpose. Process. A set of sequenced activities to achieve some purpose Semantic Analysis. Detailed expansion of the Prime Directive to elucidate full meaning Sibling. System interacting with an SOI within a container
SIF. System in Focus. (syn. SOI) Soft. Complex, poorly defined, and without clear singular purpose. SOI. System-of-Interest. The system currently under scrutiny. Synergy. Co-operation between system parts. Control and co-ordination within a system to produce some external effect. System. A collection of interrelated entities such that both the collection and the interrela- tionships together reduce local entropy. Viability. A system state compatible with continued existence in changing environment.
Guide to the Practice of Systems Engineering
Aim, Objectives and Activities of Systems Engineering —Guide to Proper Practice
There is one overriding aim of systems engineering :
To establish and deliver an application system with the emergent properties and through life support facilities required by the customer and satisfying the end-user needs.
The following objectives together satisfy the aim :
A. Create, in a structured, ordered manner, an application system with the emergent properties required by the customer
B. Create and maintain an engineering system to enable the creation and provision of life cycle support for the application system
C. Create and maintain harmony and balance between the developing sub- systems of both the application system and the engineering system such that the intended emergent properties of the application system are realized and their divergence from required values is minimized though life.
The following table presents the guide, with the left hand column providing an activity number, and the right hand column presenting the activities necessary to achieve the objectives. Together, these entries provide the essential systems engineering guide.
Activity number Systems Engineering Activity
A1 Understand the customer's requirement and the users needs, operational domain, doctrine and environment
A2 • Model the application system in its future environment, including representation of other interacting systems
• Adjust the application system model to exhibit the emergent properties required by customers and users
• Adjust the application system model to minimize the effect of undesirable emergent properties
A3 Specify the required emergent properties of the application system
A4 Design an overall application system to meet the requirement
A5 • Model different application system partitioning schemes to identify sub-systems
which will benefit sub-system design, development, manufacture, integration, installation, operation,
support and eventual replacement
• Select a preferred partitioning scheme that exhibits the requisite emergent properties of the application system
A6 Specify all emergent properties of the preferred application system's sub- systems, interconnections and intra-connections.
B1 Identify and specify the emergent properties of through-life (life cycle) support systems required by
the customer/user, including management, logistics, maintenance and training systems
B2 Understand the capabilities, constraints and environment of such support application systems
B3 Design/create such systems as application systems
B4 • Identify those features of the future application system which direct or constrain the needs of the engineering system
• Model the engineering system in its future environment, representing other interacting systems
• Adjust the engineering system model to exhibit the emergent properties required by the creating organization and by its project engineers
• Adjust the engineering system model to minimize the effect of undesirable emergent properties
B5 Specify the requisite engineering system emergent properties B6 Identify:
• The capabilities of the project engineers, their tools, methods and techniques to create the engineering system
• The constraints imposed by the creating organization, including fi- nance, location and resources
B7 Design an overall engineering system within identified capabilities and constraints
B8 • Model different engineering system partitioning schemes to identify sub-systems which will facilitate sub-system design,
development, manufacture, integration, installation, operation, support and eventual replacement
• Select a preferred engineering system design partitioning scheme that exhibits the requisite emergent properties
B9 Specify all emergent properties of the preferred engineering system's sub-systems, interconnections and intra-connections.
C1 • Record all features of the developing application and engineering systems, their sub-systems, mutual
interactions, configurations, intra-connections and interconnections
• Establish and maintain standards for interfaces, compatibility, communications and data exchanges between
sub-systems of the application system and other systems with which it will interact in its containing system
• exchanges between sub- systems of the engineering system and other systems with which it will interact in the creating organization
C2 Record decisions, changes to requirement and specifications, and the cir- cumstances, environment,
contemporary knowledge and bases in which they were made
C3 Re-partition and re-specify sub-systems to accommodate unavoidable deviations which would otherwise result
in unacceptable changes in application system emergent properties
C4 • Monitor divergence between the application system’s operating parameters and its design criteria
• Design to minimize such divergence within the constraints of the Containing system
C5 Anticipate the need for replacement application systems or sub-systems