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 13

What’s Inside:

A Quotation to Open On

Featured Article: Requirements Quality Metrics: The Basis of Informed Requirements Engineering Management


Systems Engineering News

New INCOSE In-Service Systems Working Group

Systems Engineering Conference Registration Open

CNN ranks Systems Engineer at top of Best Jobs list!

Lean Solutions Institute (LSI) Newsletter

The Gray Report – Is UK MOD Procurement Beyond Rescue?

INCOSE International Symposium 2010 – Draft Papers Due November 8 2009


Featured Society – AIAA Systems Engineering Technical Committee


INCOSE Technical Operations – INCOSE Life Cycle Management Working Group


Systems Engineering Software Tools News

Artisan adds ‘glossUML’ capability to Artisan Studio

Artisan helps steer UPDM through OMG standardization in record time

Launch of Artisan Studio Version 7.1

Artisan launches Artisan Studio Reviewer

PivotPoint Technology and Sparx Systems Announce Technology Partnership

Announcement of Sodius Solutions for DOORS


Systems Engineering Books, Reports, Articles and Papers

Finding Robust Solutions in Requirements Models


Conferences and Meetings


Education and Academia

Directory of SE Academic Programs


Some Systems Engineering-Relevant Websites


Standards and Guides

OMG Approves UPDM


Some Definitions to Close On – Desire, Expectation, Goal, Need, Requirement, Target, Want


PPI News

PPI in Rio de Janeiro


PPI Events


A Quotation to Open On

“Engineering process is useless in the absence of a knowledge of solution technologies relevant to the problem, and creativity in applying that knowledge.” – Robert Halligan

Feature Article

Requirements Quality Metrics: The Basis of Informed Requirements Engineering Management

Robert J. Halligan

Project Performance (Australia) Pty Ltd

2 Parkgate Drive

Ringwood North Vic 3134 Australia

Fax +61-3-9876-2664

email: rhalligan@ppi-int.com


Available data demonstrates that defective requirements are a dominant cause of cost and schedule overrun in technical programs. This paper presents a structured methodology for measuring the quality of requirements, individually and collectively. It is shown that requirements may be characterized by ten quality factors, each with an associated metric, and by two overall requirements quality metrics. In addition, the requirements engineering process itself can be instrumented by means of five

process-related metrics. The paper describes the author’s experience with application of both types of metric to engineering decision making.

1 Introduction

Requirements engineering deals with the creation, capture, validation, specification and traceability of requirements. Requirements engineering may commence at the level of a broad statement of need, and will continue through the definition of the system solution, right down to the lowest levels of specification of elements of that solution.

Requirements engineering does not simply happen, it requires management. Classically, management is considered to comprise planning, organizing, staffing, monitoring and controlling. If we accept that “that which cannot be measured cannot be controlled”, the role of requirements metrics is readily apparent.

But which metrics? Should we instrument the requirements engineering product (the requirements) or the process (the requirements engineering process) or both? How can requirements metrics be used to help a project team satisfy project success criteria? These and related issues are discussed below.

2 The State of the Requirements Art

Data from TRW developed in the early 1980s showed that, on a range of representative projects, 30 per cent of design problems requiring correction were due to erroneous or incomplete requirements specifications. These specifications were produced in ideal circumstances – by engineers, for engineers. Another 24 per cent of errors were due to conscious deviation from product and process requirements. Other studies have shown that the cost to correct an error typically increases by a factor of between 20 and 1000 over the life cycle of a system acquisition. System solutions which satisfy the contract, but not the need, are, unfortunately, commonplace. Abundant evidence exists that the damage done to projects by requirements with avoidable defects has improved little, if at all, over the last twenty years.

Engineering practitioners have come to regard improved requirements engineering as one of the challenges of this decade.

Responses to this challenge have included:

early, concurrent development of product and process requirements covering all product life cycle phases, from concept through to disposal;

improved capture and validation of requirements by the use of robust analytical techniques, such as context analysis, design requirements analysis, states and modes analysis, functional analysis (sometimes using executable modeling languages), rest of scenario analysis, data modeling, out-of-range analysis, and value modeling, supported by software tools; and

management of requirements through integration of text and relational database support, resulting in improvements in requirements traceability and in the productivity of requirements analysis and design activities.

This latter trend has brought with it a tendency, highly beneficial in the author’s view, to manage all program-related requirements as a single set. Requirements may be readily allocated across all elements of the program, for example deliverable product(s), project management, system engineering, test and evaluation, production, etc, and their interfaces. Within each of these program elements, requirements may be decomposed and allocated to lower level elements, including product and service interfaces.

