This

module will be examining the opera5onal concept, or how, conceptually the stakeholders intend to operate in the new environment.

 In this lecture we are moving from the process where we have dened stakeholder needs and requirements. We have examined a range of concepts to meet those needs. At this point in the process, we now focus on the selected solu/on concept. The opera5onal concept (also called the concept of opera5ons, or CONOPS) facilitates the rest of the Systems Engineering process. It denes the stakeholders inten5ons of the opera5onal concepts within which the system/ solu5on will operate. It acts as a way to validate the success of the solu5on, once implemented. The objec5ves are to introduce the deni5on of a concept of opera5ons, describe its value to the Systems Engineering role, and its value to the success of the solu5on development. We will also understand the contents of several dierent Concept of Opera5ons.

Here is the outline of the Systems Engineering process. Weve moved from the mission/stakeholder focus (#1) to the Concept of Opera5ons and Opera5onal Architecture focus (blue box #2). Now we focus on the key opera5onal constraints and scenarios describing the usage and opera5ons. These are the Context within which the system/solu5on must operate. During this part of the process, it is also important to understand the key external interfaces, e.g. external systems and work groups, and any other opera5onal constraints that might aect the scope of the system (some examples include: security, safety, performance, the environment, etc.)

This slide illustrates the feedback between the parts of the Systems Engineering process. Specically, the Concept of Opera5ons validates key opera5onal scenarios and stakeholder requirements. It can provide an early assessment of preferred concept(s) within an opera5onal context, thereby providing a valida5on of system mission and scope. Note that these processes and feedback are con5nuous. The Concept of Opera5ons is a living document (or set of documenta5on) which con5nuously evolves as the solu5on and its opera5onal context are understood. In addi5on, once the technical system is dened, there is feedback to the Concept of Opera5ons which can modify trade-o details and feasibility of the solu5on.

 The opera5onal concept incorporates all of the steps in this process, as shown in red. The system context and Opera5onal View of the architecture will be dened in the next 2 modules following this one.

 The Concept of Opera5ons (some5mes called the Opera5onal Concept, CONOPS or Opera5onal Concept Document OCD) is one or more documents, les, diagrams or images describing the current situa5on (as is) and the proposed solu5on (to be), in the language of the stakeholders. It is used to communicate the system goals between the stakeholders and system designers, and focuses on the mission or business need (that is, it focuses on the problem, not the solu5on). It forms a basis for long-range planning. It is a living document, meaning it changes and modies as the system context and uses change, and the solu5on is be\er understood. This deni5on is from the IEEE Guide for Informa5on Technology (standard 1362-1998). The full reference is in the Notes page. [1], "IEEE Guide for Informa5on Technology - System Deni5on - Concept of Opera5ons (ConOps) Document," IEEE Std 1362-1998 , vol., no., pp.i, 1998 doi: 10.1109/IEEESTD.1998.89424 URL: h\p://ieeexplore.ieee.org/stamp/stamp.jsp? tp=&arnumber=761853&isnumber=16486 (Can be accessed via Stevens Inst library)

In the Vee form of the Systems Engineering process, note that the Concept of Opera5ons, together with the User/Stakeholder Requirements are a means of conrming the valida5on of the system, once it is built. That is, to be sure we have built the right system. (Represented by the green bar at the top of the Vee)

The intent of a concept of opera5ons is a key systems engineering deliverable that clearly states the scope of the problem being addressed in the users language. It describes the current state, or problem situa5on and the objec5ve of the proposed solu5on. (Where the solu5on may be a new system or simply a set of policies or procedures, etc.) It discusses implementa5on concepts and has iden5ed key trade os between the concepts. Key opera5onal scenarios or use cases are provided that reect how the new solu5on would operate or be used. The Concept of Opera5ons also contains an ar5cula5on of any key drivers, constraints, assump5ons, dependencies, risks and any organiza5onal impacts.

 Lets take a look at how the opera5onal concept ideas work within a lean and agile framework. The concept of opera5ons must evolve as the requirements are be\er understood and the alterna5ve solu5ons begin to solidify. Make sure the concept of opera5ons captures any nego5ated changes in the acceptance criteria as solu5ons are evaluated. Remember, it is much easier to change a concept when you rst recognize concerns than aoer engineering decisions have been made and resources expended. Let the risk associated with the opera5onal concepts features inform the order of decisions and scheduling of work. Making decisions on risky aspects before you have fully analyzed them can drive a bad solu5on or require expensive rework. Focus on the capabili5es that are most valuable whenever possible however, if less valuable capabili5es are rapidly deployable without unacceptable risk, strive to provide that value as soon as possible. Most stakeholders appreciate early bits of small value over longer waits for higher value par5cularly if values change over 5me.

10

So lets summarize the primary benet of a concept of opera5on. It is clarity in understanding the scope and specic nature of the problem or opportunity being addressed from the users perspec5ve. The concept of opera5ons bridges the gap among the key stakeholders and with the system developers. It reduces the risk of developing and deploying a solu5on that will fail the test of valida5on by key stakeholders. It provides a shared vision for the preferred solu5on, including the key scenarios and use cases that the solu5on will address. It also covers relevant phased approaches to introducing and deploying the solu5on. This is par5cularly important for very complex systems.

11

This is a graphical depic5on of the FireSat Opera5onal Concept (from the Applied Space Systems Engineering text). This illustrates the dierent work centers (e.g. FireSat Ground Sta5on) and poten5al physical solu5on components (e.g. FireSat). Some of the important interac5ons between these are also shown, although not with any detail. Note that this diagram is wri\en in language the stakeholders can easily understand, aided by the graphics.

12

This depicts one of the many opera5onal scenarios for FireSat, in graphic form.

13

The next four slides contain the possible elements of a generic concept of opera5ons, and then examples of dierent organiza5onal standards for crea5on and contents of a Concept of Opera5ons. Press pause and play to look at them and their Notes pages.

14

This schema5c depicts the contents of a typical concept of opera5ons. The focus is on describing how the system ts into the opera5onal environment. While this depic5on suggests a document, a concept of opera5ons (for maximum eect and inuence) should not be paper intensive and should include graphics and mul5-media, and non- technical language. As noted, users will ul5mately validate/accept the solu5on via the Concept of Opera5ons (that is, the opera5onal concept does not assume technical knowledge and is focused on the problem, not the solu5on.)

15

The most important sec5ons for this ConOps outline are sec5ons: 3, 4, 5. 3. Current Situa5on which describes the system or manual process which is to be replaced (the as is), 4. Jus5ca5on for the new solu5on and any restric5ons on that solu5on, 5. The Proposed System or Solu5on descrip5on (the to be). This is the same reference as in the deni5on of the concept of opera5ons: "IEEE Guide for Informa5on Technology - System Deni5on - Concept of Opera5ons (ConOps) Document," IEEE Std 1362-1998, vol., no., pp.i, 1998 doi: 10.1109/IEEESTD. 1998.89424 URL: h\p://ieeexplore.ieee.org/stamp/stamp.jsp? tp=&arnumber=761853&isnumber=16486

16

Here is an example of an outline used at NASA. The scope of the solu5on is key! Ambiguity in the scope can lead to wasted eort and re-work.

17

This concept of opera5ons (from the Na5onal Archives), is more detailed. Note the explana5on of the current situa5on and jus5ca5on of the changes to the environment. These are important considera5ons at the project funding level.

18

This slide and the next one are the recommended outline for a Concept of Opera5ons for this course.

19

This slide and the next one are the recommended outline for a Concept of Opera5ons for this course.

20

Regarding these examples of how to create a concept of opera5ons document, there are some key best prac5ces to consider: First is the ac5ve use of the concept of opera5ons. As the understanding of the solu5on evolves, so must the concept of opera5ons. The ConOps should reect the latest, current shared mental model for the problem being addressed, and the solu5on being created, together with constraints and drivers. It should leverage graphics and mul5-media. Users/stakeholders will nd it easier to validate the solu5on, prior to deployment, with the rich use of graphics. A broad range of opera5onal environments and scenarios, and use cases should be ar5culated including norma5ve, abnormal, break/x scenarios, threats, etc. Since the Concept of Opera5on is to be used by all the stakeholders, keep the level of technical jargon as low as possible. And it goes without saying that it is important to iden5fy a broad range of stakeholders as a key to solu5on success.

21

In summary, the Concept of Opera5ons is a key systems engineering deliverable that: Clearly states the scope of the problem being addressed Describes the current state, or environment, or context, or problem situa5on Provides the focus and objec5ve of the envisioned solu5on (where the solu5on may take the form of a new system, a set of policies or procedures, etc.) Discusses implementa5on concepts or approaches for the envisioned solu5on, leading to the iden5ca5on of key trade os. Ar5culates key opera5onal scenarios or use cases that reect how the new solu5on would operate or be used, etc. in the envisioned future. Includes key drivers, constraints, assump5ons, dependencies, risks and any organiza5onal impacts.

22

The next three slides show a par5al concept of opera5ons with diagrams depic5ng the as is" environment, the to be environment and describing, in stakeholder- centric language how the ac5ve stakeholders will use the proposed solu5on (the solu5on selected in the concept selec5on phase).

23

The current way that consumers buy products (as is)

24

The proposed way that consumers will buy products (to be) under the scenario of the selected solu5on concept, the Online Purchasing System.

25

These are typically derived from the stakeholder capability requirements. Note that these are focused on the problem (no men5on of solu5on) and are in the language of the stakeholders.

26