Talk:Systems engineering/Archive 1

Archive 1

Archive 2

Archive 3

Some undated and unsigned remarks

The article doesn't explain the system engineering process, or the challenges associated with it. (I'll try to add this sometime.) It would be useful to show a case study eg aircraft design.

The "problems" mentioned at the bottom of the page just aren't applicable to systems engineering, irrespective of the label used in the quote. The problems mentioned are more correctly applied to Operations Research or, more specifically, Military Operations Research. This is an analytic technique that might contribute to system definition or requirements analysis, but it is not strictly part of the systems engineering process.

________

This article is an excellent start. The bottom part should be probably move to another (new?) entry. I didn't do it, because I don't know yet where to move it. --HJH

'TCP performance' seems to be the subject, but where should it live? Under TCP? Or in a new article, 'Network protocol performance'? -- The Anome

I added subtitles and refactored the last part. -- HJH

--

I have moved the talk relevant to the moved material. It is now in the appropriate /Talk -- The Anome

--

Questions about Systems Engineering

I'm a senior in high school, and I'm thinking about going into operations research or systems engineering. Can someone please tell me the differences between the two? Thanks. - Sonica

-- Sonica, I would consider Operations Research in some ways to be the science of systems engineering. By that I mean that Operations Research tries to answer through an analytic processes some optimization hypotheses or questions based on a number of given bits of information, a number of constraints on that information, and a number of unanswered variables. It's a more math and science oriented-approach that is mostly focused on "paper" answers although its not always paper that is used to demonstrate the answers anymore. Ops Research appeals to those who are interested in early phases of problem solving, particularly difficult problems. Systems Engineering is generally more practically oriented and appeals to those who want to see something evolve all the way from concept right through to end product.

Hope this helps you in your decision. In either case, the world always needs both good Ops Researchers and Systems Engineers. ThreePD 01:46, 15 November 2005 (UTC)

--

(Another reader): I do not make a strong distinction between the two disciplines (SE and OR) in practice, although academically there is a great divide in terms of coursework. If your objective is to be a systems engineer, then I recommend a degree in engineering first - your choice in which type. You may take classes in OR at the undergraduate level, or you may take them at the graduate level later. Engineers tend to be xenophobic with regard to background/training. My recommendation: don't try to crash the party (systems engineering) without an engineering background. Cask05 29 Nov. 2005

-- I disagree with parts of what Cask05 says above and what ThreePD says below. I have an undergraduate engineering degree in Systems Engineering (precisely, a BS in Systems Science and Engineering). With the many excellent schools (in the US) offering degrees in SE, it is quite possible to begin your training as an engineer with a course of study in systems engineering. It is not necessary to obtain a degree in (another field of) engineering first.

On the other hand, despite the generalized methods of SE, it is a specialized field. It is also a relatively new field of engineering. By specialized, i mean that the majority of jobs for systems engineers-- and particularly the entry-level jobs-- are with large companies doing defense contracting work. There are lots of opportunities for SEs to work on missile systems, for example. Be aware that these jobs will require government security clearance, which presents an additional hurdle to the hiring process (US citizenship is a prerequisite). That SE is a new field means that, while the tools are used in many industries, most companies do not realize that they need systems engineers. Or, if they do, they use mechanical and electrical engineers that have worked with them for 10 or 15 years. I had a hiring manager with Raytheon tell me exactly that.

