Email not displaying correctly? View it in your browser.
INCOSE Chesapeake Chapter

  June 2015Back Issues

Forward to Friend

President’s Point of View

Mr. George Anderson
INCOSE CC President george.anderson@incose.org


June begins a busy summer for our chapter. Our monthly membership meeting is coming up on Wednesday June 17, 2015 and will feature the Video, The Deming of America, a dramatic look at the origins of the process improvement movement. This video was originally produced for Television by Priscilla Petty. We use it with her kind permission and wish to thank her for her continuing support of our educational programs.

Closely following this meeting, we have our IBM System Architect with DoDAF class being held in the Kossiakoff Center on Monday through Wednesday, June 29, 30 and July 1, 2015. This course is hands-on and is the best chance to actually become proficient in producing DoDAF, DM2 compliant architecture data models. The course is presented by AVNET, a licensed IBM training provider who provides training materials and a completion certificate. Breakfast and lunch menus are part of the tuition fee and are provided by Sodexo, the on-campus contract catering service. The class is limited to 12 persons so that the instructor, Edward Vail, can provide personal assistance to each student as they struggle with the sometimes confusing menus and other options of System Architect. (I completed this program last year and I speak from experience.) The Chapter is working as a partner with AVNET to bring this course to our area at lower cost and a convenient venue, and we hope our members who need this level of training will be able to attend.

The last event is the most important. We must prepare for the International Symposium being held 13-16 July at Seattle, WA. We have advertised Chesapeake shirts on the web site and encourage everyone, but especially those who are planning to attend, to purchase a shirt. This is to show your affiliation as we are presented with the President’s award for the unsurpassed performance of the Chapter mission in 2014. There is a two-week lead time so please act promptly. Challenge coins will also be available for purchase at the next, and subsequent, member meetings for those who want to further prepare themselves for attending the IS. (For those attending who do not have chapter shirts or coins, we have a requirement for several attendees to wear a large MD crab or Chesapeake heron costume as an alternative.)

Other planning this month is directed toward making our Systems Engineering Professionals (SEP) reception a repeat success. This year, we are embracing our regional chapters, Washington Metro and Southern MD, in an attempt to reach out to more SEPs and potential candidates. As in past years, we welcome our partners in Government and industry and other engineering and professional societies to attend and enjoy an inspiring social event with featured speakers and an atmosphere of elegance that always delights and enhances our appreciation of this event. The reception is scheduled for Wednesday evening, the 26th of August 2015 at the Engineers Club of Baltimore. The online registration for the event will open early for your planning convenience.

The SEP reception is not complete without announcing and honoring our new certified professionals. We will honor those who have attained the highest level of achievement, the Expert Systems Engineering Professional or ESEP.

I am pleased to announce that we have two new ESEPs as of this writing. Myra Gross of Jovian Concepts was notified in January and Craig Tyler of Vencore was notified last month. We will be honoring them and any further additions at the Reception.

As we move through a busy summer, please remember important changes taking place affecting the practice of systems engineering. The biggest news this month is the release of two DoD supplements to the ISO 15288:2015 standard. Among other things, these supplements require the use of the standard in DoD procurement processes. This is a significant change in DoD policy and a huge vote of confidence for the practice of systems engineering in general. We, of course, expected this because of our January presentation by Gary Roedler, who played an important role in drafting the standard.

In closing, I want to continue to urge everyone to become more involved in the systems engineering profession and to consider the benefits of spending some time helping the Chapter execute the important work that we graciously provide as a focus on, and example of, systems excellence. We believe that this contributes measurably to Maryland’s sustainment and growth.


George Anderson – INCOSE Chesapeake Chapter President

Return to top

17 June, 2015 (6:00pm – 8:00pm): The Deming of America; Produced for Television by Priscilla Petty


Presentation: This video, originally produced for Television by Priscilla Petty, provides a dramatic look at the origins of the process improvement movement. Our nation must work once again to come out of our crisis. We’re challenged by global and local events. But the proven strategies in this documentary can help our country transform and innovate. Dr. W. Edwards Deming is shown at his unrehearsed best at his home, at a seminar, and in thought-provoking specially selected segments from an all-day interview with Priscilla. Brief remarks from Fortune 100 CEOs, who learned from Deming, show how he affected their thinking about their lives and companies as he worked with them to effect the transformation. Inspiring. Produced in 1991 by Petty Consulting Productions.

