Upcoming Courses

Register and pay 30 days prior to the course commencement date to receive a 10% early bird discount. Or register a group of 3+ for a 10% group discount. Available for corporate training worldwide.

Key Learning Objectives

At the conclusion of this course, participants are expected to have learned:

• the overall concepts that are characteristic of a systems approach to engineering;
• the overall process elements that collectively constitute the building blocks of systems engineering;
• the fundamental relationships between those process elements that allow us to successfully develop an engineering system well-matched to the product to be engineered;
• the basis of selection between styles of development such as waterfall, incremental, evolutionary and “spiral”;
• some of the principles and major techniques of engineering management in a systems project context; and
• some basic capability to tailor the application of the systems engineering methods to different application scenarios.

Training Method and Materials

The course is delivered using a mixture of formal presentation, informal discussion, and extensive workshop activities that exercise key aspects of systems engineering on a single system through a development life cycle. The result is a high degree of learning, as evidenced by course work products, and the extensive commendations received from participants.

The Systems Engineering training makes extensive use of workshops to put into practice the techniques covered in theory sessions.

You will be provided with:

• comprehensive Systems Engineering course notes containing presentation material
• a Workbook containing workshop exercises, with worked examples also distributed in most cases
• numerous supplementary descriptions, checklists, forms and charts which you can put to use immediately
• complimentary access to PPI’s evolving Systems Engineering Goldmine

Who Should Attend This Course?

This Systems Engineering course is designed for personnel who perform, manage, control or specify the development of small to large technology-based systems, especially for exacting applications or to fixed budgets. The course will be of particular value to people with job titles such as:

• Business analyst
• Military capability developer
• Design engineer
• Engineering manager
• Enterprise architect
• Hardware engineer
• Industrial engineer
• Logistics Support Analysis Specialist
• Product manager
• Project director
• Project engineer
• R and D manager
• Software engineer
• Software systems engineer
• Systems analyst
• System architect
• Systems engineer
• Other engineering job titles.

0. Introduction – Why Systems Engineering?

1. The System Life Cycle and Solution Development

• Systems thinking
• defining “the problem”
• the solution domain: key concepts, relationships, information types and work products, MBSE
• Operational Concept Description (OCD) / Concept of Operations (CONOPS) / Operational Solution Description (OSD) / Architectural Design Description (ADD) issues
• architectural frameworks
• relationship between problem definition and stakeholder satisfaction
• systems of systems engineering (systems of autonomously managed systems)
• waterfall, incremental, evolutionary and spiral developments
• concepts of agile, lean and concurrent/simultaneous engineering
• Product Line Engineering (PLE)
• Digital engineering, digital thread, digital twin
• summary of key concepts

2. Systems Engineering Standards

• definitions of systems engineering from standards
• standards and guidelines – pitfalls and pointers
  • EIA/IS-632, EIA 632, IEEE 1220, ISO/IEC 15288: 2008, ISO/IEC 15288: 2015, ISO 9001,
  • engineering handbooks, texts

3. Systems Engineering Processes: Principles, Concepts and Elements

• workshop – principles of the engineering of systems
• system concepts
• why MBSE and digital engineering
• SE process elements
• requirements analysis
• development of physical solution description
• development of logical solution description – MBSE: (model-based architecting/design)
• effectiveness evaluation and decision – trade studies
• specification of system elements – specification writing
• system integration
• verification and validation
• engineering management
• workshop – matching common activities to the SE process elements
• work product attributes
  • requirements traceability
  • design traceability
  • test/verification traceability

• what are requirements?
• types of requirements, and how they relate to analysis, specification & design
• requirements quality attributes
• requirements languages other than natural: operational, formal
• Requirements Analysis (RA) – how to do it. MBSE in the problem domain
• workshop – context analysis
• workshop – design requirements analysis (interactive whiteboard exercise)
• workshop – states and modes analysis
• workshop – parsing analysis of example requirements
• requirements quality metrics
• workshop – functional analysis in requirements analysis
• Entity Relationship Attribute (ERA) analysis, rest of scenario analysis, out-of-range analysis, other constraints search, stakeholder value analysis
• the Operational Concept Description (OCD)/Concept of Use (CONUSE)/Concept of Operations (OpsCon)
• managing RA
• requirements analysis and management software tools
• common pitfalls in performing RA 

5. Development of the System Physical Solution Description – Part 1

• technology and innovation in solution development
• configuration items
• criteria for selecting configuration items

6. Development of the System Logical Solution (MBSE in Design)

• types of logical representation
• functional analysis in design – how to do it
  • functional analysis/architecture process
  • workshop – physical and functional design
