Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 43


Quotations to Open On

Read More… (link/anchor to Quote)

Feature Article: An Affordable Systems Verification Activity

Read More…(link/anchor to article)

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…(link/anchor to News)

Ask Robert:

– Is the objective of systems engineering to reduce risk?

– Does it help to view a project plan as a system?

Read More…(Link/anchor to Ask Robert)

Featured Societies – International Federation of Automatic Control (IFAC),

Read More… (Link/anchor to Societies section)

INCOSE Technical Operations: Motor Sports Working Group

Read More…(link/anchor to INCOSE Tech…section)

Systems Engineering Tools News

TEEC® Releases SpecWave® – Spec Modeling System for Engineering Projects

Visure Solutions Announces Test Management Extension for IRQA

LDRA Integrates Requirements Engineering Tool into LDRA Tool Suite

Control Model-Based Systems Engineering with SysML Design Quality Metrics

TOPCASED 5.1.0 Now Available

Open source MBSE Plugin for MagicDraw with SysML

Read More… (Link/anchor to SE Tools section)

Systems Engineering Books, Reports, Articles, and Papers

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

Engineering a Safer World: Systems Thinking Applied to Safety

Read More…(link/anchor to SE Books, Articles…)

Conferences and Meetings

Read More…(link/anchor to Conferences section)

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…(link/anchor to Edu/Academia section)

Some Systems Engineering-Relevant Websites

Read More… (link/anchor to Websites)

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…(link to Standards & Guides section)

A Definition to Close on – TBD

Read More…(link/anchor to Definition)

PPI News

Read More…(link/anchor to PPI News)

PPI Events

Read More…(link/anchor to PPI Events)

Editor’s Note: 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.

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 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.

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

Feature Article


Jeffrey O. Grady

Owner JOG System Engineering

6015 Charae Street

San Diego, CA 92122


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, http://www.bth.se/com/sfr.nsf/pages/samuelafricker, 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 (embed hyperlink) http://bit.ly/re-practice

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 (embed hyperlink)


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 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 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 http://www.mfrtech.com/articles/25888.html

Ask Robert

Question: Is the objective of systems engineering to reduce risk?

Answer: 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: http://www.ifac-control.org/

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@incose.org 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

Addition to Requirements Management Tools List

SpecWave http://www.teecspecs.com/products.cshtml A specification modeling system

tracecloud http://www.tracecloud.com/GloreeJava2/jsp/WebSite/TCHome.jsp A RM tool

RequirementOne http://www.requirementone.com/Project-Management-Platform 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 (embed hyperlink)


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 (embed hyperlink)


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 (embed hyperlink)


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 (embed hyperlink)


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 (embed hyperlink) http://www.topcased.org

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 (embed hyperlink) https://sourceforge.net/projects/mbse4md/

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 (embed hyperlink) http://www.crcpress.com/product/isbn/9781420076660

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 (embed hyperlink)

Conferences and Meetings

2nd International Requirements Engineering Efficiency Workshop (REEW 2012)

March 19, 2012, Essen, Germany

More information

16th International GI/ITG Conference on Measurement, Modelling and Evaluation of Computing Systems and Dependability and Fault-Tolerance (MMB & DFT 2012)

March 19 – 21, 2012, Kaiserslautern, Germany

More information

CSER 2012 – Conference on Systems Engineering Research

March 19 – 22, 2012, St Louis, Missouri, USA

More information


March 25 – 29, 2012, Riva del Garda, Trento, Italy

More information

Fifth Edition of the Requirements Engineering Track (RE-Track’12)

Part of the 27th ACM Symposium on Applied Computing (SAC 2012)

March 25 – 29, 2012, University of Trento, Trento, Italy

More information

2nd International Workshop on Model-driven Approaches for Simulation Engineering.

Part of the Symposium on Theory of Modeling and Simulation, (SCS SpringSim 2012)

March 26 – 29, 2012, Orlando, FL, USA

More information

Symposium On Theory of Modeling and Simulation, TMS’12

Part of the 2012 SpringSim – Spring Simulation Multi-Conference

March 26 – 29, 2012, Orlando, FL, USA

More information

Software for Theory of Modeling & Simulation at TMS/DEVS’1 2

March 26 – 29, 2012, The Florida Hotel, Orlando, FL, USA.

More Information

2012 SpringSim – Spring Simulation Multi-Conference