3 Requirements Quality

Requirements, to satisfy their uses, must, in their expression, exhibit certain attributes. We refer to these attributes as requirements quality factors. The author has found that a set of ten requirements quality factors is necessary to adequately define the quality of requirements, individually and collectively.

Correctness refers to an absence of errors of fact in the statement of requirement.

Completeness requires that each requirement contains all of the information necessary, including elaborations and conditions, to enable the requirement to be implemented such that the need will be satisfied. Completeness also incorporates sufficiency of requirements as a set, noting that, for any given object, an endless set of requirements could be defined.

Consistency requires that a requirement not be in conflict with any other requirement, nor with any element of its own structure.

Clarity requires that the requirement be readily understandable without semantic analysis.

Non-Ambiguity requires that there be only one semantic interpretation of the requirement.

Connectivity refers to the property whereby all of the terms within the requirement are adequately linked to other requirements and to word and term definitions, so causing the individual requirement to properly relate to the other requirements as a set.

Singularity refers to the attribute whereby a requirement has only one actor, one action (verb) and one object of action – see later.

Verifiability refers to the existence of a finite and objective process with which to verify that the requirement has been satisfied.

Modifiability requires that: a. necessary changes to a requirement can be made completely and consistently; and b. the same requirement is specified only once.

Feasibility requires that a requirement be able to be satisfied: a. within natural physical constraints; b. within the state-of-the-art as it applies to the project; and c. within all other absolute constraints applying to the project

4 A Requirements Structural Model

Requirements are most commonly expressed as natural language statements, although graphical and formal mathematical requirements languages are also used.

For the natural language type of expression, requirements quality metrics may be developed through the parsing of each requirement statement into the elements of a structural model of a sound requirement, a template. A template found to be suitable for English language requirement statements is illustrated in figure 1. Figure 1 also shows an example requirement parsed into the template.

Figure 1 – Requirement Structural Template

Elements of the template are defined as below:

Actor. This is the subject of the sentence – the thing being specified. Examples (good and bad!) are: “the system”, “the interface”,

“the function”, …………

Conditions of Action. This defines the conditions during which the action is to take place, for example “in Replay Mode”, and/or

the initiating conditions: “upon receipt of a message”, “power having been applied”, …..

Action. This is a verb – the action to be taken by the actor (subject). Examples are “shall calculate”, “shall display”, “shall fly”,

“shall be displayed”…….

Constraints of Action. These qualify the action, for example “at a resolution of 400 x 1000 pixels”, “within limits imposed by vehicle speed”, ….., and include performance

Object of Action. This is a noun, and is the thing acted upon in taking the action. Examples are: “the message”, “the input

signal”, …..

Refinement/Source of Object. These qualify the object, for example (refinement): “of flash priority”, for example (source): “from DISCON”.

Refinement/Destination of Action. These further qualify the action, and may be additional to Constraints of Action. Examples are “in accordance with IEEE 802.11g”, “to DISCON”.

Other. This element collects non-requirements material.

5 Requirements Quality Metrics

A strong requirement will have each applicable element of the requirement, and the requirement overall, satisfying each of the quality factors described earlier. This ideal provides a basis for the development of requirements quality metrics. Figure 2 illustrates the construction of a set of metrics based on parsing of a requirement into the template.

Figure 2 – Construction of Requirement Quality Metrics

The metrics are defined below.

IRQ Individual Requirement Quality

This metric for a single requirement is a number between 0 and 1, 0 representing a totally defective requirement and 1 representing a “perfect” requirement. The metric is constructed from the parsed version of the requirement by: a. determining which of the possible seven elements of the structure are applicable and assigning a value of 1 to each applicable element (most requirements have 3-7 applicable elements); b. assessing each element of the parsed requirement against the quality factor criteria, and scoring each applicable element as 1 (satisfactory) or 0 (unsatisfactory). An element may be unsatisfactory because it is missing, or because it is defective in some other way.; c. calculating the metric by dividing the sum of the applicable element values into the sum of the element scores.

IQF1-IQF10 Individual Quality Metrics

Ten individual (requirement) quality metrics correspond to the ten requirement quality factors, as follows: IQF1 Correctness, IQF2 Completeness, IQF3 Consistency, IQF4 Clarity, IQF5 Non-Ambiguity, IQF6 Connectivity, IQF7 Singularity, IQF8 Testability, IQF9 Modifiability, and IQF10 Feasibility.

