Systems Engineering Course Introduction

This course is Project Performance International's popular 5-day public course in Systems Engineering. Since development in its original version in 1992, our Systems Engineering training has been delivered to some 6,000 delegates worldwide.

Systems engineering is NOT a rulebook. It IS a set of principles, supported by methods, to deliver maximum benefits to stakeholders.

Stakeholder measures of effectiveness could include, for example, measures of military capability, ease of use, maintainability... and programmatic measures such as investment cost, recurring cost, National Industry Content..., as applicable.

Who Should Attend This Systems Engineering 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:

Training Methods and Materials

The course is delivered using a mixture of formal presentation, informal discussion, and extensive workshops which exercise key aspects of systems engineering on a single system through a development lifecycle. The result is a high degree of learning, as evidenced by workshop 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:

Systems Engineering Training Objective

This five day course addresses systems engineering as it is understood and practised by leading acquirer, developer and supplier organisations worldwide. Our Systems Engineering training provides an integrated approach to the set of management and technical disciplines which combine to optimise system effectiveness, enhance project success and reduce risk. Ways of achieving corporate objectives, eg. time to market, cost of goods sold, product quality, military objectives, is a constant theme throughout the course.

It is expected that, on completion of the course, participants will:

Systems Engineering Course Outline

0. Introduction - Why Systems Engineering?

1. The System Life Cycle and Solution Development

• defining the problem domain
• the solution domain: key concepts, relationships, and work products
• relationship between problem definition and stakeholder satisfaction
• waterfall, incremental, evolutionary and spiral developments
• concurrent engineering
• summary of key concepts

2. Systems Engineering in Context

• definitions of systems engineering from standards
• standards and guidelines - pitfalls and pointers
• ISO 9001, IEEE 1220, EIA/IS-632, EIA 632, J-STD-016, ISO/IEC 15288
• engineering handbooks, texts

3. The Systems Engineering Process - Principles, Concepts and Elements

• workshop - SE principles
• systems concepts
• SE process
• systems of systems engineering
• requirements analysis
• development of physical solution description
• development of logical solution description
• effectiveness evaluation and decision
• description of system elements
• system integration
• verification and validation
• engineering management
• workshop - matching common activities to the basic SE elements
• work product attributes
• requirements traceability
• design traceability
• test traceability

4. Requirements Analysis

• 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
• workshop - context analysis
• workshop - design requirements analysis
• workshop - states and modes analysis
• workshop - parsing analysis
• requirements quality metrics
• workshop - functional analysis
• ERA analysis, rest-of scenario analysis, out-of-range analysis, other constraints search, stakeholder value analysis
• the Operational Concept Description (OCD)
• managing RA
• requirements analysis and management software tools
• common pitfalls in performing RA

5. Development of the System Physical Solution Description (Synthesis) - Part 1

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

6. Development of the System Logical Solution

• types of logical representation
• functional analysis in design - how to do it
• functional analysis/architecture process
• workshop - a simple physical and logical design
• workshop - physical and logical design
• performance threads
• SysML, UML V2
• n-squared charts, data flow diagrams, 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 (Synthesis) - Part 2

• use of design driver requirements
• the system physical architecture related to the functional architecture
• facilities, procedures and people
• the specification tree
• common pitfalls in developing system physical architecture
• adding the detail to design
• interface engineering
• common interfacing pitfalls
• object oriented design

8. Effectiveness Evaluation and Decision Making

• design meetings
• approach to design optimisation
• the role of MOEs and goals
• constructing a system effectiveness model
• designing utility functions
• taking account of risk
• iterative optimisation of design
• working with budgets, targets and ceilings
• value engineering
• workshop - developing a system effectiveness model
• workshop - performing a trade-off study
• 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
• use of FFBDs to structure a requirements specification
• good and poor terminology
• recommended DIDs and templates
• optional workshop - evaluation of two requirements specifications
• pitfalls in preparing requirements specifications

10. Engineering Specialty Integration (ESI)

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

11. System Integration

• design interaction with hardware and software production
• integration planning
• integration
• integration testing
• using incremental builds
• configuration audits
• qualification
• pitfalls and pointers in system integration

12. Verification and Validation

• verification and validation terms defined
• technical reviews
• requirements reviews
• principles of design review
• architectural design review (ADR)
• detail design review (DDR)
• test readiness review (TRR)
• requirements satisfaction audits (FCAs)
• design description (BS-BS) 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
• organisation - functional, project, Integrated Product Teams

13.2. Engineering Planning