March 26 – 30, 2012,  Orlando, FL, USA

More Information

Applied Ergonomics Conference 2012

March 26 – 29, 2012, Gaylord Opryland Resort and Convention Center, Nashville, TN, USA

More information

The 31st International Conference on Modelling, Identification and Control

April 2 – 4, 2012, Phuket, Thailand

More information

Fourth NASA Formal Methods Symposium (NFM 2012)

April 3 – 5, 2012, Norfolk, VA, USA

More Information

9th IEEE International Conference and Workshop on Engineering of Autonomic and Autonomous Systems (EASe 2011)

April 11 – 13, 2012, Novi Sad, Serbia, Europe

More Information

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

13-18 May 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 2012

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)

25-26 June 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

Eighth European Conference on Modeling Foundations and Applications (ECMFA)

July 2 – 3, 2012, Technical University of Denmark (DTU), Kongens Lyngby, Denmark

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

IS2012 Call for Papers: Deadline for draft papers, and proposals for panels and tutorials for IS2012 is November 8th, 2011.

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

19th World Congress of the International Federation of Automatic Control (IFAC 2014)

August 24-29, 2014, Cape Town, South Africa

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)

September 18-20, 2012, Otto-Friedrich University in Bamberg, Germany

More information

20th International Requirements Engineering Conference (RE 2012)

September 24-28, 2012, Chicago, Illinois, USA

RE 2012 includes the following workshops:

Model-Driven Requirements Engineering (MoDRE)

Requirements Engineering Education and Training (REET)

Requirements Patterns (RePa)

Requirements at Runtime (RE@Runtime)

Requirements Engineering and Law (RELAW)

Twin Peaks of Requirements and Architecture (TwinPeaks)

Requirements Engineering for Systems and Systems-of-Systems (RESS)

Empirical Requirements Engineering (EmpiRE)

Joint Call for Papers of eight RE’12 Workshops

The IEEE International Requirements Engineering Conference series (RE) is the premier international forum for researchers, educators, practitioners, and students to present and discuss the latest innovations, trends, experiences and concerns in the field of Requirements Engineering. Please consider submitting your work to the following RE’12 workshops (more detailed information of each workshop can be found below):

Important dates for all the RE’12 workshops:

Paper submission deadline: May 31, 2012

Notification of acceptance: July 13, 2012

Camera-ready submission deadline: August 6, 2012

Second International Model-Driven Requirements Engineering (MoDRE) Workshop

Webpage: http://cserg0.site.uottawa.ca/modre2012/

Organizers: Gunter Mussbacher (Carleton Univ., Canada), Joao Araujo (Univ. Nova de Lisboa, Portugal), and Pablo Sanchez (Univ. de Cantabria, Spain)

The second edition of the Model-Driven Requirements Engineering (MoDRE) workshop continues to provide a forum where researchers and practitioners can discuss the challenges of Model-Driven Development (MDD) for Requirements Engineering (RE). Building on the success of MDD for design and implementation, RE may benefit from MDD techniques when properly balancing flexibility for capturing varied user needs with formal rigidity required for model transformations as well as high-level abstraction with information richness.

MoDRE intends to identify new challenges, discuss on-going work and potential solutions, analyze the strengths and weaknesses of MDD approaches for RE, and survey existing literature on MDD for RE to stimulate discussions during the workshop.

Seventh International Workshop on Requirements Engineering Education and Training (REET)

Webpage: http://www.ecs.westminster.ac.uk/REET12

Organizers: Joy Beatty (Blue Ocean Services, USA), Ljerka Beus-Dukic (Univ. of Westminster, UK), and Sarah Gregory (Intel Corp., USA)

The Requirements Engineering Education and Training workshop will address issues related to RE education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a superficial discussion of curriculum issues and will examine specific ideas and techniques for teaching and assessing skills needed by an effective requirements engineer.

Second International Workshop on Requirements Patterns (RePa’12)

Official Webpage: http://www.utdallas.edu/~supakkul/repa12

Organizers: Lawrence Chung (Univ. of Texas at Dallas, USA), Barbara Paech (Univ. of Heidelberg, Germany), Liping Zhao (Univ. of Manchester, UK), Lin Liu (Tsinghua Univ. China), and Sam Supakkul (Sabre Inc., USA)

