Home » Resources » SyEN Newsjournal » PPI SyEN 25

PPI SyEN 25

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

Welcome to PPI SyEN 25

WHAT’S INSIDE:

A Quotation to Open On

Feature Article: The Great Divides in Systems Engineering

Systems Engineering News

18th IEEE Requirements Engineering Conference (RE 2010)
Upcoming Submission Deadlines and Themes for INSIGHT
INCOSE eNote: News and Notes from the INCOSE Network
Systems Engineering Certification Tutorial Webinar
INCOSE Event Calendar
Theme issue: Domain-Specific Modeling in Theory and Application
INCOSE INSIGHT – October 2010, Vol 13 – Issue 3
INCOSE Webinar October 20

Featured Societies – TBD

INCOSE Technical Operations – Verification and Validation Working Group

Systems Engineering Software Tools News

Siemens PLM Software Launches Machine Design Solution

Systems Engineering Books, Reports, Articles and Papers

New Multi-Million Pound Partnership Aims to Grow Systems Engineering Expertise in the Construction Industry
System-of-Systems Engineering

Conferences and Meetings

Education and Academia

Two Research Fellow Positions on Model Checking at National University of Singapore

Some Systems Engineering-Relevant Websites

Standards and Guides

ISO/IEC JTC 1/SC7 Interim Meeting

A Definition to Close on

PPI News

PPI Events

A Quotation to Open On

“Genius is typically the act of an individual; incredible stupidity can usually be traced to a committee”

‘Foe Hammer’ from an Electronista post, February 15, 2010

Feature Article

The Great Divides in Systems Engineering

Dr. Joseph Kasser DSc, CEng, FIET, CM, CMALT

Joseph.kasser@incose.org

Http://therightrequirement.com

Step outside systems engineering for a moment and look back into it. Range around the perspectives perimeter (Kasser, et al., 2009)and observe what you see from the different perspectives (Kasser and Mackley, 2008). I’ve been doing this for 15 years and have come up with and researched the following hard questions that nobody else seems to be tackling.

Why is there no universal agreed-to definition of systems engineering?
Why are there differing views on nature of systems engineering?
Why are there dichotomies on how to tackle the problems posed by system of systems, and complex systems? One group states that they are difficult problems that cannot be solved with current techniques while the other group just gets on with it without a fuss.
Why does systems engineering work well sometimes?
Why does systems engineering fail miserably (and expensively) other times?
Why is there no widely accepted body of knowledge for systems engineering?

From the generic systems thinking perspective, these types of questions tend to be posed by an observer looking into a discipline in its formative years. A discipline in this stage is characterized by

debates based on subjective opinions
participants talking past each other
a lack of listening
contradictory and confusing information
a number of myths

If systems engineering itself is considered as a system, then the parts can be aggregated in several ways and the following divisions show up.

Life cycle phase gap
Process-problem paradigms gap
Discipline-enabler paradigms gap
Systems thinking and non-systems thinking gap

Consider each of these divisions

Life cycle phase

Some systems engineers seem to have an understanding of the early stage systems engineering that takes place in Column A of the Hitchins-Kasser-Massie Framework (HKMF) for understanding systems engineering (Kasser and Massie, 2001; Kasser, 2007b, a). The majority however have no idea that column A even exists and don’t understand what happens in that column. The column A group tends to be the old timers; while the others tend to be those systems engineers educated in the last 20-30 years.

Process-problem paradigms

Some systems engineers are process-focussed others focus on identifying the correct problem and realizing the best solution achievable within the constraints that exist at the time. The process-focussed systems engineers‘ mantra is to apply the systems engineering process and all will be well. These are the ones who insist that organisations must modify themselves to follow a particular process. The others focus on the problem, identifying the best solution available given the constraints at the time and develop and then carry out a process to fit the situation.

Discipline-enabler paradigms