• performance threads
• Systems Modeling Language (SysML), Architecture Analysis Design Language (AADL), Object Process Methodology (OPM) and other system modeling languages
• state-based modeling
• n-squared charts, behavior modeling, and other functional notations
• analysis and design software tools
• pitfalls in developing system functional solution

7. Development of the System Physical Solution Description – Part 2

• use of design driver requirements
• the system physical architecture related to the functional architecture
• facilities, procedures and people
• the specification tree
• object-oriented design
• common pitfalls in developing system physical architecture
• adding the detail to the design
• Design For Six-Sigma (DFSS): e.g. Design Of Experiments (DOE) and test matrices
• interface engineering
• common interfacing pitfalls 

8. Effectiveness Evaluation and Decision-Making

• approach to design optimization
  • the role of MOEs and goals
  • constructing a system effectiveness model
  • capturing utility functions
  • taking account of risk
  • iterative optimization of design
• working with budgets, targets and ceilings
• value engineering
• workshop – engineering decision-making
• multiple stakeholders, multiple uses, event-based uncertainty
• handling, in design, conflict of interest between customers and suppliers
• pitfalls in effectiveness evaluation and decision (avoiding the smoke and mirrors)

9. Description of System Elements – Requirements Specification Development

• the eight requirement specification types and their uses
• public specification standards – the good, the bad, and the ugly
• specification structure principles
• good and poor terminology
• recommended Data Item Descriptions (DIDs) and templates
• pitfalls in preparing requirements specifications

10. Engineering Specialty Integration (ESI)

• what makes an engineering specialty special?
• common engineering specialties
• a generic approach to ESI
• organizational issues of ESI
• pitfalls, and specialty engineering examples

11. System Integration

• integration planning
• alternative system integration strategies
• integration
• integration testing
• using incremental builds
• configuration audits
• qualification
• pitfalls and pointers in system integration

12. Verification and Validation

• Verification and Validation (V&V) terms defined
• lean concepts in V&V
• technical reviews
  • requirements reviews
  • principles of design review
  • Architectural Design Review (ADR) – relationship to Preliminary Design Review (PDR)
  • Detailed Design Review (DDR) – relationship to System Design Review (SDR), Critical Design Review (CDR)
  • Test Readiness Review (TRR)
  • requirements satisfaction audits (Functional Configuration Audits [FCAs])
  • design description (Build State-Build Standard [BS-BS]) audits (Physical Configuration Audits [PCAs])
  • technical reviews and incremental builds
  • administration of technical reviews
  • customer involvement in technical reviews
  • pitfalls in conducting technical reviews
• test and evaluation
• other verification and validation methods and tools 

13. Systems Engineering Management 

13.1. Management Principles

• basic concepts
• application of lean concepts in planning and process design
• organization – functional, project, Integrated Product Teams

13.2. Engineering Planning

• scoping SE – the Systems Engineering Plan (SEP), Systems Engineering Management Plan (SEMP)?
• why prepare a SEP?
• how a SEP may relate to other plans
• content of the SEP
• pitfalls in preparing a SEP
• functional interfaces 

13.3. Project Breakdown Structures

• types of PBS (Work Breakdown Structure [WBS])
• why the PBS is a foundation of effective engineering management
• rules in preparing a PBS
• PBS/WBS Standards and Guides
• relationship of a PBS to cost accounts
• relationship of a PBS to work packages
• PBS (WBS) development pitfalls and pointers
• optional workshop – developing a PBS (WBS)

13.4. Configuration Management (CM)

• what is configuration?
• the concept and types of baseline
• CM standards – EIA, IEEE, etc.
• the four fundamental CM activities
• pitfalls and pointers in CM 

13.5. Technical Program Controls

13.6. Risk Management

• the nature of risk
• components of risk
• the five key activities of risk management

14. In Closing

• systems engineering summarized
• tailoring to specific activities or projects
• getting the most out of systems engineering methods
• systems engineering capability assessment and improvement

Q. I am a manager/team leader of systems engineers. Would the course be of any assistance to me and would I need to complete the whole course?

About 15% of participants who attend the systems engineering course are typically people who perform management roles (engineering management or project management), fully or partly. The feedback from such participants has consistently been that the course has been extremely beneficial to them, notwithstanding that the focus of the course (about 90% of content) is on doing systems engineering concepts, principles and methods.

The course is designed to bring about a convergence of understanding by Day 5 of the course. Partial attendance is not recommended but could be considered in special cases.

Q. What would be the impact of missing Day 2 of the Systems Engineering 5-Day course?