I loved my undergraduate coursework and the knowledge i gained. But if my degree were mechanical engineering, many more jobs would be available to me now. I can't recommend that you do or do not pursue an undergraduate degree in SE, because that is for you to decide. ME and EE were to me too specialized and SE presented a more abstracted set of tools, a sort of applied mathematics or physics degree with the weight of an ABET-accredited curriculum. You don't have to declare a major until late in your sophmore year of college (i entered a liberal-arts college that didn't even have an engineering department). Get in, go to classes, and wander around the engineering school talking to whomever you can find.

Best regards, Clebio 04:53, 1 December 2005 (UTC)

Clebio,

If you look again carefully at my comments, you may notice that I said "most" system engineers begin with engineering degrees in other specializations and become systems engineers informally (for better or for worse). Personally I would respect and value your undergrad degree as it stands and I certainly understand where you are coming from in your comments. But, in order to adapt to the realities of your current situation, you may need to acquire some specialization creds before your generalization talent and qualifications are truly appreciated. I hope you are a member of INCOSE, which may help you get connected into where your talent is really needed and you could also pick up some certificates in this or that specialty that may interest you, without necessarily needing another full grad or post-grad degree, though they don't hurt if you can swing it. ThreePD 04:17, 14 December 2005 (UTC)

Qualifications

What do you need to study to become a systems engineer ? Systems?--Light current 22:47, 14 November 2005 (UTC)

-- Light Current, most systems engineers begin with a particular undergraduate degree working on something they think is cool like planes, automobiles, robots, electronic gizmos, mechanical stuff, electrical stuff, computer stuff, software or whatever. Then later they figure out how to apply that knowledge in complex systems, either through post-graduate or other further training, or practical experience in the field of their choosing. The only difference is that the type of people that gravitate to systems engineering are those who want to see how the whole thing works as opposed to those who want to specialize in a particular piece of that puzzle. ThreePD 01:46, 15 November 2005 (UTC)

--

The recommendations above are very much true in my experience, however there are few things that you can do to facilitate your transition into the discipline:

1) Make sure that your coursework includes at least one probability & statistics class that is grounded in practice (not theory-only). Understanding of the basic discrete and continuous probability distributions and their application to engineering is a good start. SE is responsible for integrating all the "specialty" engineering disciplines like reliability, maintainability, manufacturability, etc.

2) Consider taking at least one introductory course in operations research [OR] (also called management science). This course should not be specialized to study just one type of mathematical programming technique (i.e., not just linear programming). You might find that the OR approach to simulation will help you in addition to the techniques used in other engineering disciplines.

3) Look for courses in system design. MIT's website (Eppenger, et al.) [1] has some interesting presentations on line.

4) Look around for information on the "systems engineering process" and familiarize yourself with them. The Defense Acquisition University (DAU) has a manual on-line [2] that you can download for free. While it sounds like there is a standard SE process, note that there really isn't just one (although there are standards that might claim there is). The purpose of recommendation is to get you familiar with the tasks associated with the discipline.

5) MIT also has a website for "system dynamics" at [3]. This is really a study of organizational system dynamics. You might be interested by this work. If you are, there is a good chance you will gravitate toward the "front end" of system engineering process.

6) If your interest is in how things go together (integration and test), then look to the DAU SE guide in this area. Most of the "back end" SE folks are good with both the technical integration tasks and the ability to influence people to achieve a common goal. There really isn't a good, on-line guide I've found for I&T processes, tasks, and tool descriptions. These tend to be application or technology-specific.

7) Consider taking courses in leadership [4] (...notice I didn't say "management"...). There are a few of these courses around. I believe that the understanding of how leadership is expressed on engineering projects is key to the understanding of the SE process. You might also consider something like "The Corporate Culture Survival Guide" [5] by Schein. The bottom line is that you need to really understand the organizational culture in which you operate in order to be effective as a systems engineer.

8) Look at Quality Function Deployment (QFD) to understand how group decision making can be used to the advantage of the project. You don't have to be an expert, just familiar with the method.

There are probably a lot of other things that can be said. I assume that you know how to pick and choose from these. Enjoy! Cask05 29 Nov. 2005

Revert Discussion

Please discuss why you might like to delete sections of the article on this page before pre-emptively making deletion revisions. User 164.100.80.37 revisions reverted because there was no discussion and no explanation.

Cask05 12:12, 18 January 2006 (UTC)

Quotes on an encyclopedia page?

