Dear Colleague,
SyEN is an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at www.ppi-int.com.
Systems engineering can be thought of as the problem-independent, and solution/technology-independent, principles and methods related to the successful engineering of systems, to meet stakeholder requirements and maximize value delivered to stakeholders in accordance with stakeholder values.
If you are presently receiving this newsletter from an associate, you may receive the newsletter directly in future by signing up for this free service of PPI, using the form at www.ppi-int.com. If you do not wish to receive future SE eNewsletters, please reply to this e-mail with "Remove" in the subject line, from the same email address. Your removal will be confirmed, by email.
We hope that you find this newsletter to be informative and useful. Please tell us what you think. Email to: contact@ppi-int.com.
A Quotation to Open On
Featured Article: The Use of English Language in Requirements Specifications
Systems Engineering News
Featured Society - American Society for Engineering Management (ASEM)
INCOSE Technical Operations - Model Driven System Design Working Group
Systems Engineering Software Tools News
Systems Engineering Books, Reports, Articles and Papers
Conferences and Meetings
Education and Academia
Some Systems Engineering-Relevant Websites
Standards and Guides
Some Definitions to Close On - Related to Problem Definition
PPI News
PPI Events
“Engineers participate in the activities which make the resources of nature available in a form beneficial to man and provide systems which will perform optimally and economically” - L. M. K. Boelter (1957)
by Robert J. Halligan, FIE Aust
Managing Director, Project Performance International
PO Box 2385
Ringwood North, Vic, 3134
Australia
Email: rhalligan@ppi-int.com
Anybody who has prepared requirements specifications knows how easy it is to express requirements which are ambiguous, incomplete, factually incorrect, unverifiable, or unclear. Anybody who has used requirements specifications knows about the damage that defective requirements can do within a project.
An effective technique for finding defects in specified requirements is the use of keyword searching, against parts of words, words and phrases, each of which may indicate a defect in a requirement. In this article, we spell out the most problematic terms, and for each term, what to look for in checking its usage. Although written as a list for verifying requirements, the list provided also contains much advice for the original writer of requirements, and requirements specifications, in English.
The list is presented as a table, with an asterisk used to represent a wildcard, e.g. “*ing” means search for any word ending in “ing”.
Happy reading, and requirements writing!
Search Term |
Checks |
| *ing | Look for gerunds, such as “displaying”, “computing”. Check that any usage of gerunds is adequate. Rarely can gerunds be used adequately in requirements. |
| able | Check whether there is any ambiguity as to whether the item is required to actually do something, and if it is, the initiating conditions and/or the conditions during which it is required to do it. |
| accura* | Check that there is an objective criterion for accurate, accurately, accuracy, as applicable. |
| adequate | Check that there is an objective criterion for adequacy. |
| all | “All” is an absolute term. Check that “all” is meant literally. Often the term will need qualification, e.g. “all … with respect to ….” |
| always | “Always” is an absolute term. Check that “always” is meant literally. Often the term will need qualification, e.g. “always … with respect to ….” |
| and | “And” may reflect a compound requirement (two or more requirements expressed in the same sentence – check this. As well, the use of “and” sometimes gives rise to ambiguity – check this also. |
| and/or | “And/or” can give rise to ambiguity as to who is to make the decision between “and” and “or”. If this term is used (normally it shouldn’t be!), check that any ambiguity is acceptable. |
| and so on | This term implies more scope, usually without defining what that extra scope is required to be. This term should not normally be used. If the term is used, check that the vagueness is acceptable. |
| applicable | Check that an objective criterion for applicability is present. |
| appropriate | Check that an objective criterion for appropriateness is present. |
| approv* | Check that approval by whom is included, and that an objective criterion for approval having been given is present, e.g. “in writing”. |
| approximat* | Check that an objective criterion for the degree of acceptable approximation is present. |
| architecture (product specifications only) | Architecture is an abstract concept. Check that the requirement expresses a verifiable characteristic of the item. Check that the requirement is factually correct, e.g. avoid the situation where a requirement is placed on the architecture, but the characteristic is actually needed of the item. |
| assist | Check that an objective criterion is present for the degree and form of acceptable assistance. |
| bad | “Bad” is a value-based term. Check that an objective criterion is present for what constitutes “bad". |
| basically | Check that an objective criterion for what constitutes “basically” is present. |
| best | “Best” is a value-based term. Check that an objective criterion is present for what constitutes “best". “Best” is an absolute term. Check that “best” is meant literally. |
| better | “Better” is a value-based term. Check that an objective criterion is present for what constitutes “better". Check whether an objective criterion for the degree of “betterness” is needed. |
| between | Check whether there is ambiguity as to the inclusion or exclusion of limit values. Check whether there is ambiguity as to “all values between” or “only a subset of values between”. |
| but | Check that no contradiction is created through the use of “but”. |
| can | “Can” is a fact word. Check that a valid requirement is expressed. |
| capab* | Check that there is no ambiguity regarding “for but not with”, design goal” or “is to actually do” interpretations. If the item is to actually do something, check that the conditions under which it is required to actually do it are present. |
| certainly | Check that an objective criterion for certainty is present. |
| clearly | Check that an objective criterion for acceptable clarity is present. |
| compatibil* | Check that an objective criterion for compatibility is present. |
| complete* | “Complete” is an absolute term. Check that “complete” is meant literally. Check that an objective criterion is present for what constitutes completeness. |
| consider* | Check that an objective criterion is present, if needed, for the degree of acceptable consideration. If consideration is not required, check that the phrase containing the term is not spurious, e.g. background. |
| correct | Check that an objective criterion is present for correctness. |
| could | Check that a valid requirement has been specified. |
| design* (product specifications only) | Check that the requirement expresses a verifiable characteristic of the item. Check that the requirement is factually correct, e.g. avoid the situation where a requirement is placed on the activity of design, but the characteristic is actually needed of the item. |
| do | Check whether necessary performance (how well) is present. |
| down to | Check whether there is ambiguity as to the inclusion or exclusion of the limit value. Check whether there is ambiguity as to “all values down to” or “only a subset of values down to”. |
| easily | Check that an objective criterion is present for the degree of ease. |
| easy | Check that an objective criterion is present for the degree of ease. |
| effective | Check that an objective criterion is present for the degree of acceptable effectiveness. |
| efficient | Check that an objective criterion is present for the degree of acceptable efficiency. |
| elegant | Check that an objective criterion is present for what constitutes “elegant”. Rarely will the use of this term be appropriate. |
| eliminate | “Eliminate” is an absolute term. Check that “eliminate” is meant literally. Often the term will need qualification. |
| enhance | “Enhance” is a value-based term. Check that an objective criterion is present for what constitutes enhancement. Check whether an objective criterion is needed and present for the degree of enhancement. |
| enough | “Enough” is a value-based term. Check that an objective criterion is present for what constitutes “enough”. |
| equivalent | Check that an objective criterion is present for equivalence. |
| etc. | This term implies more scope, usually without defining what that extra scope is required to be. This term should not normally be used. If the term is used, check that the vagueness is acceptable. |
| every | “Every” is an absolute term. Check that “every” is meant literally. |
| excellent | “Excellent” is a value-based term. Check that an objective criterion is present for what constitutes “excellent”. |
| feasibil* | Check that an objective criterion is present regarding feasibility. The requirement may need to identify who is to adjudicate feasibility, and when in time the criterion applies. |
| first rate | “First rate” is a value-based term. Check that an objective criterion is present for what constitutes “first rate”. |
| frequent* | Check that an objective criterion is present for frequency. |
| full | “Full” is an absolute term. Check that “full” is meant literally. Check that an objective criterion is present for what constitutes “full”. |
| give* | Check that the phrase containing the term is not spurious, e.g. background. |
| good | “Good” is a value-based term. Check that an objective criterion is present for what constitutes “good”. |
| great | “Great” is a value-based term. Check that an objective criterion is present for what constitutes “great”. |
| handle | Handle is a vague term. Check that the action required is specified with adequate precision. |
| high | If applicable to the use of the term, check that an objective criterion is present for what constitutes “high”. |
| however | Check that no contradiction is created through the use of “however”. |
| ideal | Check that an objective criterion is present for what constitutes “ideal”. |
| improve | Check that an objective criterion is present for the acceptable degree of improvement. |
| in order to | “In order to” expresses purpose, not requirement. Check that the use of this term is not spurious. |
| incorrect | Check that an objective criterion is present for what constitutes incorrectness. |
| Intended use | Check that there is an objective reference for intended use. |
| intuitive | Check that an objective criterion is present for what constitutes “intuitive”. |
| is | “Is” is a fact word. Check that a valid requirement is expressed. |
| its | Check for ambiguity. |
| large | If applicable to the use of the term, check that an objective criterion is present for what constitutes “large”. |
| least | Check that an objective criterion is present for “least”. |
| like | Check that an objective criterion is present for what constitutes “like”. |
| low | If applicable to the use of the term, check that an objective criterion is present for what constitutes “low”. |
| match* | Check that an objective criterion exists for what constitutes a match. |
| maximize | “Maximize” is an absolute term. Check that “maximize” is meant literally. Often the term will need qualification. |
| maximum | Check for ambiguity. |
| may | Check that “may” is used only to express permissive guidance, and only where the giving of a permission is logically valid. |
| most | Check that an objective criterion is present for “most”. |
| minimize | “Minimize” is an absolute term. Check that “minimize” is meant literally. Often the term will need qualification. |
| minimum | Check for ambiguity. |
| must | Check that must is defined to express a requirement, to avoid the ambiguity of alternative meanings: a statement of occurrence, or a statement of inevitability. Check that “must” and “shall” are not mixed in the requirements specification, unless each term is clearly and appropriately defined. Generally, the use of “must” should be avoided. |
| near* | Check that an objective criterion exists for what constitutes “near”. |
| necessary | Check that an objective criterion exists for what constitutes “necessary”. |
| never | “Never” is an absolute term. Check that “never” is meant literally, and is consistent with the context of use of the requirements specification. |
| nominal | Check that “nominal” is used only to amplify, not specify, e.g. “454.54mm (19 inch nominal)”. |
| none | “None” is an absolute term. Check that “none” is meant literally. |
| normal* | Check that an objective criterion exists for “normality”. Check for missing requirement(s) relating to abnormality. |
| obviously | Check that the word is not in a spurious phrase not specifying a part of the requirement. If the word is used in specifying a requirement, check that an objective criterion is present for what constitutes “obviously”. |
| often | Check that the word is not in a spurious phrase not specifying a requirement. If the word is used in specifying a requirement, check that an objective criterion is present for what constitutes “often”. |
| operate | “Operate” means “do something”. It does not mean “do everything”, nor “do something with specified performance”. Nor does “operate” cover non-functional requirements. If the intention is to cover only functional and performance requirements, check that the term is used within “shall operate as specified herein”. If the intention is to cover all other requirements, check that “shall operate” is defined to mean “shall meet all other requirements herein” or similar. Or avoid use of the term. |
| optimize | “Optimize” is an absolute term. Check that “optimize” is meant literally. Check that an objective criterion is present for what constitutes “optimum”. |
| optimum | Check that an objective criterion is present for what constitutes “optimum”. |
| or | Check for ambiguity. |
| ordinarily | Check that the word is not in a spurious phrase not specifying a requirement. If the word is used in specifying a requirement, check that an objective criterion is present for what constitutes “ordinarily”. Check for any missing requirements relating to “extra-ordinarily”. |
| possible | Check that an objective criterion is present regarding what constitutes possibility. May need to identify who is to adjudicate possibility, and when in time the criterion applies. |
| practicable | Check that an objective criterion is present regarding what constitutes practicability. May need to identify who is to adjudicate practicability, and when in time the criterion applies. |
| process* (product specification only) | Check that the use of this term as a verb does not result in vagueness (inadequate precision) or ambiguity. |
| propos* | Check that the requirement is expressed as an innate characteristic required of the item, irrespective of the context of usage of the requirements specification. |
| provide | Check that the vagueness usually associated with this term is acceptable. |
| quality | Check that an objective criterion is present for what constitutes “quality”. |
| quick | Check that an objective criterion is present for what constitutes “quick”. |
| rapid | Check that an objective criterion is present for what constitutes “rapid”. |
| readily | Check that an objective criterion is present for what constitutes “readily”. |
| real-time | Check that this term is adequately defined (because of the diversity of meanings of this term). |
| relevant | Check that an objective criterion is present for what constitutes “relevant”. |
| requir* | Check that the requirement is written as a statement of requirement (e.g. The system shall ..) not a statement of fact (e.g. XYZ is required). |
| same | “Same” is an absolute term. Check that “same” is meant literally. Check that an objective criterion for what constitutes “same” exists, and that the requirement is verifiable. |
| satisfactory | Check that an objective criterion is present for what constitutes “satisfactory”. |
| seamless | Check that an objective criterion is present for what constitutes “seamless”. |
| shall be | Check that passive expression is not used where active is needed (e.g. “Current time shall be displayed”). |
| shall include but not be limited to | This phrase is either incorrect or is ineffective. If the intention was to require more, the phrase is ineffective because it provides no criterion for the “more”. If the intention was to permit but not require more, the phrase is factually incorrect. |
| should | Check that each “should” expresses a goal, intended to endure as a goal through supply or development (as applicable). Check for missing requirements that should be matched to goals, but are not (e.g. The system shall have a mass not exceeding 32kg. The system should, as a goal, have a mass not exceeding 20kg.). |
| significant | Check that an objective criterion is present for what constitutes “significant”. |
| similar | Check that an objective criterion is present for what constitutes “similar”. |
| simple | Check that an objective criterion is present for what constitutes “simple”. |
| skip | Check that the use of this term is not ambiguous. |
| small | Check that an objective criterion is present for what constitutes “small”. |
| so as | “So as” expresses purpose. The use of this term in a requirement is unlikely to be appropriate. |
| so forth | This term implies more scope, usually without defining what that extra scope is required to be. This term should not normally be used. |
| so that | “So that” expresses purpose. The use of this term in a requirement is unlikely to be appropriate. |
| some | Check that an objective criterion exists where needed. |
| sometimes | Check that an objective criterion exists where needed. |
| subject to | Check for ambiguity. The use of this term is generally ambiguous. |
| substantial | Check that an objective criterion is present for what constitutes “substantial”. |
| such as | “Such as” expresses example. Check whether an effect was intended, e.g. “such that …”. An example should not generally appear within a requirement, but may be used in a note to a requirement. |
| sufficient | Check that an objective criterion is present for what constitutes “sufficient”. |
| suitable | Check that an objective criterion is present for what constitutes “suitable”. |
| support | Check for ambiguity. “Shall support” will rarely be appropriate in a requirements specification. |
| target | Check for any inconsistency with the use of the word “should”. Check for any missing requirement that should be matched to a target, but is not. |
| tender* | Check for any ambiguity or incorrectness regarding “tenderer” versus “contractor”. |
| therefore | Check that the word is not in a spurious phrase not specifying a requirement, or part thereof. Check that usage of the word is factually correct. |
| transparent | Check that an objective criterion is present for what constitutes “transparent”. |
| typical | Check that the word is not in a spurious phrase not specifying a requirement. If the word is used in specifying a requirement, check that an objective criterion is present for what constitutes “typical”. Check for any missing requirements relating to “atypical”. |
| up to | Check whether there is ambiguity as to the inclusion or exclusion of the limit value. Check whether there is ambiguity as to “all values up to” or “only a subset of values up to”. |
| user-friendly | Check that an objective criterion is present for what constitutes “user-friendly”. |
| usually | Check that the word is not in a spurious phrase not specifying a requirement. If the word is used in specifying a requirement, check that the use is factually correct. Check for any missing requirements relating to “unusually”. |
| whether | Check for ambiguity. |
| will | Check that this word is not used in a requirement, or if it must be used, the word is defined as expressing a requirement, and is used totally consistently throughout the set of requirements. Note that “will” in English language expresses intent or futurity, but not requirement. |
| with | Check for ambiguity. |
| worse | “Worse” is a value-based term. Check that an objective criterion is present for what constitutes “worse". |
| worst | “Worst” is a value-based term. Check that an objective criterion is present for what constitutes “worst". “Worst” is an absolute term. Check that “worst” is meant literally. |
Copyright Project Performance (Australia) Pty Ltd 1996-2010
The UK Defence Science and Technology Laboratory (DSTL) chooses Artisan Studio for a new project requiring compliance with the Ministry of Defence Architectural Framework (MODAF) and recently standardized UPDM Profile
Dr Ricardo Valerdi is co-editing a special issue of the International Journal of Computer Integrated Manufacturing with the theme "Managing Through-Life Costs". The goal of this issue is to bring together the work that is currently being undertaken across the lifecycle phases and emerging research that considers integrated approaches for lifecycle costing. INCOSE members are encouraged to submit relevant papers on the subject of lifecycle costing. The deadline for manuscript submission is 5th March, 2010.
See the Call for Papers.
The 7th European Systems Engineering Conference (EuSEC 2010) is being held in Stockholm, Sweden over May, 23 - 26, 2010.
THe theme for this years conference is "Systems Engineering and innovation".
Beginning January 25th until 31st March it is possible to register for EuSEC 2010 with an early-bird discount.
More details available at the EuSEC website.
Date: Mar 10, 2010
Time: Noon - 1:00 PM
Calendar: School of Systems & Enterprises
Contact: Deidre Moore
Location: Online via Wimba
Stevens Institute of Technology
“Systems engineering is a core competency of NASA’s highly skilled workforce and has been recognized as one of the ”secrets” of the Agencies success in the Apollo program and many other Programs and Projects since then.”
“The Office of the Chief Engineer (OCE) has established the first annual NASA Systems Engineering Award. Each center nominated several highly deserving projects and each was worthy of recognition. After a very difficult and competitive review process the OCE is pleased to announce the 2010 award recipients.”
Vol 6 Issue 9 - 1 Dec 2009 (01 Dec 09)
In a special awards ceremony conducted during the International Workshop in Mesa, Arizona, USA, INCOSE will recognize 14 members as Expert Systems Engineering Professionals (ESEP).
Included in the ceremony will be Eileen Arnold, Jerry Fisher, Kevin Forsberg, Terje Fossnes, Karl Geist, John Gill, David Hall, Chuck Halligan, Ken Kepchar, Bill Mackey, John Muehlbauer, Yoshi Ohkami, Garry Roedler, Mr. Hillary Sillitto, Dan Surber, Bob Turk and Mark Wilson.
“The ESEP serves to validate the credibility of systems engineers who are leaders within their respective organizations, to give them visibility as role models for other systems engineers, and to acknowledge their status among their peers, superiors, clients, and customers,” according to David Walden, INCOSE Certification Program Manager.
http://govconwire.com/2010/01/incose-to-bestow-award/
April 5-8, 2010, Hyatt Regency Mission Bay Spa and Marina, San Diego, CA, USA
This year, INCOSE and IEEE have established an INCOSE Track at the IEEE International Systems Conference. There are twelve 30-minute open presentation slots. This notice is a call for abstracts and biographies for evaluation to fill those slots.
Theme: Engineering of Complex Systems - to include Systems-of-systems, Systems Engineering, Systems Integration, and Systems Thinking
Dr. Bo Oppenheim
Winner of Best INCOSE Product Award 2010, and Professor of Mechanical and Systems Engineering, and Graduate Director of Mechanical Engineering at Loyola Marymount University, Los Angeles, California
Wednesday, February 17, 2010, 12:00pm-1:00pm (EST)
ASEM was founded in 1979 by a group of 20 visionary engineering managers from industry, education, and government who recognized that in an increasingly complex and technically based society:
The ability to manage and administer large technical engineering and research projects and budgets will continue to challenge engineering management skills; That approximately two-thirds of all engineers were spending a substantial portion of their professional careers as managers; That the management of technology required improved management processes; and That a career path that places engineers in management must be supported by engineering management education and organizations that strive to develop and enhance management skills. Since it's founding, ASEM has grown in membership, services, and recognition in the engineering management profession. Annual conferences have been held each fall since 1980 at locations from Washington D.C. to Portland, Oregon.
The 1986 Conference was held as part of the First International Conference on Engineering Management (ICEM) in September of 1986 in Arlington, Virginia. The 1989 conference was held as part of the Second International conference on Engineering Management (ICEM-II) in Toronto, Canada.
Today, ASEM is a major professional organization dedicated to the science and art of engineering management. ASEM transcends many engineering disciplines, supporting specialties, professional affiliations, and sectors of the engineering and technical community in industry, government, private practice, and education in strategic and important roles that advance engineering management.
A high-quality, technical journal which speaks to the state of the art of engineering management and helps engineering managers in their professional development;
Local sections that serve as a forum where the engineering manager may meet with their peers to exchange information on common management problems;
National and international forums for the exchange of information between other managers from industry government, and educational institutions;
A newsletter with current information on activities in ASEM and the engineering management community;
The opportunity to work with peers in developing guidelines and standards of performance for the engineering manager and accreditation standards for the engineering management education;
Student chapters at educational institutions to encourage students to become aware of engineering management;
Special recognition of outstanding engineering management achievements and performance through the annual ASEM awards program.
Ref: http://www.asem.org/about/index.html
To speak for the Engineering Management profession
Provide Engineering Management Solutions to leadership and management challenges to create and lead technical organizations
Promote the development and practice of the engineering management profession
Ref: http://www.asem.org/home.html
President:Dawn Utley
President-Elect:Joette Sonnenberg
Ref: http://www.asem.org/leaders/index.html
Website: http://www.asem.org
http://www.incose.org/practice/techactivities/wg/mdsd/
Characterize model driven system design and identify transition strategies from present document driven approaches.
Chair: Phil Spiby
Co-Chair: Roger Burkhart
Contact Model-Driven System Design Working Group for additional information or to join this group.
2008 International Workshop Model Driven System Design WG Summary Presentation (Size: 200K)
Galorath Incorporated announced major enhancements to its SEER For Hardware, Electronics & Systems ( SEER-H™ 7.1) software release. Galorath has added numerous enhancements and refined estimation of development labor, materials, cost schedule and reliability; production labor, material, reliability; and operations and support effort, schedule support approaches.
jUCMNav is a free, Eclipse-based graphical editor and an analysis and transformation tool for the User Requirements Notation (URN). URN is intended for the elicitation, analysis, specification, and validation of requirements. URN combines two complementary views: one for goals provided by the Goal-oriented Requirement Language (GRL) and one for scenarios provided by the Use Case Map (UCM) notation.
http://www.threesl.com/pages/webletter-February10/index.php
Systems of Systems (SoS) are a current focus of many organizations interested in integrating assets and utilizing new technology to create multi-component systems that deliver value over time. The dynamic composition of SoS along with the managerial independence of their component systems necessitates systems engineering considerations and methods beyond those of traditional systems engineering, particularly for SoS concept design. Qualitative and heuristic-based guidance is available in the literature, but there is a need for a method that will allow decision makers to quantitatively compare diverse multi-concept SoS designs on an equal basis in order to select value robust designs during concept exploration. Development of a quantitative method for SoS conceptual design will enable the consideration of many more architecture options than is possible through qualitative methods alone, facilitating a more complete exploration of a SoS design space. In this thesis, a quantitative method for SoS conceptual design, known as System of Systems Tradespace Exploration Method (SoSTEM), is presented. This method is based on the existing Dynamic Multi-Attribute Tradespace Exploration (MATE) which is a formal methodology for tradespace exploration during system design that allows the decision maker to make trades between both stakeholder preferences and systems early in the design process and includes the consideration of dynamic issues such as unarticulated stakeholder preferences and changing system context.

By Devendra K. Chaturvedi
Publisher: CRC Press, Publication Date: December 16, 2009
ISBN-10: 1439806721, ISBN-13: 9781439806722
Summary:
…But I think the world in which this mechanistic, linear, “if this, then that” thinking works is quickly coming to a close. Or, at least, that thinking may need to be applied in a different way…
…The problem with linear and mechanistic solutions is that when things get complicated – when the world becomes a dense ball of complexity and interconnection – those kinds of solutions often become Band-Aids that treat the symptom, but miss the root cause…
…This much is obvious: the society-environment relationship is a complex system. It might even be the most complex system, period. When problems within the system come to our attention, they deserve some serious thinking – not just a wave of the hand, followed by “Eh, technology’ll take care of it.”...
In this time of budgetary constraints and funding cutbacks, the news that the MacArthur Foundation is funding research on the development of systems thinking in middle school students is a heartening turn of events. According to a press release from Indiana University, professors Melissa Gresalfi and Kylie Peppler will be principal investigators on the three-year study called "Grinding New Lenses: A Design Project to Support a Systems View of the World." They are partnering with Nichole Pinkard, visiting professor at DePaul University, and Katie Salen, executive director of the Institute of Play, to create curricula to help sixth graders see and interpret the world with a "systems thinking disposition."
PAPERS:
CASE STUDY:
By Tom Gilb
Publisher: Butterworth-Heinemann, Publication Date: June 25, 2005
ISBN-10: 0750665076, ISBN-13: 978-0750665070
Book Overview:
Competitive Engineering documents Tom Gilb's unique, ground-breaking approach to communicating management objectives and systems engineering requirements, clearly and unambiguously.
Competitive Engineering is a revelation for anyone involved in management and risk control. Already used by thousands of project managers and systems engineers around the world, this is a handbook for initiating, controlling and delivering complex projects on time and within budget. Competitive Engineering copes explicitly with the rapidly changing environment that is a reality for most of us today.
Elegant, comprehensive and accessible, the Competitive Engineering methodology provides a practical set of tools and techniques that enable readers to effectively design, manage and deliver results in any complex organization - in engineering, industry, systems engineering, software, IT, the service sector and beyond.
By Andrew P. Sage
Publisher: Wiley-Interscience, Publication Date: March 27, 2000
ISBN-10: 0471027669, ISBN-13: 978-0471027669
Product Description
An easy-to-use, comprehensive guide to systems engineering methods.
Systems engineering (SE), or the engineering of large-scale systems, is key to achieving reliable, efficient, cost-effective products and services in diverse fields, including communication and network systems, software engineering, information systems, manufacturing, command and control, and defense systems acquisition and procurement. This book offers a unique introduction to the world of systems engineering, focusing on analysis and problem-solving techniques that can be applied throughout the life cycle of product systems and service systems. While the authors provide a framework for the functional levels involved in systems engineering processes and system management, the bulk of the discussion is devoted to the practical application of formulation, analysis, and interpretation methods.
Through the use of real-world examples and useful graphs, readers will learn to:
15 - 18 February, 2010. Andrzej Frycz Modrzewsk Cracow College, Krakow, Poland.
More information
17 - 19 February, 2010. Geneva, Switzerland.
More information
February 18, 2010
More information
March 12, 2010 - Dresden, Germany
More information
15 - 17 March 2010, Washington, DC, United States
More information
15-19 March 2010, Oldenburg, Germany
More information
March 17-18, 2010, National Defense Industrial Association, 2111 Wilson Blvd, Suite 400, Arlington, VA 22201
More information
17-19 March, Honoken, NJ, USA
More information
Satellite workshop of ETAPS 2010
March 21, 2010, Paphos, Cyprus
More information
21 - 26 March, 2010. Sierre, Switzerland.
More information
In conjunction with IEEE ECBS 2010, Oxford, UK
March 22-26, 2010
More information
22 - 26 March, 2010. Sierre, Switzerland.
More information
23 March, 2010. Laguna Cliffs Resort, Marriott Hotel - Dana Point
More information
24th March 2010, University of Bristol, exact location MVB/KES
More Information
April 5-8, 2010, Hyatt Regency Mission Bay Spa and Marina, San Diego, CA
More information
April 7-8, 2010, Statler Hotel Amphitheater
More information
April 7-9, 2010, Buena Vista Palace Hotel & Spa, Orlando, FL
More information
April 10, 2010. Paris, France
More information
April 10, 2010, Atlanta, GA, USA
More information
10 – 15 April 2010, Atlanta, GA, USA
More information
Organised at CHI 2010
10 – 15 April 2010, Atlanta, GA, USA
More information
April 11 - 15, 2010, Florida Hotel and Conference Center; Orlando, FL, USA
More information
April 11 - 15, as part of the 2010 Spring Simulation Multiconference at the Florida Mall Hotel and Conference Center in Orlando, FL, USA
In conjunction with CPSWEEK 2010
April 12th, 2010, Stockholm, Sweden
More information
April 12-13, 2010 - Cuenca, Ecuador
More Information
12 - 15 April, 2010, Orlando, Florida, USA.
More information
April 13 - 15, 2010, USA
More information
15 - 18 April, 2010, Scottsdale, Arizona, USA.
More information
April 21-23, 2010, Atlanta
More information
23 to 25 April 2010, Bangkok, Thailand
More information
26-29 April 2010, Salt Palace Convention Center, Salt Lake City, Utah
More information
April 30 – May 2, 2010, Adelphi University, Garden City, New York
More information
3 - 6 May, 2010, Stamford Grand, Adelaide.
More information
(organized in conjunction with ISORC 2010)
May 4th, 2010, Carmona (close to Sevilla), Spain
More information
May 5-6, 2010, Carmona (close to Sevilla), Spain
More information
May 8th, 2010, Cape Town, South Africa
More information
May 17-21, 2010, The Westin Lombard Yorktown Center, Chicago, Illinois, USA
More information
18-20 May 2010 - Pisa, Italy
More information
23 - 26 May, 2010, Stockholm, Sweden.
More information
Gaylord Opryland, Nashville, TN
May 24 – Thursday May 27, 2010
More information
June 7, 2010, Nantes, France
More information
In conjunction with CAiSE 2010
June 7-8, 2010, Hammamet, Tunisia
More information
In conjunction with CAiSE 2010
June 7-8, 2010, Hammamet, Tunisia
More information
In conjunction with CAiSE 2010
June 7-8, 2010, Hammamet, Tunisia
More information
In conjunction with CAiSE 2010
June 7-8, 2010, Hammamet, Tunisia
More information
07-11 June 2010, Hammamet, Tunisia
More information
June 8-11, 2010, George Mason University, Fairfax, Virginia, USA
More information
In conjunction with the 12th International Conference on Enterprise Information Systems (ICEIS 2010)
8 - 12 June, 2010, Funchal, Madeira - Portugal
More information
8 - 12 June, 2010, Funchal, Madeira - Portugal
More information
June 9-11, 2010, Singapore
More information
2nd Workshop in conjunction with SSIRI 2010
June 9-11, 2010, Singapore
More information
15/16 June 2010, Paris, France, in conjunction with ECMFA 2010
More information
June 15-18, 2010, Paris, France
More information
a satellite event of Petri Nets 2010
June 21, 2010, Braga, Portugal
More information
21-25 June, 2010, Braga, Portugal
More information
Collocated with Petri Nets 2010
June 21-25, 2010, Braga, Portugal
More information
22 June 2010 to 24 June 2010, Henry Ford College, Loughborough University, UK
More information
June 23-25 2010 Prague, Czech Republic
More information
June 28 - 30, 2010, TEI of Larissa (Greece)
More information
30 June – 2 July, 2010, Essen, Germany
More information
Satellite workshop to TOOLS 2010, 1 - 2 July, 2010, Malaga.
More information
July 1-3, 2010, National Taipei University of Technology, Taipei, Taiwan
More information
July 11–14, 2010, Ottawa, Canada
More information
July 12-15, 2010, Cambridge, United Kingdom
More information
11 - 15 July, 2010, Rosemont, IL, USA.
More information
In conjunction with COMPSAC 2010
Seoul, Korea, July 19 - 23, 2010
More information
July 21-23, 2010, Southampton, England
http://iscepublishing.com/Forum/default.aspx?g=posts&m=227
More information
July 25 – 29, 2010, Seoul, Korea
More information
To be held in conjunction with ICIS 2010
August 18 – 20, 2010, Yamagata University, Yonezawa, Japan
More information
August 22-27, 2010 - Nice, France
More information
September 1st & 2nd, 2010, Valenciennes/France
More information
1-3 September 2010, Grenoble Institute of Technology, France
More information
September 13, 2010, Hoboken, New Jersey – USA
More information
September 15 - 18, 2010, Williamsburg, Virginia, USA at the College of William & Mary, Computer Science Department,
More information
21-24 September 2010, Singapore
More information
University Residential Center of Bertinoro, Italy
23-24 September 2010
More information
September 27-October 1, 2010, San Francisco
More information
Sep 27, 2010 - Oct 1, 2010, Sydney, Australia
More information
27 September - 2 October, 2010. University Of Twente, Enschede, The Netherlands
More information
Joint with 2nd International Workshop on High Performance Computational Systems Biology (HiBi 2010)
September 30 - October 1, 2010, Twente, The Netherlands
Co-locating with
5th International Conference on Graph Transformation (ICGT 2010) , 29 September - 1 October, 2010
17th Annual workshop on Software Model Checking (SPIN 2010), 27 September - 29 September, 2010
More information
4 - 6 October, 2010. Keelung, Taiwan.
More information
October 16 – 20, Reykjavik Iceland
More information
October 20 – 23, 2010, Lugano, Switzerland
More information
October 27-29, 2010, Paris, France
More Information
1-4 November 2010, Vancouver, BC, Canada
More information
Nov 7, 2010 - Nov 8, 2010. Taipei, Taiwan
More information
January 25-27, 2011, Dubai, United Arab Emirates
More information
The overall program will comprise three possible awards. The first is a Postgraduate Certificate in Systems Thinking in Practice (C72) of 60 OU credit points. A new course due for first presentation in May 2010, ‘Thinking strategically: systems tools for managing change’ (TU811) is a compulsory 30 point course for this award together with another 30 point OU option, or where credit transfer has been arranged, a partner option.
The second award is a Postgraduate Diploma in Systems Thinking in Practice (E28) of 120 OU points. To be awarded the PG Diploma the PG certificate plus another 60 points of study must be completed. ‘Managing systemic change: inquiry, action and interaction’ (TU812) is a 30 point compulsory course with TU811 (above).
The third award is the MSc in Systems Thinking in Practice which is made up of the PG Diploma plus a further 60 points of study.
Rensselaer Polytechnic Institute, Troy, NY, USA, announced today its Department of Decision Sciences and Engineering Systems (DSES) will be renamed the Department of Industrial and Systems Engineering (ISE). The change, effective immediately, was approved recently by the Board of Trustees upon recommendation of the department and the dean, and with the support of the provost and the president.
École des Mines de Nantes (EMN) has opened a new permanent faculty position in the field of Model-Driven Engineering. The selected candidate will become part of the joint INRIA-EMN research team AtlanMod (http://www.emn.fr/x-info/atlanmod).
POSTDOC POSITION: "Real-time applications models simualtion" within the CEA LIST, Laboratory of Model Driven Engineering for Embedded Systems (LISE), Gif-sur-Yvette (Paris area), France.
Systems Engineering & Management (SEM) at UT Dallas is a new interdisciplinary program that focuses on the engineering and management of complex projects. Unlike any other program in North Texas, we provide a blending of expertise from faculty in engineering, computer science and management. The program features both technical and human-centered disciplines that broadly impact organizations and society.
Systems Engineering Advancement Research Initiative (SEAri) brings together a set of sponsored research projects and a consortium of systems engineering leaders from industry, government, and academia. SEAri is uniquely positioned within theEngineering Systems Division (ESD) at the Massachusetts Institute of Technology (MIT), a new kind of interdisciplinary academic unit that spans most departments within the School of Engineering, as well as the School of Science, the School of Humanities, Arts, and Social Sciences, and the Sloan School of Management.
http://www.sercuarc.org/research/research-projects/
The Systems Engineering Research Center is the first DoD University Affiliated Research Center focused on Systems Engineering Research in the United States.
What is the mission of the Systems Engineering Research Center?
The mission of the Systems Engineering Research Center is to enhance and enable the Department of Defense’s (DoD) capability in Systems Engineering for the successful development, integration, testing and sustainability of complex defense systems, services and enterprises.
http://www.peerpapers.com/topics/systems-thinking/0
Systems Thinking Essays and Term Papers
23–28, May 2010, Niigata, Japan
Information Processing Society of Japan /Information Technology Standards Commission of Japan(IPSJ /ITSCJ)
IPSJ /ITSCJ
Organizer contact: Jacky Takahashi at: inq-sc7niigata@itscj.ipsj.or.jp
Toki Messe Niigata Convention Center
Address: 6-1, Bandai-jima, Niigata-city, 950-0078, Japan
Web: http://www.tokimesse.com/english/
Problem definition is critically important to the achievement of stakeholder satisfaction. This month, we define a number of terms related to problem definition. Some definitions are perfectly general, and therefore applicable to an engineering context, whilst others are specifically framed for an engineering context.
PPI's Managing Director Robert Halligan is presenting a free tutorial to INCOSE - Chapter ITALIA on 17 February, 2010.
Title: "A Systems Approach to Love, Life and Business"
Date: 17 February, 2010
Time: 17:30 - 20:00
Venue:Sala Conegni "Piero Pozzoli", Confindustria La Spezia
This tutorial has also been presented to INCOSE South Africa and INCOSE Singapore.
Should you be interested in having this tutorial presented to your society, please contact us.
PPI has recently made a change in course locations in South Africa. Course originally scheduled to be delivered in Cape Town have now been moved to Stellenbosch. This is due to the high level of engineering releated activity in Stellenbosch.
See PPI's complete course schedule here.
Upcoming locations include:
View 2010/2011 Systems Engineering Course Schedule
Upcoming locations include:
View 2010/2011 RA&SW Course Schedule
Upcoming locations include:
View 2010/2011 OCD/CONOPS Course Schedule
Upcoming locations include:
View 2010/2011 Software Engineering Course Schedule
Upcoming locations include:
View 2010/2011 Cognitive Systems Engineering Course Schedule
Kind regards from the SyEN team:
Robert Halligan, Managing Editor, email: rhalligan@ppi-int.com
Alwyn Smit, Editor, email: asmit@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 2010 PROJECT PERFORMANCE (AUSTRALIA) PTY LTD, ABN 33 055 311 941. May only be copied and distributed in full, and with this Copyright Notice intact.
SyEN makes informative reading for the project professional, containing scores of news and other items summarizing developments in the field of systems engineering and in directly related fields.