• scoping SE - the SEP (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 (WBS)
• why the PBS is a foundation of effective engineering management
• rules in preparing a PBS
• relationship of the PBS to cost accounts
• relationship of the 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 Performance Measurement

13.6. Risk Management

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

14. Summary

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

About the Presenters

Mr. Robert Halligan, FIE Aust.

Robert Halligan is known internationally for his role in the practice and improvement of engineering projects. After early engineering, engineering management and project management roles within major public and private sector organisations, Robert has, for the last twenty-two years, contributed to major systems projects worldwide as a consultant and trainer. Robert has worked in this capacity extensively in Europe, the United States, Asia, South America, South Africa and Australia for some of the best known and most successful global technology-based companies and government enterprises. He has also worked extensively with start-up companies and SMEs.

Robert lead the development and delivery of the Masters module "Managing Engineering Projects" for the Australian Graduate School of Engineering Innovation, a joint venture between two Australian Universities. Robert is a Past President of the Systems Engineering Society of Australia. He was an Australian delegate to the ISO WG7 developing the international system life cycle processes standard, ISO/IEC 12258, and for three years lead the delegation of the International Council on Systems Engineering (INCOSE) to ISO/IEC JTC1 SC7 on software and systems engineering. Robert was a key reviewer of EIA 632 (Engineering of Systems) and EIA 731 (Systems Engineering Capability Model). He was a contributor of content to EIA/IS 632 and its successor in the area of requirements quality, and to IEEE 1220 in the area of functional analysis. Robert has served as Director (International) of the International Council on Systems Engineering (INCOSE). He is an INCOSE Ambassador, and an Honorary Member of the Korean Council on Systems Engineering.

View Full Robert Halligan Biography

Mr. Clive Tudge CEng, MIET

Clive Tudge is a professional Chartered Engineer with considerable national and International experience in senior project management, engineering management, and more recently, training positions in industry and government.

Clive obtained his College Diploma at the College of Electronics, which was then attached to the Ministry of Defence in the U.K. The Diploma qualified him as a Member of the Institution of Electrical Engineers (IEE), which is now known as the Institution of Engineering and Technology (IET). Clive has been on the Committee of the IET in Queensland for the last 20 years, and for three of these years was the President.

Prior to arriving in Australia, in Europe Clive held many senior Project Director positions in the aviation sector on projects such as the Tornado, Jaguar and Hawk aircraft. In Germany, he was the Senior Project Director on a unique Fly-By-Wire Flight Control System for the Typhoon Eurofighter Project, and Project Manager on various systems for the European Tiger Helicopter.

In Australia, Clive has worked with many government agencies and industrial companies including Ansett Technologies, Datacraft, Queensland Rail, Brisbane City Council, Telstra, Optus, QANTAS, Defence Materiel Organisation (DMO) and Energex, helping to bring projects to a successful conclusion. Clive has founded, and has run, successful software development companies, completing complex software-intensive projects on time, within budget and satisfying customer needs.

Clive has been involved in all aspects of procurement from requirements definition and requirements analysis and through to operational support. He has performed roles from software engineer through to Project Chief Engineer and Project Director on multi-million dollar projects. Key skill areas include: project management, systems process evaluation, risk management, system engineering design and acceptance, systems engineering training, airworthiness analysis, communications systems, engineering change management, flight testing and systems process auditing.

View Full Clive Tudge Biography

 

Systems Engineering Training Links

Systems Engineering Newsletter

Systems Engineering FAQ

For further information on how to register, or to download a copy of the registration form, please click here.

Systems Engineering Course Schedule

How to Register

There are three simple ways to register to one of our courses.

1. Online. You may register online by clicking the "register online" link next to the course of interest.
2. Fax. Download a registration form by clicking the link above the schedule and fax the completed form to our offices on +61 3 9876 2664 (Australia) or +1 888 772 5191 (North America).
3. Email. Download a registration form by clicking the link next to the course of interest and email the form here.

Upon receiving a completed registration form, a course confirmation letter and invoice will be sent electronically to the email provided within 1-2 business days. Payment can made by credit card or by bank transfer.

If you need any assistance with the registration process or have any queries, please call one of our friendly team members on Australia +61 3 9876 7345, UK +44 20 3286 1995, North America +1 888 772 5174, Brazil +55 11 3230 8256 or email us.

Key Questions

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 in the systems engineering course are typically people who perform management roles (engineering management or project management), fully or partly. The feedback from such delegates has been consistently that the course has been very helpful 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 the last day. Partial attendance is not recommended, but could be considered in special cases such as single-day other commitments.

What would be the impact of missing the second day of the Systems Engineering 5-Day course?

For a senior systems engineer, if a day were going to be missed, missing the second day would have least 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
    * defines precisely, process elements which become the basis of work products, methods and skills which are exercised/developed for the rest of the week in mainly workshop format
    * helps a lot in establishing unambiguous communication in the group for the rest of the week.

There is a clear break of content between the second and third days, so the ability of a person to understand and participate for the rest of the week would not be affected.

What is the degree of overlap between PPI's five-day Systems Engineering course and PPI's five-day Requirements Analysis & Specification Writing course?

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

In the 5-day Systems Engineering course, Requirements Analysis is put in context in the first two 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 delegates 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 workshop format.

In the 5-day Systems Engineering course, Specification Writing is put in context in the first two 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 workshop system is distributed to, and inspected by, delegates, on the fourth day of the course. More general advice on specification writing is then provided on the fifth (last) day of the course, over 10-15 minutes.

In the 5-day Requirements Analysis and 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 requirements analyst, specification writer, and designer. This session culminates in a workshop. Then, 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 systems engineering course. Overall, RA&SW5D provides greater depth in requirements analysis than does the systems engineering course.

The feedback from people who have participated in both courses has been mostly that they have appreciated the revision and extra depth in requirements analysis. However, about 10% of people 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 advice 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 (etc), notes.

What is the difference between an Operational Concept Description (OCD) and a Concept of Operations (CONOPS)?

Since the early 1970’s, two bodies of information have been distinguished:

An Operational Concept Description (OCD) for any system is a system-centric description of the intended users, uses, how the system is intended to be used, and the external conditions expected during use of the system. As such, it is the definitive reference for fitness of the system for intended use. An OCD may also identify other stakeholders and the interest in the system of each stakeholder. If so, the OCD becomes a reference for stakeholder satisfaction.  

A Concept of Operations (CONOPS) for a given system (limited to an enterprise or business or capability system) is a description of the concept of how human and technical resources within the system solution are to interact to result in the enterprise or business or capability outcome. That is, a CONOPS is a conceptual description of  the operational part of the system solution. The operational part of the system solution is that part of the solution which is intended to meet the requirements on the system which serve an end-use purpose.

This is all very good, until the IEEE came along and issued in 1998 IEEE 1362-1998 - IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document, which in content is a standard for an  Operational Concept Description (OCD). The resulting confusion is now history, and also current reality.

More recently, the International Council on Systems Engineering (INCOSE) has managed to increase the confusion, with one part of INCOSE participating in a joint project with the AIAA to update ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents, January 1993, and in so doing, describing the confusion and the clear distinction between OCD and CONOPS, in ANSI/AIAA G-043-200x Draft 2.0 29 August 2006. In the meantime, another part of INCOSE publishes a Systems Engineering Handbook that uses the term CONOPS to mean an Operational Concept Description (OCD)!

What a mess!

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

I believe that the course will be of substantial benefit to any Business Analyst (BA). There is much content that aligns with the Business Analysis Body of Knowledge® (BABOK®) Guide, as BA and SE are in in many respects concerned with the same things - same objectives, same principles, and similar methods. SE tends towards greater rigour, and methods that are more robust than those commonly used in BA, but are equally applicable to BA. So the BA should get a lot from the course that has been the history of participation in the course by BAs.

That benefit is increased value to the enterprise 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 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 reference is CMMI V1.2, which can be viewed as representing good practice, but is far removed from best practice (as understood today).

Click here to download a presentation by PPI Managing Director Robert Halligan FIE Aust titled "The Business Case for Systems Engineering".

 

What is the difference between requirements and specifications?

Requirements are totally abstract things. A requirement is simply something that somebody requires. The Oxford English Dictionary defines a requirement as an order, a demand, an imperative. In the most common engineering context, a requirement is a required characteristic of something that is to be engineered or otherwise acquired.

If  a requirement is written down, it is now a specified requirement.

A specification is a specific record.

In the two most common engineering contexts, we have requirements specifications and design specifications. The first is a specific record of a set of requirements; the second is a specific record of a design. Thus a requirements specification is the artifact that contains the specified requirements as a set, for the item which is the subject of the requirements specification.

In new product design, a requirements specification for the product would normally drive that design. Once design of the product is implemented, verification of the product will be carried out against the requirements specified in the requirements specification.

The activity of design creates requirements on elements of the solution, e.g. on a subsystem. The requirements on a subsystem will normally be extracted from the design and specified as a set for the purpose of communicating the requirements on the subsystem to the designer or supplier of the subsystem. And so it goes on.