The quotes by Aristotle and Rear Admiral Hopper are very nice quotes, two of my favorites in fact, but are they really relevant to an encyclopedia article? Further, when reverting revisions made by a user, or when deleting text, it is polite to leave a reason on the talk page, or a succinct justification in the revision comment. --Matthew 01:23, 31 January 2006 (UTC)

Are these questions, or are you suggesting a revision that would edit out the quote(s)? Is there something more relevant that you might add? Cask05 02:13, 31 January 2006 (UTC)

Being as that I am fairly new to editing, I suppose it is a little bit of both. --Matthew 03:48, 31 January 2006 (UTC)

Quotes are not unheard of on Wikipedia. For example, the Computer science article uses a (fairly famous) quote by Edsger Dijkstra to help describe the nature of computer science. See also the Grand jury and Open source articles. That said, while I think the Aristotle quote is nice, I'm not really sure it adds much to the article. On the other hand, I think the Hopper quote provides some nice historical context, which is one of the reasons that I reinserted it in the history section after it was removed. YMMV. --Allan McInnes 04:26, 31 January 2006 (UTC)

==> ::Moreover, coming from the next generation after Hopper, and starting out in engineering in the early '50s, I can't think of a more true historical statement, nor one that says more about the advent of "systems" and "systems engineering" as important fields of human endeavor. I think its original placement up front was a fine introduction to the field. ⇒ _normxxx| ^talk ⇒ email 07:14, 31 January 2006 (UTC)

I deleted the Hopper quote, because I think that it gives a negative aspect to the system engineering. Because it looks like there is no benefit of Systems Engineering because it makes everything more complicated. That is may be true, but when I read first this quote on a definition page then I think I don't need it.

But you are right I should have wrote this here before, I will do this next time.--Ma-Lik 17:17, 31 January 2006 (UTC)

Wiki ed?

I'm confused about the need for all of the Wiki ed remarks that have just appeared in leader paragraphs. First of all, they disrupt the flow of the text. Secondly, Wikipedia is supposed to have NPOV; editorial comments make no sense in that context. If there are alternate point of view, why can't we just state them without trying to give them them imprimatur of Wikipedia itself? Unless I hear some good reasons to keep them, I will remove the Wiki ed labels, and try to integrate both views. --Allan McInnes 18:24, 31 January 2006 (UTC)

There is no conflict between NPOV and "Wiki ed" comments— such as those to extend or generalize on a quote, or to limit the range/extent of a quote, as in both of my changes. However, I do agree that it breaks up the flow of the first paragraph.

(However, Cask05 privately, and legitimately, objected that:

I hate to bring this up but I think that there is one small issue that was introduced in your 01:59, 31 Jan. edit: the lead paragraph was a direct quote from the INCOSE website. I would not normally take issue, but the INCOSE was chosen because 1) they are recognized as the lead professional society for the discipline at hand, and 2) they do a pretty good job of deconflicting their work (i.e., many experienced and knowledgeable people have already provided their edits to the existing text). I realize that your latest edit was meant to increase readability, but the issue is that the INCOSE link is still attached, and currently the linked page doesn't match. This might be handled via: a) remove the INCOSE link (not preferred by me), b) modify the link to point to the INCOSE home page instead of the definition page, c) revert to the INCOSE definition, d) revert back to not having a definition on the lead paragraph (my least-preferred alternative), or e) whatever alternatives that I missed. Could you comment on your thoughts? I hope that you understand the root of my concerns. I truly appreciate your efforts in this area to date. Cask05 08:59, 31 January 2006 (UTC) )

If you see my original changes— the one before the changes you object to [do a compare with Cask05]— you will see they are much less intrusive. If you do a 'combine,' the definition will still be 95% INCOSE, so I think they still deserve the bulk of the credit. I leave to you and Cask05 the task of resolving this to your joint satisfaction— I believe that you and Cask05 have done an admirable job of defining and enhancing this definition to date. ⇒ _normxxx| ^talk ⇒ email 19:12, 31 January 2006 (UTC)

