Company Logo

SE&D Blog Post #2 – August 14, 2017

Topic: SOI Concept and Context within a Value-Added System

…I like your book very much because every word you wrote is just I recognized in the real world for failure …

I am confused for the concept of SOI, when you illustrate it in (a) value added system, I can’t understand the root meaning of system of interest, when this word become useful could you help to explain.”



  1. C. Wasson August 15, 2017 10:24 am

    Comment #1

    Tony, thanks for your feedback and question.

    … I like your book very much because every word you wrote is just (as) I recognized in the real world for failure …

    I’m delighted to hear the new 2nd Edition provides insights and opportunities for advancing Systems Engineering concepts, principles, and practices in your work.

    Your question addresses a couple of key points for discussion: (1) SOI concept and (2) SOI context within a value-added system. Let’s address each separately.

  2. C. Wasson August 15, 2017 10:27 am

    Comment #2
    Topic: SOI Concept

    Tony’s comments noted:

    …. I am confused for the concept of SOI …

    To establish a frame of reference, let’s begin with the definition of a System of interest (SOI). Wasson (2016, p. 52) defines an SOI as follows:

    System of Interest (SOI)An entity such as a system, product, or service with boundaries scoped for contextual (investigation), analysis, research, or study (and/or preventive or corrective maintenance action) purposes and tasked to perform one or more Enterprise or organizational missions with outcome-based performance objective(s) within a specified time frame, available resources, and within specified operating constraints.

    Note the operative terms “entity” and “contextual.”

    Since the universe is a “System of System (SoS)”, any generic “entity” within the hierarchy has a bounded context and therefore can be designated as an SOI for investigation, analysis, research, or study purposes. In the case of Engineered Systems, Wasson (2016, Figure 8.4, p. 179) illustrates hierarchical Levels of Abstraction – System, Segment, Product, Subsystem, Assembly, Subassembly, or Part Levels – that can be designated as SOIs or potential SOIs. Each Level of Abstraction or one of its entities has specified boundaries that define the scope of investigation, analysis, research, or study purposes.

    To illustrate this point, consider an automobile example using Wasson (2016) Figure 8.4:
    • The Automobile System (System Level Entity) can be an SOI.
    • The Automobile’s Audio System (Subsystem Level Entity) can be an SOI.
    • The Audio System’s Display, AM-FM Radio, XM Radio, Aux Input, or Speakers (Assembly Level Entities) can each be an SOI.
    • And so forth.

    It is important to recognize that application of the contextual term, SOI, does not apply to every entity within a System. In the example above, once an entity such as a System, Segment, Product, Subsystem, Assembly, Subassembly, or Part ceases to provide value-added performance-based outcomes for the User, it becomes: (1) a focal point for further investigation, analysis, research, study, and/or preventive or corrective maintenance actions and (2) is designated as an SOI or potential SOI, depending on the circumstances. In the Automobile System example above, if the Audio System fails to operate properly, the Audio System is designated as an SOI, not the Automobile System.

    I hope this clarifies the contextual usage of SOI.

  3. C. Wasson August 15, 2017 10:30 am

    Comment #3
    Topic: SOI Context within a Value-Added System

    Tony noted: “… when you illustrate it (SOI) in (a) value added system, I can’t understand the root meaning of system of interest, when this word become(s) useful … could you help to explain.

    First, one of the attributes of any “system” at any Level of Abstraction – e.g., System, Segment, Product, Subsystem, Assembly, Subassembly, or Part Levels – is to “add value” to a set of Mission Resources- inputs – for a given set of Operating Environment constraints, conditions, and so forth. Wasson (2016, Figure 4.1, p. 80) notes a User’s “Fitness for Use” Standards and Acceptance Criteria – e.g., performance-based outcomes – for each “value-added” system within a Supply Chain.

    Over time if an SOI fails to: (1) deliver the specified outcome(s) and level(s) of performance – e.g., objectives; operating costs; reliability, availability, maintainability (RAM), etc. to meet the User’s operational needs or (2) achieve a User’s evolving or emerging operational needs, its value diminishes thereby forcing the User to make decisions such as: (a) perform corrective maintenance actions, (b) upgrade and retrofit the SOI – as a legacy system – or (c) retire and replace it with a new SOI.

    Hopefully, this clarifies the contextual application of the term, SOI, in a value-added system. Again, many thanks for your feedback about the new 2nd Edition and Blog question.

  4. Tony November 20, 2017 8:54 am

    Dear Mr. Wasson,

    You can’t imagine how surprised and excited for receiving you feedback of my questions.
    It is clearly clarified and my visual range in heart is widened suddenly.
    By the way, I’m sorry for my lots of typos last time.

    I’m a young engineer in China based in renewable energy vehicle battery pack design and development. I was assigned as system engineer but met a lot of problems which stimulate me to find a proper way to solve the problems happened all the time. For auto mobile industry I get touched with a lot of requirements from different auto mobiles makers in the world, but our development system is not capable of supporting this kind of development, worse combined with the newly emerged product/system/industry. Your patient/kind illustration, explanation, delineation and encouragement in your book gives me a guide light to solid(ify) my will to affirm myself protecting confidence of myself. I understand when there is problem, there is a way. (The) Enterprise tends to be SDBTF (Specify-Design-Build-Test-Fix), people tend to solve (a) problem before (we) make clear (the) problem statement which makes our engineers mind go to chaos combined with interests balanced in organizations. Actually, (the) lack of SE background, atmosphere, education, practice is the No. 1 enemy for transfer(ing) our amazing mind/concept creation ideas to reality. Sometimes, I feel frustrated and disappointed with not (being) understood by others and feel alone.

    Anyway, I’m honored to have the opportunity to talk to you kind of master in this domain, to my understanding, SE is opened and inclusive with Sos (System of Systems) thinking.

    Your book (-) I have read to Chapter 21 REQUIREMENTS DERIVATION, ALLOCATION FLOWDOWN, AND TRACEABILITY. I read and practice with my small team to serve (the) customer, to confront directly of problems internally. I have to say, I will follow the way you given forever, and I am planning to apply (for) a SEP certified (INCOSE Certified Systems Engineering Professional) if conditions and my SE system mind is coming to matured.

    Wish you could give me more guide and more suggestions if you are available.

    Best regards!


  5. C. Wasson November 27, 2017 8:22 am


    Thank you for the inspiring feedback. I’m so delighted to hear that the new 2nd Edition text and Blog provide meaning to your work and enable you to inspire and lead your team along the pathway to achieving SE & Development excellence.

    My sincere best wishes for you and your team for continued success!


  6. Tony January 7, 2018 1:36 am

    Dear Mr. Wasson,

    I’m very glad to have this platform to propose some questions to you.
    My questions is about some terms which confused me these days.

    When WE define the system requirements and verification criteria, we always use some abstract vacabularies such as quality and capability.

    when the word capability comes out firstly fromt he stakeholders needs and mission analysis, we can see they need system to have capability to perform to satisfy the operational output requirements.

    when quality comes out, I think it is general, but when I read the SE handbook we find it come from the quality identification for system requirement definition with relaibility, secrtity, supportbility …..

    The other contextual confusion for me for long time is the MOE/MOP, what are their relationships among quality, capability, MOE/MOP, measurement means verification domain.?

    Thanks and best regards!