brought to you by

Project Performance International (PPI)

SyEN 43 – April 19, 2012

Dear Colleague,

SyEN is an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at

Systems engineering can be thought of as the problem-independent, and solution/technology-independent, principles and methods related to the successful engineering of systems, to meet stakeholder requirements and maximize value delivered to stakeholders in accordance with their values.

If you are presently receiving this newsletter from an associate, you may receive the newsletter directly in future by signing up for this free service of PPI, using the form at If you do not wish to receive future SE eNewsletters, please reply to the notifying e-mail with "Remove" in the subject line, from the same email address. Your removal will be confirmed, by email.

We hope that you find this newsletter to be informative and useful. Please tell us what you think. Email to:


Quotations to Open On
Read More…

Feature Article: An Affordable Systems Verification Activity
Read More…

Systems Engineering News
• Requirements Engineering and Business Analysis: State of Practice Study
• Fujitsu Establishes New Regional Systems Engineering Companies
• SysML Versions 1.3 and 1.4
• INCOSE Brasil Chapter Formed
• Vitech Corporation and INCOSE Announce 2012 Fellowship Award Application Process is Now Open
Read More…

Ask Robert:
- Is the objective of systems engineering to reduce risk?
- Does it help to view a project plan as a system?
Read More…

Featured Societies – International Federation of Automatic Control
Read More…

INCOSE Technical Operations: Motor Sports Working Group
Read More…

Systems Engineering Tools News

Read More…

Systems Engineering Books, Reports, Articles, and Papers
Read More…

Conferences and Meetings
Read More…

Education and Academia
University of South Alabama (USA) is now offering a PhD in Systems Engineering
Advanced Modeling & Simulation Techniques for Multi-body Robotic Systems

Read More…

Some Systems Engineering-Relevant Websites
Read More…

Standards and Guides
Status of Update to EIA-STD-632 "Processes for Engineering a System"
TechAmerica Standard on Joint Technical Reviews and Audits?
SE Body of Knowledge (SEBoK) V0.75
TRAK Open Source Enterprise Architecture Framework

Read More…

A Definition to Close on – Function
Read More…

PPI News
Read More…

PPI Events
Read More…

Quotations to Open On

“As quality increases, productivity increases. This fact is well known
but only to a select few.”
- W. Edwards Deming

“Yes, maybe I have a clear writing style, but actually I have first to
understand for myself what I’m writing.”
- BG Massimo Pica

Editor’s Note: A quotation in SyEN 41 now has an author! In the February 2012 edition of SyEN we included the quotation: “To the optimist, the glass is half full. To the pessimist, the glass is half-empty. To the systems engineer, the glass is twice as big as it needs to be” - Unknown. We are pleased to announce that the author has been found, and is Mr. Paul Davies. Paul is Head of Innovations Group, Defense Mission Systems, of Thales, UK.

Feature Article


Jeffrey O. Grady
Owner JOG System Engineering
6015 Charae Street
San Diego, CA 92122

jeff (at)

Copyright. All rights reserved.


Verification is a process for developing evidence that the design solution satisfies the requirements on which it is based. The purpose of verification is to determine the degree of compliance between the design of the system and its lower tier entities and the content of the specifications corresponding to those entities. The verification work must be preceded by an effective requirements activity that results in a set of specifications containing in each case a minimum but complete collection of well-formed requirements statements derived from a modeling approach applied on all programs. The typical methods used to verify compliance include test, analysis, demonstration, and inspection. Verification techniques include walkthroughs, performance testing, simulation, database analysis, algorithm analysis, functional testing, stress testing, and interface testing. The outputs of the verification work are documented verified requirements; an updated requirements traceability matrix; and updated preliminary operational and system concept documents. Addressing requirements verification early, during requirements development, provides opportunities to control cost and risk. Obviously, the verification approach impacts the cost and effort required for verification. Use of a verification planning checklist facilitates asking the right questions. Performing the steps described in this paper will result in an affordable systems verification activity.

Verification Purpose

The purpose of the verification work is to determine the degree of compliance between the design of the system and its lower tier entities and the content of the specifications corresponding to those entities. The content of the specifications is intended to be the basis for the design of the system in that they each specification contains the essential characteristics that the system and its entities must possess. Therefore, the specification becomes the standard against which the product is compared in verification activity.

Verification Process

Entry into the verification activity for a particular system entity (system, subordinate product entity, or interface entity) coordinates with the requirements database containing verification requirements for all product requirements in sections 3 and 5 of the specification for that entity coordinated with methods of verification (test, demonstration, analysis, or examination) assigned. This transition from requirements into verification activity need not be delayed until completion of all requirements analysis activity. Rather, it should be started as each specification is completed beginning with the system specification so the verification design activity should be in progress throughout the requirements analysis activity progressively expanding as the lower tier layers of the work continue. Figure 1 illustrates how this activity should flow as described in subordinate paragraphs.

Figure 1 Systems Verification Activity

Figure 1 shows three major portions of the verification work and an overall management activity all of which will be explained. There are two views of the activity of interest as suggested by the horizontal and vertical orientations of the diagram. The activity takes place in three major sequential steps (illustrated in the vertical columns on the diagram): (1) plan the verification activity, (2) accomplish the activity in accordance with that plan, and (3) report the results to the customer and/or submit to an audit of the evidence of compliance. The three phase related channels are identified as activities beginning with modeling ID strings beginning with F2# so that each of the three need only be discussed once in this overview. Primary inputs to this activity are three kinds of specification: (1) one system specification, (2) multiple item performance specifications, and (3) multiple item detail specifications. We will explore these kinds of specifications shortly and their purpose.

The overview of this activity will be explained from this perspective because all three major sequences are performed in essentially the same way and can all be described in a single discussion. Of course, there are unique distinctions in each of the three sequences that paper size will not permit coverage of. The description of the verification activity in this paper has been overwhelmingly influenced by the author’s many years of experience in the development of systems primarily for military purposes. As a result, the Department of Defense way of organizing systems and the work to develop them is apparent. However, this approach was evolved from many years of procurement experience of some very complex systems to satisfy very difficult needs and the same basic process can serve very well the needs of the developer of commercial systems whether the products be complex or not.

In addition to the major sequence focus, the activity is commonly partitioned into three major phases each coordinated with a kind of specification (the three horizontal rows in the diagram). A development program will have only a single system specification so that row only shows a single flow. A system will consist of two or more product entities that interact through interface entities. The latter may be covered by interface specifications or the requirements for these may be included in pairs (recognizing the two terminals of each interface) of product entity specifications under interface requirements. Thus at the item level under the system we will have to deal with multiple specifications of two kinds. In Figure 1 only three are shown but in most systems there will be quite a few reflecting an expanding hierarchy of product entities. A generic activity designator “&” is used as a vehicle of discussion to avoid discussing each of the three major steps in the verification activity for each phase.