P.S. You might go with my additional changes and change the INCOSE attribution to read, "This definition was almost entirely derived from ..." But that kind of attribution may not be looked on favorably by INCOSE.

Three things:

1. I can find no usage of "wiki ed" that does not involve a talk page, or a reference to User:Wiki-Ed.
2. If the text you are using is a quote, it should be identified as such (particularly due to Wikipedia's sensitivity to copyright issues). OTOH, merging the original texts and the editorial comments you have added will produce a new text. Not to mention the fact that it would improve the flow.
3. The INCOSE fellows consensus provides an alternative (although very similar) definition. An interpolation of the two INCOSE definition plus your comments would probably be reasonably representative.

So, I stand by my recommendation to merge the editorial text into the body. I am happy to let you do that, but will do it myself if necessary. --Allan McInnes 19:51, 31 January 2006 (UTC)

It Is A REAL Stretch To Blame SE For Failures Of Its Principles In An Alien Field, Namely Combat!

None of this stuff is remotely related to SE. If there is anything of merit in it, it belongs in OR or in Military science. None of this was a failure of SE; rather, it was a failure of R. McNamara.

=== Failures ===

By way of a negative example, systems engineering was also incompletely used in many aspects of the Vietnam War. This was part of Robert S. McNamara's plan to win the war. Despite extensive use of ideas like Cost Benefit Analysis and other detritus of Systems theory, the war was a complete and utter failure to stop the NVA and it also lead to the death of over a million people, most of them civilians.

"What I saw in this particular exercise and the results from it were very similar to what I saw as a young second lieutenant back in the 1960s, when we were taught the systems engineering techniques that Mr. [Robert] McNamara [Secretary of Defense under Presidents John F. Kennedy and Lyndon Johnson] had implemented in the American military. We took those systems…to the battlefield, where they were totally inappropriate. The computers in Saigon said we were winning the war, while out there in the rice paddies we knew damn well we weren’t winning. That’s where we went astray, and I see these new concepts potentially being equally ill-informed and equally dangerous."

Quoted from Paul Van Riper in the article "Is The U.S. Vulnerable In The Persian Gulf" by Mark H. Gaffney.

We were too focused on atomic weapons and what it would mean, focused on the scientific approach to war; in particular [Secretary of Defense under Kennedy and Johnson Robert] McNamara's systems engineering. That's what I was taught as a young lieutenant—what a nuclear war would be like, and how do we [take] systems engineer[ing], not just for the acquisition of weapons systems, but how do we take systems engineering into the battlefield? And of course we saw the results in Vietnam.

Interview with Paul Van Riper on PBS Frontline. Transcript here.

=== Lessons learned ===

Lessons learned from the Vietnam War and "McNamara doctrine" include military operations research of military operations/needs that were not able to balance the political decisions to develop physical systems and politically motivated doctrine that violated military principles. A notable episode came during the operational testing of the F-111B "fighter-bomber" as tested by the Navy (and attributed to the pilot/flag officer upon exiting the operationally tested aircraft): "that was not a fighter...and it will never be a fighter".

The key lesson to be learned is that subject matter experts must be listened to in every system development.
Other decision making intrusions directly into operational decision making often fails.

It is noted that U.S. military doctrine and operations lessons learned
from Vietnam were applied with great success in Operation Desert Storm.

Retrenchment

I agree--someone originally introduced the McNamara material; my re-edit objective was to balance the discussion a bit. I don't think that the McNamara episode was an SE failure-it seems to be in the realm of political agenda overwhelming rational decision making. If there is consensus, I would excise most of the Lessons Learned material from the article. Cask05 23:27, 31 January 2006 (UTC)

As a SE you should know better! Congress proves every day the Hell we can dig ourselves into if we never revert, but only try to 'fix' the "adds." How about my changes? ⇒ _normxxx| ^talk ⇒ email 01:11, 1 February 2006 (UTC)

On another note, my suggestion to use the INCOSE definition probably is too demanding. I would like to backtrack on this request so that the lead paragraph doesn't require any special editing marks. My original objective to apply the INCOSE definition was based on extensive "definition-gaming" inherent in the SE domain. My intent was to circumvent this type of debate, but I believe that it is just too difficult to implement in the Wiki environment. Cask05 23:27, 31 January 2006 (UTC)

The problems in defining SE could be worse: we just concluded a mediation round over the first sentence of the Computer science article. :-) As far as getting a debate-free definition of SE, I doubt that even using the INCOSE definition would save you. The INCOSE discuss mailing list still sporadically breaks out into extended arguments over what the definition of SE is... --Allan McInnes 23:39, 31 January 2006 (UTC)