Click here for more details:(www.incose-cc.org)

Go to www.incose-cc.org/registration/ to register

Parsons Auditorium, Bldg 1
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD

View MapMap and Directions


Return to top

Revisiting the Wright Brothers and the Sound of Bells


George Anderson, ESEP

3 June 2015

A practicing systems engineer should consider approaching all projects as having unknowns that will require in depth examination and perhaps new insights or understanding. There are a lot of knowledgeable subject matter experts (SME) available but few of them can help when the information or practice is obscure, little studied or just unknown. The arrogance of assuming adequate knowledge to accomplish a task is a constant engineering hazard dating back to at least the ancient Egyptians who at one point had the world’s greatest building failure when an almost completed pyramid collapsed into a heap of dressed stone blocks. The giant debris field still exists today as an enduring reminder to do more thorough research on unknowns.[1]

Figure 1: Meidum Pyramid 2625 BC

We might be able to forget this 4640 year old disaster if more recent challenges were not so similar in the form of assuming adequate knowledge. I have worked on two projects that still amaze me as to the methods used and the types of critical knowledge involved. These involved the Wright brother’s progress towards manned flight and the analysis of the sound of bells. Both subjects would not have been of interest to me had I not been given systems engineering tasks that required me to fully understand the technical details of these two somewhat different technologies.

The Wright brother’s saga has been told many times but the latest work by historian David McCullough entitled, The Wright Brothers, is popular enough to become first on the NYT best seller list this week and inspire me to mention an example of their perseverance.

I am informed on most of the Wright’s technical advances having received my degree in Aerodynamics from an institution[2] that lies only a few hundred yards from Huffman Prairie—the Wright’s first aircraft flight test facility after Kitty Hawk. Although there is much to admire and consider about the Wright’s technical experimentation and development efforts, the point I especially want to highlight is their questioning of existing data on manned flight. They were so concerned that their early test flights were not consistent with existing data on the lifting forces of wings that they built their own wind tunnel. Using this tunnel, they spent hours testing wing shapes until they were sure that existing data was wrong. Before the Wright’s tunnel, there were no established devices that could be used for measuring forces on the test wing specimens.

My wind tunnel testing occurred in 1973. This was during a period when mathematical modeling of airflow over wings was heavily funded. News from the physical world that conflicted with the models was not welcome and there was a great deal of resistance to testing in general. Thanks to the example set by the Wright brothers, wind tunnels continued to provide real performance data that was used to design new aircraft and reduce risk. Today, we still have areas that are not well understood such as vortex flows, and some aspects of hypersonic flight. We also know little about the regime of microscopic flight (low Reynolds numbers) where many want to explore and develop unmanned micro vehicles.

Figure 2 The Wright Brothers Wind Tunnel on display at the USAF Museum, Dayton, OH

The problems faced by the Wrights are similar to many that we encounter today. It is always true that you need to explore all the problem space to find what you don’t know and make plans to deal with it. Like the captain on a ship, if you see an area of poorly charted waters you may avoid failure or uncertainty by circumnavigation. If you must sail in the unknown area prudence dictates that you study whatever information is available, make estimates and provide contingency plans for coping. The Wright brothers did not see the absence of a suitable tool to measure wing lift as an insurmountable barrier. They simply designed and developed their own. My other area of tracking the unknowns takes us to the much older technology of bells.

Bells represent an ancient technology that continues to serve a variety of purposes in almost every culture. Bells were being made before any scientific analysis using modern instruments and theories existed. The sound of the bell was its primary distinguishing feature and a customer, or customers, purchasing a bell had very strong ideas what that sound should be.

