Systems Engineering

for Technology-Based Projects
and Product Developments

A course presented over five days

presented by Mr. Robert Halligan FIE Aust CPEng, Mr. Michael Gainford MAEng FRAeS MSc ESEP CEng MINCOSE or Mr Alwyn Smit Pr Eng, CSEP

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 9,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:

  • Product manager
  • Project director
  • R and D manager
  • Engineering manager
  • Systems engineer
  • Capability developer
  • Business analyst
  • Systems analyst
  • System architect
  • Enterprise architect
  • Software systems engineer
  • Software engineer
  • Design engineer
  • Hardware engineer
  • Project engineer
  • LSA specialist
  • Industrial engineer
  • Other engineering job titles.

Training Methods and Materials

The course is delivered using a mixture of formal presentation, informal discussion, and extensive work shops 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 course work products, and the extensive commendations received from participants.

The Systems Engineering training makes extensive use of courses 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
  • a two-CD Systems Engineering resource containing about 1GB of valuable information (handbooks, templates, guides, papers, reports, standards, etc.) ;and
  • complimentary access to PPI's evolving Systems Engineering Goldmine, from which the CD-Rom is drawn.

Systems Engineering Training Objective

This five day course addresses systems engineering as it is understood and practised by high-performance enterprises worldwide. Our Systems Engineering training provides an integrated approach to the set of management and technical disciplines which combine to optimize system effectiveness, enhance project success and reduce risk. Ways of achieving corporate objectives, e.g. 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:

  • understand the overall concepts which are characteristic of a systems approach to engineering
  • understand the overall process elements, and their relationships, which collectively constitute the building blocks of systems engineering
  • understand and be able to relate the roles of developer as supplier, developer as creator and developer as acquirer, and to place their own roles, and those of their customers (internal and external) and suppliers (internal and external) within this framework
  • be able to perform the basics of some of the more important techniques of system requirements analysis, development of physical solution, development of logical solution, evaluation of solution alternatives (trade-off studies) and design iteration
  • be familiar with the principles and major techniques of engineering management in a systems project context
  • have some basic capability to tailor the application of the systems engineering principles and methods to different application scenarios; and
  • be capable of extensive further learning in the field of systems engineering within a sound conceptual framework.

Systems Engineering 5-Day Course Outline

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
  • 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
  • summary of key concepts

2. Systems Engineering Standards

  • 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: 2008, ISO/IEC 15288: 2015
    • engineering handbooks, texts

3. Systems Engineering Processes: Principles, Concepts and Elements

  • workshop - principles of the engineering of systems
  • system concepts
  • SE process principles & elements
  • requirements analysis
  • development of physical solution description
  • development of logical solution description MBSE: (model-based architecting/design)
  • effectiveness evaluation and decision - trade studies
  • description 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

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. MBSE in the problem domain
  • workshop - context analysis
  • workshop - design requirements analysis (interactive whiteboard exercise)
  • workshop - states and modes analysis
  • workshop - parsing analysis
  • requirements quality metrics
  • workshop - functional analysis
  • lean concepts in functional analysis for the product-oriented enterprise
  • ERA analysis, rest-of scenario analysis, out-of-range analysis, other constraints search, stakeholder value analysis
  • the Operational Concept Description (OCD)/CONUSE
  • 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 (MBSE in Design)

  • types of logical representation
  • functional analysis in design - how to do it
    • functional analysis/architecture process
    • workshop - development of a physical solution
    • workshop - development of functional solution
  • performance threads
  • SysML, LML and other systems modeling languages
  • 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 (Synthesis) - 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
  • DFSS: e.g. Design of Experiment (DOE) and test matrices
  • interface engineering
  • common interfacing pitfalls