In Figure 1 the reader will note that the three major inputs to the verification activity are three kinds of specifications. Commonly, the item qualification work is accomplished first based on the content of the item performance specifications that are intended to be the basis for the development of the item design. Following completion of item qualification, system test and evaluation is authorized because all of the entities that the end items of the system shall be assembled from will have proven that they comply with their specification content. The content of the system test is the basis for the development test and evaluation (DT&E) activity accomplished by the developer of the system. After the system has completed DT&E activity successfully and sufficient system assets have been delivered to the user, the user will commonly conduct an operational test and evaluation (OT&E) to gain confidence that the system is adequate to perform the missions the user must be capable of performing. As production begins every product entity produced must be subjected to an acceptance verification based on the content of the item detail specification content.

The flow of verification activity in Figure 1 must actually be combined with the flow of product to fully grasp the complexity of the verification process. Item qualification is normally accomplished using product entities manufactured in an engineering shop, for there is not normally a production line available at the time that these entities must be made available. The production line that produces the end items needed for DT&E may be referred to as a low rate production line, and once the DT&E has been completed and results approved by the customer a full rate production line may be ready to begin producing production units that will flow to the field to provide material needed for OT&E and start providing for deliveries to those who will use the system.

Formal acceptance is not always required for the items produced for item qualification and may not be required for product produced to support DT&E. But, a contractor is wise to employ a draft acceptance verification plan and procedure as early in a program as possible so that it will be a fully proven process by the time it must be formally applied. This practice is also supportive of the developer’s claim that the products manufactured on a production line will perform the same way that those proven to comply with specification content that were manufactured in small numbers in an engineering laboratory by engineers and highly skilled mechanical and electrical technicians.

It should be noted that both the system and lower tier item performance specifications are performance specifications intended to convey to the design community the essential characteristics that the design must possess. They are specifications for the design of the product. The item detail specifications are the basis for the design of the acceptance process through which the developer will make decisions on the suitability of every product article completing the manufacturing process for delivery to the customer. Systems are commonly manufactured and delivered in terms of the end item product entities that compose them so there is no need for a system detail specification.

Verification Documentation

In the past, paper documents were prepared using typewriters and later computer word processors for three sets of verification documents: plans telling what was to be done for a particular task, procedures telling the precise order in which task work was to be done with pass-fail criteria clearly defined, and reports giving the results of the task relative to the question of the degree to which it was established through performing the task that the product design was shown to be compliant with the requirements the task was responsible for. Computer applications are available today for capturing the requirements derived from modeling into requirements databases that can be extended to include capture of all verification documentation with clear traceability from entity requirements through verification requirements, the assigned methods, allocation to specific tasks under the responsibility of a particular principal engineer, the content of the plans, procedures, and reports related to the tasks. In this case the option is available to publish plans, procedures, and reports in paper as we did in years past or deliver to the customer the verification data in computer media.

I have long preferred the development of a set of integrated verification plan, procedure, and report documents with one of each for each entity where verification is necessary. In this configuration, one of each of these three documents is prepared for each entity requiring considerable organization and management skill because they will each draw content from many tasks of all four methods and therefore many principal engineers. The advantage is that it collects all of the documentation needed for an audit in one document however it is published.

The alternative is to prepare a collection of plans, procedures, and reports each for one specific task of one particular method. In this case the principal engineer for the task is entirely responsible for the three documents corresponding to his or her task and the process can be more easily managed toward a satisfactory conclusion as far as that principal engineer is concerned.

Depending on how the requirements are allocated to verification tasks, some task documentation may be very thin consisting of a cover page, a table of contents, and a couple of pages of text. This is particularly true for non-test methods. In other cases the documentation may be fairly voluminous, especially if integrated verification documentation is employed. In this overview of verification work, the documentation method covered employs the individual task focus because of the degree of difficulty in explaining and managing the integrated approach.

Major Verification Activities

This discussion covers the verification activity in terms of a generic portrayal applying to all three horizontal frameworks on Figure 1. In this paper we will only discuss item qualification but these phases have much in common in each of the three sequence steps of planning, accomplishing, and reporting the results.

The discussion focuses on one particular product entity at whatever level we choose. The level of choice for DoD programs is commonly the configuration item. For each of these items on a development contract there is a series of major reviews and audits where the customer formally reviews contractor progress and makes formal decisions in each case about contractor performance relative to contractual obligations. Early in the development effort system requirements and system design reviews are held, but subsequent reviews and audits are commonly held at the configuration item level. These remaining ones are: (1) preliminary design review (PDR) where the customer reviews configuration item design concepts; (2) critical design review (CDR) where the customer reviews the completed design of a configuration item; (3) functional configuration audit (FCA) where the customer audits the qualification verification evidence for a configuration item; and (4) physical configuration audit (PCA) where the customer audits the configuration item first production article acceptance verification evidence. The FCA appears in activity F2#3213 of Figure 1for each configuration item and PCA appears in activity F2#3313 of Figure 2.

Verification Planning

The planning activity consists of three basic steps pictured in Figure 2. All of the activity pictured is taking place within activity F2#3X1 shown on Figure 1 and is intended to portray the planning work required for the first step in any of the three phases corresponding to system, item performance, or item detail specifications. This work is required for every system entity for which a specification is developed on a program. The input to this activity is a specification in paper, computer image of the specification, or in database form. The output is a set of plans and procedures, a pair for each entity to be verified as compliant with its requirements.

Figure 2 Plan Verification Activities

For any given system entity, all of the requirements (generally limited to Sections 3 and 5 of the specification template encouraged by the author and DoD) in the entity specification, each of which was assigned to it a method of verification in the development of the specification, must be assigned to a specific task. One way to do this would be to assign every requirement in each specification to a single unique task. This is not the most cost-effective way of designing the program verification plan. However, to do this critically important activity we must assign a task principal to each task who will be responsible for developing the task plan and procedure, accomplishing the task in accordance with the plan and procedure, and reporting upon the task. All of the tasks are linked in a verification schedule and coordinated with a budget. These first three tasks in activity F2#3&11 of Figure 2 are accomplished across all program tasks.

As is apparent from Figure 2, something different happens from this point forward in the planning activity. The work splits into many task-oriented activities all of which come back together with the completion of task reports. The program organizational entity, generally a systems engineering element, responsible for the overall verification activity, should develop and deliver a copy of a list of the requirements that each task principal is responsible for developing evidence of compliance based on task results. The assigned task principals must subsequently accomplish their work for each entity related verification task with the result being that each task has a published, reviewed, and approved plan and procedure under configuration control. The plans must not become approved unless they include the list of requirements assigned to the task coordinated in a table with references in the report to the location of the evidence of compliance. This is the key to affordable verification.

