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
Abstract
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.
Metric
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 | |
| 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
- 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.
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.
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.
http://money.cnn.com/magazines/moneymag/bestjobs/2009/snapshots/1.html
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/
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
http://www.incose.org/practice/techactivities/wg/leansewg/
CHARTER
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.
LEADERSHIP
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.
AREAS OF INTEREST
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.
POTENTIAL LCMWG TECHNICAL PROJECTS
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.
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.
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.
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.
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.
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
INCOSE Cleveland-Northern Ohio – (Region IV Autumn ’09)
25-26 October, 2009, OHIO Aerospace Institute, 22800 Cedar Point Road, Cleveland, OH 44142
12th Annual Systems Engineering Conference
26 – 29 October, 2009, San Diego, CA, USA.
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
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.
16th International Symposium on Formal Methods (FM2009)
2 – 6 November, 2009, Eindhoven, The Netherlands.
FM 2009 Doctoral Symposium
6 November, 2009, Eindhoven, The Netherlands.
28th International Conference on Conceptual Modeling
9 – 12 November, 2009, Gramado, RS, Brazil.
Workshop on Requirements, Intentions and Goals in Conceptual Modeling
9 – 12 November, 2009, Gramado, RS, Brazil.
Tag des Systems Engineering (Day of Systems Engineering)
Friedrichshafen am Bodensee
12 – 13 November, 2009
CMMI 9th Technology Conference and User Group
16 – 19 November 2009, Hyatt Regency Tech Center – Denver
Decision Analysis and Its Applications to Systems Engineering
17-18 November 2009 at the Omni Hotel in Newport News, Virginia
Model Driven Day (MDDAY) 2009 
26 November 2009, Paris, France
1st Annual Global Conference on Systems and Enterprises (GCSE)
2 – 4 December, 2009. Singapore.
4th South-East European Workshop on Formal Methods (SEEFM 2009)
4-5 December 2009, Thessaloniki, Greece
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)
INCOSE 2010 International Workshop
7 – 10 February, 2010. Phoenix Marriott Mesa, Mesa, Arizona.
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
1st Workshop on Semantically-Enabled Systems Engineering (SENSE-2010)
15 – 18 February, 2010. Andrzej Frycz Modrzewsk Cracow College, Krakow, Poland.
IESS 1.0: First International Conference on Exploring Services Sciences
17 – 19 February, 2010. Geneva, Switzerland.
CSER 2010 8th Annual Conference on Systems Engineering Research
17-19 March, Honoken, NJ, USA
Track on REAL-TIME SYSTEMS at ACM SAC 2010
21 – 26 March, 2010. Sierre, Switzerland.
The Third Edition of the Requirements Engineering Track (RE-Track’10)
22 – 26 March, 2010. Sierre, Switzerland.
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,
USA
WER’10: 13th Workshop on Requirements Engineering
April 12-13, 2010 – Cuenca, Ecuador
Agent-Directed Simulation Symposium (ADS 2010)
12 – 15 April, 2010, Orlando, Florida, USA.
Second NASA Formal Methods Symposium (NFM 2010) 
April 13 – 15, 2010, USA
COFES: Congress on the Future of Engineering Software (COFES) 2010
15 – 18 April, 2010, Scottsdale, Arizona, USA.
2010 The 2nd IEEE International Conference on Systems Engineering and Modeling (ICSEM 2010)
23 to 25 April 2010, Bangkok, Thailand
22nd Annual Systems & Software Technology Conference (SSTC 2010)
26-29 April 2010, Salt Palace Convention Center, Salt Lake City, Utah
Systems Engineering and Test Evaluation (SETE) 2010
3 – 6 May, 2010, Stamford Grand, Adelaide.
Software Process Improvement and Capability dEtermination (SPICE) 2010 
18-20 May 2010 – Pisa, Italy
EuSEC 2010: Systems Engineering and Innovation
23 – 26 May, 2010, Stockholm, Sweden.
The 22nd International Conference on Advanced Information Systems Engineering (CAiSE’10)
07-11 June 2010, Hammamet, Tunisia
21st IEEE International Symposium on Rapid System Prototyping 
June 8-11, 2010, George Mason University, Fairfax, Virginia, USA
PETRI NETS 2010
21-25 June, 2010, Braga, Portugal
ACSD 2010: 10th International Conference on Application of Concurrencyto System Design 
Collocated with Petri Nets 2010
June 21-25, 2010, Braga, Portugal
ISARCS 2010 – 1st International Symposium on Architecting Critical Systems 
Federated with CompArch 2010
June 23-25 2010 Prague, Czech Republic
20th Annual INCOSE International Symposium (IS10)
11 – 15 July, 2010, Rosemont, IL, USA.
Fourth Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
11 – 13 September, 2010. Keelung, Taiwan.
The 18th International Requirements Engineering Conference (RE 2010) 
Sep 27, 2010 – Oct 1, 2010, Sydney, Australia
Complex Systems Design & Management 2010 
October 27-29, 2010, Paris, France
Education & Academia
Directory of SE Academic Programs
INCOSE maintains a directory of systems engineering academic programs worldwide. The directory may be viewed at:
http://www.incose.org/educationcareers/academicprogramdirectory.aspx
Some Systems Engineering-Relevant Websites
http://www.insearchofstupidity.com/
This website, written about marketing disasters, could equally have been written about engineering. A hilarious read with a serious message.
http://asingh.com.np/?q=node/3
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
Singapore
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.
