This paper provides an overview of a number of research areas that include investigating the nature of systems engineering and its underlying concepts, defining the properties of object-oriented requirements, producing prototype object-oriented tools for systems engineering, and applying of systems engineering to various domains.

1. A Program of Research
into Systems Engineering
Joseph E. Kasser DSc CEng CM MIEE, Stephen C. Cook PhD
FIEE FIEAust
Systems Engineering and Evaluation Centre
University of South Australia
School of Electrical and Information Engineering
Mawson Lakes Campus, South Australia 5095
Telephone: +61 (08) 8302 3941, Fax: +61 (08) 8302 4723
Emails: Joseph.Kasser@unisa.edu.au, Stephen.Cook@unisa.edu.au
© University of South Australia, 2003 1

2. Topics
 The elements of a framework for the
engineering of complex systems;
 Object-oriented systems engineering;
 Research into prototype object-
oriented tools for systems
engineering;
 The application of systems
engineering to various domains.
© University of South Australia, 2003 2

3. Systems Engineering
 Academia is
teaching it
 Industry is
practicing it
 INCOSE is trying to
improve it
Tower of Systems
Engineering
© University of South Australia, 2003 3

4. Systems Engineering
 But nobody knows
what it is
 No agreed
definition
 Academic debate
about degrees in the
subject
Tower of Systems
Engineering
© University of South Australia, 2003 4

5. The 5-Layer Systems Engineering
Model
Socio-Economic  Government Regulation and Control.
Systems Engineering Economic, legal and political influences.
Industry System  National Wealth Creation, the Nation’s
Engineering Engine. (Japan operates at this level)
Business System  Industrial Wealth Creation. Many
Engineering Businesses make an industry
Project System  Corporate Wealth Creation. (The West
Engineering operates at this level.)
Product/sub-system  Technology Artefacts. To some the only
Engineering “real” systems engineering. Many Products
(can) make a system
Time Derek Hitchins, SETE 2000
© University of South Australia, 2003 5

6. ISO/IEC 15288 Road Map
Enterprise Processes Technical Processes
Project
Enterprise Environment Stakeholder Requirements
Management Process
Processes Definition Process
Project Planning Requirements Analysis Process
Investment Management Process
Process Architectural Design Process
Project Assessment
System Life Cycle Process
Management Process Implementation Process
Project Control
Resource Management Process Integration Process
Process
Decision
-making Verification Process
Process
Quality Management
Process Transition Process
Risk Management
Process
Validation Process
Configuration
Operation Process
Agreement Processes Management Process
Acquisition Process Maintenance Process
Information
Management Process
Supply Process Disposal Process
© University of South Australia, 2003 6

7. Elements for Area of Research
 The Area of Concern (A),
• which might be a particular problem in a discipline (area of
study), a real-world problem situation, or a system of interest.
 A particular linked Framework of Ideas (F) in which
the knowledge about the area of concern is expressed.
• includes current theories, bodies of knowledge, heuristics, etc
as documented in the literature as well as tacit knowledge.
 The Methodology (M) in which the framework is
embodied
• incorporates methods, tools, and techniques in a manner
appropriate to the discipline that uses them to investigate the
area of concern.
© University of South Australia, 2003 7

8. Relationships Between F,M&A
Elements relevant to any piece of research
(Checkland and Holwell, 1998: p 13).
© University of South Australia, 2003 8

9. Broad Areas of Concern
 A designed physical system
• (that also contains human components).
 A human activity system
• (engineering organisation).
 Each span many disciplines and require pluralistic approaches that
not only invoke multiple methodologies but ones that rest on quite
distinctly different frameworks of ideas.
 They are of fundamentally different types and hence will probably
have to be approached with different methodologies.
 As such we now understand why:
• Many systems engineers cannot clearly articulate the functions and
benefits of systems engineering (Kasser and Shoshany 2001).
• It has been extremely difficult to establish a systems engineering
body of knowledge (SEBOK) for the diverse activities that are
known by the term “systems engineering.” (Kasser and Massie,
2001).
© University of South Australia, 2003 9

10. Topics
 The elements of a framework for the
engineering of complex systems;
 Object-oriented systems engineering;
 Research into prototype object-
oriented tools for systems engineering;
 The application of systems
engineering to various domains.
© University of South Australia, 2003 10

11. Object-Oriented SE has a Gap
Concept of
operations
(Use Cases)
Systems (objects)
Object-oriented Object-oriented
software hardware
© University of South Australia, 2003 11

12. What is a Requirement?
 It is a means of communication
 It is a representation of a need
• Traditionally text based
 Requirements are crucial to
delivering the right system and
producing it in the most effective
manner (optimal costs)
© University of South Australia, 2003 12

13. What is a Good Requirement?
 Describes something (“what”) about
the system to be implemented
• Product dimension
 Facilitates the process of implementing
the system
• Process dimension
 It’s a real requirement
• Well-written but useless
© University of South Australia, 2003 13

14. RequirementTest
The RealDesign
Requirement
Acceptance
criteria
(property of a requirement)
© University of South Australia, 2003 14

15. Research Questions
 Can an object-oriented approach provide
traceability from the highest level need
statement to the lowest level of
implementation?
 Can a conversion to object-oriented
requirements bypass or resolve today’s
problem of poor requirements?
 What are the properties of object-
oriented requirements?
• Product dimension
• Process dimension
© University of South Australia, 2003 15

16. Topics
 The elements of a framework for the engineering