This is related to the process-problem gap. On one side, systems engineering is a [process] discipline, on the other side of the gap it’s an enabler. The discipline camp preach that systems engineering needs to widen its span to take over other disciplines while in the enabler camp, systems engineering is just a tool that can be used in all disciplines for tackling certain types of problems.

Systems thinking and non-systems thinking

This gap represents the camps that look outwards from systems engineering and those that can see systems engineering from both inside and outside. Those that can see systems engineering from outside tend to be systems thinkers who can view an issue from multiple viewpoints while the insiders tend to have a single viewpoint. The insiders generally exhibit the ‘biased jumper’ level of critical thinking (Wolcott and Gray, 2003) at least as far as systems engineering is concerned and also belong in the process paradigm. The outsiders generally also belong in the enabler paradigm.

Discussion

Still with me? If you are then I have the following questions for you.

Are you aware of these divisions?
On which side of each of them are you?

Do you agree with this analysis? Let’s hear from you on the INCOSE discussion reflector. If you want more information, check out the papers on my web site.

References

Kasser, J. E., A Framework for Understanding Systems Engineering, Booksurge Ltd, 2007a.
Kasser, J. E., “A Proposed Framework for a Systems Engineering Discipline”, proceedings of The Conference on Systems Engineering Research, Hoboken, NJ, 2007b.
Kasser, J. E., Hitchins, D. and Huynh, T. V., “Reengineering Systems Engineering”, proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering (APCOSE), Singapore, 2009.
Kasser, J. E. and Mackley, T., “Applying systems thinking and aligning it to systems engineering”, proceedings of the 18th INCOSE International Symposium, Utrecht, Holland, 2008.
Kasser, J. E. and Massie, A., “A Framework for a Systems Engineering Body of Knowledge”, proceedings of 11th International Symposium of the INCOSE, INCOSE, Melbourne, Australia, 2001.
Wolcott, S. K. and Gray, C. J., Assessing and Developing Critical Thinking Skills, 2003, http://www.wolcottlynch.com/Downloadable_Files/IUPUI%20Handout_031029.pdf, last accessed

Systems Engineering News

18th IEEE Requirements Engineering Conference (RE 2010)

By A Smit

RE 2010 took place from September 27 to October 1, 2010 in Sydney, Australia. When I was presented with the opportunity to attend this conference, I was more than happy to add one more continent to my list of overseas visits. The land down under has long been a favourite destination for many South Africans, many who have taken a one-way trip over the last two decades. Arriving in Sydney after a 12 hour plane trip, my only interest was to find the fastest transport and the shortest route to the hotel. After a good rest I donned my walking shoes and hit the road. What an experience! Sydney is indeed a beautiful city with lots of things to do and places to see. During my first two days I first did some scouting on the City Explorer bus tour and then, by foot, visited the Darling Harbour area, the Aquarium, the Foreshore Walk from Darling Harbour to Circular Quay, Circular Quay, the Botanical Gardens, the Opera House, various shopping centres (1^st on the list was of cause the Apple Store) and of course a harbour cruise. The start of the conference actually came as somewhat of a relief to my aching feet.

$D:\My Documents\My Pictures\2010_09_25_to_31_Sydney\Picture 185.jpg$ The conference started on Monday 27 September with four parallel tracks covering two workshops and four tutorials. On Tuesday another five workshops were presented in parallel tracks as well as another four tutorials in four parallel tracks. The last three days consisted of paper sessions and other special sessions as well as twelve very impressive and professional looking posters displayed in the hallway.

On Wednesday morning Mary O’Kane, NSW Chief Scientist and Engineer, gave the keynote on “Requirements Engineering for Expensive Technologies Which need to Operate in Underconstrained Policy Systems that are Interdependent with National and Regional Economies”. She highlighted the special challenges facing large renewable energy projects a time of great uncertainty about policies on climate change and emissions control.