In this paper the author has chosen to refer to the work that must be accomplished on a program as activities in preference to functions because of his conversion from years of support for functional analysis as his preferred modeling approach to UML-SysML where what are called functions in functional analysis are referred to as activities in UML-SysML. However, from years of habit the author could not bring himself to refer to the activity diagram block by anything but functions in terms of their assigned numbering.

Design Verification Process for an Entity

In some way, the person or persons responsible for designing the verification activity, commonly a system engineering responsibility, must organize all of the requirements in all of the specification Sections 3 and 5 into a collection of verification tasks in task F2#3&111 of Figure 2. This must be done for each of the three verification phases (system, item qualification, and item acceptance) but these three phases can be discussed generically because they are essentially the same. As noted earlier, there are four generally accepted methods of verification (test, analysis, demonstration, and examination) to which we may add “none”. So, the first problem is to partition all requirements by method. In each specification there should be a verification traceability table linking each requirement in Sections 3 and 5 with one or more corresponding requirements in Section 4. The Section 3 requirements provide the design engineer with the essential characteristics of the entity they must complete a design for. Section 4 tells the requirements for the verification task where it will be determined to what extent the entity design complies with the entity requirements. Further this table should define the method to be used in that verification task.

The “None” method subset is composed of all of those specification paragraphs consisting of only a paragraph number and title with no accompanying sentences or containing sentences that fail to define essential characteristics that the design must possess. In the author’s specification template, Paragraph 3.1 and all of the content of its sub-paragraphs would also be excluded, since it deals with introductory information and reference to the modeling approach employed through which the remaining content of Section 3 was derived. The content of Paragraph 3.2 dealing with performance, Paragraph 3.3 dealing with interfaces, Paragraph 3.4 dealing with specialty engineering, and Paragraph 3.5 dealing with environmental requirements containing shall statements would be included in the set of requirements that must be verified. Each of these will have a method prescribed in the verification traceability table in the specification.

The challenge for the person or persons responsible for designing the verification work is to collect the requirements into groups with the same method that are related in some way such that they can all be verified applying a common approach, equipment, technique, and/or personnel.

Commonly, it works out best if all of the requirements in a specification are verified in a set of tasks that are focused on the content of that specification. Cases may arise where it is possible to best achieve the desired outcome from the overall verification activity by covering the content of parts of multiple specifications in single tasks that bridge the boundaries of single specifications. For example the author has seen all of the reliability, availability, and maintainability verification work for the whole system and all of its parts bundled into a single task and report. Similarly, a system mass properties task can be organized so that it is reported at the system level where everything is weighed and reported upon in a single report. While organizing tasks relative to product entities is a good norm, to deny the team access to promotion or demotion of requirements across entity boundaries does run the risk of increasing verification cost.

As each task is identified and a principal engineer named, that engineer should be provided with a list of requirements they must provide compliance data for in a task report containing the table showing how those requirements map to the content of the report. This simple move of providing each task principal with a list of requirements and requiring that that principal’s report trace the requirements to report content will pay dividends as the verification work is completed and is audited by the customer.

Prepare Task Plan

The principal task engineer begins the process of preparing a task plan by making a copy of the enterprise Verification Task Plan template for the method to be applied and identifying it relative to the entity and task assigned. The tasks can be assigned at any level in the system from system level to the lowest entity where verification is required on the program. The principal will have received a table from system engineering identifying the requirements that correspond to the task involved and must place this table in the plan coordinated, as the plan content matures, with the paragraphs, figures, and tables where task activity produces insight into the degree of proven product compliance with listed requirements.

It is critically important that the plan include the verification table given to the principal engineer that lists all of the requirements for which the task must produce evidence of compliance. The reason for this is that principal engineers tend not to focus adequately on establishing a clear traceability path between the requirements and the evidence of compliance included in the report, leading to a considerable waste of time on the part of the system engineers who must make these connections. Where some time passes between the completion of a report and efforts to submit evidence of compliance to the customer, it will be more difficult to make these connections because the principal engineer may have been reassigned to another program and not be available to assist.

Once a plan has been completed it should be reviewed and approved or rejected for correction by the principal engineer. Once approved, the plan should be placed under configuration control such that the master may not be altered without review and approval.

Prepare Task Procedure

As soon as the plan is approved the principal can begin preparation of the task procedure that contains step-by-step instructions for accomplishing the task. In some cases this may be as simple as a single sentence such as “Place item on a calibrated scale and read scale.” In other cases, especially involving tests, the procedure may be very involved requiring multiple people to accomplish steps coordinated with responses from prior steps and dynamic performance of the product under test.

The completed procedure must be reviewed and approved followed by placement under configuration management control. The review must include coordination with the plan such that it is clear that the procedure and plan are mutually consistent. Changes to the procedure, like the plan, must be reviewed and approved and placed under configuration item control before the procedure is employed to control work on a verification task.

Task Accomplishment and Reporting

Figure 3 shows an activity diagram for accomplishing the planned task and reporting upon the results. As the time for implementation of the verification task approaches on the schedule, the task principal engineer must ensure that resources planned for availability in support of the task will be available and in good condition. This may include training some task personnel if test or demonstration is the method of verification.

As the task is accomplished, a record of results is kept with particular attention to pass-fail criteria for each step and the map of task results relative to requirements, so as to ensure that the report covers compliance evidence. The map is passed to system engineering and results are entered in the VCRM data by system engineering.

The principal engineer prepares the task report including the map and passes it on for review and approval. The approved plan is placed under configuration management control. Part of the review and approval process is for a system engineer involved in the verification work who checks the evidence in the report that is referenced in the map to see if the evidence is convincing.

Upon completion of any verification task the principal engineer has a responsibility to prepare a report of findings. This report should include the table provided to the principal engineer with report references to the evidence contained in the report for each requirement mapped to that task.

Program Verification Reporting and Auditing

In addition to the reporting that principal engineers do regarding the task they are responsible for, the customer must be kept informed about the progress of the verification work and in the end for each of the phases (item qualification, system, and item acceptance) the customer may require the contractor to provide them with an audit of the verification evidence. So, we will break this discussion down into those three parts after a few words about in-process reporting.

Figure 3 Accomplish Verification Task

Verification Management

Requirements verification work seeks to provide clear evidence of the degree of compliance between the requirements for a system entity and the degree of entity compliance with those requirements. All verification work deals with comparisons between an entity of interest and a standard of excellence in the form of the requirements that were intended to supply the design engineer the minimum essential characteristics for the design. This comparison must be accomplished with full attention focused on the truth, avoiding any temptations to shade the results untruthfully in the favor of cost or schedule limitations. Those limitations will become a real problem only to the degree that verification design was accomplished badly or not at all.