of complex systems;
 Object-oriented systems engineering;
 Research into prototype object-oriented
tools for systems engineering;
• OCH
• CREAP
• PETS
 The application of systems engineering to various
domains.
© University of South Australia, 2003 16

17. The Operational Concept
Harbinger
 Takes a holistic approach through greater
participation of stakeholders in a form that
allows them to contribute meaningfully
 Helps to elicit (complete the set of)
requirements
 Reduces poorly articulated requirements
 Minimizes undocumented requirements
 Minimizes immeasurable requirements
© University of South Australia, 2003 17

18. OCH Evolutionary Sequence -
Summary
 Combined Operations Concept and
Requirements information
 Added
• Measures of effectiveness
• Multi-media and diagrammatic
information
• Non-sequential access to, and display of,
information
• Parallel display (views) of information
© University of South Australia, 2003 18

19. The Place of the OCH in the SDLC
© University of South Australia, 2003 19

20. Structure of the OCH
 Frame-based
 Underlying sequential State Machine
 Use Case scenarios
 UML swim lane format
 Activity sequence (PERT like) relationships
© University of South Australia, 2003 20

21. Scenario Formats
 UML, basic and enhanced with graphics
• the current way of working.
 Static workflow diagrams
• adding user perspective,
 Dynamic workflow diagrams
• animated diagrams showing sequences.
 Audio files
• containing verbal descriptions
 such as environmental conditions for the deployed system, or user
concerns.
 Video files
• showing scenarios
 animated or filmed.
 Simulations
• of all or part of the system.
 Text mode
• for those people who still think in terms of “requirements”
© University of South Australia, 2003 21

22. Example
© University of South Australia, 2003 22

23. Physical View of OCH
Server
LAN/Internet
S1 S2 Sn
CONTROL
© University of South Australia, 2003 23

24. A Practical OCH
© University of South Australia, 2003 24

25. Advantages of the OCH
 Bypasses today’s problems due to “poor
requirements”
 Connects development effort more directly to
the user needs
 Visual representation of “needs”
• Improves the requirements elicitation process
by providing an interactive facility for exploring the capabilities
of the customer’s needs.
• leads to inherited non-functional “needs”
which reduces the quantity of “missing requirements”
 Helps bridge the gap between soft and hard
systems
© University of South Australia, 2003 25

26. The Purpose of the Communications
Requirements Evaluation & Assessment
Prototype (CREAP)
 To determine if Requirements Engineering tools could
be extended to:
• Constrain writers of requirements to feasible specifications
• Generates a list of feasible implementation options consistent
with a defined inventory
 To determine if
• User selected combinations of equipment from inventory list
• Would provide the needed communications capability
• For a specific category of service
Antennas
Receivers
Transmitters
Modems
© University of South Australia, 2003 26

27. Communications coverage
© University of South Australia, 2003 27

28. Elements of the CREAP
 The frames
• General purpose so that the contents of the frames
can be replaced by a set of frames for a different
scenario allowing the tool to be used in another
scenario potentially with no additional
programming.
 The user interface template
• Provides the template for the information to be
displayed on the GUI.
 The frame interpreter
• A state machine, which interprets the contents of the
frames.
© University of South Australia, 2003 28

29. CREAP
© University of South Australia, 2003 29

30. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 30

31. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 31

32. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 32

33. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 33

34. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 34

35. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 35

36. Prototype Educational Tools for
System and Software Engineering
(PETS)
© University of South Australia, 2003 36

37. Topics
 The elements of a framework for the
engineering of complex systems;
 Object-oriented systems engineering;
 Research into prototype object-
oriented tools for systems engineering;
 The application of systems engineering
to various domains.
© University of South Australia, 2003 37

38. Research areas
 An Acquisition Methodology for the Procurement and
Integration of a Network Enabled Warfare System of
Systems
 A Systems Approach to the Evaluation of Complex, Real-
Time Information Systems: Determining the
Effectiveness of Command and Control Organisations
 Developing methodologies to make efficient use of
Commercial Off The Shelf software products in Research
 How the audio interface for short range infrared guided
air-to-air missiles can be improved
 Measures of Effectiveness: The Standards for Success
 Strategic Planning and Capability Engineering
© University of South Australia, 2003 38

39. Systems Engineering Glossary
Project
 Student summer project
• One iteration through the Development Life Cycle
 Initial announcement on Discuss Reflector
 Prototype (limited vocabulary) in test
 SECOE project
© University of South Australia, 2003 39

40. Conclusions
 A research program into systems engineering covers a
broad range of activities
 The incorporation of process elements into the
requirement object has shown to be a promising approach
for increasing the effectiveness of the systems engineering
process and providing customers with a product that meets
their needs.
 The reductionist approach to solving the problem of poor
requirements is the time-phased parallel process of
building a suite of tools for performing specific tasks.
 While the reductionist approach may not be applicable to
solving all complex problems, in these applications the
results have been promising. FRED, CREAP, TIGER, the
remaining PETS and the OCH provide capability that
shows that parts of the problem of poor requirements can
be alleviated by applying the appropriate technology.
© University of South Australia, 2003 40

41. Summary
 The elements of a framework for the
engineering of complex systems;
 Object-oriented systems engineering;
 Research into prototype object-
oriented tools for systems engineering;
 The application of systems engineering
to various domains.
© University of South Australia, 2003 41

42. Questions ?
© University of South Australia, 2003 42