A few years ago, I was asked to oversee the founding of a sizable bell and assure its performance in my capacity as a test engineer. Why anyone thought I knew anything about bells says a lot about the management of the auto industry at that time, but also it may have more to do with the assumption that bells were just shapes of metal. I started my task with just that assumption and in several days of research was considerably humbled. I not only did not know how a bell was made, I did not know how the bell made its sounds, what they were, or how one controlled the process to achieve these sounds. SMEs could not explain what they knew in enough technical detail for me to make any progress.

I considered the explanation of tuning a bell especially baffling. Clearly, I needed further study. Later, I understood one reason for my confusion was the terminology used by the few people who knew about bells. After all at that time, there were only three bell founders in the US and less than eight in Europe.

Thankfully, the bell project was cancelled before my project was memorialized in a two-ton mass of copper-tin alloy scrap. What I had learned in the meantime was considerable. The highlights were:

  • A complete course in sound measurement permitted me to understand how to test a bell’s sound pressure emissions and describe them in acceptable laboratory terms using calibrated and repeatable processes.
  • I learned the language of the bells. People who write about bells talk in the language of music, and early design rules of thumb further obscured this by using centuries old jargon probably made legitimate by medieval guilds protecting their art.
  • Tuning a bell almost always involves removing metal from the inside of a newly cast bell.
  • Removing metal from a bell may not always produce the desired result.
  • In 2015, there is more, but still incomplete, theory on precisely how bells produce their sound spectrum and what constitutes the best or most desirable sounds.[3]
  • I have learned that researchers have established that the bell sounds are not the total system under study. The human ear with its perceived pitch and aural harmonics alters the sound of the bell to another pitch heard by the brain’s auditory receptors.[4] This effect is so significant that testing of humans in the loop has drastically changed the desirable spectral specifications for a bell.

Figure 3. The Ten Ton Weight Berlin Freedom Bell

Overall, I concluded that in the bell industry, nobody understood how to meet a customer’s expectations. This was partly because there were no modern technical standards and partly because the customer was probably expecting the sound produced by another bell. Rules of thumb and proprietary secrets ruled the industry and in the end you got a product that at best was tuned to nominal sound spectrum. Customers bought from the most prestigious or oldest foundry and humbly accepted the product as delivered. A delivery specification, if such was involved, was typically vague as to spectral performance.

This state of affairs led me to believe that our modern audio spectrum measurement capability was useless if the test specification was defective or not validated.

Unlike the pyramid collapse, neither of my learning experiences produced immediate disaster. On the other hand, they taught me to be very careful about unknowns. The Wright brothers inspired me to aggressively pursue knowledge and the short-lived bell project taught me not to depend completely on SMEs to completely fill the knowledge gap. Special knowledge is cumulative and has a way of helping in future projects and providing special satisfaction. I still enjoy reading about new discoveries in vortex flow and hearing the sounds of church bells on Sundays.

Hear the Freedom Bell Ring: https://www.youtube.com/watch?v=AxWJnbQyexI


[1] http://en.wikipedia.org/wiki/Meidum

[2] The Air Force Institute of Technology, Wright-Patterson AFB, OH, Established 1919.

[3] http://www.hibberts.co.uk/index.htm

[4] Our Acoustic Environment, Frederick A. White, John Wiley & Sons, New York, 1975


Return to top

Elicitation and Analysis of Requirements


Gary Wieboldt, ESEP

27 April 2015

In the classic system engineering Vee diagram, a keystone, early activity in the process are requirements. The process consists of:

  1. Requirements Elicitation (get them)
  2. Requirements Analysis (can they be done?)
  3. Specification (document them)
  4. Requirements Validation and Verification (did you build the right thing and was the thing built right?)
  5. Requirements Management (how do I change them?)

We believe in the mantra of a “complete but minimal” set of requirements is important to prevent over complexity (hence reduced reliability, and a host of other issues like cost) of a system:

Communication of requirements is key, so that all stakeholders and engineers know what product or service they are going to receive. They cannot be developed in a vacuum, heavy interaction, with all stakeholders are necessary to get good requirements.:

Here I would like to focus on the difficulty in steps one and two: getting them (Requirements Elicitation) and understanding if they are doable (Requirements Analysis).