Activity A2#35 shown on Figure 1 is a continuation of this same activity from the systems requirements work earlier in a program and should provide programs with a single requirements and verification tool set so as to provide for maximum integrity of the data. This set should embrace all of the requirements for system, hardware, and software. This common repository would ideally provide for the hierarchical and modeling traceability, VCRM record keeping, publishing specifications, ad hoc access, and management support. In the most expansive form this tool set would also provide for verification plans, procedures, and reports as well with all of the inter-document traceability discussed elsewhere in this paper.


Developing a set of integrated verification plan, procedure, and report documents for each entity where verification is necessary has in my experience provided the best approach. Major verification activities include verification planning, designing a verification process for each entity, preparing the task plan, preparing the task procedure, task accomplishment and reporting, program verification reporting and auditing, and verification management. Performing these steps will result in an affordable systems verification activity.

Systems Engineering News

Requirements Engineering and Business Analysis: State of Practice Study

Dr. Samuel A. Fricker, Blekinge Institute of Technology,, is conducting a scientific survey to understand the current state of art in requirements engineering/business analysis and how it has evolved. The landing page after the survey gives an initial overview of the responses to the survey, and hence allows comparison with others. Detailed analysis follows the conclusion of data collection.

More information and the survey

Fujitsu Establishes New Regional Systems Engineering Companies

Launch of Fujitsu Systems East and Fujitsu Systems West marks reorganization and integration of Fujitsu's regional systems engineering companies. Fujitsu has announced the reorganization of its regional systems engineering (SE) companies - four companies in eastern Japan and six companies in western Japan - with the two new organizations to be known as Fujitsu Systems East Limited and Fujitsu Systems West Limited, respectively. As regional SE operations for the Fujitsu Group, the two newly integrated companies, together with Fujitsu Kyushu Systems Limited, which was formed in April 2009, will be the backbone of Fujitsu's solutions and systems integration business.

More Information

SysML Versions 1.3 and 1.4

Version 1.3 of the systems engineering modeling language SysML will be published in a few weeks time. Development of a version 1.4 is underway. The full scope of changes incorporated in version 1.3 is not publicly available. Most changes appear to be in the area of ports. The goals for version 1.4, similarly, are not publicly available.

A full report on SysML 1.3 will be published in SyEN once this version of the language is formally released.

INCOSE Brasil Chapter Formed

The Brazil INCOSE Chapter and its Board of Directors was established on 26th March, 2012, at a meeting of INCOSE members in São José dos Campos, SP, Brasil. The necessary bureaucratic process to create a formally legalized entity under Brazilian Law has now commenced, with an expectation of completion by July 2012. Professor Geilson Loureiro and Dr. George Sousa are respectively President and Vice-President elect.

Vitech Corporation and INCOSE Announce that 2012 Fellowship Award Application Process is Now Open

Vitech Corporation has announced that the application process is now open for the James E. Long Memorial Post-Doctoral Fellowship Award, established by the International Council on Systems Engineering (INCOSE) Foundation. Honoring and recognizing the many contributions to the field of systems engineering by Jim Long, Vitech's former CEO, the yearly fellowship will be awarded at the 22nd annual INCOSE International Symposium in Rome, July 9-12, where nearly 1,000 of the world's leading systems engineers will gather. The $5,000 award supports post-doctoral research with the potential to advance the state of the art in systems thinking or the systems perspective, or advance the practice of systems engineering.

More information

Ask Robert

Question: Is the objective of systems engineering to reduce risk?
An objective of systems engineering to reduce risk. The objective of systems engineering is to maximize value delivery to the applicable (primary) stakeholders.

Question: Is it useful to regard a project plan as a system?
Answer: While technically a project plan is a system, no, it is not useful to view a project plan as a system.

What is enormously valuable is to view a project plan as a description of a system, specifically a description (design) of a project system. When that view is taken, it suggests that systems engineering principles and practice can, and should, be applied to project planning (and re-planning). An examination of historical project failures and the associated reasons, on which there is a plethora of data, support the conclusion.

The project manager, in the role of planner, can and should be regarded as the systems engineer of the project system.

Robert Halligan, FIE Aust

Featured Society

International Federation of Automatic Control

The International Federation of Automatic Control (IFAC), founded in 1957, is a multinational federation of National Member Organizations (NMOs), each one representing the engineering and scientific societies of its own country which are concerned with automatic control. The aims of the IFAC are to promote the science and technology of control in the broadest sense and in all systems, whether, for example, engineering, physical, biological, social or economic, in both theory and application. IFAC is also concerned with the impact of control technology on society.

IFAC pursues its purpose by organizing technical meetings, by publications, and by any other means consistent with its constitution and which will enhance the interchange and circulation of information on automatic control activities. International World Congresses are held every three years. Between congresses, IFAC sponsors many symposia, conferences and workshops covering aspects of automatic control.

The technical areas covered by IFAC are addressed by IFAC's Technical Committees. These Committees are responsible for the planning and monitoring of the technical events, such as symposia, conferences and workshops, with the NMOs acting as hosts. The technical areas are also promoted by the Technical Committees in other ways, such as establishing contacts with other international organizations, and publication of reports on selected topics.

The current Technical Committees are:

CC 1 - Systems and Signals
TC 1.1. Modeling, Identification and Signal Processing
TC 1.2. Adaptive and Learning Systems
TC 1.3. Discrete Event and Hybrid Systems
TC 1.4. Stochastic Systems
TC 1.5. Networked Systems

CC 2 - Design Methods
TC 2.1. Control Design
TC 2.2. Linear Control Systems
TC 2.3. Non-Linear Control Systems
TC 2.4. Optimal Control
TC 2.5. Robust Control
TC 2.6. Distributed Parameter Systems

CC 3 - Computers, Cognition and Communication
TC 3.1. Computers for Control
TC 3.2. Computational Intelligence in Control
TC 3.3. Telematics: Control via Communication Networks

CC 4 - Mechatronics, Robotics and Components
TC 4.1. Components and Technologies for Control
TC 4.2. Mechatronic Systems
TC 4.3. Robotics
TC 4.5. Human Machine Systems

CC 5 - Manufacturing and Logistics Systems
TC 5.1. Manufacturing Plant Control
TC 5.2. Manufacturing Modeling for Management and Control
TC 5.3. Enterprise Integration and Networking
TC 5.4. Large Scale Complex Systems

CC 6 - Process and Power Systems
TC 6.1. Chemical Process Control
TC 6.2. Mining, Mineral and Metal Processing
TC 6.3. Power and Energy Systems
TC 6.4. Fault Detection, Supervision & Safety of Technical Processes

CC 7 - Transportation and Vehicle Systems
TC 7.1. Automotive Control
TC 7.2. Marine Systems
TC 7.3. Aerospace
TC 7.4. Transportation Systems
TC 7.5. Intelligent Autonomous Vehicles