These metrics assume, for an individual requirement, a value of 1 or 0 depending on whether the requirement overall has a defect of that type (0) or not (1).

Rarely do the metrics for individual requirements directly serve a useful purpose. It is necessary to aggregate individual requirements metrics to form metrics for groups of requirements in order to serve our objective of control of requirements quality. In making this transposition to aggregate metrics, we have consistently found the need to allow for requirements which are missing altogether, not just incomplete in the sense of missing a condition or a refinement. This leads to two key metrics, the first being a measure of the quality of what is there, and the second being an overall quality metric incorporating an adjustment for what is estimated to be necessary but missing. The second metric is produced by factoring in the estimated number of missing requirements at IRQ=0.

The number of requirements which need to be present but are in fact missing may be estimated by estimating, for each requirement that is present, the number of related but missing requirements: an omission ratio. Another method of estimating the number of necessary but missing requirements is norms of relationships between requirements types (Primary Requirement Type for Primary Actor – terms which we will not go into in this paper). A third estimating method is “should be” numbers based on the history of the number of requirements in takes to adequately specify, for development, a certain type of thing – where that history exists.

The quality metrics for sets of requirements correspond to, and are produced from, the individual metrics, as follows (for n requirements):

RQ Requirements Quality

QF1 Correctness

QF2 Completeness

Note that completeness may have a negative value.

QF3 to QF10 are derived as for QF1.

6 Application of Requirements Quality Metrics

A metric is only of value if it assists in decision making. Areas of application of the metrics described above are summarized in Table 1.


RQ Requirements Quality