The keynote on Thursday morning was given by Professor Al Davis, University of Colorado at Colorado Springs, USA on “Requirements: A Textbook Example of Goals Displacement”. He stressed that the goal of requirements engineering (or requirements management) is to increase the likelihood that the end product of the endeavour does in fact create value for stakeholders. Quoting from the abstract “Instead, we see displaced goals like: create a perfect software requirements specification (SRS); check an SRS for some combination of completeness, consistency, non-ambiguity, etc; automatically generate (or analyze) some formalized modelling notation; follow an onerous 20-step process; or automatically transform one modelling notation into another. Woefully few (although there are some terrific exceptions!) published papers connect the requirements process with its real goal: value creation.”

The keynote at the closing plenary on Friday was given by Graeme Simsion of Simsion & Associates on “Being Right Isn’t Enough”. The key message was that the greatest challenges in practical requirements engineering are psychological and political rather than technical and that the requirements engineer is quite often also communicator, interpreter, facilitator, conciliator, negotiator, salesman and sometimes counsellor.

The social events associated with this conference were something to remember. Firstly the welcome reception took place at the Opera Bar at……you guessed it, the Sydney Opera House. The conference banquette was an unforgettable harbour cruise dinner on the Blue Room departing from Star City Warf, Pyrmont.

Being the first IEEE RE conference that I attended, it was very apparent that the general attendance and the presentation of papers were predominantly from the software engineering industry. What was also surprising to see was the huge research component: nine research sessions presented compared to the five industry practice and experience sessions.

Current requirements engineering practices in my own environment were confirmed and renewed emphasis has been placed on spending enough time in doing RE and paying particular attention to requirements traceability. Some techniques that I want to investigated further is cognitive mapping and i* modelling. The most promising research papers were on automated requirements tracing and the most interesting were on linguistic analyses to improve requirements quality.

$D:\My Documents\My Pictures\2010_09_25_to_31_Sydney\Picture 536.jpg$ In a fitting conclusion to a wonderful trip, I visited the Blue Mountains on my last day in Australia. Having walked down the Furber steps into the Jamison Valley beside Katoomba Falls, the near vertical (so it felt) train trip back up was awe inspiring.

Sitting on the plane on the long trip back home, I could not help but wonder why requirements engineering still seems to be so much of a stumbling block for the successful execution of projects if there is so much research going on. Are we really making sure that we tailor the breadth and depth of the RE effort to only that which adds value to our particular project? Do we really devote enough time to the RE effort or are we pressured into a rushed completion of specifications in order to get hardware and software that we can show for our effort? Are we meticulous enough with the wording of requirements and with traceability? Most importantly, do we do enough to train young practitioners in the ABC of RE to fast track them on the road to becoming proficient requirements analysts?

And O! Does the INCOSE RE working group and the IEEE cooperate at all on RE?

Upcoming Submission Deadlines and Themes for INSIGHT

INSIGHT is the newsletter of International Council on Systems Engineering. It is published four times per year (January, April, July, October). INSIGHT features status and information about INCOSE’s technical work, local chapters, and committees and boards. Additionally, related events, editorials, book reviews, trends, and how-to-do articles that are pertinent to the many aspects of a systems engineer’s job are also included, as space permits.

Upcoming submission deadlines and themes for INSIGHT

INCOSE eNote: News and Notes from the INCOSE Network

eNote is the electronic newsletter of INCOSE. Published every four to six weeks, eNote is a compilation of INCOSE news, event announcements, and items of interest for our members. Subscriptions to eNote are available to INCOSE members as part of their membership.

eNote features INCOSE information as well as notes from systems engineering and related fields. Questions and comments as well as submissions for future eNotes should be directed to the eNote Editorial Team.

PPI SyEN 25

Subscribe to PPI SyEN

PPI SyEN 143

PPI SyEN 142

PPI SyEN 141

PPI SyEN 140

FREE Original SE Articles and Industry News?

Subscribe to PPI

MORE About Us