CC 8 - Bio- and Ecological Systems
TC 8.1. Control in Agriculture
TC 8.2. Biological and Medical Systems
TC 8.3. Modeling and Control of Environmental Systems
TC 8.4. Biosystems and Bioprocesses

CC 9 - Social Systems
TC 9.1. Economic and Business Systems
TC 9.2. Social Impact of Automation
TC 9.3. Developing Countries
TC 9.4. Control Education
TC 9.5. Supplemental Ways of Improving International Stability.

IFAC activities are for everyone interested in control engineering research, development and education. About fifty National Member Organizations are involved in promoting and developing the area of control by organizing technical meetings and by publishing control literature - including Preprints and Proceedings of IFAC meetings, the IFAC Journals Automatica, Control Engineering Practice, Annuals Review in Control, Journal of Process Control and Engineering Applications of Artificial Intelligence, and a number of affiliated journals.

More information

INCOSE Technical Operations

Motor Sports Working Group

Leverage the excitement and enthusiasm inherent in motor sports to accelerate learning about systemics, science, technology, engineering and mathematics and other subjects.

Chair: Jack Ring
Co-chair: Bill Mackey
Contact jack.ring (at) for additional information or to join this group.

Planned Work
Evolve an SE in Motor Sports 101 syllabus
Compile multimedia for use in classrooms
Devise a series of modeling exercises
Work with schools and sponsors to encourage adoption of the motor sports advantage

Published Products
MSWG Charter
MSWG Backgrounder
Draft syllabus “What Does It Take to Get to the Checkered Flag?”

Presentations and Links
2008 International Workshop Motor Sports WG Summary Presentation Size: 200K

Systems Engineering Tools News

Additions to Requirements Management Tools List

SpecWave modeling system
tracecloud A RM tool
RequirementOne A web-based RM service

TEEC® Releases SpecWave® - A Specification Modeling System for Engineering Projects

TEEC, The Engineering Essentials Company, has announced the release of SpecWave® 2012, a specification modeling system. TEEC, and its SpecWave technology aim to help architectural and engineering firms speed and improve:
Master specification clean-up and ongoing management,
Project specification production
Multi-purpose publishing to specification end-users
Change management to specifications in the field, and
Update and re-use of lessons learned and field improvements into master specifications.

More Information

Visure Solutions Announces Test Management Extension for IRQA

Visure Solutions has integrated test management into its IRQA requirements engineering solution. With this addition to IRQA, developers of safety- and mission-critical software can automate end-to-end requirements traceability, with fulfilled tests providing the evidence points needed for regulatory certification.

More Information

LDRA Integrates Requirements Engineering Tool into LDRA Tool Suite

LDRA has announced the integration of Visure Solutions’ IRQA requirements engineering tools with TBmanager, a test management and traceability component within the LDRA tool suite. This integration eases regulatory compliance by providing transparent, end-to-end traceability from system requirements to verification and validation for safety- and mission-critical software. Process-oriented standards, such as DO-178C and ISO 26262, mandate that all source code and validation tests be traceable to requirements. This mandate ensures that the embedded software fulfills all requirements, operates correctly, and has no extraneous code not associated with a requirement.

More Information

Control Model-Based Systems Engineering with SysML Design Quality Metrics

The release of SDMetrics V2.3, a software design quality measurement tool for the Unified Modeling Language (UML), was announced in late March 2012. SDMetrics measures structural design properties such as coupling, size, and complexity of UML designs. SDMetrics also checks design rules to automatically detect incomplete or incorrect design, and adherence to style guidelines such as circular dependencies or naming conventions. Software developers use this information to focus their design reviews, design refactoring, and testing efforts on the potentially critical areas that are likely sources of reliability or maintainability problems in their software designs. SDMetrics V2.3 adds support for analyzing UML models that are extended by UML profiles. A prominent example of a UML profile is the Systems Modeling Language (SysML). The SysML adds common concepts from model-based systems engineering (MBSE) to the UML. SDMetrics users can define custom design metrics and rules to take these extensions into account. The support for UML profiles such as SysML extends the scope of SDMetrics V2.3 beyond software system design. Systems engineers need model-based metrics to manage large-scale projects. SysML metrics are an important input to design and development effort estimation, and monitoring of design and development progress. SysML design rules assess the completeness, correctness, and consistency of SysML models. SDMetrics V2.3 provides systems engineers with SysML metrics and rules that are custom-tailored to their local MBSE processes.

More Information

TOPCASED 5.1.0 Now Available

TOPCASED 5.1.0, an open-source toolkit for critical systems, is now available. The new release is based on the latest Eclipse 3.7.1 platform (Indigo).

Critical Systems Topcased is a software environment primarily focused on the realization of critical embedded systems which include hardware and/or software. Modeling Topcased promotes model-driven engineering and formal methods as key technologies.

Open-source Topcased is released as free open-source software by a group of partner organizations which include Airbus France, EADS Astrium, Rockwell Collins, and Thales.

More Information

Open source MBSE Plugin for MagicDraw with SysML

The INCOSE Telescope modeling challenge team has released version 1.1. of its MBSE plugin for MagicDraw with SysML. The Plugin for the MagicDraw modeling tool provides support for model based document generation which ties together system model and documents to keep them up to date and consistent, using a AWYSIWYG editor in MagicDraw. The plugin provides basic support to model variants and extract variants from a system model. It also provides support to generate organizational structures. The plugin provides basic pattern based support to reason on a system model, for example to extract numbers like total power, cost, power consumption for a given product tree.

The MBSE plugin for MagicDraw requires MagicDraw 17.0 SP4 or higher with an installed SysML plugin 17.0 SP5 or higher.

More Information

Systems Engineering Books, Reports, Articles and Papers

Engineering Mega-Systems: The Challenge of Systems Engineering in the Information Age

Renee Stevens

Published by: Auerbach Publications
ISBN: 9781420076660
Publication Date: July 15, 2010

Abstract: With their ability to cross traditional boundaries and achieve a level of functionality greater than their component elements, mega-systems have helped corporations and government organizations around the world resolve complex challenges that they otherwise couldn’t address with stand-alone systems. This book provides a clear understanding of the engineering of this class of systems—a process that demands consideration of increasing program scale and the rapid change of underlying technologies. The author is a Senior Principal Engineer at The MITRE Corporation with decades of experience analyzing, engineering, and acquiring large-scale systems for the U.S. Department of Defense and other government agencies. The book explains how the engineering of mega-systems is inherently different from that of large-scale monolithic systems. It supplies the vocabulary and framework needed to explore the issues relevant to mega-systems. This framework then evolves into the Profiler diagnostic tool that helps you understand the nature and context of the system at hand and, on that basis, select the most appropriate processes, tools, and techniques. Stevens examines commercial and government applications of mega-systems to provide insight into the contemporary challenges of engineering these systems in three critical dimensions: engineering processes, management processes, and the larger context in which these systems are developed and deployed. Complete with two case studies in engineering mega-systems that illustrate valuable lessons learned and highlight emerging practices, this book supplies the understanding and the tools needed to begin engineering, characterizing, and acquiring mega-systems across multiple dimensions.

