What’s Inside:
Featured Article
Types of Requirements – Robert Halligan
… READ MORE
Systems Engineering News
OMG, INCOSE Team on Certification Program for Systems Modeling Language Congress Strikes Deal on Acquisition Reform
Army to Create Central Acquisition Organisation
Australia Introduces “Systems Thinking in Schools” Training SysML France Recently Launched
… READ MORE
Featured Society
Systems Engineering Society of Australia (SESA)
… READ MORE
INCOSE Technical Operations – Requirements Working Group
… READ MORE
Systems Engineering Software Tools News
MagicDraw UML Wins Design and Modeling Category Award at Great Indian Developer Summit 3SL GSA Contract
Future Cradle Direction
… READ MORE
Systems Engineering Books, Reports, Articles and Papers
Build Safety-Critical Designs with UML-based Fault Tree Analysis Design Must-Haves for your Mission-Critical System
How to Save a Failing Project: Chaos to Control
… READ MORE
Conferences and Meetings
… READ MORE
Education and Academia
Keio University, Japan, Opens Admissions for GSSDM
… READ MORE
Some Systems Engineering-Relevant Websites
… READ MORE
Standards and Guides
ISO/IEC JTC 1, SC 7 Standards Relevant to Systems Engineering
… READ MORE
A Definition to Close On – Capability Maturity Model (CMM)
… READ MORE
PPI News
… READ MORE
PPI Events
… READ MORE
A Quotation to Open On
“Large skepticism leads to large understanding. Small skepticism leads to small understanding. No skepticism leads to no understanding” – Xi Zhist
Feature Article
Types of Requirements
by Robert Halligan
Managing Director, Consultant and Trainer
Project Performance International
Why Should We Care About Types of Requirements?
The Types of Requirements, e.g. functional, performance, external interface, etc., are important to three roles in engineering: the Requirements Analyst role, the Specification Writer role, and the Designer role.
For the Requirements Analyst, a close relationship exists between the types of requirements, and specific analytical techniques. Thus, the analyst benefits from an excellent understanding of the Types of Requirements to select the most appropriate combination of analytical techniques to address a particular requirements problem. To even communicate about requirements and their capture and validation, relies upon a good understanding of the distinctions between different types.
For the (requirements) Specification Writer, of all the influences on good requirements specification structure, the Types of Requirements have the greatest influence. That is not to say that there is a 1:1 relationship between Types of Requirements and
elements of structure, e.g. sections. There is not. A sound schema and understanding of Types of Requirements enables the Specification Writer to very efficiently place each (singular, not compound) requirement in its single correct place. This transformation of a pile of requirements in a database into a well structured, no logical disconnects, easy to use requirements specification may even be automated.
For the Designer, many of the Types of Requirements have corresponding design process issues. In some cases, e.g. external interface requirements and other qualities requirements, there are also corresponding, specific design management issues.
In this paper, as soundly-based schema of Types of Requirements is presented, and the significance of each type to each of the three roles of Requirements Analyst, Specification Writer, and Designer is described.
State/Mode Requirements
State/mode requirements state the required states and/or modes of the item, or the required transition between one state and another state, one mode and another mode, made in one state to mode in another state, or the response required of the system as a direct consequence of a transition having occurred. A “state” is a condition of something – required or permitted. A “mode” in this context is a related group of functionality for a purpose, i.e. “mode of operation”.
Significance to the Requirements Analyst:
To the Requirements Analyst, a States & Modes Analysis is performed early, and can contribute considerably to the capture of missing requirements and the validation of requirements that are already there. Because States & Modes Analysis deals with “big picture” required and permitted dynamics of the system, a States & Modes Analysis is a high return on investment analysis. The skillful use of States and Modes by the Requirements Analyst reduces word count and increases clarity of a requirements specification.
Significance to the Specification Writer:
How the Specification Writer deals with states and modes in structuring a requirements specification can have a huge influence on the effectiveness of that requirements specification. Some of the older requirements specification standards have directed very damaging practices regarding the states and modes aspects of requirements and their specification.
Significance to the Designer:
For the Designer, states and modes requirements have a soft influence, affecting, because of their “big picture” orientation, initial conceptualization of solution alternatives, and subsequently feeding directly (for a given concept) into the more abstract levels of logical design.
Functional Requirements
Functional requirements state what the system is required to do. Significance to the Requirements Analyst:
The Requirements Analyst captures and validates functional requirements in a Functional Analysis (e.g. development of Use Cases). Whenever the Requirements Analyst discovers a functional requirement, the Analyst immediately goes looking for the associated required measures and values of performance. Having done so, the Analyst then iterates to Rest-of-Scenario Analysis, looking for requirements of other types.
Significance to the Specification Writer:
For the Specification Writer, functional requirements are placed in a Functional and Performance Requirements part of the requirements specification.
Significance to the Designer:
Consistent with a given physical (structural) concept of solution, functional requirements represent a point of departure into logical design corresponding to that concept.
Performance Requirements
Performance requirements state how well the system is to do what it is to do. That is, performance is an attribute of function. Significance to the Requirements Analyst:
If the Requirements Analyst finds a performance requirement without corresponding function, the Analyst has found an incomplete requirement. The Analyst finds the corresponding function, and brings the function and performance together into a complete statement of the requirement, now a functional and performance requirement.
Significance to the Specification Writer:
The Specification Writer keeps function and performance together structurally. The Specification Writer does not place functional requirements in one section of a requirements specification and performance requirements in another; to do so results in duplication or ambiguity or both. The Specification Writer prefers to express function and associated required measures and values of performance in the one expression of the requirement; it is not one requirement to fly, and another requirement to fly at a certain speed!
Significance to the Designer:
The Designer designs to achieve required function and associated required measures and values of performance from the first acts of initial conceptualization of solution alternatives, through to completion of design in all detail necessary for implementation. The Designer may subject required measures and values of performance to a Performance Thread Analysis, an iterative analysis which is used to reduce any risk arising from any possibility of failing to achieve performance, and to optimize the use of design margins.
External Interface Requirements
External Interface requirements state the required characteristics at a point or region of connection of the system to the outside world (e.g. location, geometry, inputs and outputs by name and specification, allocation of signals to pins etc).
Significance to the Requirements Analyst:
The Requirements Analyst captures and validates external interface requirements in a Context Analysis, and complements this capture and validation with Rest of Scenario Analysis, Parsing Analysis, Out-of-Range Analysis, and for data-oriented systems, Entity-Relationship-Attribute (ERA) analysis.
Significance to the Specification Writer:
The Specification Writer places requirements to “have an external interface” in a particular place in the requirements specification, and requirements on a given external interface in another place in the requirements specification. The Specification Writer decides whether to specify the latter set of requirements in an Interface Requirements Specification involed by reference, or to specify the external interface requirements entirely within the subject System Requirements Specification or Software Requirements Specification (as applicable). In each case, the Specification Writer decides whether to organize the requirements on the interface alphabetically by parameter, or alternatively in accordance with some “level of abstraction” model, such as the OSI 7-Layer Model.
Note that requirements on an internal interface are design requirements, and that the Specification Writer treats them accordingly.
Significance to the Designer:
What is not in external interface requirements is discretionary for the Designer, and becomes the subject of external interface design. External interface design must be consistent between the two ends of the interface. Furthermore, in most cases, external interface design assumes the status of requirements, when the overall design to meet requirements is baselined prior to release into production, construction and/or acquisition. This is a unique aspect relating to externat interface requirements. The Design Manager must manage this transformation such that, at any point in time, there is a complete and accurate answer to the question “what are the characteristics required of this interface?”.
Environmental Requirements
Environmental requirements limits the effect that external environment (natural or induced) is to have on the system, and/o the effect that the system is to have on the external enveloping environment.
Significance to the Requirements Analyst:
The Requirements Analyst captures and validates environmental requirements in Context Analysis and in Rest-of-Scenario Analysis, conducted iteratively with Functional Analysis.
Significance to the Specification Writer:
For the Specification Writer, environmental requirements are a unit of structure in the requirements specification, with three related concerns for a physical system:
classes of environment, if any (e.g. Storage Environment and Operational Environment)
for each class of environment, the set of environmental parameters that apply to that class; and
for each class of environment, the applicable environmental envelope(s) – set envelope(s) of ranges of environmental parameters that apply simultaneously.
Significance to the Designer:
With respect to environmental requirements, there are no unique, generic, design process issues.
Resource Requirements
Resource requirements limit the usage or consumption by the system of an externally provided resource. Significance to the Requirements Analyst:
The Requirements Analyst captures resource requirements in Context Analysis and in Rest-of-Scenario Analysis. Significance to the Specification Writer:
For the Specification Writer, resource requirements correspond to a section of the requirements specification. Significance to the Designer:
Any impedance in the supply of an externally provided resource has affect the behaviour of a system. The Designer may conduct a Resource Coupling Analysis with respect to each externally provided resource.
Physical Requirements
Physical requirements state the required physical characteristics (properties of matter) of the system as a whole (e.g. mass, dimension, volume, centre of gravity, surface coefficient of friction, density, etc)).
Significance to the Requirements Analyst:
The Requirements Analyst captures resource requirements in several analyses incrementally. Significance to the Specification Writer:
For the Specification Writer, physical requirements correspond to a section of the requirements specification. Significance to the Designer:
With respect to physical requirements, there are no unique, generic, design process issues.
“Other Quality” Requirements
Other quality requirements state any other required quality, that is not one of the above types, nor is a design requirement. Significance to the Requirements Analyst:
Whilst a number of analyses contribute incrementally to the capture and validation of “other quality” requirements, the Requirements Analyst relies primarily on a Stakeholder Value Analysis to capture and validate requirements of this type.
Significance to the Specification Writer:
For the Specification Writer, “other qualities” requirements correspond to a section of the requirements specification. Significance to the Designer:
“Other qualities” requirements are often of profound significance to the designer. A whole body of knowledge often applies regarding engineering to achieve the quality. For example, safety engineering, reliability engineering, producability engineering, are each disciplines in their own right. In addition, the Design Manager must ensure that the body of knowledge associated with engineering to achieve each required “other quality” is effectively integrated with the technology disciplines involved in designing to meet requirements of other types. This necessity leads to the widely emphasized concept of Engineering Specialty Intergation.
Design Requirements
Design requirements direct the design (internals of the system), by inclusion (build it this way), or exclusion (don’t build it this way).
Design requirements that already exist and are already specified are identified and validated in a Design Requirements Analysis. This sometimes usually results in a substantial reduction in the number of design requirements, many to be replaced by valid requirements of other types.
How the Specification Writer deals with design requirements can have a profound effect on the quality of a requirements specification, especially if design requirements are numerous. The Specification Writer must apply sound principles in organizing the structure of the requirements specification to incorporate design requirements.
Significance to the Designer:
For the Designer, invalid design requirements (.. and as well the solution must be ..) can cause considerable grief, forcing the Designer to do things that no reasonable person on earth would choose to do except under direction.
However, design requirements also move the pointer of share of responsibility for the design from the Designer to the requirer, and can therefore be used to avoid responsibility for the success of a design.
Systems Engineering News
OMG, INCOSE Team on Certification Program for Systems Modeling Language
OMG™ and the International Council on Systems Engineering (INCOSE) announced that they have agreed to work together on the development of OMG’s new program to certify Systems Engineers and other practitioners on the OMG Systems Modeling Language (OMG SysML™) standard. SysML is a graphical modeling language used to perform Model-Based Systems Engineering (MBSE) – that is, to specify and design complex systems that may include hardware, information, personnel, and facilities in addition to software. The program, to be called OCSMP™ (OMG-Certified Systems Modeling Professional), will be OMG’s fourth certification.
More information
Congress Strikes Deal on Acquisition Reform
By John T. Bennett
U.S. House and Senate negotiators have hammered out a final version of defense acquisition legislation that would shake up the Office of the Secretary of Defense, and give the combatant commanders a greater say in deciding which weapons the Pentagon will buy…
The House-Senate bill also proposes creation of two new director-level positions within OSD, one to oversee developmental test and evaluation and another to manage the Pentagon’s systems engineering efforts…
More information
U.S. Army to Create Central Acquisition Organisation
By Katherine McIntire Peters
Under pressure to bring more engineering expertise back in-house after years of ceding such capability to contractors, the United States Army has begun standing up a centralized staff of systems engineers with the skill and judgment to broadly examine and improve the service’s acquisition programs.
More information
Australia Introduces “Systems Thinking in Schools” Training
Ian Marsden, eLearning Project Officer of the Wide Bay Resource Centre in the state of Queensland, has arranged for trainers from the Waters Foundation in the United States to run their Systems Thinking in Schools: Level 1 Workshop in Queensland.
To support this training prior to the event, and to provide introductory information about what systems thinking is, and how it applies to education, a web conference event has been scheduled. Participation is free.
Session 2: Saturday August 8, from 9:00 – 10:00 (Australian Eastern Standard Time). If you are interested in the training and the web conference, you may email Ian Marsden at ian@jistae.com and he will place you on the jistae.com distribution list.
The main training will occur over: September 29th – October 2nd, 2009 Where: Cavendish Road State High School
Cnr Cavendish and Holland Roads
Holland Park QLD 4120 AUSTRALIA
Registration Costs: A$1500 including GST
A lot more on systems thinking and related education in schools is at the excellent Waters Foundation web site:
“SysML France” Association Launched
For those interested in French discussions/information on SysML, the “SysML France” association has just been launched.
More information
Featured Society
Systems Engineering Society of Australia (SESA)
SESA (the Systems Engineering Society of Australia) is a Technical Society of Engineers Australia. SESA’s Mission is to lead Australia towards achieving the highest probability of success in areas where there are complex projects.
SESA has its origins in the Victorian Systems Engineering Branch of the Institute of Engineers, Australia (IEAust), which was formed in 1990. In September 1994, a small group of interested engineers launched an initiative towards the formation of an Australian systems engineering association. The network quickly grew to exceed 250, and an inaugural meeting was held in Canberra on the 2 December 1994 to formulate the way ahead.
SESA was formalized as a Technical Society of the IEAust in October 1995, and was launched at a very successful one day conference held in Sydney in October 1995.
The rest is history, with chapters, working groups, annual conferences, and hosting of the 2001 INCOSE International Symposium held in Melbourne.
SESA’s mission is to foster the definition, understanding, practice and advancement of Systems Engineering in Australian Industry, Academia and Government. Systems Engineering is applicable to many types of projects, including software intensive systems projects, where the structured guidelines promoted in current international commercial and military standards should be applied.
SESA aims to provide the Australian national vehicle to make systems projects successful, through the establishment of a viable systems engineering culture in Australia.
Membership is open to everyone with an interest in systems engineering. SESA membership comprises people working in fields of software engineering, government, academia, project management, electronic engineering and other relevant fields.
Organisationally, SESA is lead by a President, Executive Committee and Management Committee. Key appointments presently are President: Kerry Lunney, Deputy President: Chris Bland, Immediate Past President: Pat Lockley; Secretary: David Green; and Treasurer: Ian Harrison.
More information
INCOSE Technical Operations
Requirements Working Group
http://www.incose.org/practice/techactivities/wg/infrastructure/
Charter
The vision of the Requirements Working Group (RWG is) to be the acknowledged leader in advancing the state of the theory, education, and practice of requirements engineering and management within the systems engineering community.
The mission of RWG is to take stakeholders needs, real world constraints, and capture and evolve the Requirements body of knowledge (BOK – e.g. theory, case studies, application evidence), and to provide value-added technical products to assist the INCOSE membership to effectively implement and apply requirements engineering and management in their own unique settings.
The objectives of RWG are to:
capture and evolve the Requirements BOK
develop and deploy practical processes, methods, tools, training material, application evidence, and services enhance the knowledge and understanding of the RWG membership of requirements engineering and management demonstrate benefits of applying requirements engineering and management in the work place
provide quality technical products to the INCOSE membership, while following the guidelines of the INCOSE Technical Board.
Leadership
Chair: Jeremy Dick, Telelogics, U.K.
Co-Chair: Lily Birmingham, Lockheed Martin Corporation, U.S.A. Co-Chair: Lou Wheatcraft, Compliance Automation Inc, U.S.A. Co-Chair: Gauthier Fanmuy, PSA Peugeot-Citroën, France
Members of the RWG meet twice yearly – at the International Workshop and at the the International Symposium. A teleconference is held approximately monthly.
Members of the RWG in Europe hold local meetings approximately every two months. Contact the Requirements Working Group for additional information, or to join this group.
Accomplishments
REGAL (database of requirements good practice) 2007.
Guide for Operational Concept Documents (ANSI/AIAA G-043) 2006.
Preliminary REGAL became on-line (http://p-ring.net) for interactive sessions to help users to determine best practices for requirements development and management. Presented at INCOSE International Symposium July 2005. “Requirements Completeness”, March 2004 – Prepared by the RWG by Ron Carson (lead), Erik Aslaksen, George Caple, Paul Davies, Regina Griego, Ron Kohl, and Abd-El-Kader Sahraoui. Presented at INCOSE IS 2004 in Toulouse, France by Ron Carson.
“Requirements Categorization”, 2001 – Prepared by the RWG by Andrew Gabb (lead), George Caple, Paul Davies, Steve Eppig, David Haines, Anthony Hall, David Jones, Dave Lamont, Jim van Gassbeek, and Bill Vietinghoff.
“Executable Requirements Management Model Interim Report”, 1998. A RWG Information Report by David Jones. Published in CD-ROM Proceedings of the 8th Annual International Symposium of the International Council on Systems Engineering – Volume II: INCOSE Technical Working Group Papers, 1998.
“Interfacing Requirements Management Tools In The Requirements Management Process – A First Look”, 1997, A RWG Information Report by David Jones, Pradip Kar, Jim van Gassbeek, Frank Hollenback, Marty Bell, and Dr. Robert Ellinger. Published in Proceedings of the Seventh International Symposium of the INCOSE – Volume II, August 1997. “Characteristics of Good Requirements”, 1996. Prepared by the RWG by Pradip Kar and Michelle Bailey. Presented at the 1996 INCOSE International Symposium.
“Writing Good Requirements”, 1994. Prepared by the RWG by Ivy Hooks. Published in the Proceedings of the Third International Symposium of the NCOSE – Volume 2, 1993.
“What is a Requirement?” 1993. Prepared by the RWG by Richard Harwell (lead), Erik Aslaksen, Roy Mengot, Ivy Hooks, and Ken Ptack. Published in the Proceedings of the Third International Symposium of the NCOSE, 1993.
Current Projects
REGAL (Requirements Engineering Guide for All)
Objective: Assist in identifying requirements best practices. Goal: Productized by IS08 Contact: Gauthier Fanmuy
RAFT (Requirements Assessment For Teams)
Objective: Assist in identifying requirement best practice based on parametric definition of project context. Goal: Prototyping RAFT by IS08
Contact: Erwin Duurland
Guide for Writing Requirements Objective: Draft by IS08
Ongoing support for ISO WG4/WG7
Ongoing support for BOD/CAB Concept of Operations
Objective: Updating ANSI/AIAA G-043 guide to the preparation of operational concept documents. (Joint project with AIAA.)
Contact: Jim van Gaasbeek
Elicitation Methods & Project Environments
Objective: Assist in selection of requirements elicitation methods based on parametric definition of project environments. Contact: Regina Gonzales
SE Handbook revision
Objective: Contribute requirement expertise to the authors of the SE Handbook. Contact: Jeremy Dick
New Activites
Modeling with respect to Requirements (joint with MBSE, Architecture, HSI & Security) VV&T with respect to Requirements
Product Family Management with respect to Requirements
Systems Engineering Software Tools News
MagicDraw UML Wins Design and Modeling Category Award at Great Indian Developer Summit
No Magic, Inc., claiming to be the leading provider of integrated modeling software and services, announced that its premier product, MagicDraw® 16.0 was the recipient of the design and modeling category award at the Great Indian Developer Summit Awards presentation 2009 held in Bangalore, India April 22-25, 2009.
More information
3SL GSA Contract
3SL advised potential and current U.S.A. customers that they have been granted a schedule by the U.S. Government’s General Services Administration (GSA). This allows end-users in the U.S. Federal Government to order Cradle licenses, maintenance, training and consulting services from 3SL, more quickly, with less paperwork, and at a discount.
More information
Future Cradle Direction
For some time, 3SL has provided two Cradle clients, Toolset and WorkBench. Originally, all Cradle functionality was in the Toolset client. 3SL introduced WorkBench to offer a client with a more modern UI and with better ease-of-use and customisation facilities. Over time, the functionality of WorkBench has grown, both by enhancing functionality that is specific to WorkBench itself, and by either replicating functionality from Toolset in WorkBench, or by moving functionality from Toolset into WorkBench.
3SL has stated that the continued existence of Toolset caused unwanted complication in the installation, use and administration of the Cradle environment…
3SL has eliminated all of these problems in the next major release, Cradle-6.0, in which the Toolset client has been completely removed.
More information
Artisan Newsletter 30 June 2009
Artisan promotes a fully integrated suite of modeling tools targeted to meet the development needs of embedded systems and software engineering. The suite provides notation support for the OMG’s UML, SysML, UPDM (DoDAF and MODAF) and Data Modeling.
The 30 June 2009 edition of the Artisan Newsletter contains the following articles:
Using Model Driven Architecture (MDA) for gluing embedded software onto host-based validation environments An overview of UPDM – A Unified Profile for DoDAF/MODAF
Westinghouse Rail Systems Reduces SIL4 Validation Effort by 70% with Artisan Studio Research Projects
More information
Systems Engineering Books, Reports, Articles and Papers
Build Safety-Critical Designs with UML-based Fault Tree Analysis
Authored by Bruce Powel Douglass, IBM/Rational
The Unified Modeling Language (UML) has been successfully used in many real-time and embedded domains, including aerospace, military, and medical markets. Many of these systems within these markets are used within safety critical contexts.
So far, disparate tools and environments have been used for capturing requirements, creating designs, and analyzing system safety. However, UML is an extremely powerful, extensible language. To this end, the author has created a UML profile that support capturing requirements, creating designs, and analyzing system safety, all within the same UML tool environment.
This series of three articles discuss the use of Fault Tree Analysis (FTA) for safety analysis in embedded systems design, and use of the UML profiling mechanism to create a safety analysis profile, including the definition of its normative metamode.
This profile enables developers and analysts to capture safety-related requirements, perform FTA and other safety analyses, create designs that meet those safety concerns, and provide reports showing the relations between the safety analysis, requirements, and design model elements.
Part 1: The basics of safety and capturing of fault metadata for analysis Part 2: Defining a UML Safety Analysis Metamodel Profile
Part 3: Fault Tree Analysis of a surgical anesthesia ventilator
Design Must-Haves for your Mission-Critical System
By Dr. Asif Naseem, GoAhead Software
Learn from this real-life example why the continuous availability of mission-critical applications must be factored into system design from the get go.
Service availability, or uninterrupted service to the end user in the presence of failures, cannot be effectively bolted on to an already-developed system if little or no consideration has been given to High Availability (HA) during the design phases. In this article, Dr. Naseem outlines the key considerations a designer of a highly available system must keep in mind.
More information
How to Save a Failing Project: Chaos to Control
Ralph R. Young, DBA Steve M. Brady, PMP Dennis C. Nagle, Jr. ISBN: 978-1-56726-239-1
Poor project results are all too common and result in dissatisfied customers, users, and project staff. With countless people, goals, objectives, expectations, budgets, schedules, deliverables, and deadlines to consider, it can be difficult to keep projects in focus and on track. How to Save a Failing Project: Chaos to Control arms project managers with the tools and techniques needed to address these project challenges. The authors provide guidance to develop a project plan, establish a schedule for execution, identify project tracking mechanisms, and implement turnaround methods to avoid failure and regain control.
More information
Conferences and Meetings
WER’09: 12th Workshop on Requirements Engineering
July 16 – 17, 2009. Valparaiso, Chile
More information
INCOSE 19th Annual International Symposium (IS) 2009
July 20 – 23, 2009. Singapore
More information
3rd Annual International Workshop on Requirements Engineering for Services (REFS’09)
In conjunction with COMPSAC 2009, July 20 – 24, 2009. Seattle, Washington
More information
2nd IEEE International Workshop on Industrial Experience in Embedded Systems Design (IEESD 2009)
In conjunction with COMPSAC 2009, July 20 – 24, 2009. Seattle, Washington
More information
2009 International Conference of the System Dynamics Society
July 26 – 30, 2009. Albuquerque, New Mexico
More information
PICMET ’09 Conference: “Technology Management in the Age of Fundamental Change”
August 2 – 6, 2009. Hilton Portland and Executive Tower, Portland, Oregon, USA
More information
CGBDP – VII Brazilian Congress on Product Development Management
August 3 – 5, 2009. Embraer Eugenio de Melo, Brazil
More information
Innovation 2009 – As Real as it Gets
August 4 – 5, 2009. Histon Hotel, Sydney, Australia.
More information
Improving Systems and Software Engineering Conference (ISSEC 2009)
Co-located with the 6th Annual Project Management Australia Conference (PMOZ 2009). August 10 – 12, 2009. Canberra, Australia
More information
Workshop on Logical Aspects of Fault Tolerance (LAFT)
(affiliated with LICS 2009). August 15, 2009. University of California, Los Angeles, USA
More information
17th IEEE International Requirements Engineering Conference (RE’09)
31 August – 4 September 2009, Atlanta, Georgia, USA
More information
Workshop on Collaboration and Intercultural Issues on Requirements: Communication,
Understanding and Softskills (CIRCUS)
In Conjunction with 17th IEEE International Requirements Engineering Conference (RE’09). 31 August, 2009. Atlanta, Georgia, USA
More information
Doctoral Symposium at RE’09
1 September, 2009. Atlanta, Georgia, USA.
More information
4th International Workshop on Requirements Engineering Vizualisation (REV’09)
31 August, 2009. Atlanta, Georgia, USA.
More information
4th International Workshop on Requirements Engineering Education and Training
31 August, 2009. Atlanta, Georgia, USA.
More information
2nd International Workshop on Managing Requirements Knowledge (MaRK ’09)
In conjunction with the 17th IEEE Requirements Engineering Conference 1 September, 2009. Atlanta, Georgia, USA
More information
2nd International Workshop on Requirements Engineering and Law
In conjunction with the 17th IEEE Requirements Engineering Conference 1 September, 2009. Atlanta, Georgia, USA
More information
1st Workshop on Service-Oriented Business Networks and Ecosystems (SOBNE ’09)
1 September, 2009. Auckland, New Zealand.
More information
European Systems & Software Process Improvement and Innovation (EuroSPI2)
September 2 – 4, 2009. University of Alcala, Spain
More information
3rd International Workshop on Enterprise Modeling and Information Systems Architectures
10 – 11 September, 2009. Ulm University, Germany
More information
AIAA Space 2009 – Joint Space Systems Engineering and Economics Track
Within the conference is a joint Space Systems Engineering and Economics Track that has room for slots for four space systems engineering papers. September 14 – 17, 2009. Pasadena, CA, USA
Download Call for Papers
Additional Conference Information
Third IEEE International Conference on Self-Adaptive and Self-organising Systems (SASO’09)
(IEEE approval pending)
September 14 – 18, 2009. San Francisco, USA
More information
SEPG Asia-Pacific 2009
September 16 – 18, 2009. Osaka, Japan.
More information
ICAPS 2009 Workshop on Verification and Validation of Planning and Scheduling Systems (VV&PS 2009)
September 19 – 20, 2009. Thessaloniki, Greece.
More information
14th System Design Languages Forum
September 22 – 24, 2009. Ruhr-University of Bochum, Germany
More information
ICISE 2009 – International Conference on Industrial and Systems Engineering
September 23, 2009, Toronto, Canada
More information
Ninth International Workshop on Automated Verification of Critical Systems (AVoCS 2009)
Swansea University Computer Science, September 23 – 25, 2009.
More information
Workshop “Games, Business Processes and Models of Interactions”
September 28, 2009, University of Lubeck, Germany.
More information
Systems Thinking in Schools: Level 1 Workshop
September 29 – October 2, 2009. Cavendish Road State High School, Holland Park, QLD, Australia.
More information
12th Australian Workshop on Requirements Engineering (AWRE’09)
October 1 -2, 2009. University of Technology, Sydney, Australia.
More information
Workshop “Integration Engineering” held at the annual meeting 2009 of the Gesellschaft fuer Informatik e.V. (GI)
October 2, 2009, University of Lubeck, Germany.
More information
ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems
(formerly the UML series of conferences)
4 – 9 October, 2009, Denver, Colorado, USA.
More information
2nd International Workshop on Model Based Architecting and Construction of Embedded Systems (in conjunction with MODELS 2009)
- October, 2009. Denver, Colorado, USA.
More information
Track Systems Engineering 2009
- – 8 October, 2009, Munich, Germany.
More information
2009 SEER by Galorath North American User Conference: Best Practices in Project Estimation, Planning & Control
- – 9 October, 2009. Porofino Hotel, California, USA.
More information
International Conference on Man-Machine Systems (ICoMMS)
11 – 13 October, 2009, University of Malaysia Perlis.
More information
Symposium on Automotive/Avionics Systems Engineering SAASE 2009
14 – 17 October, 2009, San Diego, CA, USA.
More information
12th Annual Systems Engineering Conference
26 – 29 October, 2009, San Diego, CA, USA.
More information
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
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
1st Annual Global Conference on Systems and Enterprises (GCSE)
2 – 4 December, 2009. Singapore.
More information
IESS 1.0: First International Conference on Exploring Services Sciences
17 – 19 February, 2010. Geneva, Switzerland.
More information
The Third Edition of the Requirements Engineering Track (RE-Track’10)
22 – 26 March, 2010. Sierre, Switzerland.
More information
Agent-Directed Simulation Symposium (ADS 2010)
12 – 15 April, 2010, Orlando, Florida, USA.
More information
Fourth Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
11 – 13 September, 2010. Keelung, Taiwan. Website to be advised
Education & Academia
Keio University, Japan, Opens Admissions for GSSDM
The Keio University, Tokyo, Japan has opened enrollments for its Graduate School of System Design and Management.
The Graduate School of System Design and Management has the objective of fostering the leaders of the new generation to meet social needs, via:
Innovative Education Concept to Celebrate the 150 Anniversary
A New Program to Foster Social/Technology Leaders of the 21st Century
Capability Reinforcement to Design and Operate a Complex System of Systems in Totally International Framework A Melting Pot to Provide Forum for Fusion of Different Generations, Fields, Social Status Regardless of Educational Background
Leading Edge Information Technology Applied to Design Projects.
The following degrees are offered:
Master of System Engineering, or Master of System Design and Management Ph.D. in System Engineering or Ph.D. in System Design and Management
The Graduate School of System Design and Management is lead by Professors Ohkami, Yoshiaki; Urago, Masataka; Ogi, Tetsuro; Takano, Kenichi; Teshima, Ryuichi; Toma, Tetsuya; Nishimura, Hidekazu; Haruyama, Shinichiro; Hibiya, Taketoshi; Maeno, Takashi; Sasaki, Shoichi; and Nakano, Masaru.
The Graduate School of System Design and Management has affiliations with:
Japan Chapter of INCOSE (the International Council on Systems Engineering) Massachusetts Institute of Technology, USA
INSA (Institut National des Sciences Appliquées), France EIC, Loughborough University, UK
Stanford University, USA
Stevens Institute of Technology, USA
JAXA AIST Industry Research Centers, Japan.
PPI has regularly presented its one-week engineering courses for the Graduate School of System Design and Management, the most recent delivery being in March, 2009.
More information
Some Systems Engineering-Relevant Websites
http://www.watersfoundation.org/
An organisation promoting the effective application of systems thinking concepts, habits and tools in classroom instruction and school improvement.
http://jistae.com/tag/systems-thinking/
A blog started by Ian Marsden to be a map of his journeys into Systems Thinking and Education.
Designs for Thinking – Professional development facilitating thinking and learning through the use of visual tools and Thinking Maps®.
http://www.habits-of-mind.net/
Habits of Mind – Provides resources to support the understanding and use of the Habits of Mind.
isee Systems – Information about the purchase and use of STELLA® Computer modeling sofware. Examples of and guidelines for computer models.
Pegasus Communications – Information about periodicals, resource materials, and workshops related to systems thinking concepts and tools, dynamic modeling and organisational learning.
Sustainability Institute – Appling systems thinking concept and tools, dynamic modeling and organisational learning practices to economic, environmental and social challenges.
System Dynamics Group – MIT – Systems based research projects at the Sloan School of Management, Massachusetts Institute of Technology.
http://iisd1.iisd.ca/pcdf/meadows/default.htm
The Global Citizen – Archives of a bi-weekly column written by Dr. Donella H. Meadows commenting on world events from a systems point of view.
http://pascal.computer.org/sev_display/index.action
This web page provides access to SEVOCAB: Software and Systems Engineering Vocabulary. SEVOCAB is a project of the IEEE Computer Society and ISO/IEC JTC 1/SC7, SEVOCAB includes definitions from international standards – including ISO/IEC and IEEE. You can search for a term as defined in the standards included in the data base, or for all the definitions in a nominated standard. SERVOCAB is destined to become an international standard – ISO/IEC 24765.
http://www.iso-architecture.org/ieee-1471/
This is the website for IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-intensive Systems, which is also ISO/IEC 42010:2007.
The website provides for subscription to an IEEE 1471 Users Group Email List. The purpose of the Users Group is to serve as an open forum to discuss issues pertaining to IEEE 1471. With a joint ISO and IEEE revision of the standard underway, the Users Group mailing list is intended to be the primary source of announcements about the revision, calls for participation, etc.
Other content of the site includes a history of IEEE 1471, IEEE 1471 FAQ, IEEE 1471 events calendar, downloads and links related to the standard.
Standards and Guides
ISO/IEC JTC 1, SC 7 Standards Relevant to Systems Engineering
ISO/IEC 14102:2008, Information technology — Guideline for the evaluation and selection of CASE tools ISO/IEC 15026:1998, Information technology — System and software integrity levels
ISO/IEC DTR 15026-1, Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary
ISO/IEC CD 15026-2, Systems and Software Engineering — Systems and Software Assurance — Part 2: Assurance case ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes
ISO/IEC 15289:2006, Systems and software engineering — Content of systems and software life cycle process information products (Documentation)
ISO/IEC 15504-1:2004, Information technology — Process assessment — Part 1: Concepts and vocabulary ISO/IEC 15504-2:2003, Information technology — Process assessment — Part 2: Performing an assessment ISO/IEC 15504-2:2003/Cor 1:2004
ISO/IEC 15504-3:2004 Information technology — Process assessment — Part 3: Guidance on performing an assessment
ISO/IEC 15504-4:2004, Information technology — Process assessment — Part 4: Guidance on use for process improvement and process capability determination
ISO/IEC 15504-5:2006, Information technology — Process Assessment — Part 5: An exemplar Process Assessment Model
ISO/IEC TR 15504-6:2008, Information technology — Process assessment — Part 6: An exemplar system life cycle process assessment model
ISO/IEC TR 15504-7:2008, Information technology — Process assessment — Part 7: Assessment of organizational maturity
ISO/IEC 15909-1:2004, Software and system engineering — High-level Petri nets — Part 1: Concepts, definitions and graphical notation
ISO/IEC 15909-1:2004/FPDAmd 1
ISO/IEC FDIS 15909-2, Software and system engineering — High-level Petri nets — Part 2: Transfer Format ISO/IEC 15939:2007, Systems and software engineering — Measurement process
ISO/IEC 16085:2006, Systems and software engineering — Life cycle processes — Risk management ISO/IEC FDIS 16326, Systems and software engineering — Life cycle processes — Project management ISO/IEC DTR 18018.2, Information technology — Configuration Management tool capabilities
ISO/IEC TR 19760:2003, Systems engineering — A guide for the application of ISO/IEC 15288 (System life cycle processes) ISO/IEC DTR 24748-1, Systems and software engineering — Guide for life cycle management
ISO/IEC FDIS 24765, Systems and software engineering — Vocabulary
ISO/IEC DTR 24766.2, Information technology — Requirement engineering tool requirements
ISO/IEC TR 24774:2007, Software and systems engineering — Life cycle management — Guidelines for process description ISO/IEC WD 26511, Software and systems engineering — User documentation requirements for managers
ISO/IEC CD 26512, Software and Systems Engineering — Requirements for acquirers and suppliers of user documentation 169ISO/IEC FDIS 26513, Systems and software engineering – Requirements for testers and reviewers of user documentation ISO/IEC 26514:2008, Systems and software engineering — Requirements for designers and developers of user documentation ISO/IEC NP 26516, Software and Systems Engineering – Reference model for software and systems product lines
ISO/IEC NP 26517, Software and Systems Engineering – Tools and methods of requirements engineering and management for product lines
ISO/IEC NP 26521; Software and Systems Engineering – Tools and methods of requirements engineering and management for product lines
ISO/IEC 26702:2007, Systems engineering — Application and management of the systems engineering process
ISO/IEC CD 29118, Information Technology – Tools and Methods of requirements engineering and management for product lines
ISO/IEC AWI 29148, Software and systems engineering — Life cycle processes — Requirements engineering
185ISO/IEC NP 29152, Software and Systems Engineering — Requirements for acquirers and suppliers of user documentation (proposed ISO/IEC 26512)
188ISO/IEC NP 29169, Information technology — The application of conformity assessment methodology to process capability and organizational maturity
190ISO/IEC 29881:2008, Information technology — Software and systems engineering — FiSMA 1.1 functional size measurement method
ISO/IEC 42010:2007, Systems and software engineering — Recommended practice for architectural description of software- intensive systems
ISO/IEC CD 42010, Systems and software engineering — Architectural description 193ISO/IEC 90003:2004
ISO/IEC TR 90005:2008, Systems engineering — Guidelines for the application of ISO 9001 to system life cycle processes More information: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.htm?commid=45086
A Definition to Close On
Capability Maturity Model (CMM)
A model that contains the essential elements of effective processes for one or more disciplines and describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.
Source: CMMI® for Development, Version 1.2
Project Performance International News
PPI Releases New Course “Cognitive Systems Engineering” presented by Dr. Gavan Lintern
Cognitive systems engineering (CSE) is an approach to the engineering of systems containing humans. CSE aims to amplify and make more reliable the human capability to perform cognitive work, by integrating technical functions of subsystems with the human cognitive processes that they need to support. Cognitive work involves the cognitive activities of knowing, understanding, planning, deciding, problem solving, integrating, analyzing, synthesizing, assessing and judging, as performed, for example, in military command and control, civil air traffic control, transportation, health care and video games!
This course, which we believe to be world-leading, teaches methods of cognitive analysis and cognitive design, and illustrates how the methods can be applied to enhance human systems effectiveness and safety within system development and acquisition. Experiential design exercises give delegates practical experience with these techniques. The course, while standing alone, complements PPI’s 5-day systems engineering course.
The 5-day course is available on-site, worldwide. Initial public deliveries will be:
28 Sep – 2 Oct, 2009 Adelaide, SA, Australia
2 – 6 Nov, 2009 London, U.K.
16 – 20 Nov, 2009 Las Vegas, U.S.A.
More information
PPI Changes Brazil Contacts
With effect from 8 July 2009, PPI’s new contact arrangements for PPI’s clients in Brazil are: Tel.: +55 12 3212 2017 (answers in Australia)
Fax: +61 3 9876 2664
Professional: Robert Halligan Administrative: Joshua Freeman
After a transition period, calls from Brazil clients may be returned in Portuguese or English, as appropriate to the caller.
More information
PPI On-Site Training May/June
During May and June 2009, PPI delivered on-site training in Canada, Australia, the United Kingdom, and Turkey.
Project Performance International Events
Systems Engineering 5-Day Courses
Upcoming locations include:
Melbourne, Australia Sydney, Australia Adelaide, Australia Munich, Germany Singapore
Rio de Janeiro, Brazil Cape Town, South Africa Las Vegas, USA
View 2009 Systems Engineering Course Schedule
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
Las Vegas, USA Melbourne, Australia Cape Town, South Africa
Amsterdam, The Netherlands Adelaide, Australia
View 2009 RA&SW Course Schedule
OCD/CONOPS 5-Day Courses
Upcoming locations include:
Adelaide, Australia Las Vegas, USA Pretoria, South Africa
View 2009 OCD/CONOPS Course Schedule
Software Engineering 5-Day Courses
Upcoming locations include:
Pretoria, South Africa Adelaide, Australia Amsterdam, The Netherlands
View 2009 Software Engineering Course Schedule
PPI Upcoming Participation in Professional Conferences
20 – 23 July, 2009 – INCOSE International Symposium 2009 – Singapore (Exhibiting) 20 – 23 July, 2009 – MICSSA 2009 – Pretoria, South Africa (Silver Patron)
18 – 22 August, 2009 – INCOSE South Africa 2009 – Pretoria, South Africa (Gold Sponsor)
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
Michael Halligan, Production, email: halliganm@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.
Disclaimer
No person should rely on the contents of this publication without first obtaining advice from a qualified professional person. This publication is provided free as a public service on the understanding that (1) the authors, consultants and editors are not responsible for the results of any actions taken on the basis of information in this publication, nor for any error in or omission from this publication; and (2) the publisher is not engaged in rendering professional or other advice or services. The publisher, and the authors, consultants and editors, expressly disclaim all and any liability and responsibility to any person, whether a reader of this publication or not, in respect of anything, and of the consequences of anything, done or omitted to be done by any such person in reliance, whether wholly or partially, upon the whole or any part of the contents of this publication. Without limiting the generality of the above no author, consultant or editor shall have any responsibility for any act or omission of any other author, consultant or editor.
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.