QF1-QF10 Requirements Quality Factors

  • estimation of requirements-related bidding risk/opportunity (depending on the type of contr
  • estimation of requirements-related contract risk/opportunity
  • determination of the skills and level of resources required for requirements analysis
  • measurement of the quality of the product of requirements analysis, in relation to decision a. termination of formal requirements analysis;

b. whether the project is ready for System Requirements Review (SRR), Software Spec requirements reviews;

c. whether system requirements are sufficiently mature for establishment of the functional b d. whether CI requirements are sufficiently mature for establishment of the allocated baselin

  • assessment of the specification writing skill levels of project team members
  • estimation of requirements-related subcontract risk/opportunity
  • use as a technical performance measurement (TPM) parameter QF1-QF10 Requirements
  • identification of aspects of requirements which are unsatisfactory
  • identification of requirements-related skills in which training of project personnel is needed
  • use as a technical performance measurement (TPM) parameter

Table 1 – Application of Requirements Quality Metrics

Metrics should only be used where they contribute positively to the degree of satisfaction of project goals, including cost goals.

7 Typical Values of Requirements Quality Metrics

Our experience in use of the metrics suggests the typical relationships between values of the metrics and requirements quality shown in Table 2.

Very poor set of
requirements, Fair set of requirements, may just be suitable Requirements at SRR suitable
Metric requiring for purposes of solicitation, depending on the for carrying forward into
substantial SOW and type of contract envisaged development
RQ- 0.01-0.3 0.3-0.7 0.85-0.99
QF1-Correctness 0.9 0.98 0.98
QF2-Completeness -5 0 0.9
QF3-Consistency 0.9 0.97 0.98
QF4-Clarity 0.9 0.97 0.98
QF5-Non-Ambiguity 0.3 0.7 0.9
QF6-Connectivity 0.3 0.9 0.98
QF7-Singularity 0.1 0.3 0.98
QF8-Testablity 0.1 0.7 0.98
QF9-Modifiability 0.1 0.5 0.98
QF10-Feasibility 0.95 0.99 0.98

Table 2 – Typical Values of Requirements Quality Metrics

8 Requirements Process Metrics

We have also found it beneficial to use, for engineering management purposes, requirements process metrics, derived for requirements analysis tasks such as system requirements analysis and software requirements analysis.

Useful metrics include:

RSTA Percent Started. This metric indicates the percentage of source requirements currently under development, the “work in progress”.

RTBD Percent “To be Determined”. This metric indicates the percentage of requirements containing TBDs (To Be Determined), i.e., requirements for which the resolution of incompleteness is beyond the resources of the analyst and which have been referred to other individuals, organizations or phases for resolution of missing information.

RCOM Percent Completed. This metric indicates the analyst’s view of that analysis of the source requirement has been completed.

RAPP Percent Approved. This metric indicates the percent of source requirements for which the results of analysis have been approved for incorporation in the destination document/database.

In addition, the need to control the process of formally decomposing requirements and allocating derived (in design)

requirements to subordinate elements has led to an additional metric:

RALL Percent Allocated. This metric indicates the percent of parent requirements of a system-of-interest for which there exists one or more child requirements, each of which has been allocated to a subordinate element, e.g. a subsystem.

All of the above process metrics provide data for earned value measurement within project cost/schedule control systems. In addition, RTBD has proved to be a useful parameter for incorporation into a technical performance measurement (TPM) program.

Systems Engineering News

New INCOSE In-Service Systems Working Group

  1. new working group has been set-up within INCOSE called the In-Service Systems Working Group (ISSWG). Traditional Systems Engineering has sometimes focused on the development of new systems. The ISSWG focuses on how Systems Engineering techniques can support systems that are operational and are preferably not taken out of service for maintenance and logistic support, for example, air traffic control systems and telecommunication systems.

This international working group further elaborates on work done by a U.K. working group, looking at how INCOSE products (eg.

The Systems Engineering Handbook) can be modified to deal better with the In-Service Systems Engineering.

Please contact isswg-info@incose.org if you are interested in taking part in the first WG telecon during the second half of October (TBC: 15th or 21st!!), or in subsequent telecons.

More Information

Systems Engineering International Symposium Registration Now Open

Systems Engineering, a discipline sometimes associated with putting satellites into space, or creating the newest car models, has evolved to address transportation, health care and education systems. These topics will be presented and debated during the 2010 INCOSE International Symposium. Over July 12-15, 2010, the International Council on Systems Engineering (INCOSE) will hold the 20th Anniversary INCOSE International Symposium, in Chicago, Illinois, U.S.A.

More information

CNN Ranks Systems Engineer at Top of Best Jobs List!

Systems engineers know this already, but read more of what CNN Money has to say.


Lean Solutions Institute (LSI) Newsletter

by Robert Halligan

I was pleased to receive by email the first edition of a new Lean Solutions Institute, Inc. (LSI) newsletter, prepared by Tim Olson, LSI President. LSI seeks to apply lean principles outside of manufacturing, to areas such as engineering (e.g., systems, software), finance (e.g., banks, insurance), service (e.g., help desks, IT), including complex systems and systems of systems (e.g., DoD, NASA).

Since Lean (do nothing that doesn’t add value) and sound systems engineering are as one, I am pleased to advise readers of

Tim’s new newsletter. To quote from Tim’s newsletter:

“Almost every “Lean” book points back to Toyota. Toyota appears to be the inventor of “Lean”, and “Lean” appears to be born in manufacturing. So how has lean helped Toyota? While U.S. automotive manufacturers are struggling, Toyota dominates the world automobile industry. Toyota has the most market share (world wide), the most profit, the most automation, the most revenue per employee, the most quality awards, etc. I could go on and on, but I think you get the point. Lean has made a huge impact in the automobile industry and in manufacturing.”

The first edition of Tim’s newsletter warns against removing best practices (e.g. design reviews, configuration management) in pursuit of an illusion of saving money.

More information: www.lsi-inc.com

The Gray Report – Is UK MOD Procurement Beyond Rescue?

Asks a U.K. respondent! The Gray report is a report commissioned by the former UK Defence Secretary and prepared by Mr. Bernard Gray, to assess the steps the department has undertaken to reform its procurement process, and to make further recommendations as to how procurement can be improved. Reading the Gray report leads to a conclusion that the problems of UK MOD procurement appear to be embedded in the ethos of the department and of industry. Mr. Gray has recommended a number of far-reaching actions – signs are that his recommendations may well be adopted.

More information:


Download the report:


INCOSE International Symposium 2010 (IS10) – Draft Papers Due November 8 2009

As you may be well aware the INCOSE International Symposium 2010 (IS10) is being held in Chicago, IL, USA over July 12 – 15, 2010.

Draft papers for submission by November 8, 2009.

Submit papers here: https://www.myassociationservices.com/incose/

More information

Featured Societies – AIAA Systems Engineering Technical Committee

The mission of the American Institute of Aeronautics and Astronautics is to address the professional needs and interests of the past, current, and future aerospace workforce and to advance the state of aerospace science, engineering, technology, operations, and policy to benefit global society.

In 1963, the two aerospace societies of the day merged. The American Rocket Society and the Institute of Aerospace Science joined to become AIAA. Both brought long and eventful histories to the relationship – histories that stretched back to 1930 and 1932 respectively, a time when rocketry was the stuff of science fiction and the aviation business was still in its infancy.

Today, with more than 31,000 members, AIAA is the world’s largest professional society devoted to the progress of engineering and science in aviation, space, and defense. The Institute continues to be the principal voice, information resource, and publisher for aerospace engineers, scientists, managers, policymakers, students, and educators. AIAA is also the go-to resource

for stimulating professional accomplishment and standards-driven excellence in all areas of aerospace for prominent corporations and government organizations worldwide.

The AIAA Systems Engineering Technical Committee aims to foster the definition, dissemination, development, understanding and application of system engineering processes, methodologies and tools to aeronautics, space, computer and ground systems. Present Chair is John Day of Inspace Systems. The Committee meets twice yearly; monthly telecons are also conducted.

Website: https://info.aiaa.org/tac/ETMG/SETC/

INCOSE Technical Operations

INCOSE Life Cycle Management Working Group



The Charter of the Life Cycle Management Working Group (LCMWG) is to expand the body of knowledge of Systems Engineering (SE) as it is, and should be, applied to acquisition and system life cycles. Specifically, the LCMWG is formed to:

promote the use of SE principles, techniques, processes, and tools in the wide range of activities related to life cycle management;

share SE best practices as they relate to life cycle management;

link SE organizations across international boundaries to improve life cycle processes and the management of the life cycle; and

encourage research into the application of SE throughout a life cycle.


Chair: Bill Doyle, General Dynamics – Advanced Information Systems

Co-Chair: Jan de Liefde, Dutch Ministry of Public Works

Contact Life Cycle Management Working Group for additional information or to join this group.


Define the term “life cycle” as it applies to the overall system, and to subordinate life cycles (e.g. technology, safety, regulatory, acquisition)

Develop life cycle frameworks for system components and processes such as technology, contracting, safety, environmental, and others.

Research life cycle management concepts, processes, and practices to improve system satisfaction of stakeholder needs.


The Life Cycle Management Working Group will conduct technical projects focusing on specific life cycle management issues, addressing both the application of systems engineering in each component life cycle (i.e., technology, regulatory, safety, and environment) as well as on how these subordinate life cycles integrate with the overall product life cycle. These technical projects may include, but are not limited to:

Acquisition Life Cycle Management

Technology Life Cycle Management

Regulatory (legal) Life Cycle Management

Process adaptation across life cycle stages

Knowledge management over a life cycle

Life cycle key decisions (are they all at the end points of stages?).

Systems Engineering Software Tools News

Artisan Adds ‘glossUML’ Capability to Artisan Studio

Artisan Software Tools has added a ‘glossUML’ capability to Artisan Studio. An extension to SysML/UML, glossUML enables presentation-quality diagrams to be generated quickly, easily and directly from the models created in Artisan Studio.

More information

Artisan Helps Steer UPDM through OMG Standardization in Record Time

Artisan Software Tools has announced that it has helped successfully steer UPDM (the Unified Profile for DoDAF/MODAF) to OMG standardization approval. The content definition and preparation of the UPDM 1.0 specification was led by Artisan and No-Magic as co-chairs of the UPDM Group, drawing on the extensive experience of Artisan’s customers in defining DoDAF/MODAF and other defense enterprise architectures using Artisan Studio.

More information

Launch of Artisan Studio Version 7.1

Artisan Software Tools has launched a major new version of its flagship model-driven development tool suite, Artisan Studio Version 7.1. It is claimed to deliver some major new modeling features including comprehensive support for the new OMG Unified Profile for DoDAF and MODAF (UPDM 1.0) standard, improved model diagram presentation through glossUML, all new documentation generation through Artisan Publisher, increased extra-large model support and enhanced UML Activity modeling.

More information

Artisan Launches Artisan Studio Reviewer

Artisan Software Tools has launched Artisan Studio Reviewer, a powerful design reviewer that automates the otherwise manual task of checking UML, SysML and UPDM models for completeness, correctness and consistency. With applications development deadlines continually shortening, Artisan Studio Reviewer is stated to significantly enhance the management and operation of complex mission and safety-critical development projects, cutting design time by up to 30% and improving design quality.

More information

PivotPoint Technology and Sparx Systems Announce Technology Partnership

PivotPoint Technology and Sparx Systems have announced a technology partnership to promote model-based systems engineering with the Systems Modeling Language (SysML). Under the agreement, PivotPoint will be Sparx’s primary partner for training and consulting services that use Sparx’s new SysML product (MDG Technology for SysML™), which was released recently.

More information: http://jorn.expressaudio.com.cn/lina/24129

Announcement of Sodius Solutions for DOORS

Sodius announces the release of its new Sodius Solutions for DOORS, and associated web site: www.dxleditor.com.

Sodius has developed the DXL Editor, offering features aimed by Sodius to improve DOORS DXL developers’ lives. Sodius states: “going far beyond syntax highlighting, the DXL Editor is a real development environment for DXL built on the market-leading Eclipse platform. Last but not least, DXL Editor is available for FREE!”

DXL Editor can be downloaded at http://www.dxleditor.com/download.

For DOORS users looking for advanced functionality in model-driven engineering, Sodius is also offering a version of its MDWorkbench framework named MDWorkbench for DOORS. This add-on to DOORS helps to architect DOORS databases, to reverse engineer DOORS schemas, to generate documents and to exchange any DOORS information with other environments.

More information: www.dxleditor.com/mdworkbench.

Systems Engineering Books, Reports, Articles and Papers

Finding Robust Solutions in Requirements Models

Gregory Gay , Tim Menzies , Omid Jalali , Gregory Mundy, Beau Gilkerson, Martin Feather, and James Kiper

Solutions to non-linear requirements engineering problems may be “brittle”; i.e. small changes may dramatically alter solution effectiveness. Therefore, it is not enough to merely generate solutions to requirements problems – we must also assess the robustness of that solution. This paper introduces the KEYS2 algorithm that can generate decision ordering diagrams. Once generated, these diagrams can assess solution robustness in linear time.

More information

Conferences and Meetings

Business Analyst World

19 – 22 October, 2009, Boston, USA. More information

26 – 29 October, 2009, Vancouver, Canada. More information

16 – 19 November, 2009, Chicago, USA. More information

30 November – 1 December, 2009, Ottawa, Canada. More information

MIT Conference on Systems Thinking for Contemporary Challenges Addressing Complexity in Health Care, Energy, Space, and the Environment

October 22–23, 2009, at MIT, Cambridge, MA, USA

More information

INCOSE Cleveland-Northern Ohio – (Region IV Autumn ’09)

25-26 October, 2009, OHIO Aerospace Institute, 22800 Cedar Point Road, Cleveland, OH 44142

More information

12th Annual Systems Engineering Conference

26 – 29 October, 2009, San Diego, CA, USA.

More information

INCOSE San Diego Chapter 14th Annual Mini-Conference

System Complexity: Is Systems Engineering Effective in Complex Systems Development and Deployment?

San Diego, CA, USA October 31, 2009

More information

The Role and Development of System Engineers –

A Defence Industry Perspective

NSW Chapter of the Australian Society For Defence Engineering Presented by Dr, Terry Stevenson, Chief Technology Officer, Raytheon Australia

November 2, 2009, Sydney, Australia

Formal Methods for Industrial Critical Systems (FMICS) 2009

2 – 3 November, 2009, Eindhoven, The Netherlands.

More information

16th International Symposium on Formal Methods (FM2009)

2 – 6 November, 2009, Eindhoven, The Netherlands.

More information

FM 2009 Doctoral Symposium

6 November, 2009, Eindhoven, The Netherlands.

More information

28th International Conference on Conceptual Modeling

9 – 12 November, 2009, Gramado, RS, Brazil.

More information

Workshop on Requirements, Intentions and Goals in Conceptual Modeling

9 – 12 November, 2009, Gramado, RS, Brazil.

More information

Tag des Systems Engineering (Day of Systems Engineering)

Friedrichshafen am Bodensee

12 – 13 November, 2009

More information

CMMI 9th Technology Conference and User Group

16 – 19 November 2009, Hyatt Regency Tech Center – Denver

More Information

Decision Analysis and Its Applications to Systems Engineering

17-18 November 2009 at the Omni Hotel in Newport News, Virginia

More Information

Model Driven Day (MDDAY) 2009

26 November 2009, Paris, France

More information

1st Annual Global Conference on Systems and Enterprises (GCSE)

2 – 4 December, 2009. Singapore.

More information

4th South-East European Workshop on Formal Methods (SEEFM 2009)

4-5 December 2009, Thessaloniki, Greece

More information

International Joint Conferences on Computer, Information, and Systems Sciences, and Engineering (CISSE 09)

December 4 – 12, 2009

Sponsored by the University of Bridgeport – Technically co-sponsored by the IEEE Computer Society, Communications Society and Education Society (Connecticut Section)

More Information

INCOSE 2010 International Workshop

7 – 10 February, 2010. Phoenix Marriott Mesa, Mesa, Arizona.

More information

Semantic Models for Adaptive Interactive Systems

In conjunction with 2010 International Conference on Intelligent User Interfaces (IUI 2010) in Hong Kong, China, on February 7th, 2010

More information

1st Workshop on Semantically-Enabled Systems Engineering (SENSE-2010)

15 – 18 February, 2010. Andrzej Frycz Modrzewsk Cracow College, Krakow, Poland.

More information

IESS 1.0: First International Conference on Exploring Services Sciences

17 – 19 February, 2010. Geneva, Switzerland.

More information

CSER 2010 8th Annual Conference on Systems Engineering Research

17-19 March, Honoken, NJ, USA

More information


21 – 26 March, 2010. Sierre, Switzerland.

More information

The Third Edition of the Requirements Engineering Track (RE-Track’10)

22 – 26 March, 2010. Sierre, Switzerland.

More information

Symposium On Theory of Modeling and Simulation – DEVS Integrative M&S Symposium (DEVS’10)

April 11 – 15, as part of the 2010 Spring Simulation Multiconference at the Florida Mall Hotel and Conference Center in Orlando, FL,


WER’10: 13th Workshop on Requirements Engineering

April 12-13, 2010 – Cuenca, Ecuador

More Information

Agent-Directed Simulation Symposium (ADS 2010)

12 – 15 April, 2010, Orlando, Florida, USA.

More information

Second NASA Formal Methods Symposium (NFM 2010)

April 13 – 15, 2010, USA

More information

COFES: Congress on the Future of Engineering Software (COFES) 2010

15 – 18 April, 2010, Scottsdale, Arizona, USA.

More information

2010 The 2nd IEEE International Conference on Systems Engineering and Modeling (ICSEM 2010)

23 to 25 April 2010, Bangkok, Thailand

More information

22nd Annual Systems & Software Technology Conference (SSTC 2010)

26-29 April 2010, Salt Palace Convention Center, Salt Lake City, Utah

More information

Systems Engineering and Test Evaluation (SETE) 2010

3 – 6 May, 2010, Stamford Grand, Adelaide.

More information

Software Process Improvement and Capability dEtermination (SPICE) 2010

18-20 May 2010 – Pisa, Italy

More information

EuSEC 2010: Systems Engineering and Innovation

23 – 26 May, 2010, Stockholm, Sweden.

More information

The 22nd International Conference on Advanced Information Systems Engineering (CAiSE’10)

07-11 June 2010, Hammamet, Tunisia

More information

21st IEEE International Symposium on Rapid System Prototyping

June 8-11, 2010, George Mason University, Fairfax, Virginia, USA

More information


21-25 June, 2010, Braga, Portugal

More information

ACSD 2010: 10th International Conference on Application of Concurrencyto System Design

Collocated with Petri Nets 2010

June 21-25, 2010, Braga, Portugal

More information

ISARCS 2010 – 1st International Symposium on Architecting Critical Systems Federated with CompArch 2010

June 23-25 2010 Prague, Czech Republic

More information

20th Annual INCOSE International Symposium (IS10)

11 – 15 July, 2010, Rosemont, IL, USA.

More information

Fourth Asia-Pacific Conference on Systems Engineering (APCOSE 2010)

11 – 13 September, 2010. Keelung, Taiwan.

More information

The 18th International Requirements Engineering Conference (RE 2010)

Sep 27, 2010 – Oct 1, 2010, Sydney, Australia

More information

Complex Systems Design & Management 2010

October 27-29, 2010, Paris, France

More Information

Education & Academia

Directory of SE Academic Programs

INCOSE maintains a directory of systems engineering academic programs worldwide. The directory may be viewed at:


Some Systems Engineering-Relevant Websites


This website, written about marketing disasters, could equally have been written about engineering. A hilarious read with a serious message.


This website contains a summary of IEEE Recommended Practice for Software Requirements Specifications.

Standards and Guides

OMG Approves UPDM

UPDM is the Unified Profile for DoDAF/MODAF, each an architectural framework. DoDAF is of U.S. DoD origin. MODAF comes out of the UK Ministry of Defence. Standardization in the form of UPDM has been achieved in record time, using the Object Management Group’s (OMG) fast-track RFC standardization process, resulting in the OMG formally approving UPDM as an OMG standard in early October 2009. The UPDM Group was formed in May 2008, and the draft specification was submitted on time to the OMG in September 2008.

Matthew Hause, Chief Consulting Engineer at Artisan Software Tools and co-chair of the UPDM Group said “It is important to stress that UPDM is not a new Military Architectural Framework. Instead, it provides a consistent, standardized means to describe DoDAF and MODAF architectures in UML/SysML-based tools, as well as a standard for model interchange and a better means for the flow-down from systems of systems to systems development.”

Fully endorsed by both the US DoD and the UK MOD, and supported by NATO, the UPDM 1.0 specification defines an industry standard UML/SysML representation for DoDAF 1.5 and MODAF 1.2-compliant enterprise architectures.

UPDM is not intended to be a static standard. Other Architectural Frameworks will be supported, as UPDM is updated in the future to maintain model exchange compliance, including DoDAF v2.0 (which was recently released, in June 2009), NAF (the NATO Architectural Framework) which is very similar to MODAF 1.2, and possibly aspects of the Canadian DNDAF framework.

More information: http://www.tradingmarkets.com/.site/news/Stock%20News/2570303/

Some Definitions to Close On

Desire: an unsatisfied longing or craving (OED)

Expectation: an instance of expecting or looking forward (OED)

Goal: (1) the object of a person’s ambition or effort; a destination; an aim; (OED) (2) a desired characteristic of an item (product or service), usually for which a solution will be pursued, subject to trade-offs with other goals.

Need: a condition of lacking or requiring some necessary thing, either physically or psychologically. (OED)

Requirement: (1) an order, a demand, an imperative, a dependant for success or fulfillment. (OED) (2) a required characteristic of an item (product or service), usually for which a solution will be pursued.

Target: see “goal”

Want: wish for possession of (OED)

Legend: OED: Oxford English Dictionary

Project Performance International News

PPI in Rio de Janeiro

PPI is holding its first public Systems Engineering 5-Day course and workshop in Rio de Janeiro, Brazil over 26 – 30 October, 2009

Project Performance International Events

Systems Engineering 5-Day Courses

Upcoming locations include:

Rio de Janeiro, Brazil

Cape Town, South Africa

Las Vegas, USA


Amsterdam, The Netherlands

London, UK

View 2009/2010 Systems Engineering Course Schedule

Requirements Analysis and Specification Writing 5-Day Courses

Upcoming locations include:

Amsterdam, The Netherlands

Las Vegas, USA

Melbourne, Australia

Cape Town, South Africa

View 2009/2010 RA&SW Course Schedule

OCD/CONOPS 5-Day Courses

Upcoming locations include:

Las Vegas, USA

Pretoria, South Africa

Adelaide, Australia

View 2009/2010 OCD/CONOPS Course Schedule

Software Engineering 5-Day Courses

Upcoming locations include:

Amsterdam, The Netherlands

Melbourne, Australia

Pretoria, South Africa

Las Vegas, USA

View 2009/2010 Software Engineering Course Schedule

Cognitive Systems Engineering 5-Day Courses

Upcoming locations include:

Las Vegas, USA

Melbourne, Australia

London, UK

Adelaide, Australia

View 2009/10 Cognitive Systems Engineering Course Schedule

PPI Upcoming Participation in Professional Conferences

26 – 29 October, 2009 – 12th Annual Systems Engineering Conference – San Diego, CA, USA (Exhibiting)

31 October, 2009 – INCOSE San Diego Chapter 14th Annual Mini-Conference – San Diego, CA, USA (Exhibiting)

Kind regards from the SyEN team:

Robert Halligan, Managing Editor, email: rhalligan@ppi-int.com

Alwyn Smit, Editor, email: asmit@ppi-int.com

Julie May, Production, email: jmay@ppi-int.com

Luke Simpson, Production, email: lsimpson@ppi-int.com

Project Performance International

PO Box 2385, Ringwood, Vic 3134 Australia

Tel: +61 3 9876 7345

Fax: +61 3 9876 2664

Web: www.ppi-int.com

Email: contact@ppi-int.com

Copyright 2009 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 us if acknowledgement is not received within 7 days.

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

Scroll to Top