I think the INCOSE definition, with my edits (which just included an early aside to explain their one genuine oversight, namely the omission of "termination" as part of the lifecycle) is outstanding (occasionally, a committee will produce something of note, especially if they have one realy good worker bee and the committee just votes "accept or rework"). My final edit (adding, "within constraints," is just an attempt to alert the reader to the fact that few real world situations are so ideal that we don't have to worry about (deliberately and otherwise) missing or omitted requirements. I am reasonably sure that INCOSE thought of that one, but decided to go with the 'ideal' definition. Therefore, if it means we will get into a never ending "discussion" of the original succinct definition, I bow to reason and can live without my edits to it.

And we haven't even gotten around to the dread requirements creep!
⇒ _normxxx| ^talk ⇒ email 01:11, 1 February 2006 (UTC)

Allan, your changes look great. Hope you guys like my recent (mostly minor changes) to the various sections, but especially SE failures.

P.S. I noted (in passing) that the whole intro to Engineer's degree is weird. It makes no distinction between licensed and degreed engineers, and seems to garble the two definitions— claiming, that a B.S.E.E. is not an engineer, but a M.S.E.E. or Ph.D.E.E. are— neither of which propositions may be true in any given state that I know of!

I think we need someone who is active in IEEE and conversant with the license requirements of the various states, as well as the various academic curricula to try to disentangle it. (Has IEEE or some other like body come up with a minimum set of criteria for allowing one to be called a degreed engineer? 'Twould be new to me.) I know I had to have 80 engineering credits beyond my required 60 in "liberal science, including math" to be graduated from C.C.N.Y. in 1956. But I never heard of anyone passing judgement on those who had far fewer credits. —The preceding unsigned comment was added by Normxxx (talk • contribs) .

Thank you. Glad they pass muster. I haven't looked through all of your changes, but based on those I've sampled you've done an admirable job of clarifying things in a number of sections.

Regarding the article Engineer's degree, I think you'll find that it is discussing a type of degree known as the "Engineer" (see here for an example). Note that this is not the same thing as BSEE or MSEE - it is a separate type of degree. It is also not the same has having a professional engineering certification. A number of universities offer Engineer's degrees as a graduate degree option. It is usually seen as somewhere between an MS and PhD (at least in the US). In some cases it's awarded as a degree to PhD students in engineering who fail their qualifying exams, although the nominal purpose is to provide practically-oriented (rather than theoretically oriented) graduate education beyond the MS. It is a less well-known degree, and becoming more rare (my own college is in the process of phasing it out). Wikipedia has other articles covering the Bachelor of Science (which includes engineering), and the Bachelor of Engineering (the standard Commonwealth undergraduate engineering degree), as well as the various graduate options. Hope that clears things up. --Allan McInnes 04:33, 2 February 2006 (UTC)

==>That was an excellent reference for 'Engineer;' more of it needs to be reflected in Engineer's degree. Would you believe that over 50 years in engineering, if I ever ran across one, no one told me! I wonder if this was an experiment that fizzled; I am sure C.C.N.Y. did not have one when I was there— well, pretty sure. 50 years is a long time.

In some cases it's awarded as a degree to PhD students in engineering who fail their qualifying exams, although the nominal purpose is to provide practically-oriented (rather than theoretically oriented) graduate education beyond the MS.

==>That sounds pretty much like the "Doctor of Science" (D.Sc.) degree that was popular for a while for Ph.D. students that had passed all their qualifications but the thesis, and had given up on that. ⇒ _normxxx| ^talk ⇒ email 08:30, 2 February 2006 (UTC)

List of university SE programs

I have removed the list of links to various university SE programs, since Wikipedia is not a repository of links. This list was already long, and only likely to grow, dwarfing the length of the rest of the article. I feel that a single link to INCOSE's directory of SE academic programs is more than sufficient. --Allan McInnes (talk) 21:04, 10 March 2006 (UTC)

Systems engineering versus non-systems engineering

The problem with this article is that it fails to explain what makes systems engineering different from any other kind of engineering. No wonder there are many questions from potential students! Apart from the word "interdisciplinary", the first two sentences are applicable to any competent engineering project. Engineering (and technology in general) essentially is a process of combining components into something that is more than the sum of its parts. In 1880 giving testimony to support his carbon microphone patent Thomas Edison described his approach to inventing it thus:

"Like any other machine the failure of one part to cooperate properly with the other part disorganizes the whole and renders it inoperative for the purpose intended. The problem then that I undertook to solve was stated generally, the production of the multifarious apparatus, methods, and devices, each adapted for use with every other, and all forming a comprehensive system"

So Edison saw his inventions as systems, just as most engineers do today. Even the "interdisciplinary" component seems questionable since it is arguable that to be a competent engineer a person needs to be aware of factors from other disciplines.

⇒To be more valuable this article needs to explain the methods used in Systems Engineering that are absent in other forms of engineering or, indeed, in other domains like architecture. IanWills 22:54, 22 March 2006 (UTC)IanWills

Generally, this can't be done, as there are no neat boundaries, but instead a continuous overlap— which is program and people specific— between systems architecture and systems engineering, or between systems engineering and software engineering/architecture (or any of the other "ilities"). Only the hardware engineer still maintains a (relatively) neat boundary, but even that may be violated, depending on the people and program.

On a huge (generally, government) program, there may be one or more systems architects, systems engineers, software architects (rarely, since the systems architect usually assumes this role), and sotware engineers. On a small program run on a general purpose computer (and/or other general purpose hardware), there may only be a software engineer, performing the other roles as needed. But, generally, on the huge programs, there is one Chief Engineer whose word is law (regardless of what discipline s/he comes from), at least if the PM wishes to retain his/her sanity!

In any case, the specific roles and responsibilities must be determined on each program by the people/engineers involved (hopefully) according to their capabilities and inclinations. ⇒ _normxxx| ^talk ⇒ email 20:31, 21 April 2006 (UTC)

Links to other disciplines

I like the section on relationships to other fields, but I'm suprised not to see Project Management mentioned explicitly. Matt Whyndham 17:42, 23 June 2006 (UTC)

INCOSE refs

The leader has been substantially rewritten, and as a result I don't believe that it is valid to use the previously provided INCOSE references as sources for the material in the leader. I'm putting the citations in question here, in case someone wants to use them again in the future:

• INCOSE Communications Committee (14 June 2004). "A Consensus of the INCOSE Fellows". What Is Systems Engineering?. Retrieved 2006-07-11.
• INCOSE. "Guide to the Systems Engineering Body of Knowledge — G2SEBoK". Retrieved 2006-07-11.

--Allan McInnes (talk) 16:13, 23 August 2006 (UTC)

Lead paragraphs vs Overview

Vincehk 07:43, 24 August 2006 (UTC) Any suggestions on what to focus on in lead paragraphs vs Overview section? Also on what Overview should cover. I feel some of the text in the lead paragraph go better in the overview, although ideas from them should be distilled and remain in lead.

What makes SE unique

The leader currently contains a claim to the effect that SE is unique because it doesn't deal in tangible products, but relies on other engineering disciplines to produce a finished work. Not only does this particular (uncited) claim sound suspiciously like original research, it doesn't strike me as particularly convincing: civil engineers may "design buildings", but they rely on materials engineers, electrical engineers, telecommunications engineers, and other disciplines to deliver a functioning and useful modern building. Which makes the CE sound an awful lot like a systems engineer to me, at least under the distinction proposed in the current leader. The same goes for the earlier example involving aeronautical engineers.

Of course, this same argument has occupied much bandwidth on the INCOSE "discuss" mailing list over the years: What is SE? Is SE the same thing as the engineering of systems? The fact that this issue is (still) controversial is why it's necessary to provide citations for any definitions of systems engineering you might choose to introduce into the article.

--Allan McInnes (talk) 17:59, 24 August 2006 (UTC)

Vincehk 18:31, 24 August 2006 (UTC) Your point taken. One of the things that need emphasis in the article is that systems engineering is not the sole domain of systems engineers. Other engineering disciplines often practice systems engineering, consciously or not -- perhaps one reason why systems engineering has a hard time getting recognized as a true engineering discipline (another source of confusion being Microsoft's MCSE designation). And yet, SE as a separate discipline does seem to exist. .

Well, I don't necessarily disagree with you, but I know there are folks that do disagree. They claim that SE is something quite different from "engineering" and that classical engineers employ reductionist approaches rather than systems thinking. I've heard people like Derek Hitchins argue along those lines a number of times. As I said above, the definition of "systems engineering" (and beyond that, what it actually means to practice systems engineering) is a source of vigourous disagreement. And yes, it is further clouded by the existence of things like the MCSE, and the fact that many advertised "systems engineering" jobs amount to little more the system and network administration.

You asked above what the overview should contain vs. the leader. I'd suggest that the overview would be a good place to discuss the differing opinions on SE (i.e. things like "According to Buede SE is unique because...", "According to Hitchins SE is not engineering because..."), while the leader should probably simply state that there is some controversy as to what constitutes SE (the leader is supposed to provide a summary of the rest of the article). --Allan McInnes (talk) 18:46, 24 August 2006 (UTC)

SE Failures

Regarding the examples given under the 'Failures' section, I can't seem to connect them to SE. Are they supposed to be examples of undertakings where SE should have been applied but was not, leading to failure? Are they examples where SE was applied, but applied badly, leading to failure?

In SE Failures "And, there were entirely too many players and not enough workers." sounds plausible, but planners sounds more plausible. Since I don't know what the author meant or what the author might be quoting to check for myself, I'll let someone else change it

Scope

"Only the hardware engineer still maintains a (relatively) neat boundary, but even that may be violated, depending on the people and program. For example, firmware embedded into a micro-controller is often assigned to the hardware engineer, but it is essentially a software development."

Propose delete this. To me it reflects personal experience, and not current industry practice. Design of modern hardware/software systems and subsystems (e.g. mobile phone, portable audio/video player) requires a systems engineering approach. Typically hardware/software partitioning issues have to be addressed, and optimal design solutions cannot be achieved by maintaining "neat" boundaries between hardware and software disciplines.

In fact a section relating systems engineering discipline to modern complex embedded systems might be a good idea aswell. --Johnva 23:34, 8 December 2006 (UTC)

I agree that that text you've quoted above smacks of personal experience. Deleting is probably a good idea.

I'm not as enthusiastic about your suggestion of a section relating SE to embedded systems. That seems like a fairly specialized comparison, which I'm not sure has a place in this article (for that matter, the article as a whole seems to have a bent towards computer systems, and ignores the wider applications of SE to things like space systems, military systems, enterprises, etc. - INCOSE has a wide variety of working groups on different areas where SE is applied). --Allan McInnes (talk) 05:43, 9 December 2006 (UTC)