More Information

Engineering a Safer World: Systems Thinking Applied to Safety

Nancy G. Leveson

Published by: The M-T Pre-s
ISBN: 0262016621

Engineering has experienced a technological revolution, but the basic engineering techniques applied in safety and reliability engineering, created in a simpler, analog world, have changed very little over the years. In this book, Nancy Leveson proposes a new approach to safety that is more suited to today's complex, sociotechnical, software-intensive world--based on modern systems thinking and systems theory. Revisiting and updating ideas pioneered by 1950s aerospace engineers in their System Safety concept, and testing her new model extensively on real-world examples, Leveson has created an approach to safety that is more effective, less expensive, and easier to use than current techniques. Arguing that traditional models of causality are inadequate, Leveson presents a new, extended model of causation (Systems-Theoretic Accident Model and Processes, or STAMP), then shows how the new model can be used to create techniques for system safety engineering, including accident analysis, hazard analysis, system design, safety in operations, and management of safety-critical systems. She applies the new techniques to real-world events including the friendly-fire loss of a U.S. Blackhawk helicopter in the first Gulf War; the Vioxx recall; the U.S. Navy SUBSAFE program; and the bacterial contamination of a public water supply in a Canadian town. Leveson's approach is also useful in offering techniques for "reengineering" any large sociotechnical system to improve safety and manage risk.

More information

Conferences and Meetings

Workshop on Requirements Engineering (WER’12)
April 24 - 27, 2012, Buenos Aires This workshop will be held in parallel with CIbSE'12 and ESELAW¹12.
More information

International Conference on Industrial Engineering and Systems Management (ICIESM) 2012
April 25 - 26, 2012, Paris France
More information

CMMI Made Practical 2012
April 26 - 27, 2012 London, UK
More information

April 30 - May 2, 2012, Brisbane Convention and Exhibition Centre, Brisbane, QLD, Australia
More information

Software Engineering Institute Architecture Technology User Network (SATURN) 2012 Conference
May 7 - 11, 2012, St. Petersburg, FL, USA
More Information

Lean Software and Systems 2012
May 13 - 18 2012, Boston, MA USA
More information

1st Annual Systems Engineering in the Washington Metropolitan Area Conference (SEDC 2012)
May 14 - 16, 2012, George Mason Inn and Conference Center, Washington, USA
More information

2012 Industrial and Systems Engineering Research Conference
May 19 - 23, 2012, Orlando, Florida
More information

Risk Engineering Society Conference: RISK 2012
May 23 - 24, 2012, Lovedale, NSW, Australia
More information

12th International Design Conference Design 2012  
May 21 - 24, 2012, Dubrovnik, Croatia
More information

Systems thinking for solving complex problems
May 24, 2012, James Cook Hotel Grand Chancellor Wellington, New Zealand
More information

Australian System Safety Conference 2012
May 23 - 25, 2012, Brisbane, Australia
More information

12th International SPICE Conference on Process Improvement and Capability determination in Software, Systems Engineering and Service Management
May 29 - 31, 2012, Palma de Mallorca, Spain
More Information

Engineering Leadership Conference (ELC 2012)
May 30 - June 2, 2012, Adelaide, Australia
More information

International Conference on Software and Systems Process (ICSSP) 2012
June 2 - 3, 2012, Zurich, Switzerland (co-located with ICSE 2012)
More Information

2012 First International Workshop on Usability and Accessibility Focused Requirements Engineering (UsARE)
June 4, 2012, Co-located with ICSE'12 - University of Zurich, Zurich, Switzerland
More information

SEPG Europe 2012new
June 5 - 7, 2012, Madrid, Spain
More information

119th American Society for Engineering Education (ASEE) Annual Conference & Exposition
June 10 - 13, 2012, San Antonio, Texas, USA
More information

Kongsberg Systems Engineering Event (KSEE)
June 14 - 15, 2012, Høgskolen i Buskerud, Kongsberg, Norway
More information

The Third International Symposium on Engineering Systems - CESUN 2012
June 18 - 20, 2012, Delft, The Netherlands
More information

iFM2012 ABZ 2012 - Abstract State Machines 
June 18 - 22, 2012, CNR Research Area of Pisa, Italy
More information

12th International School on Formal Methods for the Design of Computer, Communication and Software Systems: Model-Driven Engineering (SFM-12:MDE)
June 18 - 23, 2012, Bertinoro Italy
More Information

GfSE User Forum: MBSE in practice - challenges
June 22, 2012, Hamburg, Germany
More information

International Conference on Business Process Modeling, Development, and Support (BPMDS 2012), the 13th edition of the BPMDS series, held in Conjunction with Conference on Advanced Information Systems Engineering (CAiSE’12)
June 25 - 26 2012, Gdansk, Poland
More information

3rd IEEE Track on Collaborative Modeling and Simulation (COMETS 2012)
June 25 - 27, 2012, Toulouse, France
More information

EuroSPI 2012 Conference/19th EuroSPI Conference - European Systems and Software Process Improvement and Innovation
June 25 - 27, 2012, Vienna University of Technology, Austria
More information

PETRI NETS 2012 - 33rd International Conference on the Application and Theory of Petri Nets and Concurrency 
June 25 - 29, 2012, Hamburg, Germany
More information

12th International Conference on Application of Concurrency to System Design (ACSD 2012)
June 27 - 29, 2012, Hamburg, Germany
More Information

8th European Conference on Modelling Foundations and Applications
July 2 - 5, 2012, Technical University of Denmark, Denmark
More information

The World Congress on Engineering 2012
July 4 - 6, 2012, London, United Kingdom
More information

INCOSE International Symposium (IS) 2012 
July 9 - 12, 2012, Rome, Italy
More information

Interdisciplinary Network for Group Research (INGRoup) - Seventh Annual Conference
July 12 - 14, 2012, Chicago, IL, USA
More information

IEEE SOSE 2012 7th International Conference on System of Systems Engineering
July 16 - 19, 2012, Genoa, Italy
More information

International Conference of the System Dynamics Society, 2012
July 22 - 26, 2012, St. Gallen, Switzerland
More Information

4th Improving Systems & Software Engineering Conference (ISSEC) 2012
August 15 - 16, 2012, Melbourne, Australia
More information