For a senior systems engineer, if a day were to be missed, missing Day 2 would have a minimum effect. However, it would certainly not be helpful to miss the day, which:

• sets foundations for architecting – physical and logical
• superimposes V&V on the development framework
• precisely defines process elements which become the basis of work products, methods, and skills which are exercised/developed for the rest of the week in mainly course format
• establishes unambiguous communication in the group for the rest of the week.

There is a clear break of content between Day 2 and Day 3 so the ability of a person to understand and participate for the rest of the week would not be affected.

Q. What is the degree of overlap between PPI’s 5-Day Systems Engineering course and PPI’s 5-day Requirements Analysis & Specification Writing course?

Both Requirements Analysis and Specification Writing are critically important sub-disciplines within Systems Engineering, therefore, these disciplines are covered in both courses.

In the 5-Day Systems Engineering course, Requirements Analysis is put in context in the first 2 days of the course. Then, 1.7 days is devoted to “how to do requirements analysis capture and validation of the information content of requirements”. This depth of coverage is sufficient for participants to go away with new insights, and importantly, new skills, in performing Requirements Analysis. Workshops are used extensively, based on a single system that is taken through Requirements Analysis then subsequently Design.

In the 5-Day Systems Engineering course, Specification Writing is put in context in the first 2 days of the course. Specification Writing is then touched upon incidentally in Requirements Analysis, especially in parsing analysis, and in the “clean-up” activity, a related handout for which lists problematic English: parts of words, words and phrases, and the checks that are done regarding adequacy of language in relation to use of these words (etc.).

In the 5-day Systems Engineering course, a revised requirements specification for the course system is distributed to and inspected by, participants, on Day 4 of the course. More general advice on specification writing is then provided on Day 5 (last day) of the course, over 10-15 minutes.

In the 5-Day of the Requirements Analysis & Specification Writing course, Requirements Analysis and Specification Writing are put in context in the first 0.8 days of the course. Focus is then given to the types of requirements and their significance to the roles of the requirements analyst, specification writer, and designer. This session concludes with a workshop. Subsequently, 2-2.5 days are devoted to “how to do requirements analysis capture and validation of the information content of requirements”. This is a significantly greater depth of coverage compared with the systems engineering course. Workshops are again used extensively, based on a single system, almost always a different system to the system used for the systems engineering course. There are more, and longer, workshops in requirements analysis compared with the systems engineering course. Overall, the RA&SW5D course provides greater depth in requirements analysis than does the Systems Engineering course.

The feedback from participants who participated in both courses has mostly been that they appreciated the revision and extra depth in requirements analysis whilst about 10% of participants have regarded the overlap as excessive for their purposes.

In the 5-Day Requirements Analysis and Specification Writing course, hugely more coverage is given to the structuring of system and software requirements specifications, and specifications of services. Similarly, almost a day is devoted to advising on the use of language (English) in expressing requirements pitfalls and pointers. There is also substantial coverage of writing non-requirements sections of requirements specifications scope, applicable documents, definitions, notes, (etc.).

Q. What benefits would this course offer me as a Business Analyst?

I believe that the course will be of considerable benefit to any Business Analyst (BA). There is much content that aligns with the Business Analysis Body of Knowledge® (BABOK®) Guide, as Business Analysts and Systems Engineers are in many respects concerned with the same things – same objectives, same principles, and similar methods. System Engineering tends towards greater rigor and methods that are more robust than those commonly used by BAs but are equally applicable to BAs. So BAs should benefit greatly from attending this course.

The benefit to the enterprise is the increased value from technical projects:

“Systems engineering is an interdisciplinary, collaborative approach to the engineering of systems (of any type) which aims to capture stakeholder needs and objectives and to transform these into a description of a holistic, life cycle balanced system solution which both satisfies the minimum requirements, and optimizes overall project and system effectiveness according to the values of the stakeholders. Systems engineering incorporates both technical and management processes” Source: Halligan, 2003

Scientifically-based studies by Carnegie Mellon University SEI, IEEE and the NDIA show correlation coefficients between systems engineering practices and project performance (quality, cost and schedule) averaging +0.3 for technical projects in general and +0.6 for the more complex projects. These figures are very significant, given that the process reference is CMMI V1.2, which can be viewed as representing good practice, but is removed from best practice (as understood today).

Click here to download a presentation by PPI’s Managing Director Robert Halligan FIE Aust CPEng titled “The Business Case for Systems Engineering”.

Q. Will the course benefit my company in the area of design?

It depends! A quick test to get an indication would be to ask yourselves the following questions:

1. do we make solution decisions that are significant to the success of our organization? YES
2. do our designs (solution decisions) when implemented in development, normally work the first time? YES
3. do we have a significant incidence of rework in design due to errors made arising from design complexity? NO
4. are we challenged to meet the development schedule and cost imperatives and targets? NO
5. faced with feasible design alternatives, do we have a quantitatively based, objective way of evaluating and selecting between these alternatives? YES
6. do we have, for a given solution concept, a quantitatively based, objective way of converging in design on an optimum balance of product qualities such as various measures of performance, unit cost of production, reliability, etc.? YES
7. do we have a quantitatively based, objective way of factoring risk into design decisions? YES
8. is system integration (bringing our solution elements together to build in development a working product) normally trouble-free? YES
9. do our products/systems almost always compare favorably with those of our competitors or allies? YES

If the answers to these questions are mainly as shown, opportunities for improvement will lie mainly in technology improvements and breakthroughs, not in the organization’s approach to design. If not, the course will benefit your organization in the area of design.

Q. Is the 5-Day training course for beginners or for senior level experienced people?

PPI’s Systems Engineering course has demonstrated delivery of valuable understandings and methods to people of all levels of experience. We have had excellent feedback from delegates ranging from final year university undergraduates to delegates who have been practicing systems engineering for decades. The course is designed for anyone who performs, manages, controls or specifies aspects of the development of small to large technology-based systems.

Q. I am a mechanical engineer working in the development of mechanical systems in the wind industry. I would like to know whether the focus of the course and the examples used is directed more towards those who work in software development.

The focus of the course and the examples used to span a variety of technologies. Indeed, systems engineering can be viewed as technology-independent principles and methods of the engineering of systems.

The system used for all the courses, through requirements analysis, and through design, is an Emergency Communication Buoy. In Requirements Analysis, of course, the technology is not relevant. In design, system solution normally has a mixture of technologies which delegates can choose, including mechanical. We do a “dry-run” mini-workshop, in which the example used for logical and physical design is mechanical, involving Archimedes Principle. Delegates are free to choose a requirement to which relates any aspect(s) of solution technology. The value model building part of the trade-off study course is technology-independent, whilst the trade-off study itself involves various technologies. The first design optimization trade involves trading increased size for improvements (mostly) in other Measures Of Effectiveness (MOEs).

More generally, examples are chosen during course delivery to match, as much as practical, the technology and application interests of the group.

Q. Are software tools used in the Systems Engineering course?

No. The course aims to equip delegates with the principles of systems engineering, and with at least a basic ability to perform the most important activities, especially requirements capture and validation, physical and logical design, and trade-off studies.

Whilst software tools are fundamental to performing these activities efficiently in real work scenarios, their use in a 5-day course would compromise the objectives of the course because of the time impact and distraction of having to learn to manipulate tools.

The course achieves its objectives very effectively through a series of workshops conducted manually. Representative software tools supporting process areas such as requirements capture and validation, physical and logical design, and trade-off studies are identified and discussed during the course.

Q. How is Verification and Validation (V&V) covered in the Systems Engineering 5-Day course?

V&V is covered incrementally during the week. When a V&V matter arises, we discuss it in relation to the subject of the V&V. With one and a half hours of incremental coverage of V&V throughout, the course starts with the introduction of the nature, subjects and representative methods of V&V.

On Day 1 we address the question “what is this systems engineering approach?” (ref. the roadmap process diagram and the dog diagram), through to the superimposition of V&V on requirements and design work products via requirements and design reviews in a complex systems diagram (also Day 1), through to the explicit appearance of V&V in a SE Principles workshop (Workshop 1), through the discussion of V&V as represented on a “Football Diagram” process model. On Day 2 we cover in-depth V&V using a Wedge Model (a PPI evolution of the V model, which, unlike the V model, accommodates multiple-build developments, this diagram is totally concerned with V&V), through to discussions of inputs to and outputs from V&V respectively via “box” diagrams, through to extensive presence of V&V in Workshop 2, through to the consideration of verification traceability via discussion of a verification traceability diagram towards the end of Day 2. On Day 4 we discuss the key-word searching approach to requirements verification, through to the brief reinforcement of the importance of using requirements reviews for requirements verification, through to discussion of the use of simulation and control flow analysis for design verification via a logical design process diagram. This is revisited on Day 5 via course notes content in Chapter 6.

Next comes the V&V in Chapter 12 of the course notes. With the exception of a little advice on the administration of design reviews and some definitions, Chapter 12 brings together material that we have dealt with incrementally during the week.

Q. What is the difference between PPI’s 5-day Systems Engineering course and CTI’s CSEP Systems Engineering course?