“Patterns” have been used to capture knowledge of software engineering, concerning software architectures, component designs and programs, and more recently requirements engineering. This workshop provides an open forum for researchers and practitioners to exchange ideas and experience, regarding pattern-based approaches to capturing, organizing, and reusing of all requirements engineering knowledge, from both process and product perspectives.

The RePa’12 Workshop solicits patterns that capture knowledge of requirements engineering processes and products. Examples of such patterns include, but not limited to, requirements modeling patterns, requirements engineering process/activity patterns, application/domain- specific requirements patterns, application/domain-independent requirements patterns, goal patterns, social patterns, scenario patterns (e.g. use cases, user stories), workflow patterns, business patterns, analysis patterns, functional requirements (FRs) patterns, non-functional requirements (NFRs) patterns, problem patterns (e.g. anti-patterns, miss-use patterns, fault patterns, attack patterns), and requirements to architecture/design mapping patterns.

This workshop also welcomes technical reports, including research and position papers, experience reports, empirical studies, case studies that report findings on requirements pattern-related topics, including, but not limited to, capturing, harvesting and mining, cataloging, organizing (e.g. by relationships such as uses, meta-pattern/occurrence, generalization/ specialization, and aggregation/decomposition), searching, selecting, reusing, applying requirements patterns, as well as pattern quality, management, and tool support.

Requirements @ Runtime

Official Webpage: http://sites.lero.ie/RRT12

Organizers: Yijun Yu (Open Univ. UK), Liliana Pasquale (Lero, Ireland), Nauman Qureshi (NUST, Pakistan), and Bashar Nuseibeh (Lero & Open Univ., Ireland & UK)

Requirements@run.time will explore a radical challenge to the traditional view of requirements models as static, slowly-evolving and purely design-time entities. Requirements@run.time will explore the potential for runtime abstractions and models of requirements as a practical means to address the challenges posed by volatile or poorly-understood environmental contexts. These include (e.g.) business environments that are subject to dramatic and unforeseen economic conditions, or physical environments that may be remote and hostile to humans and computers. For such systems, detailed a-priori domain understanding is not achievable at design-time. This inevitably acts against the formulation of stable requirements. Rather, the requirements will need to be revised and reappraised over periods too short to be achieved by off-line adaptive maintenance. To achieve this, systems will need to maintain requirements models that are dynamic, runtime entities that support reasoning, sometimes with the aid of human, and sometimes not, so that the systems can respond in appropriate ways to changes in their environments. requirements@run.time takes its cue from important recent work in a number of areas, including requirements monitoring, computational reflection, self-adaptive systems and multi-objective reasoning.

Fifth International Workshop on Requirements Engineering and Law (RELAW 2012)

Official Webpage: http://relaw2012.eecs.uottawa.ca/

Organizers: Annie Anton (North Carolina State Univ., USA), Travis Breaux (CMU, USA), Daniel Amyot (Univ. of Ottawa, Canada), and Wade Chumney (Georgia Tech., USA)

The objective of the RELAW workshop is to foster the discussion related to requirements engineering triggered by any legal regulation or law. The theme this year is “Compliance under Uncertainty”. RELAW is a multidisciplinary, one-day workshop that will bring together practitioners and researchers from two domains: Requirements Engineering and Law. Participants from government, industry and academic sectors investigate challenges to ensure that information systems comply with policies and laws. The workshop will probe important issues, including the processes for identifying relevant policies, laws and jurisdictions, aligning laws with system requirements, managing requirements and changes in the law and demonstrating how systems comply with relevant laws through evidence-based mechanisms such as documentation, testing and certification, even in the presence of uncertainty. RELAW will include a track with requirements engineering research and industry papers and a second track with papers from law scholars to address emerging IT challenges in today’s regulatory environment.

First International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks2012)

Official Webpage: http://re.cs.depaul.edu/twinpeaks/

Organizers: Jane Cleland-Huang (DePaul Univ., USA), Mehdi Mirakhorli (DePaul Univ., USA), Roshanak Roshandel (Seattle Univ., USA), and Janet E. Burge (Miami Univ., USA)

The Twin Peaks draws attention to the synergistic relationship between requirements and architectural design. It emphasizes the need to progressively discover and specify requirements while concurrently exploring alternative architectural decisions.