Workshop on Model-Driven Engineering for Networked Ambient System (MDE4NAS)
August 27 - 29, 2012, Niagara Falls, Canada
More information

18th International Symposium on Formal Methods
August 27 - 31, 2012, CNAM, Paris, France
More information

Sixth IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO 2012)
September 10 - 14, 2012, Lyon, France
More information

International Workshop on Enterprise Integration, Interoperability and Networking (EI2N'2012)
September 12 - 13, 2012, Rome, Italy
More information

10th International Conference on Formal Modeling and Analysis of Timed Systems (FORMATS 2012)
September 18 - 20, 2012, London, United Kingdom
More information

12th International Workshop on Automated Verification of Critical Systems (AVoCS 2012)new
September 18 - 20, 2012, Otto-Friedrich University in Bamberg, Germany
More information

20th International Requirements Engineering Conference (RE 2012)
September 24 - 28, 2012, Chicargo, Illinos, USA
More information

MODELS 2012, ACM/IEEE 15th International Conference on Model-Driven Engineering Language & Systems
September 30 - October 5, 2012, Innsbruck, Austria
More Information

6th INCOSE Annual Great Lakes Regional Conference 2012new
October 12 – 13, 2012, Schaumburg, Illinois, USA
More information

World Engineering Education Forum (WEEF12)
October 15 - 18, 2012, Buenos Aires, Argentina
More information

Human Factors and Ergonomics Society HFES 2012 Annual Meeting
October 22 - 26, 2012, Boston, MA, USA
More information

October 23 - 25, 2012, Paris, France
More information

The World Congress on Engineering and Computer Science 2012 
October 24 - 26, 2012, San Francisco, USA

Building Business Capabilities (BBC) 2012
October 28 - November 2, 2012, Fort Lauderdale, FL, USA
More information

12th Annual CMMI Technology Conference and User Group new
November 5 – 8, 2012, Denver, USA
More information

INCOSE UK Annual Systems Engineering Conference 2012
November 7 - 8, 2012, London, UK
More information

Systems Engineering Day 2012 (TdSE 2012)
November 7 - 9, 2012, Paderborn, Heinz Nixdorf Museums Forum, Germany.
More information

14th International Conference on Formal Engineering Methods (ICFEM 2012)new
November 12 - 16, 2012, Kyoto Research Park, Kyoto, Japan
More information

3rd International Conference on Complex Systems Design & Management (CSD&M 2012)
December 12 - 14, 2012, Cité Internationale Universitaire, Paris (France)
More information

INCOSE International Workshop IW2013
January 26 - 29, 2013, Jacksonville, Florida USA
More information

19th World Congress of the International Federation of Automatic Control (IFAC 2014)
August 24 - 29, 2014, Cape Town, South Africa
More information

Education and Academia

University of South Alabama (USA) is now offering a PhD in Systems Engineering​

The University of South Alabama has received approval from the Alabama Commission on Higher Education to offer a Doctor of Science in Systems Engineering degree beginning in 2013. With a focus on applied research, it will be the first doctoral program offered by the USA College of Engineering. “The Doctor of Science in Engineering represents the continued maturing of the breadth and scope of the University of South Alabama’s academic offerings,” said USA President Gordon Moulton. “This program is important because it meets the needs of industry, stimulating the growth of clean and sustainable jobs in the Mobile region and beyond.”

More information

Advanced Modeling & Simulation Techniques for Multi-body Robotic Systems

This webinar introduces new techniques and case studies for efficiently increasing the fidelity of system models for multi-body robotic system design. Using symbolic computation techniques, multi-body models can be effectively preprocessed to select optimal coordinate frames, eliminate redundant calculations, simplify algebraic constraints, and generate computationally minimal code for real-time deployment. Furthermore, novel mathematical techniques can be deployed for efficient parameter optimization and other advanced analysis. Applications in robotics, including space and industrial robotics will be presented. The symbolic computation system Maple and the related modeling system MapleSim will be used to illustrate examples.

More Information

Some Systems Engineering-Relevant Websites
This is the website of Open Services for Lifecycle Collaboration (OSLC), an open community dedicated to making it easier to use software lifecycle tools in combination. phase-two-whitepaper-2.html
These blog pages contain an evaluation of requirements management tools.
This is a commercial site which provides many useful requirements resources, oriented towards software and business systems.
This is the home page of DACS, the Data & Analysis Center for Software, a U.S. Department of Defense (DoD) Information Analysis Center (IAC). As an IAC, the DACS is a Center of Excellence, and a technical focal point for information, data, analysis, training, and technical assistance in software-related technical fields. The site contains much systems-related content, including a Software & Systems Cost and Performance Analysis Toolkit, a Software Engineering Bibliographic Database (SEB), and an Acronym Database.
This site provides access to the U.S. Defense Standardization Program documents obtained from the official DoD repository, the ASSIST database. The site provides access to and status information on many systems engineering-related U.S. DoD documents.
This is the website of the VASY team of INRIA Rhone-Alpes. The team develops formal methods for safety-critical systems, notably formal specification languages and associated methodologies, compiling and rapid prototyping techniques, simulation, validation, verification, and testing.
This is Tim Weilkiens' MBSE Blog. Well worth a read.

Standards and Guides

Status of Update to EIA-STD-632 “Processes for Engineering a System”

This systems engineering standard supported by TechAmerica has been in revision for some time. The revision (Rev A) is in non-final draft form, ready for TechAmerica Committees to review. Core process content is done, and work is in progress to align the standard with ISO/IEC 15288, clean up input/output connectivity, and finalize Annexes.

TechAmerica G47 is proposing within TechAmerica an architecture of standards as follows, related to ISO/IEC 15288:
EIA-632A provide a lower level of connected process detail to that in ISO/IEC 15288, aligned with ISO/IEC 15288
Other TechAmerica standards provide the next level of detail below EIA-632, or, if content isn’t addressed in EIA-632A, below ISO/IEC 15288.

TechAmerica Standard on Joint Technical Reviews and Audits?

MIL-STD-1521B on technical reviews and audits was cancelled in the mid 1990s. Subsequently, Electronic Industries Alliance (EIA), now subsumed into TechAmerica, started work on development of such a standard. However, the project was subsequently discontinued.

TechAmerica G47 has recommended that the project be reactivated, either to produce a Technical Bulletin or a Standard.

SE Body of Knowledge (SEBoK) v0.75

The review period of the Systems Engineering Body of Knowledge (SEBoK) V0.75 has concluded. This is the last draft version up to Version 1 that will have a public review period prior to its release.

The SEBoK has been supported by many organizations. The authors have gratefully acknowledged them, most importantly, INCOSE, the IEEE Computer Society, the IEEE Systems Council, the Association for Computing Machinery, the U.S. National Defense Industrial Association, the Institute of Industrial Engineers, and the Systems Engineering Research Center. Primary funding was provided by the U.S. DoD Office of the Deputy Assistant Secretary of Defense for Systems Engineering, with significant contributions in kind coming from the home organizations of the authors.

More information on SEBoK

TRAK Open Source Enterprise Architecture Framework

TRAK is a general systems-thinkers'/system-centric enterprise architecture framework. It is simple, user-friendly, pragmatic and not limited to information technology. TRAK allows a TRAK user to describe a system, its parts (which can include people, software, other systems and physical things) and how it relates to the residual world. TRAK covers everything from the enterprise and its goals, to the concept to the procurement of the solution via projects, and the introduction or withdrawal of the system from service.

TRAK is a derivative of U.K. Ministry of Defense’s MODAF 1.2, but is based on ISO/IEC 42010 - the international standard for architecture description. There is a minimal process in which the architect selects the viewpoints (specifications for views) that address the task sponsor's concerns. TRAK has rules that ensure that the description is consistent, and is also readable by a non technical audience.

TRAK can be implemented in a wide range of modeling tools and architecture description languages (a term taken from ISO 42010), such as UML, BPMN. These can be used to represent parts of the TRAK metamodel and therefore can be used in creating TRAK architecture views.

There are five implementations of TRAK on Sourceforge (please see the link below):
UML profile for TRAK. Provides a set of objects and relationships for any UML modeling tool
MDG Technology for TRAK. Provides the views, toolbox palettes, custom searches and context-sensitive linking for Sparx Systems' Enterprise Architect UML modeling tool
TRAK MooD 2010 Template. Provides a template through which TRAK views can be created using Salamander MooD modeling tool and is constrained to use object and relationship types from the TRAK metamodel
OmniGraffle Stencil for TRAK. A stencil that provides the stereotype objects and connectors for OmniGroup's OmniGraffle (a Visio-like tool for Mac).
TRAK Visio Template.

There may be other implementations of TRAK outside of Sourceforge.

Release of the TRAK Viewpoints is under the control of the TRAK Steering Group, chaired by the U.K. Department of Transport.

More information

A Definition to Close On: Function

Function: an activity or purpose natural to or intended for a person or thing

Function: the action for which a person or thing is particularly fitted or employed

Function: the kind of action or activity proper to a person, thing, or institution; the purpose for which something is designed or exists; role

Function: a task, action, or activity that must be accomplished to achieve a desired outcome
Source: ISO/IEC 24570:2005 Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis

Function: a defined objective or characteristic action of a system or component
Source: ISO/IEC 24765:2008 Systems and software engineering vocabulary

Editors Note: SyEN 42: System(s) of Systems, System(s) of Systems Engineering (SoSE)
In the March 2012 edition of SyEN, a definition of System of Systems was attributed to Sage and Cuppan (2001), and the reference does include the definition. The origin of the definition is, however, Maier, Mark W. 1998, “Architecting Principles for System-of-systems.” Systems Engineering 1 (4): 267–284. Thanks to Dr. Clifton Baldwin for pointing this out.

PPI News (see

PPI at DSA 2012

PPI is proudly exhibiting at the 13th Defence Services Asia Exhibition & Conference, Kuala Lumpur, Malaysia, over 16 - 19 April 2012, under the Team Australia pavilion.

PPI Exhibiting at SSTC, Salt Lake City

PPI is proudly exhibiting at the Systems and Software Technology Conference 2012 over 23 - 24 April in Uhah, USA. To our friends attending, feel free to stop by and visit out booth!

PPI/CTI Expands in USA

We are delighted to announce that Mr. David Mason has joined the PPI/CTI team. David has extensive systems engineering experience, mostly in the space sector. David combined his education, systems engineering, Lean Six Sigma (LSS) and project management, to lead to teams in the field of system integration, mainly with Lockheed.

David’s academic accomplishments include a Bachelor of Science (BSBA) in Production and Operations Management, and a Master of Science (MSBA) in Quantitative Business Methods.

A member of INCOSE since 1998, David was the San Francisco Bay Area Chapter President in 2009 when the Chapter earned the ‘President’s Award’ for Most Improved Chapter. David is an INCOSE Certified Systems Engineering Professional (CSEP), and presented CTI’s CSEP training course in San Diego over 26 - 29 March 2012. Since February 2008, David has served as the INCOSE Assistant Director for the Student Division.

PPI Events (see

Systems Engineering Public 5-Day Courses
Upcoming Locations Include:

Melbourne, Australia
Pretoria, South Africa
Las Vegas, USA
Amsterdam, The Netherlands

Requirements Analysis and Specification Writing Public Courses

Upcoming Locations Include:

Adelaide, Australia
Melbourne, Australia
Amsterdam, The Netherlands
Stellenbosch, Australia

Software Engineering Public 5-Day Courses

Upcoming Locations Include:

Sydney, Australia
Pretoria, South Africa
Amsterdam, The Netherlands

OCD/CONOPS Public Courses

Upcoming Locations Include:

Pretoria, South Africa
Las Vegas, USA
Brasilia, Brazil

Cognitive Systems Engineering Courses

Upcoming Locations Include:

Adelaide, Australia
Las Vegas, USA

CSEP Preparation Course (Presented by PPI subsidiary Certification Training International)

Upcoming Locations Include:

Washington, USA
Las Vegas, USA
Austin, USA

PPI Upcoming Participation in Professional Conferences

PPI will be participating in the following upcoming events. We look forward to chatting with you there.

SETE/APCOSE 2012 | Exhibiting | Brisbane (30 April – 2 May 2012)
12th International Design Conference 2012 | Participating | Croatia (21 – 24 May 2012)
ICOMS Asset Management Conference | Participating | Hobart, Australia (4 – 8 June 2012)
INCOSE IS 2012 | Exhibiting | Rome, Italy (9 - 12 July, 2012)
Land Warfare Conference 2012 | Exhibiting | Melbourne, Australia (22 - 26 October, 2012)

Kind regards from the SyEN team:
Robert Halligan, Managing Editor, email:
Ralph Young, Editor, email:
Stephanie Halligan, Production, email:

Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 11 3230 8256
Tel UK: +44 20 3286 1995
Tel USA: +1 888 772 5174

Copyright 2012 Project Performance (Australia) Pty Ltd, trading as Project Performance International

Tell us what you think of SyEN: email to

If you do not wish to receive a copy monthly of SyEN in future, please reply to this e-mail with "Remove" in the subject line. All removals are acknowledged; you may wish to contact PPI if acknowledgement is not received within 7 days.

COPYRIGHT 2012 PROJECT PERFORMANCE (AUSTRALIA) PTY LTD, ABN 33 055 311 941. May only be copied and distributed in full, and with this Copyright Notice intact.

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.