Interpersonal relationships are key in the first two steps: between customer and vendor and all the people who make up the consolidated team. The elicitation process is a system of people, interpersonal relationships, thoughts and ideas. In the elicitation phase it is key to not only identify stakeholders, but to clearly understand their roles and how you are going to manage their varied requests.

As we elicit we occasionally perform in situ requirements analysis to understand the validity of consequences of the proposed requirements. Sometimes this analysis has to be performed offline from the elicitation process due to the interrelationships and complexity of the requirements set. But there are times where during the elicitation phase obvious conflicts are present and need to be adjudicated.

That brings us to this video: https://www.youtube.com/watch?v=BKorP55Aqvg which, although a farse, does show how elicitation and analysis of requirements from different stakeholder views can make an engineer’s job very difficult to accomplish. Especially if he/she is “An expert”, and the people around them are far from it.


Return to top


Seven (Plus or Minus Two)


by Zane Scott

George A. Miller died July 22, 2012 at age 92. He was truly a giant in the world of psychology. In 1956 he published an article in Psychological Review entitled “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information”. His ideas were especially important because they were introduced into the stimulus-response world dominated by behavioral psychology. As he developed his thought he posited an information processing theory of human cognition where behavior resulted from taking in and processing information instead of being the deterministic outcome of conditioned responses to external stimuli that behaviorists believed drove a person’s behavior.

This had paradigm-shifting implications for the field of psychology in general but perhaps the most important to the world of communications was his research showing that, while long term memory capacity was practically unlimited, the short term memory that we use to take in information for processing is essentially limited to seven “chunks”- plus or minus two- hence the title of his article. Any attempt to hold more chunks in short term memory results in loss or degradation in the processing as with objects falling off an overloaded desktop.

In a practical sense we do not have direct access to the unlimited long term memory when we communicate. We are only able to place chunks of information before our “receivers” for reception into short term or “working” memory for processing. Therefore, we need to respect the existence of a short term memory limitation as we chunk our information and organize it for presentation.

There has been a great deal of work suggesting that the limit is different for different kinds of information and that the limit may be lower than seven. Some researchers have suggested four items and some three, but whatever the number there is now broad acceptance of the existence of the limit. For that we must tip our hats to Miller.

The next time we do a presentation we should pause to think of him and heed his work. Do our slides violate the principle of a limited working memory? Does our organization honor the principles behind chunking information for processing? We can all think of violators and their violations of these principles. Perhaps by remembering Miller we can avoid joining those ranks. We may not become slaves to the number three, or four or even seven but we can certainly avoid the numbers 20 and 30 and 50!

As we do so, we thank you George. May you rest in peace.

© Vitech Corporation 2015, Reprinted by Permission


Return to top

Why Systems Engineers are Essential to Your Organization


by John Thomas

A systems engineer is invaluable to an organization by preventing system problems from impacting the cost and schedule of programs. They rely on their technical and leadership skills to reduce the potential for rework associated with changes in design, interpretations with requirements, or confusion with the user’s intent. They are the ones who pay attention to the system details and ensure the user, the buyer, and the investor are all satisfied with the project’s outcome – which is the ultimate measure of success.

It is the systems engineers’ role to understand the intended use and ultimate purpose of the system, and then to clearly communicate the proper system design to component builders. This begins by translating the user’s vision into information required by the architecture team to generate an optimal systems design. It is followed by the systems engineer providing component builders with a translation of the architecture teams’ vision, along with the appropriate technical requirements for building each component within the system.

Yet systems engineers know it is not enough simply to deliver a solution that works. To meet the user’s highest expectations, they use their skills and insight to understand the user’s perspective and to establish those expectations in the technical language of systems builder. Often, this involves helping the end-user think through a more complete definition of a successful outcome by producing missing details critical for influencing the systems design. Only when the systems engineer gets it right, will the user – as well as the investor and the buyer – completely embrace the result.

Systems engineers also recognize that they have to match what the architecture team is hoping to accomplish with what the component builders can best provide. Through their leadership skills, the systems engineer works toward an ideal balance between the user’s vision, and a systems design that is easily implemented. When this balance is achieved, the systems engineer packages the builder information into three critical areas: 1) how the component must function; 2) how it needs to interface with the other components; and, 3) how it must adapt to the larger operational environment.