The Twin Peaks workshop will focus on the issues and challenges related to the interplay between requirements and architecture across all phases of the software development lifecycle. These challenges are particularly evident in agile and lean development environments, or when new requirements are introduced into existing and well-established architectures. The workshop will explore techniques for specifying architecturally significant requirements, for creating, and assessing architectures, and for managing and visualizing the interplay between requirements and architectures. It will also identify open research challenges for delivering robust and effective architectures that satisfy stakeholders concerns, at continually increasing levels of scale, complexity, and delivery speed.

Second International Workshop on Requirements Engineering for Systems and Systems-of-Systems (RESS’12)

Official Webpage: http://www.csd.uwo.ca/RESS12/

Organizers: Brian Berenbach (Siemens Corp., USA), Nazim H. Madhavji (Univ. of Western Ontario, Canada), and Krzysztof Wnuk (Lund Univ., Sweden)

Systems engineering is an interdisciplinary field focused on the design and implementation of large and complex systems. A System-of-systems integrates a set of otherwise independent and self-contained systems that pool their resources in order to meet a common goal. Such systems include transportation systems, hospital networks, “smart” buildings, large scale defense systems, as well as systems from many other domains. Managing requirements for such projects can be extremely complex and challenging as requirements must be addressed not only for individual components, but also for the overall infrastructure, interfaces, and governance of the system. As an emerging area of research, Requirements Engineering for systems and systems-of-systems represents a critical discipline in which methodologies, thought processes, frames of reference, and technology support are still emerging. This workshop therefore invites contributions addressing issues, challenges, and solutions related to requirements engineering for such systems. The workshop puts a special emphasis on quality (aka non- functional) requirements, which are an important and challenging part of systems engineering efforts.

Second International Workshop on Empirical Requirements Engineering (EmpiRE 2012)

Official Webpage: http://selab.fbk.eu/empire2012/

Organizers: Maya Daneva (Univ. of Twente, The Netherlands), Daniela Damian (Univ. of Victoria, Canada), Oscar Dieste (Univ. Politecnica de Madrid, Spain), Alessandro Marchetto (FBK, Italy), and Oscar Pastor (Univ. Politecnica de Valencia, Spain)

The second International Workshop on Empirical Requirements Engineering (EmpiRE) aims to increase the cross-fertilization of Empirical Software Engineering (ESE) methods and Requirements Engineering (RE) by actively encouraging the exchange of ideas to understand why and how the empirical methods from ESE can help to assess and improve existing or new approaches in RE. EmpiRE also intends to push toward new evaluation techniques, domains and problems for exercising empirical methods or building new ones.

More information

MODELS 2012, ACM/IEEE 15th International Conference on Model-Driven Engineering Language & Systems – Call for Papers – Deadline 19 March 2012

Sept. 30th – Oct. 5th, 2012 – Innsbruck/AUSTRIA

More Information

6th INCOSE Annual Great Lakes Regional Conference 2012

October 12 – 13, 2012, Schaumburg, Illinois, U.S.A

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

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)

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

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.


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: an activity or purpose natural to or intended for a person or thing
Source: http://oxforddictionaries.com

Function: the action for which a person or thing is particularly fitted or employed
Source: http://www.thefreedictionary.com/function

Function: the kind of action or activity proper to a person, thing, or institution; the purpose for which something is designed or exists; role
Source: http://dictionary.reference.com/browse/function

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

PPI News (see www.ppi-int.com)

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 released.

INCOSE Brasil Chapter Formed

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

PPI Events (see www.ppi-int.com)

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.

The 10th Annual Conference on Systems Engineering Research (CSER 2012) | Participating | Rolla, MA, USA (19 – 22 March 2012)

WASET 2012 | Participating | Madrid, Spain (28 – 29 March 2012)

INCOSE LA Mini-Conference | Las Angeles, CA, USA (31 March)

Australian EW, IO & Cyber Convention 2012 | Participating | Brisbane, Australia (15 – 17 April 2012)

ST&T 2012 | Participating | Charleston, SC, USA (17 – 18 April 2012)

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: rhalligan@ppi-int.com

Ralph Young, Editor, email: ryoung@ppi-int.com

Stephanie Halligan, Production, email: shalligan@ppi-int.com

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

Web: www.ppi-int.com

Email: contact@ppi-int.com

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

Tell us what you think of SyEN: email to contact@ppi-int.com

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.

Scroll to Top