8. Effectiveness Evaluation and Decision Making

  • design meetings
  • approach to design optimization
    • the role of MOE's and goals
    • constructing a system effectiveness model
    • designing utility functions
    • taking account of risk
    • iterative optimization of design
  • working with budgets, targets and ceilings
  • value engineering
  • workshop - engineering decision making - developing a system effectiveness model
  • workshop - engineering decision making - 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 FFBD's to structure a requirements specification
  • good and poor terminology
  • recommended DID's 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

  • 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
  • lean concepts in V&V
  • technical reviews
    • requirements reviews
    • principles of design review
    • architectural design review (ADR) - relationship to PDR
    • detail design review (DDR) - relationship to SDR, CDR
    • test readiness review (TRR)
    • requirements satisfaction audits (FCA's)
    • design description (BS-BS) audits (PCA's)
    • 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 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
  • 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 Performance Measurement

13.6. Risk Management

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

14. Summary

  • systems engineering summarized
  • 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 CPEng

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 organizations, 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 SME's.

Robert led 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 led 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. Michael Gainford MAEng FRAeS MSc ESEP CEng MINCOSE

Michael Gainford is a Principal Consultant with Project Performance International, contributing in both the training and consulting roles to the success of PPI's clients. Michael comes to PPI with decades of experience in systems engineering, product and process development, programme management, and business change management, applied in complex international projects, including safety-critical situations. During his career Michael has worked across all the major life cycle phases, for example research & technology, concept definition, product development, legacy product replacement and in-service support.

Michael is an active member of INCOSE (the International Council on Systems Engineering), and has achieved the status of ESEP (Expert Systems Engineering Practitioner). He is also a past employer representative to the INCOSE UK Advisory Board.

View Full Michael Gainford Biography

Mr. Alwyn Smit Pr Eng, CSEP

Mr Alwyn Smit is a Principal Consultant with Project Performance International (PPI). Alwyn has a B.Eng. (Electr) degree from the University of Stellenbosch, South Africa, and is registered with the Engineering Council of South Africa (ECSA) as a professional engineer. He spent the bulk of his career working in the South African defence industry as systems engineer and project manager on technology-intensive projects, most recently as principal systems engineer with the Council for Scientific and Industrial Research (CSIR).

As a lead systems engineer, Mr Smit has contributed extensively to the development of complex technology demonstrators as well as the low volume production of weapon systems in the areas of anti-aircraft systems, radar systems, electronic warfare systems and specialised equipment for special forces application.

View Full Alwyn Smit 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.

Download Brochure Download Form

Systems Engineering Course Schedule (Scroll to view full 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.

Frequently Asked Questions

I am a manager/team leader of systems engineers. Would the workshop 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, not withstanding 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 course 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. Courses 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 course 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. Courses 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 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 rigor, 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.

The benefit to the enterprise is 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 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.

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 at least a basic ability to perform the most important activities, especially requirements capture and validation, and 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 five 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 within the course.

How are verification and validation (V&V) covered in the systems engineering 5-day course?

V&V are covered incrementally during the week. When a V&V matter arises, we discuss it in relation to the subject of the V&V. 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 first thing Day 1 morning (in answer to 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 course (Workshop 1), through the discussion of V&V as represented on a "football diagram" process model (Day 2 morning), through the in-depth coverage of 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 (also Day 2), through to extensive presence of V&V in Workshop 2 (also Day 2), through to the consideration of verification traceability via discussion of a verification traceability diagram on late Day 2 afternoon, through to the discussion on Day 4 of a key-word searching approach to requirements verification, through to the brief reinforcement of the importance of using requirements reviews for requirements verification (Day 4 afternoon), through to discussion of the use of simulation and control flow analysis for design verification (on Day 4 via a logical design process diagram, and again on Day 5 via workshop notes content in Module 6).

Then there is the V&V Module 12 of the workshop notes. With the exception of a little advice on the administration of design reviews, and some definitions, Module 12 brings together material that we have dealt with incrementally during the week.

What is the source of data used on slide 36 titled "Requirements Analysis ROI for Contractor" of your "Business Case for Systems Engineering" downloadable presentation?

The sources of the data are:

Marketing 12.5%: my experience in working with two systems contractors, one in the role of Manager Engineering and Support to Marketing, the other in setting up an Electronics Warfare systems business for a large American company. I won't name the companies, but you wouldn't need to look far to connect the dots. I have also substantiated this figure as representative in discussion with a few BD managers of systems companies.

Branding and other general positioning/public relations 3%: my experience in working with a systems contractor in the role of Manager Engineering and Support to Marketing.

Win ratio of the more successful companies 1 in 2, to 1 in 4: I have seen this info in print on a number of occasions. It should be available on the web easily; if there is difficulty in finding, contact Hy Silver (with a name like that, he is easy to find!).

Cost/bid information: Apart from deriving cost/bid from the above, I have seen these figures in study reports on the cost of bidding/tendering, one at least from the U.S. National Technical Information Service (NTIS), and one from a study done in Australia by, I recall, Defence Science and Technology Organization (DSTO), for what is now the Defence Materiel Organisation (DMO). DSTO has a good searchable catalogue of its reports on its website. Most of the reports are publicly available.

Cost of Requirements Analysis (RA): This data comes from records of cost of RA per requirement for requirements analyses that I have lead over the years. The data has not been previously published, to my knowledge.

Relative cost of Winning Business from a New Customer vs an Existing Satisfied Customer: 5:1: I did some research on this about fifteen years ago (!), and found a number of sources of credible data behind the "throw-away line". I expect that this data is easily available through normal searching channels. If help is needed in finding it, let me know.

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 are more for people who work in software development.

The focus of the course and the examples used 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, solution course 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-odd 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.

How well does PPI?s system engineering training cover aspects of CMMI?

The systems engineering management 5-day course briefly overviews CMMI. The coverage is mainly overview, because the correlation coefficients between CMMI practices and project performance (cost, schedule and quality) average out at only +0.3. The average is somewhat higher for the complex projects. These figures tell us that CMMI is generally in the right direction, but that there is a lot more to achieving high performance in engineering projects than is represented in CMMI.

The reasons for the only moderate correlations could be that:
systems engineering practices are not always beneficial; or
CMMI is substantially less that an optimum representation of systems engineering practices (I believe this to be the case); or
other factors dominate over systems engineering practices in achieving high project performance.

We are sure that CMMI is of value the data proves that and will continue to evolve and improve.

If the CMMI correlation coefficients were close to 1, PPI's training in systems engineering would align very closely with CMMI. Until this is the case, PPI will continue to maintain broad alignment, but teach what actually works best, where there is a difference!

Interestingly, CMMI is least effective in the area of systems engineering management; two of the correlation coefficients are negative!

Reference: "A Survey of Systems Engineering Effectiveness", CMU/SEI-2008-SR-034, December 2008

Can you let me know if the 5 day training course is for beginners or senior level experienced people?

PPI's Systems Engineering course has demonstrated delivery of valuable understandings and methods to people all levels of experience. We have had excellent feedback from delegates ranging from final year university undergraduates, to delegates who have been practising 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.

Is Systems Engineering applicable in an applied research environment?

Yes, SE, well defined and implemented, is applicable in applied research without modification. Though its focus on value adding, the differences are in the decisions made in a research application, not in the principles of making those decisions, nor in the tool set used to implement the principles.

What are the differences between the new INCOSE Systems Engineering Handbook v4 and the previous INCOSE Systems Engineering Handbook v3.2.2?

In summary, Systems Engineering Handbooks v3.2.2 and v4 differ by reflecting the differences between ISO/IEC 15288:2008 and ISO/IEC/IEEE 15288:2015. ISO/IEC 15288:2008 was a terrible standard; ISO/IEC/IEEE 15288:2015 is much better! The main areas of improvement in 15288:2015, reflected in the new handbook, are:

  • improvements in the area of the problem definition of an enterprise/business/capability system and the transformation of this problem definition into definitions of life cycle based solution elements (but there remain serious weaknesses)
  • clear distinction of design as applying to objects which are the subject of design and carried out through levels of abstraction of architecture and detail to give solution description the next physical level down, each solution element (that does not then exist) becoming a new subject of design. The recursive application of architectural and detailed design is well explained, not entirely with this language, but clear enough. By contrast, ISO/IEC 15288:2008 on which v3.2.2 was based, had architectural and detailed design as high and low physical levels of design respectively. This was a relic of muddled thinking that was around 40 years ago but had disappeared until 15288 came on the scene!
  • a clear emphasis on the application of systems engineering to any sort of problem definition/solution development situation. By contrast, ISO/IEC 15288:2008, on which v3.2.2 was based, explicitly excluded the application of systems engineering at low physical levels where design objects became of a homogenous technology, e.g. software, or mechanical, or electronics, etc.
  • the emphasis on verification of all work products. By contrast, ISO/IEC 15288:2008, on which v3.2.2 was based, explicitly limited verification to only system verification. No verification of requirements work products, or of design! It was a 40 year regression to the days of only testing in quality!
  • the emphasis on validation of all work products. By contrast, ISO/IEC 15288:2008, on which v3.2.2 was based, explicitly limited validation to only system validation. Similar comments apply as above.
  • a strong emphasis on the application of concurrent (simultaneous) engineering (the concurrent, collaborative and balanced development of a system-of-interest and one or more enabling systems, e.g. a production system. By contrast, ISO/IEC 15288:2008, on which v3.2.2 was based, did not contain a shred of content of concurrent engineering. And yet concurrent engineering is probably the most significant aspect of the evolution of engineering practice over the last 100 years!

The SEH V4 is also much more detailed and better written in many areas.

A detailed (14 pages) application guide on ISO/IEC 15288:2008

A detailed (25 pages) application guide on ISO/IEC/IEEE 15288:2015

What are the pros and cons of including design content in requirements?

We should start by defining terms. Design requirements say "build it INTERNALLY this way" or "don't build it INTERNALLY this way". Requirements specifications with a lot of design requirements are described as "design oriented". Specifications that are all design are referred to as "Design Specifications".

Valid reasons for including design content in requirements specifications are:
the benefits of commonality of design with something else exceed any downsides (i.e. there is a net benefit from standardisation)
we already have a qualified design, and we simply want more of the same (for build to print - a Design Specification)
we are more expert in aspects of design than are the developers, and the risk to us (or whomever we serve) is reduced by forcing aspects of the design on the developer
the product has already been developed, and external interface design is added to the requirements (typically by invoking an IDD or ICD) to ensure that any replacement product is form, fit and functionally equivalent to the product that has emerged from development
applicable regulations or standards impose design requirements.

Invalid reasons for including design content in requirements specs are:
the design content is perception of solution
we don't know any better.

Potential consequences of including invalid design content in requirements specs are:
exclusion of better solutions
exclusion of any solution
more work without value in
writing requirements
reading requirements
discussing requirements
implementing requirements traceability
developing verification requirements
developing verification procedures
carrying out design verification activities that add no value
carrying out system verification activities that add no value
moving the responsibility for the outcome from supplier to acquirer
increasing risk to the acquirer by moving the responsibility for the outcome from supplier to acquirer
increasing risk to the supplier from future acquirer dissatisfaction
reducing risk to the supplier as a result of transference to the acquirer of some of the risk inherent in development.

The fact that a product has been developed doesn't change the problem. A Product Development Specification (a requirements specification) drives development. After development, we may produce a Product Specification that specifies what we have achieved. In the context of development this is not a "requirements specification" but it is a specification none-the-less. Let us say that:
the required MTBF was 8,000 hours, there was a goal of 10,000 hours, and we achieved 9,000 hours. If we could commit in future to 9,000 hours, we might put that figure in the Product Specification.
the required mass was not greater than 450g. We didn't quite make it, we ended up at 470g, but the product is still viable. If we could commit in future to 470g, we might put that figure in the Product Specification.

In responding to the question I have used typical (but not universal) terms. There is no universal standard for terminology in engineering (but the dictionary is a good starting point!).

What is a requirements specification vs a design specification?

A requirements specification records requirements and serves primarily to drive design or acquisition. A design-oriented requirements specification records requirements and drives design, but with significant direction as to what that design is to be.

A design specification records an as-built or as-developed design and drives production or construction. A design specification is a design description at a level of detail that is implementable.

Where the term "specification" is used without qualification, either a requirements specification or a design specification could be intended. The practice varies between sectors and individual companies (etc).

Q. What is your opinion on the use of Morphological Analysis (MA) in Systems Engineering (SE)

MA has an important role in SE in the creative activity of conceiving and pre-qualifying solution alternatives (eliminating the infeasible and the ineffective). It is most applicable in the engineering of socio-technical systems, but also has application to purely technological systems. MA extends what is achievable by the application of knowledge and judgement alone to pre-qualify solution alternatives for further development. As a consequence, MA allows us to get to the same best solution with less effort than if we had not used MA (when applied to the right solution set).

Select your region

Find out when PPI's Systems Engineering course is being presented in your region:

Closely Related Public Courses

Closely Related On Site Courses

  • Systems Engineering Overview (3-day)
  • World Class Systems Engineering (2-day)
  • Requirements Analysis, The Business Case for (2-hours)

View full on-site course list


"Excellent, detailed course material"

delegate, Australia

Systems Engineering NEWSLETTER

SyEN makes informative reading for the project professional, containing scores of news and other items summarizing developments in the field of systems engineering and in directly related fields.