When these “translation” activities occur correctly, the user’s vision is achieved akin to providing a finely-tuned racing bike suitable for the Tour de France. When these activities are missing or poorly accomplished, the bike intended for the Tour de France may wind up with knobby tires and a heavy frame, not the ideal bike a rider needs in order to win.

Across an organization’s products or services, systems engineers also provide critical leadership for integrating the technical activities. They have skills to influence multidisciplinary teams to reach consensus on how the system solution should come together. As problem-solvers, they focus on outcome, not process. They “own” the project: they don’t start from the position that expensive rework or user dissatisfaction—or for that matter, a builder delivering less than ideal components—is someone else’s responsibility. They step in and resolve the issue, often before most others even know the risk exists.

As translators, systems engineers can prevent many of the system problems that tend to derail projects. As leaders, they deal with the complexity of those problems as they arise. This powerful set of skills, abilities and know-how is why systems engineers are a valuable resource to an organization.

INCOSE_Fact Sheet_2_01.09.12, Reprinted by Permission


Return to top

Upcoming Events and Announcements

  • Click here to order your Chesapeake Chapter Shirt
  • June 17, 2015: Dinner Lecture – Movie Night: The Deming of America
  • June 29 – 1 July, 2015: Course on DoDAF 2.0 Modeling with IBM Rational System Architect V.11.4; by AVNET’s Ed Vail
  • July 15, 2015: Dinner Lecture – SE Consideration in the Design of Autonomous Air, Ground, Surface and Undersea Vehicles; David Scheidt, Principal Professional Staff JHU/APL (Tentative)
  • August 19, 2015: Dinner Lecture – In Close Encounters We Mostly see Ourselves—The Origin of UFO Alien Faces; by Dr. Fred Malmstrom (Tentative)
  • August 26, 2015: Systems Engineering Professionals (SEP) Reception
  • Interested in Jobs Networking? Contact Mark Kaczmarek at mkaczmarekengr@comcast.net


In Vol. 6 Issue 6

This is the monthly newsletter for INCOSE Chesapeake, a local chapter of INCOSE International. We are a not-for-profit organization dedicated to providing a forum for professionals practicing the art and science of Systems Engineering in the Northern & Central Maryland & Southern Pennsylvania area.

Join INCOSE Today!

The Chesapeake Chapter is always looking for volunteers to speak at our upcoming meetings! Please contact our 2015 Programs Director, Glenn Townson, if you would like the opportunity to speak or can recommend someone.

The Chesapeake Chapter of INCOSE is proud to recognize the following organizations for sponsoring our endeavours to expanding the understanding and appreciation of Systems Engineering in the local area:






Eliassen Group
















Jovian Concepts












Eliassen Group
















Jovian Concepts








This Newsletter is to serve our members and is open to all for contributions. Do you have an interesting idea for an article? A review of a new book related to engineering? Let us know. We’d love to hear about it. It may wind up in a future issue of our Newsletter.

Return to top

INCOSEKeep up with the latest news and events. Find out about our new Board of Directors. Explore our extensive library of previous lectures from our Monthly Dinner Meetings. Learn of the Benefits of Joining INCOSE. Check out Systems Engineering education in the local area. All this and more awaits you at our INCOSE Chesapeake Chapter Website.

For any comments or suggestions about this newsletter please e-mail our President, George Anderson or our Communications Director, Pat Williams. We value your feedback.

Board of Director Officers, 2015

– President: Mr. George Anderson

– Past President: Mr. Erik DeVito

– President Elect: Mr. John Boccio

– Treasurer: Mr. Kent DeJong

– Secretary: Mr. Mark Kaczmarek

Directors at Large
– Communications: Mr. Pat Williams

– Programs: Mr. Glenn Townson

– Membership Committee: Gundars Osvalds

Please use the Forward email link below so we can invite your friends to join our mailing list. Thanks in advance.

INCOSE Chesapeake Chapter © 2015