This 5-day Systems Engineering for Technology-Based Projects and Product Developments course is intended for anybody who will perform or manage significant engineering roles, whether under the name “systems engineering” or not. This course is ideal for formal systems engineering training in that it leads the participant through the ways of thinking and acting that is systems engineering.
The course instills significant understanding together with actionable methods from which skill can be developed through application of the methods in the workplace.
This 5-day course addresses systems engineering as it is understood and practiced by leading developer and supplier organizations worldwide.
Our Systems Engineering training provides an integrated approach to the set of management and technical disciplines that 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, strategic objectives, are a constant theme throughout the course.
The course commences with broad concepts of a systems approach to the engineering of systems (based on systems thinking) and progressively adds detail. Concepts are introduced through a very simple system, and then re-applied to the engineering of a larger, more complex system. A single system is then taken in workshop format through all process areas. Participants leave the course equipped with an understanding of, and some experience via substantial workshops in, effective, efficient, actionable methods. The course is strong in Model-Based Systems Engineering (MBSE) techniques throughout.
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, delegates 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
- OCD/CONOPS/OSD/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
- 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
- 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
- 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 of example requirements
- requirements quality metrics
- workshop - functional analysis in requirements analysis
- ERA analysis, rest of scenario analysis, out-of-range analysis, other constraints search, stakeholder value analysis
- the Operational Concept Description (OCD)/CONUSE/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
- SysML, AADL, OPM and other systems 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
- DFSS: e.g. Design of Experiment (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 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 testing
- using incremental builds
- configuration audits
- 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 (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
- 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 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
- participatory development of new or revised approaches
- achievement of demonstrated success on pilot projects, and without betting the enterprise
- frequent delivery of simple, clear messages of basic principles
- development of high quality resources which make it easy for people to put these principles into practice
- achievement of necessary higher-level support by talking in the language of the person whose support is needed, and demonstrating value in terms meaningful to that person, for example, as applicable: greater profitability, reduced costs, compressed timescales, greater capability for a fixed budget, fewer injuries, etc.
Q? Are there legitimate opportunities to use Model-Based Systems Engineering (MBSE) to reduce the Verification & Validation burden in the implementation. Where are the risks in doing so?
The greatest value from MBSE in design lies in the modeling playing an integral role in the process of design, helping mere mortals design with early prevention and detection of errors leading to reduced errors in the implementation. So for the same degree of product assurance, the optimum amount of verification of the implementation is reduced if MBSE has been used as a design tool. Beyond the reduced likelihood of design error if model-based design is performed, the average cost of detecting an error in logical design is lower than the average cost of detecting the same error by software testing. The ROI, already good, is dramatically increased when the average cost of errors that go undetected in software testing is added.
All of the above is predicated on the MBSE being based on sound design processes, using a logically sound MBSE language that provides for rigorous mapping of logic onto implementation.
So a way to maximise the MBSE ROI is to emphasize verification of design models, enabling a reduction in the amount of software testing that would otherwise be needed to achieve the same degree of product assurance.
The other aspect of MBSE is constructed simulations, where the simulation and the design are in different languages. These need a LOT of V&V, because the opportunity for undetected errors in the simulation is a lot higher than with formal logical design mapped to implementation. A case to illustrate the point is a theater missile defense program on which much of the design work was based on the results of constructed simulation using a particular simulator that had never been validated, and turned out to be riddled with bugs. Failures in test came close to killing the project, and the system failed subsequently in operational use provide the protection sought.
- using MBSE without a sound underlying design process
- loosing sight of the mail purpose of MBSE in design, which is to help us get the implementation right
- using inadequately verified and validated constructed simulations.
The “single source of truth” aspect of MBSE is also very valuable, as long as it is not in reality a single source of untruth! Also valuable is MBSE in the problem domain, provided that a sound requirements analysis process that is inherently model-based is used. Improved requirements validation aligns with reduced need for validation of the implementation.
Q? Why do you not recommend Quality Function Deployment (QFD)
The main reason is that QFD weights MOEs (which it calls requirements) rather than weighting defined ranges in improvements in each MOE. The folly of this is illustrated easily, say for a cellphone:
Cellphone A costs 10 cents more than cellphone B, but provides 200 hours more time between charges (6 hours for B, 206 hours for A) or
Cellphone A costs $200 dollars more than cellphone B, but provides 10 seconds more time between charges.
It is not even just the magnitude of improvement, but the actual range points. For example, going from 6 hours' time between charges to 206 hours is hugely more valuable than going from ten million hours to 10 million plus 200 hours.
So the QFD weights are pretty much meaningless.
This flaw in QFD can be fixed, but it still leaves a methodology that is tedious and imprecise. MAUT used as an integral part of the 3-step optimization process is MUCH more effective and time-efficient. Having said that, the evidence is strong that QFD is certainly a lot better than nothing. It simply isn’t the best approach to maximizing value to the customer. VOC is a catchy and appropriate phrase, but QFD is not the only way, or the best way, to pursue it.
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 delegates 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 delegates 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 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 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, delegates, 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 delegates who participated in both courses has mostly been that they appreciated the revision and extra depth in requirements analysis whilst about 10% of delegates 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. Can the course be tailored?
Yes! Public courses are always tailored informally in delivery to best match the mix of interests of course participants.
On-site deliveries are also always informally tailored in delivery, mainly by choice of verbal examples and through the framing quiz questions. This is commonly the extent of tailoring that eventuates, because systems engineering can be thought of as the problem-independent and solution technology-independent principles and methods for the successful engineering of systems/products/anything. There are certain activities that must be performed, and other activities that are performed selectively, value-adding being the criterion for selection. These activities are the process building blocks - requirements capture and validation; physical design, logical design, the conduct of trade-off studies, specification of system elements, system integration, verification of work products, validation of work products, and engineering management. The names may vary, but the activities are fundamental.
Two additional forms of tailoring are also sometimes applied. In the standard course delivery, a single system is taken in workshop format through the activities of requirements analysis and design, ending on the last afternoon with a tradeoff study. The workshop system can be understood by anybody, and the design workshops are designed to cater for a wide range of technology backgrounds. However, some individuals or companies feel uncomfortable working with a system that is not in their application domain.
One approach to tailoring that we use, that avoids the extra cost to the client, is to use the standard workshop system and resources as examples and to improvise in conducting the workshops using a customer-nominated system meeting criteria that we supply. This approach provides the comfort factor, but the downside is a reduction in learning.
The second approach to tailoring is to redevelop the workshops to use a customer-nominated system meeting criteria that we supply. Such redevelopment is funded by the client, and the redevelopment ensures that all learning points are achieved.
PPI is always eager to work with clients to achieve a learning outcome that best meets their needs.