The Conceptual Design Featuring The Concept Of Operations

The Conceptual Design Featuring The Concept Of Operations
A Tutorial By Joseph F Iaquinto, PE May 14, 2012 This tutorial addresses conceptual design in general terms and one kind of conceptual design, The Concept of Operations in specific terms © 2012 Joseph F Iaquinto, PE

Introduction Now for a little preview of this tutorial
© 2012 Joseph F Iaquinto, PE

Introduction Some Definitions
Concept An abstract or generic idea generalized from particular instances Design To create, fashion, execute, or construct according to plan There are three terms that represent the focus of this tutorial. To insure a common understanding of these terms, they are here upon defined The focus of these terms is abstraction in planning. That is to say we are going to spend today exploring the industrial art of reasoning in most general terms about what to build in order to facilitate some public or governmental endeavor. Conceptual Design An abstract construction plan selected and refined to satisfy a specific need that is a member of a generalized class of needs © 2012 Joseph F Iaquinto, PE

Introduction Conceptual design as a useful abstraction
When we use the term conceptual, especially in the phrase conceptual design, as system engineers we mean a USEFUL abstraction. There are a number of roles that are affected by a conceptual design. For each role that plays a significant part in the creation and use of the artifact under design, a — usually unique — abstraction must be conjured by the System Engineer. For the customer or end user role, this almost always requires concepts that make the artifact useful in the execution of the customer's "business". For the tradesman or artifact fabrication, this almost always requires concepts that aid the tradesman is selecting the correct trade practices, implements and raw material that will most productively lead to the desired artifact. Useful to customer in directing the construction of the artifact Useful to tradesmen for making detailed implementation decisions © 2012 Joseph F Iaquinto, PE

Overview of CONOPS Templates Essential template
Scope: Identification System Overview Document Overview System Concepts: Intention (Intended use) Roles Activities Docs Relationships CONOPS Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Operational Scenarios: Key business events Anomalies accounted for Selected representative This slide presents a recommended essential template. It follows the IEEE template closely. The order is top to bottom, right to left. A detailed discussion of each section of the essential template can be found in the like named section of the IEEE template. The Scope section contains the usual introductory material that (1) names the business and system under definition, provides an overview of the business aspects to be effected by the system and in that context the system and finally an overview of this document. The problem description section is very business centric. It defines the business as it exists currently with emphasis on those aspects of the business one wishes to change. After first carefully defining the business context, the business problem that is the focus of this CONOPS is stated. Finally the intended solution to the business problems is stated with definitive goals and quantative objectives. Remember, this section is entirely business centric. There is exactly NO technical discussion. The third section simply lists the documents that were referenced in this CONOPS. They may be simply listed or organized in some fashion. The fourth section defines the business and system concepts, that is to say it defines the language with which the CONOPS will be constructed. The minimum essential set of concept categories are: Intention (Intended Use) — why are we writing this CONOPS Roles — what business roles are important in this CONOPS? Documents — what business documents (information) are important in this CONOPS Activities — what business activities / processes are important in this CONOPS? This is the topic in which key business events are identified. Relationships — how are the previously defined concepts related? The fifth section defines the operational scenarios that will be used to explain the business execution after introduction of the system under definition. This section contains a complete, definitive set of business events. It also includes any business anomalies that must be addressed by the scenarios. Finally it describes in business detail each representative scenario. If important, the rules for selection of the representative scenarios may appear in this section. The sixth section provides the analysis of the Operational Scenarios of the last section in the form of Operational Capabilities. The operational capabilities are defined in terms of their structure, behaviors and functions within behaviors. This entire document could be only a few pages long! Remember the shorter, the better. Well, usually. Documents: Referenced Operational Capabilities: Structure Behaviors Functions within Behaviors © 2012 Joseph F Iaquinto, PE

Introduction CONOPS – The Key Concepts
Roles Mission or Intention Information Required Activities A primary focus of this tutorial is the construction of the CONOPS. The receipt for a CONOPS is rather simple at the conceptual level. First, it requires the definition of a user / operator role for the artifact that forms the focus of the CONOPS. Second, it requires the definition of a supplier of said artifact. Third, for the user / operator, we need to formulate the mission or intent of the user / operator, the execution of which is to be addressed by the artifact. Fourth for the supplier role, we need to formulate the information required by this role in order to insure the desired artifact is created correctly. Fifth, a very detailed description of the intended user activities that are to be supported by the artifact is required. Sixth, the relationships among the ingredients are an important part of the receipt. Seventh, the aforementioned ingredients logically yield the Operational Requirements. Relationships Operational Capabilities © 2012 Joseph F Iaquinto, PE

Introduction Elementary Example – System Definition
In this slide we see an elementary example of a CONOPS — in this case a system definition version of the CONOPS © 2012 Joseph F Iaquinto, PE

Introduction Conceptual Engineering Principles
Intended “business” use Critical Thinking Seek the Problem Postulate an Applicable Solution Stated In Social Terms, Not Technical! Maintain Conceptual Integrity Management of Domain Complexity Management of problem solving teams By way of an example of conceptualization, this slide presents the most important principles that govern the understanding of Conceptual Engineering. The intended use of the artifact forms the single most important principle of Conceptual Engineering. This is a clear definition of why the owner / operator of the artifact will make use of the artifact and how they intend to profit by it. As such it provides the focus of the Conceptual Engineering effort. The principle of critical thinking is the key conceptual process by which Conceptual Engineering is conducted. This is the structured, highly directed application of logic and reason that is used to both seek the social problem and postulate an applicable solution. The conceptual model of the problem and solution are stated in social terms, not technical terms. A CONOPS is not a Theory of Operations. The principle of the mythical man month defines the two most important constraints on Conceptual Engineering — conceptual integrity and complexity management. These principles will be discussed at length in this tutorial. © 2012 Joseph F Iaquinto, PE

Introduction Conceptual Engineering Fallacies
Architecture as Implementation OO vs. Procedural vs. SOA Systemantics There are some widely held fallacies regarding conceptual engineering that deserve our immediate attention. Frequently, the term Architecture is used to mean a conceptual description of the implementation of the artifact under consideration. An example is the term System Architecture. In fact the word as used in this context should be replaced by "Configuration". Architectures should be conceptual in nature, with the most abstract of Architectures being the Enterprise Architecture. There is an ongoing debate regarding the relative merits of 00 versus Procedural versus SOA system engineering methods. This level of discussion is far below the level of abstraction required in conceptual engineering; thus, they are an indication of a error in conceptualization when considered in light of Conceptual Engineering. Interestingly these buzz terms represent various levels of abstraction in software engineering. There are a number of failure modes in the process of Conceptual Engineering. An important number of them, too many to address in this tutorial, are addressed in the "Science of Systemantics" series of books by John Gall. © 2012 Joseph F Iaquinto, PE

A Process for doing the conceptual design (CONOPS)
Define the Problem Define the Roles and Responsibilities Define the Business Events Define Representative Scenarios The process of doing a conceptual is conceptually simple! In the first step we identify the significant business events. Recall we introduced the concept of the business event very briefly last session. A significant business event is a business event that is related to our purpose for creating a CONOPS. Judgment and experience must be exercised is selecting which business events are the significant ones. Each business event or related set of business events cause the enterprise to react. Several such reactions can be formulated into a representative scenario. In addition it is important that these representative scenarios be carefully selected to cover all of the political topics that need to be addressed in the CONOPS. In order for a system to support any particular Representative Scenario, it must provide a set of operational capabilities. Defining and discovering these operational capabilities is the concluding step in generating the information needed for the CONOPS. We are now going to elaborate on the use of business events in producing the material needed in the CONOPS. Define Structure, Function, Behavior Organize Functionality Into States and Modes Define Operational Capabilities © 2012 Joseph F Iaquinto, PE

Introduction Example: Web Provisioning
Specification Status In order to ground this tutorial, we will study a few partial conceptual designs and one complete toy system. Our partial conceptual design will discuss a web based provisioning system that can represent either a consumer provisioning or industrial provisioning. Our complete toy system will discuss a semi-automated grass mowing system for use by a large consumer community. Product © 2012 Joseph F Iaquinto, PE

Introduction Not limited to IT systems!
A great deal of attention is devoted to IT systems when discussion CONOPS (User manuals); however, conceptual design in general and CONOPS in particular apply to any artifact, no matter what its technology. © 2012 Joseph F Iaquinto, PE

Introduction Tutorial Sessions
What is a Conceptual Design and Who Cares? Principles and fallacies of conceptual design Process for defining a CONOPS Example Walkthrough Toy CONOPS (Homework) This tutorial is organized into 4 approximately one half hour sessions as illustrated. Session 1 including this introduction sets the stage with a discussion of the basic concepts and motivation behind conceptual design. The military version of the CONOPS is created in numbers far greater than the system definition CONOPS; however, we will not address this topic in this 4 hour version of the tutorial. An entire session is devoted to presenting the skills necessary to reason conceptually. Four sessions are allocated to covering conceptual design and CONOPS construction, step by step. The last session will be a very brief walkthrough and discussion of our complete example CONOPS. © 2012 Joseph F Iaquinto, PE

Introduction Ground Rules
Each Session 50 Minute formal lecture 10 Minute break every hour These are the ground rules I will try to live by. Given the sometimes tedious nature of this material, I will limit the talking head part to about 40 minutes between breaks. I hope you have brought examples and problems related to CONOPS with you so that we can discuss them at the appropriate points in the tutorial. I intend to be absent from the podium for 10 minutes out of each hour to give us all a refreshing break. © 2012 Joseph F Iaquinto, PE

What is a conceptual design and who cares?
Session 1 What is a conceptual design and who cares? The purpose of the CONOPS is to document a conceptual operational design. This is true for both classes of CONOPS we will discuss today. The underlying skills required to create a conceptual design is the focus of this first session. © 2012 Joseph F Iaquinto, PE

What is a conceptual design and who cares?
Avoiding Brook’s “law”: “All major mistakes are made on the first day of the project”! Fred Brooks and I were contemporaries at IBM corporation in the mid to late 60's. Fred was the program manager of the OS/360 development program, the largest and most complex software development effort up to that time. I was an SE trainee in IBM's Philadelphia Manufacturing Branch Office. Fred's inability to deliver the OS on time cost IBM tens of millions of dollars in revenue. Fortunately, Fred wrote down the fruits of this experience. Fred Brooks, The Mythical Man Month, ISBN: © 2012 Joseph F Iaquinto, PE

Topics of Session 1 What is a conceptual design and who cares?
Motivation – When is a CONOPS needed??? The Role of Conceptual Integrity (A Central One) Definition of Conceptual Design Recipe for a conceptual design Mission or Intention The Roles Activities (Described by representative scenarios) Information Introduction to some useful standards and templates Where the conceptual design fits into the System Engineering Process This session briefly addresses some critical concepts about conceptual design, the most important one of which is why even do it? This topic, Motivation, is the first one we will address in session 1. © 2012 Joseph F Iaquinto, PE

Motivation – When is a CONOPS needed We have a problem
System Engineering Is Too Expensive! System engineering continues to fall in popularity among the business elite. One of their most easily proven assertions is the System Engineering is too expensive especially when considered in light of the falling costs to develop and produce products. System Engineering needs to address this problem by moving our focus up the conceptual ladder, just as design and implementation has moved up the conceptual ladder (IC's, SOA, etc.) © 2012 Joseph F Iaquinto, PE

Motivation – When is a CONOPS needed This problem has become visible
System Engineering Fails More Than It Succeeds! The other devastating assertion made by the business elite is that we fail more than we succeed in terms of our ability to influence the outcome of product or services development in the eyes of the consumers and procurers of these products or services. This provides additional motivation to concentrate more of our attention on the intended outcome of product / service developments from the perspective of the consumers and procurers of these products or services. © 2012 Joseph F Iaquinto, PE

Motivation – When is a CONOPS needed – Test 1 Is there ambiguity?
One of the causes of decline in System Engineering has been the inappropriate application of System Engineering. As product developers have become more experienced and their work more abstract, the opportunity for System Engineering to offer benefits has declined. Here is the first of two significant tests I propose to be used to establish the need or lack of need to employ System Engineering. Ambiguity is the natural consequence of isolated minds. When this natural ambiguity in a product's definition exceeds the ability of discipline engineering to resolve, there is a definite need for System Engineering. However, this need for System Engineering is clearly for assistance in creating a consistent, un-ambiguous conceptual product design. © 2012 Joseph F Iaquinto, PE

Internal Construction?
Motivation – When is a CONOPS needed – Test 2 Will the product serve diverse needs? I want to start my 5 HP Engine with the push of a button. While camping, I want to be able to read all night by the illumination of a 60 watt bulb. SE: SE: Voltage = 12 V Capacity = 40 AH Form Factor = 10x10x10 cm Voltage = 12 V Capacity = 40 AH Form Factor = 10x5x2 cm A second significant test addresses that class of products for which the acquirer intends to apply in an operationally complex manner, in short — a "Reusable" product. Although the software development community continues to strive toward this goal with much fanfare, the rest of the product development community routinely addresses this kind of requirement. In this example, we see that some detail design decisions that must be made by the battery engineer are significantly influenced by (and in turn significantly influences) the end user's intended use (illustrated in the blue boxes). Chemistry? Internal Construction? Recharge CONOPS? Battery Engineer: © 2012 Joseph F Iaquinto, PE

Initiate Conceptual Integrity
Motivation – When is a CONOPS needed– Test 3 Is there more than one developer / user? Initiate Conceptual Integrity “I will contend that conceptual integrity is the most important consideration in system design” .. Fred Brooks Begins with a conceptual model. A conceptual model is the most abstract description of how the business / mission tasks are conducted when the system is available. We are now going to study the main reason for conducting a conceptual design. The primary reason for doing a conceptual design is to establish conceptual integrity throughout the system definition and development process. © 2012 Joseph F Iaquinto, PE

The Role of Conceptual Integrity Establish Discipline
Conceptual Integrity is the enforcement of a single conceptual model and the absolute compliance with that model by all development personnel. Conceptual Integrity is the first principle of conceptual design. Without conceptual integrity, there can be no system design, only a disjoint set of related designs. No effort should be spared in establishing and enforcing conceptual integrity. It is a "must win", no compromise situation. © 2012 Joseph F Iaquinto, PE

The Role of Conceptual Integrity Establish The Goal
The conceptual model is the reference / touchstone that is used to coordinate all technical and political activity on the project. Coordination of the technical and political activity on the project is essential to insuring the system / product works when finished in a manner that is recognizable to the users and procurers of the system. This is hard enough to do when there is a rigorous effort to enforce conceptual integrity and impossible when there is no conceptual integrity. © 2012 Joseph F Iaquinto, PE

The Role of Conceptual Integrity Create Coordination
Requires a single mind that conceives, communicates, adjudicates and enforces the fundamental technical and political approach to solving the operational problem Conceptual design is no place for teamwork or group think! There must be a single (or two like minded) leaders that everyone else follows. This is a pre-condition for successful conceptual design. © 2012 Joseph F Iaquinto, PE

The Role of Conceptual Integrity Leverage Expertise
The conceptual model cannot survive group consensus. It requires a competent boss who has: appropriate experience demonstrated good judgment the courage to be held accountable for the entire project’s success the authority to fire anyone who refuses to comply Conceptual designs are only as good as the talent, experience, and judgment of the conceptual designer. This concludes our discussion of motivation. Now let's discuss exactly what is a conceptual design and a system definition CONOPS is particular. © 2012 Joseph F Iaquinto, PE

The Role of Conceptual Integrity
The Role of Conceptual Integrity Example of Conceptual Integrity - Software Make Tracking Sheet with color code I will make color code in column E dependent on value in column B Joe Jack I don’t like the ordering of the columns. I will move them into a more logical order. Here is an example of a failure to maintain conceptual integrity in the rather common realm of office automation applications development. This example is actually funny. Can you spot the conceptual conflict? Amanda Rick © 2012 Joseph F Iaquinto, PE

The Role of Conceptual Integrity
The Role of Conceptual Integrity Example of Conceptual Integrity - Hardware Blowback design ok if: Use stick powder Clean Frequently Need to be cheap(?): Use ball powder Never needs cleaning This is a considerably more serious example of failure to maintain conceptual integrity. It is a stern warning to the IPT / Groupthink believers. The requirements for a new battle rifle lead Colt engineers to a blowback design. This design had been previously rejected in rifles (although it is common in handguns) due to the rapid fowling of the bolt and combustion chamber common to this kind of design. Colt engineers compensated for this problem by specifying the use of ball propellant and frequent cleaning of the action. Military command personnel were under pressure to reduce / minimize cost and assumed that they were competent enough to change the manufacture’s specified propellant and maintenance schedule. This resulted in an unfortunate loss of life on the battlefield. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design From some CONOPS standards
A user-oriented document that describes a system’s operational characteristics from the end user’s viewpoint. Synonym: operational concept description (OCD)…IEEE The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used. The OCD is used to obtain consensus among the acquirer, developer, support, and user agencies on the operational concept of a proposed system. Depending on its use, an OCD may focus on communicating the user’s needs to the developer or the developer’s ideas to the user and other interested parties. The term “system” may be interpreted to apply to a portion of a system…MIL-STD-498, DID (CANCELED!) NOT Joint Operation Concepts / Joint Operating Concepts of CJCSI C a procurement document Key concepts here: Description of the system's use in the conduct of human activities (business) In terms of the people who are doing the activities assisted by the system It is a two way street: user asking developer for help, developer telling user what is possible. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design Some excellent references
Frederick J Brooks, “The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition”, Addison-Wesley Press, ISBN Johnson & Henderson in “Conceptual Models: Begin by Designing What to Design”, Interactions, January + February 2002 Fred Brooks was the first author to define the notion of conceptual design and conceptual integrity for software intense systems. His essay (later expanded into a book) on the topic defined many of the principle of conceptual design that are in use today. A more recent essay on the subject by Johnson & Henderson provides a more formal description of Conceptual Models — which we will visit in the next slide — as well as some practical advice for discipline engineers who are attempting to make the transition to conceptual design. Both references are well worth the effort to read and study them. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design Foundation for Artifacts
CONOPS Architecture System Requirements Specifications Conceptual Design Always keep in mind that the CONOPS and the system related specifications are only a small part of the effort required to define and make use of the Conceptual Design. In fact the CONOPS is simple one view into the conceptual design. INCOSE lists the following as some other conceptual viewpoints in the SE Handbook: Concept of Production Concept of Deployment Concept of Operations Concept of Support Concept of Disposal Concept of Development © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design
Definition of Conceptual Design Fundamental Principles of Conceptual Design High level description of the proposed business / mission process Forms the basis of how the roles or users conceive of the system Task domain metaphors and analogies Task domain activities that users execute Task domain information users create and manipulate Activities users can perform Exposes the relationships between the Concepts Illuminates the mappings between the Concepts and the task-domain the system is designed to support Interpretation of: Johnson & Henderson in “Conceptual Models: Begin by Designing What to Design, Interactions, January + February 2002 This slide summarizes the fundamentals of conceptual design as formalized by Johnson & Henderson. Each concept will be discussed at length in a few slides. The metaphors and analogies that are to be employed in the design are mostly mined from the problem domain, that is to say obtained by observing and interacting with the communities who are to be benefited by the product / process / system. For example, folks who operate spacecraft use the metaphor of "flying" the spacecraft. In the case of our toy CONOPS, the user might refer to the Automower as a "Goat"; thereby, highlighting the goat's propensity to shorten grass and to do so with minimum human effort. Metaphors usually form the subject of the activities or processed to be augmented by the system. Generally speaking the concepts referred to by Johnson & Henderson refer to the information manipulated by the activities of the people who are to be assisted by the system. An example of this is the concept of the "General Ledger". From our toy CONOPS there is the concepts of noise and effort. The roles played by the people conducting the activities, for example the train's "Engineer" or the "Mower Repair Technician". Frequently, the relationships are stated as business rules. For example: "the mower repair technician replaces field replaceable mower parts". The mappings are generally the primary subject of the representative scenarios. It should be noted that Johnson & Henderson's essay has broader application than to the rather simple software systems discussed in the essay. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design Fundamentals: Example of a metaphor
A purposeful cross domain mapping Can be used to set the conceptual goal or purpose of the system (Mapping: farm (inexpensive (of reliable but inconsistent conformation), frisky workhorse) -> machinery (automobile)) In these next few slides we will examine some examples of components of a conceptual design. Metaphors are a common and important part of our language. We use them frequently to add interest to our interactions with others, especially in the conduct of our business. The Ford pony cars are a result of Henry's farming background and the fact that he saw the farming community as a major source of revenue for his products. This slide illustrates an example. It also illustrates a problem with metaphors — they are limited to a sub-culture (few of us understand the Pinto metaphor today). © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design Fundamentals: Example of a Mapping
Visit Grandma Grocery shop Go to work Movement This slide is an example of two classes of concepts, one set in the problem (task) domain and the other in the system definition domain, but still sensible to the user community. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design Fundamentals: Example of Relationships
To move, the system must be started To start the system, the system must be occupied Movement and Stop are mutually exclusive (These examples are Business Rules) Here we examine an example of relationships. Notice how they take the form of "business rules. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design Fundamentals: User Activities
To occupy, the system must support mount and dismount To start means to turn it on or off Movement means to control stopping and going Movement means to control direction Finally, we have an example of a mapping between the user conceptual problem domain and the user conceptual system domain. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design The Operational Viewpoint
Expression of the Conceptual Design requires a Viewpoint Technical Viewpoint (how to do it) Political Viewpoint (law, sociology…) Operational Viewpoint (What does it do) Financial Viewpoint (funding, ROIC…) IEEE 1471 INCOSE SE Handbook Concept of Production Concept of Deployment Concept of Operations (ConOps) Concept of Support Concept of Disposal The most important ingredient in the receipt for a conceptual design is the viewpoint or group of viewpoints selected. Recall from slide 32 that the SE Handbook describes several viewpoints into the conceptual design. Here we define the 5 most common types of viewpoints. The technical viewpoint into the conceptual design of a system provides the conceptual approach the various design disciplines intend to take in creating the physical implementation of the system. The political viewpoint unfortunately is commonly ignored or superficially covered in whatever governance material presented in architectural and design specifications. However, it is the single most important viewpoint into the conceptual design. The operational viewpoint into the conceptual design describes how the system is intended to facilitate human endeavor. It is the primary focus of this tutorial. The financial viewpoint into the conceptual design addresses important topics such as how will the system design, implementation and use be funded and what is the expected: return on investment. For government systems, one needs to be a bit more creative regarding the definition of return. © 2012 Joseph F Iaquinto, PE

Definition Of Conceptual Design The Operational Viewpoint
By Convention use the Operational Viewpoint Show business or mission context Emphasizes rational for development Places people in context Very suggestive of what the technology must do By convention, the first product of a conceptual design in the system development process is the development of the Operational Viewpoint. The operational viewpoint includes the parallel development of: -The Scenarios (business or mission context) -The intended uses (the rational for development) -The actors (people's roles in the context of the scenarios The focus of the operational viewpoint is to portray what the system must do for the users. © 2012 Joseph F Iaquinto, PE

Definition of Conceptual Design The CONOPS
The Operational View of the conceptual design is called the “Concept of Operations” or “CONOPS” When documented, it is sometimes called the “Operational Concepts Document” or “OCD” The CONOPS document is the most common representation of the operational view of the conceptual design in system engineering . The terms CONOPS and Operational Concepts Document are synonyms, sort of. © 2012 Joseph F Iaquinto, PE

Recipe for a CONOPS – The Key Concepts
Roles Mission or Intention Information Required Activities A primary focus of this tutorial is the construction of the CONOPS. The receipt for a CONOPS is rather simple at the conceptual level. First, it requires the definition of a user / operator role for the artifact that forms the focus of the CONOPS. Second, it requires the definition of a supplier of said artifact. Third, for the user / operator, we need to formulate the mission or intent of the user / operator, the execution of which is to be addressed by the artifact. Fourth for the supplier role, we need to formulate the information required by this role in order to insure the desired artifact is created correctly. Fifth, a very detailed description of the intended user activities that are to be supported by the artifact is required. Sixth, the relationships among the ingredients are an important part of the receipt. Seventh, the aforementioned ingredients logically yield the Operational Requirements. Relationships Operational Capabilities © 2012 Joseph F Iaquinto, PE

Recipe for a CONOPS Mission or Intent
Client’s goals for the system Why would a person use the system? What are the “Business” processes that the system supports Innate (problem invariant) vs. artifacts of technology How will system earn a profit (why build it?) The following slides address each ingredient of the CONOPS in somewhat more detail. The intended use of the system or the mission in military terms provides the touchstone for the entire conceptual design. It defines the innate problem that the user or customer is addressing when they are conducting the business process that the intended system is to augment. © 2012 Joseph F Iaquinto, PE

Recipe for a CONOPS The Roles
People who support the system Users For any system of interest, there are always a number of roles to be defined as part of the conceptual design. These roles conduct the business activities and are the main beneficiaries of the system. This slide lists 4 of the most common roles: The users of the system are the people who will actually interact with the system in the conduct of a business process. The client is the role that benefits from the business processes which are in turn augmented by the system under description. For any significant system, there are a number of people to support the system, including sales, distribution, fuel, maintenance, and disposal. The last role illustrated on this slide is that of he people who are affected by the system. This includes people who are in the vicinity during usage, the general public, foreign personnel, etc. People who are affected by the system Client © 2012 Joseph F Iaquinto, PE

Recipe for a CONOPS Information Required
Analogies In the conduct of business one encounters a limitless set of forms and documents. All of these are simple analogues of the information required to conduct the business. The challenge in performing conceptual designs is to infer the business information required for the business activity under study from the information artifacts (foams and documents) that are used in the business. Although the primary activity in conceptual design is to abstract the business information from the information artifacts, an equally important activity is to cast these information artifact as key concepts and business objects. Information (Documents/Forms) © 2012 Joseph F Iaquinto, PE

Recipe for a CONOPS Activities / Scenarios (system engineering, not OOA)
Prose not “Geek Speak” Very abstract (conceptual) – BRIEF! Science fiction story Sequential or concurrent As “seen” by the users Where does it “fit” in the business (process) Although the system engineering community in general and the conceptual engineering discipline in particular had laid claim to the work "scenario" in the 50's, the 00A crowd made use of the same term to mean something quite different— the human machine interface behavior in context. The difference is that the 00A scenario focus on the rather narrow interaction of the person with the system whereas the conceptual activity / scenario focuses on the achievement of overall business intent. Review each bullet point. This slide provides guidance in discovering the business activities and writing scenarios from them. © 2012 Joseph F Iaquinto, PE

Recipe for a CONOPS Deriving the Operational Capabilities
Intention + Role + As promised in the last slide, the key relationships modeled or documented in the CONOPS are: The roles / actors are driven to achieve the intended use of the system The roles / actors engage in activities (as documented in the scenarios). An analysis of the activities is used to determine the capabilities the system will need to have in order to augment the process. Capabilities Activities © 2012 Joseph F Iaquinto, PE

Receipt for a CONOPS Operational Requirements / Capabilities
Abstract / Conceptual Derived from the activities / scenarios In problem / usage (Business / Mission) domain terms If number of them justifies, categorize them (temporally) Generally reactive to business / mission events The most important outcome of the conceptual design from a system definition standpoint is the production of a set of operational requirements / capabilities. These are then studied by the various design disciplines for decomposition into a set of functional requirements. This slide provides guidelines for deriving Operational Requirements or Capabilities as part of the conceptual design process. © 2012 Joseph F Iaquinto, PE

Aside: Engineering Design Process Applies To CONOPS
The difference is only a matter of level of abstraction Define the problem Reformulate to match design heuristics Associate, Associate, Associate Synthesize the overall solution Sub-problems with known solutions Shifting gears, we now address the topic of how conceptual and engineering design are related. This slide serves to both summarize the conceptual design process (conceptually) as well as relate it to the follow-on engineering design efforts. The design steps listed apply to any design effort, whether it is conceptual or engineering. Conceptual design benefits from experience at least as well as engineering design. There are repeating conceptual designs as well as repeating engineering designs. This is a tutorial on design, not law; thus, we inspect for achievement of our original goals and modify the design based upon what we observe. Refine the solution (test & rebuild) Monitor the solution in full operations Update design heuristics / known solutions © 2012 Joseph F Iaquinto, PE

Introduction to Useful Standards and Templates
ANSI / AIAA G Guide for the Preparation of Operational Concept Documents IEEE P1362 IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document MIL-STD-498 / DI-IPSC-81430 Operational Concept Descriptions SPC MC Operational Concept Document Template NASA-DID-P100 Concept Data Item Description Some of these standards have been OBE'd; however, they all offer useful information and advice. © 2012 Joseph F Iaquinto, PE

Where Conceptual Design Fits Into System Engineering Process
CONOPS Components & Relationships Capabilities System Requirements System Architecture The CONOPS is the originating effort which produces the originating documents for system engineering. Walk through the slide. © 2012 Joseph F Iaquinto, PE

Where Conceptual Design Fits Into System Architecture Process (DODAF)
CONOPS Operational Information Exchange Matrix Operational Concept Graphic For those of us still using DODAF, this slide illustrates the direct association between the CONOPS and the Operational Views. Although these are the primary views, other views might also be related, such as the statechart (OV-7) Operational Node Connectivity Diagram © 2012 Joseph F Iaquinto, PE

The Conceptual Design More on mapping CONOPS to DODAF
Components Missions / Intentions (OV-1) Roles (OV-4!!) Skills Where (Nodes) Needed Information (OV-3 / OV-7?) Performance Activities (OV-5, SvcV-4) Relationships Mission to Role (OV-5) Mission to Activity (OV-6) Role to Node (OV-5) Role to Information (OV-2) Role to Role (OV-4) Role to Activity (OV-5) Here we some additional details about the mapping of the CONOPS to DODAF. Mapping requires judgment and skill © 2012 Joseph F Iaquinto, PE

Principles and Fallacies of Conceptual Design
Session 2 Principles and Fallacies of Conceptual Design In session 1 we familiarized ourselves with the basic notions of conceptual design and the concept of operations. In session 2 we studied in depth one of the two forms of the CONOPS, the military CONOPS. The rest of the tutorial will be a study of the System Definition CONOPS including the process and art of generating the content and the creation of the document that serves as the "deliverable". In Session 3 we start our journey toward a System Definition CONOPS by taking a look at advanced topics in Conceptual Design. © 2012 Joseph F Iaquinto, PE

Topics of Session 2 Principles and fallacies of conceptual design
The Conceptual Problem Think “User Viewpoint” Think Critically Selecting Perspectives (Views) From the Tar Pit: Fred Brooks Common Conceptual Design Fallacies Big Failure Modes - Systemantics Creating a conceptual system design creates a number of problems for the SE, which we will explore in this session © 2012 Joseph F Iaquinto, PE

The Conceptual Problem – A Checklist
How do we discover the mission or intent? What roles are required to achieve the intent? What information is needed to achieve the intent? Where are the roles located? What activities do the roles need to perform in order to achieve the intent? What are the important relationships (e.g. role to information)? How can I capitalize upon experience (associate this system with past solutions)? Our problem in creating a conceptual design of the CONOPS type is dominated by our need to understand the business domain which we mean to facilitate by the system under definition. Walkthrough each bullet point. © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” Intended Use Centric
Capture manner of customer’s circumstance Language Intentions Historical Perspective The conceptual design represented by the CONOPS focuses on the intended use of the technology, not the technology itself. Capture the intended use in the manner of the customer's circumstance to include but not be limited to: Language Intentions -Historical Perspective Intended use is not always what is vocalized by the user — you must use experience, logic and intuition. Here the intended use might be to "get the girl". Magellan 750 © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” Establish Foundation
Judgment is essential in establishing the User's Viewpoint. Judgment is required to improve the quality of your inference given the uncertainty introduced by dialogues with the users, observations of their behaviors and discussions with their "masters". Tell story of deer hunter on contract you worked on a few moons ago. Bottom line is that Judgment (as well as "common sense") requires application domain knowledge and experience. Acquire “Domain” (User) Knowledge Acquire “Domain” (User) Experience Judgment © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” Conceptualize in Customer’s Language
Understand the metaphors Understand the technical artifacts Discover the innate principles and activities Look for archetypical concepts (the only basis for reuse) In the spirit of "being the customer" you need to do all of your conceptualization in the customer's language. Walk through the bullet points. The conceptual design and CONOPS must be fully comprehensible by the user / customer / stakeholder community. © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” Conceptualize in Customer’s Language
Parts List NOT Aggregation! Kinds of Parts NOT Generalization / Specialization Interconnection NOT Association Here are some examples of mistakes that are frequently made by SE's who came up the ranks from careers as software engineers. Avoid technical jargon in any conceptual design or CONOPS, even if it requires loss of technical conciseness. Tell story of Tim Taylor. © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” A Counter Example – As found
System Concepts Provide Services Provide Worldwide Access Dynamic Collaboration Enterprise Management Dynamic Resource Allocation System Assurance “Network” With Co-workers Private Conversations Knowing What is Happening This slide presents a common mistake in conceptual design. Notice that the system concepts are decomposed into technical concepts that are clearly not in the set of all user viewpoints (see blue boxes). If you cluster these technical concepts into process concepts, you arrive at the green bubbles. Let's assume for the purpose of discussion that the terms in the green bubbles are in customer's viewpoint. An example of where this kind of counter example can profoundly effect users is when it is used to design the user interface — each block representing a screen or screen type. © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” A Counter Example – The reality
System Concepts “Network” With Co-workers Private Conversations Knowing What is Happening The more appropriate presentation of these system concepts is depicted herein. Notice the reversal of the blocks and the bubbles. Now the user viewpoint terms directly connect to the System Concepts block and the SE viewpoint terms, the conceptual software design, is used to represent an elaboration of the system concepts. Provide Services Provide Worldwide Access Dynamic Collaboration Enterprise Management Dynamic Resource Allocation System Assurance © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” Be Aware of Implementation Possibilities
The operator will have complete control over the direction in which the vehicle moves. In order to preserve the user's viewpoint, one must beware of expressing implementation possibilities during the conceptual design. What makes this especially hard is that you should be aware of the technical implementation possibilities' as a way to insure that you are postulating a feasible, indeed desirable CONOPS. Thus, the technical conceptual design must take place in parallel with the operational conceptual design BUT REMAIN SEPARATE. In this case we can postulate a CONOPS in which a vehicle operator controls direction of motion of the vehicle because we know of steering wheels and joysticks. © 2012 Joseph F Iaquinto, PE

Think “User Viewpoint” A Most Important Architectural Artifact
In software intense systems, it is common for the business executor / user to interact with the software through a User Interface. Conceptual screen shots or control panel layouts are a legitimate component of any conceptual design that includes a human machine interface. User Interface (example: screen shot) is important part of Conceptual Design and a legitimate architectural artifact! © 2012 Joseph F Iaquinto, PE

Think Critically – Foundation for Problem / Solutions Basic Principles
Clarity Precision Accuracy Relevance Consistency Logical Correctness Completeness Fairness My Favorite Barrier: Wishful Thinking This slide contains the basic principles of Critical Thinking. They are all interrelated. If you can remember only two things, remember the bolded items (Relevance and Completeness). Clarity refers to focusing the conceptual design on those aspects of the application domain that are important and germane. Precision in conceptual design refers to the need to state quantifiable goals that the conceptual design seeks to achieve through quantifiable conceptual characteristic of the design. Accuracy refers to correctness of both the concepts in the conceptual design as well as assumptions and goals. Relevance drives one to create concepts that are directly related to the desired outcome and only those. It also means that all arguments offered to support design assertions actually advance the decision making process toward a valid decision. Consistency is an analogue of conceptual integrity, which we have already discussed at some length. Logical correctness demands that we not abandon logic in our concepts or our arguments. Logic is our single most powerful gift and the wellspring of all successful human enterprise. It is so important that there is an extensive literature on the topic. Completeness demands that conceptual designs address all relevant topics. This usually refers to rainy day scenarios as well as happy path and all classes of stakeholders, not just the "important" ones. It also demands financial and project conceptual models that are of adequate complexity and not oversimplified. Fairness in conceptual design requires the designer to consider all stakeholder concerns, even those that are not supportive of the design. All such concerns must be addressed in the conceptual design. This last point is one of my pet peeves and an important challenge as conceptual designers. The principle of "Wishful Thinking". This principle has become the principle conceptual design tool in modern business and government. It has caused the loss of countless wealth. © 2012 Joseph F Iaquinto, PE

Think Critically Be Argumentative
Controversy Resolution Issue Claim Evidence Claim Warrant Inference Be Argumentative. Argumentation is NOT BAD!! To argue is to offer reason (in proof or rebuttal). To argue is to seek voluntary concurrence and agreement. To argue is to seek to discover fallacies in one's own reason. Conclusions that have reason can be logically examined for rational concurrence or attack. Be aware that argumentation is the enemy of: -Group think -Fascists -Managers -Military leaders -Politicians -All of those who seek to control our conceptualization processes by force (power). © 2012 Joseph F Iaquinto, PE

Think Critically Be Argumentative
Where is the Issue: COBOL is totally obsolete; thus, we need to code in JAVA Where is the Evidence (Rationale): We cannot find college trained COBOL programmers; thus, we need to code in JAVA. This is an example where argumentation can save money and provide a role for System Engineering. In business and government today, a statement of an issue is frequently mistaken for a proven assertion. An inexperienced government or industry decision maker could easily be tricked into spending substantial funds to replace existing software staff, and re-code existing applications. The second statement is a more correctly formed argument. The antecedent in this statement is more applicable as evidence supporting the consequent versus that of the first sentence (which is more like an assertion itself). Nonsensical statements like the first one are far more common than true arguments. They are all too often used to both justify and define conceptual designs. Always challenge them and demand properly formed arguments. Once you have a correctly formed argument, use the rules of argumentation to test the conclusion for validity and the rules of logic to test the conclusion for correctness. © 2012 Joseph F Iaquinto, PE

Think Critically Be Argumentative – Another Checklist
Is there an issue? Is the issue important (or important enough) and relevant? Is there a rationale? Does the rationale support the conclusion? Is the rationale (hence the conclusion) related to the issue? Does the conclusion indeed resolve the issue? This slide presents a checklist to be used for testing arguments. You should be able to define a single, clearly stated issue that must be resolved. The issue should be both relative and important to the problem for whose solution you are pursuing with the conceptual design being formulated. You should be able to identify the reason given for the conclusion; that is to say, the rationale. Is the reason offered relevant to the argument- does it support the conclusion? Does the conclusion provide a concept that resolves or works toward resolving the original problem? © 2012 Joseph F Iaquinto, PE

Think Critically Beware of Conditional Statements
If you abstract applications away from the underlying hardware, then resources can be used more efficiently. If you have reusable software services, then you can simplify the development of custom applications, allowing IT to avoid writing code unnecessarily. Conditional statements are particularly troublesome, especially conceptual ones like those illustrated. They resemble a simple form of argument, the syllogism (a deductive reasoning tool) and are often mistaken for same. They are easily recognized by the informed as being counterfeit arguments, because they lack the major and minor premise. (All mammals have fur, mice have fur, and therefore, mice are mammals). The first conditional statement is actually a proposition, and not a complete argument. The second conditional statement actually contains 2 propositions and no evidence. These are NOT syllogisms! © 2012 Joseph F Iaquinto, PE

Think Critically Consider All Relevant Dimensions
Reusable Services Use Rather Than Code Restrictive Association (to services) Understand What They Do Understand How They Work This slide expands upon the second conditional statement of the previous slide. Appealing to the CT principle of completeness, I have created a map of some of the dimensions of this assertion. The bolded block states the only dimension mentioned in the assertion that code reuse saves the need to re-code. As you can see there are several other dimensions. Restrictive Association refers to the likely restrictions placed by the service provider on access to these services and on allowable associations among vendors. This is the tip of the contractual and other legal implications of purchasing services and service level agreements from vendors. Understand What They Do refers to the fact that the data and behaviors that services provide need to be studied before they can be used. The more complex the behavior of a service, the more effort that is required to understand how to make use of it and the greater the uncertainty in understanding it. Understand How They Work refers to the fact that once a programmer understands what a service does, they then have to understand how to make use of it in their application development process. This includes how to invoke it, how to interface to it and how to deal with abnormal behavior. Understanding Prototypes refers to the fact that programmers are most likely going to have to build test applications in which they test their understanding of the services they are using and their understanding of how constellations of services behave. Component Change Impact refers to the impact upon an application that uses these services of a change by the provider in their services. The Microsoft DDL fiasco of a few years ago provides a real world example of this kind of conceptual impact that needs consideration. Test Them or Trust Them refers to the service qualification concept. How much testing do we expect our programmers to do in order to assure the services do indeed work as advertised. Even with this incomplete list, we can see that the proposition that we use reusable software services is woefully over simplistic; thus, exposing us to possible unintended and unplanned expenses that can be quite sever. Component Change Impact Test Them Or Trust Them? Understanding Prototypes © 2012 Joseph F Iaquinto, PE

Think Critically Use of the Scientific Method
Body of Knowledge (Always Changing) + Method (Limited Use) One of the most celebrated CT methods is the Scientific Method. It is frequently used as a irrefutable argument in politics and occasionally in business and government. The Scientific Method consists of the two components illustrated. © 2012 Joseph F Iaquinto, PE

Use of the Scientific Method The Body of Knowledge
Established by the Scientific Method Approximate due to limitations of the Scientific Method Useful for Conceptual Designs Beware of: It an approximation only It evolves with time New systems can change the knowledge The first component of the Scientific Method is the Body of Knowledge that was constructed by proclamation and use of the process. Never forget that the scientific body of knowledge varies considerable with time and contains considerable uncertainty. Both the time dependencies and uncertainty are ill understood by scientists and lay people alike. Another situation to be aware of is that certain systems that you build using the body of knowledge can, when placed in operation, change this body of knowledge. © 2012 Joseph F Iaquinto, PE

Use of the Scientific Method The Method
Problem Hypothesis (Guess) Controlled Experiment Notion of exactly 1 Dependent and exactly 1 Independent Variable!!!!! Control (Independent Variable Value) Is Mandatory! This slide summarizes the process. Notice that this method by is very nature, has extremely limited application!! © 2012 Joseph F Iaquinto, PE

Think Critically Use of the Scientific Method - Fallacy
Fertilizer Work? Hole in Ozone Layer? Drawing from the arena of public argumentation, an example of a valid and a fallacious application of the scientific appears on this slide. You should routinely rebut any arguments offered about real world systems that claim to be based upon the scientific method. Basically, it does not scale. Real world systems of the complexity that require the services of an SE are not tractable by the scientific method. They require the use of argumentation which is designed to deal with situations where there the actual truth of the matter is fundamentally unknowable. Test Article Control Test Article Control??? © 2012 Joseph F Iaquinto, PE

Think Critically Usefulness of the Scientific Method
Control on left or Right? Associate Orders or Not? Pizza Order Form for Order Entry Function 1 Function 2 Go Go 1 m Soda Order Despite these words of caution, the scientific method can be used to aid in establishing the details behind a conceptual design. The basic idea is to exploit the observability of results rather than guess or IPT the answer. The scientific method can be used to answer these two questions because one can make up an experiment and observe the results in a very deterministic way. In this slide we show two examples of the kinds of conceptual questions that can be answered. On the left is an interface design example. On the right is a conceptual data model example. Be aware, that although these are both conceptual design issues, they are barely conceptual in nature. Those issues that bridge from the conceptual design domain to the system design domain are usually the best candidates for benefiting from the scientific method. © 2012 Joseph F Iaquinto, PE

Think Critically The Process of Problem Solving
Identify The Problem Identify The Cause Identify & Remove Barriers Gather Information Generate Solutions Select Solution This slide presents an often quoted process for using critical thinking to perform problem solving. Identification of the problem is the single most important task in conceptual design. Antidotal information can be useful, but not as a substitute for a problem statement. If you don't properly identify the problem you are trying to solve with your conceptual design, all subsequent work will be mostly waste. Once the problem has been identified, CT processes suggest that you identify the cause of the problem. Although this seems obvious, it is rarely done in current day established practice. Current practice is to state a problem and immediately state a solution without bothering to contemplate the actual cause of the problem. This is perfect in politics, but disastrous in system definition. This next step refers to the process of critical thinking. There are always thinking barriers, such as culture, prejudices, and established practices that prevent freedom of thought. Given the problem situation at hand, these barriers need to be identified and compensated for. CT recommends that the task of gathering information about the problem, causes, enterprise politics, technical considerations, etc be a formal task. The act of gathering this information not only provides the SE with needed decision making information, but also aids in expanding the purview of the SE. Yes, this is the miracle step. It relies in rather intangible assets of the SE to invent out of experience, judgment and logic the set of solutions to be considered. Liberal application of argumentation is required in order to qualify solutions as truly addressing the problem. The next three steps involve testing the solution in some real world or close to real world circumstance (simulation and modeling). The results of this testing is necessarily an evolution of the originally postulated solution. The process of CT is not an academic process. It is a simply expression of the value of offering reason for action and evaluating that reason and proposed actions against the original motivation for change. Evaluate Solution Courage to Evolve Solution Genesis of the CONOPS © 2012 Joseph F Iaquinto, PE

Think Critically Detect Fallacies – Fallacies of Relevance
Is the argument advancing? Personal attack Attacking the motive (turf battle!) Look who’s talking Two wrongs make a right Appeal to force Appeal to pity Bandwagon argument Straw man (striking beside the issue) Red herring Equivocation (I did not have sex with that woman!) Begging the question CT being a human endeavor is subject to mistakes and downright sabotage. This slide lists the most common fallacies. These are all fallacies of relevance, a very common mistake and ploy. I recommend that you study the literature and familiarize yourself with these since we don't have the time to address each one in adequate detail. The point is not to name fallacies you hear or read, but rather to equip yourself to recognize the fallacy so that you can defend or attack the fallacious argument more effectively. There are two that I will give special mention to. The "Personal Attack" is very popular in government today. Variations on this theme are: Nothing is perfect (the arguer is a perfectionist and therefore his arguments are irrelevant) — example: we should have clearly stated requirements to support our solution decision. You have got to take "baby steps" (the arguer is being unrealistic in their proposal) — example: the system design should be documented in a system design specification and an interface control document. The second fallacy we see being used extensively in government today is the "Red Herring". Here is a common example: Issue: We need to create a formal customer requirements process in order to prevent another rejection of the product by the customer. Red Herring: That will take too long. © 2012 Joseph F Iaquinto, PE

Think Critically Detect Fallacies – Insufficient Evidence
Reasons Don’t Support Conclusion Inappropriate appeal to authority Appeal to ignorance False alternatives (often result from lack of technical expertise) Loaded question Questionable cause Hasty generalization Slippery slope Weak analogy Inconsistency The previous slide presented fallacies of relevance, that is to say these fallacies do not advance the argument (proof or rebuttal) toward a conclusion. Now we turn our attention to fallacies of insufficient evidence. Once again, these fallacies are well documented in the literature. The two most common one used in government are the first one and the sixth one. Example of #1: We need to write a system requirement specification to insure we are addressing the customer's needs. Captain Joe said we don't need system requirements since we already know what the customer needs. The Hasty Generalization is important enough to be addressed on a later slide. The bottom line is that these fallacies do not provide evidence for or against the proposition. © 2012 Joseph F Iaquinto, PE

Think Critically Understand the use of language
Vital to understanding domain and assessing arguments Avoid misunderstanding with precise language Illustrations Use dictionary definitions, not jargon Emotive language Used to slant the truth Avoid euphemisms and political correctness Shifting gears Another principle of CT and argumentation is the notion that language is a critically important component in thinking. I hope no one finds this surprising. This slide summarizes the literature on the topic. A key concept regarding language of importance to technical workers is avoiding jargon. Repeat Tim Taylor story again. © 2012 Joseph F Iaquinto, PE

Think Critically Understand Prejudices Inherent in Customer
Setup artillery after Move takes 1 hour When dealing with both the problem and the solution, beware of the customer. Asking customer / user / acquires for suggestions to improve their business processes is notably hazardous to engineering. Tell Mazda SW story. An SE must be aware of customer prejudices even more than their own prejudices. The most hazardous form of prejudice is, poetically, technology induced artifacts of thought and practice. This slide presents an example. Innate problem: Precisely determine location Artifact: Engineers have to survey the new location Conclusion: Artifact of technology causes prejudice © 2012 Joseph F Iaquinto, PE

Think Critically Understand “Common” Beliefs in Customer Domain
Identifying common beliefs Artifacts of technology Artifacts of history Artifacts of personality "Common beliefs", a form of "common sense" is a particularly hazardous form of group think. Common belief are artifacts of many factors, the 3 most important ones are listed. Clearly, the SE needs to develop a deep understanding of the customer's technology, history and personalities in order to be able to factor common beliefs into the CT and conceptual design process. We will address each of these important factors in turn. © 2012 Joseph F Iaquinto, PE

Artifacts of technology Process Technical constraint vs. innate Productivity limitation Documents Communications (between departments) Continuity of operations Limitations Insufficient productivity Insufficient communications This slide lists some of the sources and consequences of "common beliefs" that derive from artifacts of technology. The business processes that are used in the customer's domain are very dependent upon the technology used to facilitate their execution. This can lead to "common beliefs" about what the business processes need to consist of that are purely artifacts of the underlying technology. It also makes it difficult to infer those activities that are innate to the business. These technology artifacts and the common belief they can induce lead to limitations on productivity growth. Similarly, the documents (business objects) that are used in the customer's domain are also dependent upon both innate business needs and artifacts of the technology used in the business. This can inhibit changes in the communications between departments and lead to problems with designing. Limitations induced by these common beliefs include insufficient productivity and communications within the target business. © 2012 Joseph F Iaquinto, PE

Artifacts of history Law Process to accommodate prior laws Documents required by prior laws Limitations inherited from prior laws Culture Process dictated by religion or “pecking” order Documents dictated by philosophy Limitations dictated by social relationships (DOD) This slide lists some of the sources and consequences of "common beliefs" that derive from artifacts of history. Historical inertia is a common topic of study in the study of the politics of organizations. Laws result in business adopting compensatory business processes. These business processes may persist even after the law has been changed or abandoned. Similarly, documents may exist to satisfy laws some of which are no longer in effect. These taken together may place limitations on the conceptual design or require CT in order to provide compensation. Similarly culture can distort the innate purpose of a set of business behaviors. Religious beliefs and social hierarchies can greatly influence business processes. The documents processed by the business process are as much influenced by philosophy, perhaps of departed influential managers as they are dependent upon innate business needs. These factors must be considered in the conceptual design / CT process and both accommodated and used to identify the conceptual degrees of freedom available to the SE. © 2012 Joseph F Iaquinto, PE

Artifacts of personality Founders Process defined by founder Shift into reverse while moving forward Documents defined by founder Limitations of founder’s imagination Key management personnel Similar to founders This slide expands the influence of personality upon an organization's common beliefs. Founders have a most fundamental influence on the belief system of the organizations they create as well as related organizations. Processes that have been defined by a founder may persist long after the circumstance in which they have been defined has changed. Tell Henry transmission story. The same is true of business documents that have been defined by the founder. Clearly, these factors create limitations on the conceptual design that must be understood and / or compensated for. The same can be said for key management personnel with the additional problem that there may be more key management personnel than founders and they may be active during the time of the CT / conceptual design process. © 2012 Joseph F Iaquinto, PE

Think Critically Understand Emotional Influences In Customer
Fear of job loss Fear of prestige loss Fear of failure Angry at being forced… Genuine concern User We will now address some of the more devastating fallacies. During the "Gathering of Information" CT task it is essential that the SE understand the emotional influencers that drive the behavior of the customer. Some typical emotional topics are listed on this slide. It may be necessary to make explicit arguments to the users aimed at allaying their fears and concerns — whether these arguments reflect real management concern or not. Some of these emotional concerns will be apropos to the CT / conceptual design and need to be given proper consideration. System Engineer © 2012 Joseph F Iaquinto, PE

Think Critically Avoid Overgeneralizations
Drawing broad conclusions on basis of single incident An airport inspector failed to confiscate a knife -> we have to replace all airport inspectors with personnel with clearances Schools don’t teach COBOL -> we have to replace all COBOL programs with JAVA programs A person drove onto a school playground killing 5 students --> we must ban all private ownership of automobiles We pay too much for sending EDI messages -> we must re-build our IT infrastructure upon Web Services This slide provides real world examples of one of the most significant fallacies of today — hasty / over / inappropriate generalization based upon events. These are four of nearly and unlimited set of real world unjustifiable conceptual generalizations that have or could have had disastrous results. Avoid the crowd by identifying and eliminating hasty generalization in your conceptual design process. © 2012 Joseph F Iaquinto, PE

Think Critically Avoid Selective Abstraction
Focus on one detail and ignoring the big picture If the Intel Community shared data, 9/11 would never have happened Mainframes cost too much to buy; therefore, we need to switch all of our applications to Unix servers. We don’t understand each other’s architectural artifacts; therefore, we need to define a DODAF We don’t understand each other’s data; therefore, we all need to use the same data model This slide provides more real world examples of one of the most significant fallacies of today — hasty / over / inappropriate generalization but this time based upon tunnel vision or oversimplification of the problem domain. These four selective abstractions all ignore significant concepts in the problem domain. Had these other concepts been considered the SE would have arrived at a significantly different conceptual design. Let's consider some notional examples. This first example ignores the fact that the 9/11 attack was a military attack that the US military failed to repel. Given this concept, the conceptual design of the desired new CONOPS may have proceeded quite differently. (information sharing cannot repel attacks) The second example ignores the administration cost of the two options being discussed. If the administration cost was a part of the conceptual design model, a significantly different CONOPS would emerge potentially saving billions of dollars. The third example ignores the fact that an understanding of different architecture requires substantially more than making use of the same classes of diagrams. Of course this would lead to a substantially more complex, and useful CONOPS of architecture study. The last example is typical of a common and very destructive class of fallacy wherein the engineering team diverts their energy into a efforts that have no direct impact upon the customer's situation. Making data models does not further the business's objectives. It is at least one level of abstraction removed; thus, it requires careful CT / argumentation to prove that it is useful to the customer. © 2012 Joseph F Iaquinto, PE

Think Critically Exploit Natural Orders To Organize Analysis
Ordering is central to Conceptual Design Topical Order Order of place Central to structural / static modeling Analogical Order Similarity and metaphorical ordering Central activity of Engineering Chronological Order Time or sequence Central to behavioral modeling Causal Order Reasons or cause and effect Important theme of behavioral modeling We have spent a significant amount of time on learning common fallacies that are to be avoided in any critical thinking. Shifting gears a bit, we turn our attention to two more important concepts of CT, clustering and reasoning. This slide addresses the very powerful notion of clustering in CT. Clustering is used to group concepts into categories of concepts so that we my reason about the clusters rather than all of the individual concepts. This greatly reduces the level of effort while making the analysis more understandable to the actors in the problem domain. Topical ordering is useful in creating abstract or conceptual static models which are one of the most important system concept views. Analogical ordering is critical to the engineering community since it is very useful in identifying conceptual known problem / known solution sets. Chronological ordering is important in abstracting behavioral model, which are the central theme in CONOPS as well as being a key integrative concept in system descriptions. Causal ordering is also critical in abstracting behavioral models. Use ordering to organize your analysis by important concepts. © 2012 Joseph F Iaquinto, PE

Think Critically Employ Inductive and Deductive Reasoning
Deductive Thinking From the general to the specific Syllogism: premise (reason) and a conclusion that follows Most natural, everyone is capable of this kind of thinking Inductive Thinking From the specific to the general Analogical argument: a specific similarity implies general similarity Very hard to do, requires a mutant The principle fallacy of the OO method, Ontologism… There is considerable confusion in the business and government communities regarding these basic concepts in reasoning. Deductive thinking does not create new knowledge. It simply allows one to reason about the implications of previously established knowledge. Inductive thinking creates new knowledge from existing knowledge. It is really hard to do, so beware of any CONOPS methods that require induction. © 2012 Joseph F Iaquinto, PE

Selecting Perspective (Views) Useful Concepts
See IEEE Recommended Practice for Architectural Description of Software Intensive Systems DODAF product is one representation of a VIEW A View is a representation of a whole system from the perspective of a related set of concerns. Usually a model Has a very specific purpose A Viewpoint is a specification for constructing and using a view. A concern is a stakeholder’s intent in acquiring the system The most useful reference for mastering the art of Viewpoints and Views is IEEE 14712000. The DODAF standard defines a small set of viewpoints and a set of views for each viewpoint. This standard addresses a very narrow goal of studying interoperability / integration so it has limited applicability to conceptual design. The central theme of this slide is that there are multiple groups interested in the conceptual design (the stakeholders) who have a set of concerns about the conceptual level system definition. Therefore, any conceptual design must consist of the appropriate set of viewpoints and views necessary to address all targeted stakeholders concerns. © 2012 Joseph F Iaquinto, PE

Selecting Perspectives (Views) Basic Concepts of “Perspective”
Is addressed by Stakerholder Concern Viewpoint Has a Represented by specific Views Rendered / addressed by specific This diagram is a simplification of the IEEE standard quoted in the last slide. The basic concepts of the standard are related on this slide. Walkthrough the slide. Products / Model Bottom line: products are arguments! © 2012 Joseph F Iaquinto, PE

Selecting Perspectives (Views) First Rule: Keep Views Very Simple – Bad Example
The conceptual model must maintain a level of simplicity that permits ready comprehension of the concepts you mean to project to the user community. This is an example of an overly complex OV-4. Recall from our discussion of argumentation that each concept should present and prove a proposition. It is very hard to understand the issues and controversies when looking at this slide let alone follow the argument. It is usually a bad idea to provide a view that simply states everything you know about a particular topic. Views should be thematic. What you should do is describe a concept or constellation of concepts that address a concern of a specific stakeholder system. © 2012 Joseph F Iaquinto, PE

OV-4 Naval Command Structure
Selecting Perspectives (Views) First Rule: Keep Views Very Simple–Better Example OV-4 Naval Command Structure JFACC JFMCC Operational Command / Control Tactical Control CSG Air Related Organizations Non Air Related Organizations In this diagram we attempt to provide a conceptually more informative view. The theme of this view is command structure, in particular who has operational command and control and who has tactical control and how do they interact. Carrier Strike Group Organizations © 2012 Joseph F Iaquinto, PE

From the Tar Pit: Fred Brooks Basic Concepts
C.R.Knight, Mural of La Brea Tar Pits The Mythical Man Month Conceptual Integrity The Surgical Team Aristocracy, Democracy, and System Design As we have discussed before, one of the pioneers of modern conceptual design is Fred Brooks. He has sent us a message from the tar pit that proposes the four basic concepts about how things go wrong during a conceptual design attempt. We will now address each in turn. © 2012 Joseph F Iaquinto, PE

From the Tar Pit: Fred Brooks The Mythical Man Month
The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth Adding manpower to a late software project make it later Training Cost + Interaction Cost Break up the conceptual design effort into parallel teams a BAD IDEA Operational (Views) System (View) Many "laws" are attributed to Brooks since we readers of the Mythical Man Month find many insights presented therein. However there is only one law that he lays claim to and that is the second bullet point on this slide. The concept behind this is that there are two costs to adding team members to increase productivity: -The cost to train the new members of the team -Most importantly is the cost of interaction / coordination. Brooks dwells upon this topic at length. The bottom line to us is that breaking up the conceptual design into tasks that are executed by interaction, but different teams is a bad idea — a very bad idea. The slide lists a most common mistake in DODAF architectural / conceptual design efforts. All such project I am aware of (about a half dozen) were failures, as predicted by Brooks. © 2012 Joseph F Iaquinto, PE

From the Tar Pit: Fred Brooks Conceptual Integrity
Single most important reason for failure of CONOPS Conceptual design MUST proceed from one mind, or a very small number of agreeing resonant minds IPTs as advisors, not consenters Teams as amplifiers, not consenters Every part must reflect the same philosophies Every part must have the same balancing of desiderata Every part must use the same techniques in syntax and analogous notions in semantics Unity of design We have addressed the notion of conceptual integrity before. Now we are going to consider it in somewhat more depth. Although it is self evident, it is the most violated principles of conceptual design. Almost without exception, if a CONOPS fails to produce a useful system, it is due to a failure to maintain conceptual integrity. Any conceptual design, including the CONOPS must follow from one mind. No IPTs. No Teams, No compromise. The philosophical approach to defining and resolving the problem must not change or be confused in the conceptual design. The desired outcome of possessing the system under description must be the same in all aspects of the conceptual design. Even the use of language, including metaphors and analogue must be exactly the same throughout the conceptual design and its documenting CONOPS. The conceptual design must be organic. © 2012 Joseph F Iaquinto, PE

From the Tar Pit: Fred Brooks The Surgical Team
Architect Co-Architect Engineering Administrator Tool Maker Tech Pubs QA / Test Fred's first premise is that conceptual design is the purview of the architect, NOT ENGINEERING. Fred likens an effective conceptual design team to a surgical team (where conceptual integrity is essential). The figure illustrates a product development team constructed as an analogue of the surgical team. Notice that there is one architect who is in complete charge of all aspects of the product development team. Yes, this is the traditional role of the SE, so the SE is a kind of architect when discussing conceptual design. There may be only one co-architect who is also subordinate in decision making authority to the architect. Notice that the production and test functions (Tool Maker, QA/Test) are not subordinate to engineering, but are subordinate to the architect. "Heros" have been denigrated in modern project management literature with a resulting loss in creativity in US Engineering. To return to more productive, creative tradition it is necessary to organize the "surgical team" not to suppress the talents of the "hero" but rather to multiply or amplify the effectiveness of the "hero". For the conceptual design, this organization scales perfectly. There is no enterprise that we can undertake that requires more than one or two like minded architect. Maintain Conceptual Integrity Multiply Effectiveness of “Hero” Scales Sufficiently for Conceptual Designs Domain Expert © 2012 Joseph F Iaquinto, PE

From the Tar Pit: Fred Brooks Aristocracy versus Democracy
Conceptual integrity is the most important consideration in conceptual design. Conceptual integrity demands that someone control the concepts. Aristocracy needs no apology. Discipline is good for art. Conceptually integrated systems are faster to build and to test. Separate conceptual design from implementation to assure conceptual integrity on large projects. Democracy in conceptual design? Read Homer’s “The Odyssey”. Modern government and industry management practices are somewhat antithetical to the establishment or maintenance of conceptual integrity. This slide presents some arguments to help overcome this unfortunate situation. Pursuit of conceptual integrity is vital to the success of any conceptual design effort. Have a person control the concepts also provides accountability. The discipline required of conceptual integrity focus the execution of the conceptual design effort on both defining goals and measuring their achievement. By minimizing the effort required to coordinate the efforts of individual team members and by eliminating subsystem incompatibilities, conceptual integrity reduces the resources and time necessary to build and test a system. Implementation produces a number of design details which don't need to be coherent across a particular system. However, conceptual design produces a rather high level of abstraction system description. Therefore, one should not mix implementation details into a conceptual design because of the risk of breaking coherence. Conceptual design, since in depends upon conceptual integrity has no room for Democracy. A rather humorous treatise on the effect of democracy on conceptual integrity, and the results that issue from the problem can be studied in Homer's "The Odyssey". The message here is that maintenance of as much conceptual integrity as possible needs to be an important activity in any conceptual design effort. Conceptual integrity is a must win activity. Conceptual integrity is not theory that can be ignored in practice. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies
Common Conceptual Design Fallacies Typical Misuses Of Technical Concepts Zachman / Architecture As Implementation Lack of Focus In Illustrations (keep drawing simple and to the point) OO Versus Procedural Versus SOA… Use of UML Cartoons Ontology Reuse Technical Conceptual Design ≠ Operational Conceptual Design If you are getting the impression that architecture and conceptual design are related, you are correct. Architecture is a conceptual design at the highest level of abstraction. An Enterprise Architecture is an all topic conceptual design. This slide is a kind of fallacy recognition chart for conceptual designers. The main theme of this slide is that technical conceptual design DOE NOT EQUAL system conceptual design, most especially Operational Conceptual Design — the CONOPS. The first step in avoiding these fallacies is to recognize when they are occurring. This is actually harder than it looks. The first step in compensating for unavoidable fallacies is to recognize when they are occurring and what it means to have such a fallacy in the conceptual model. Although all of these fallacies are capable of leading to fatal results, you still must exercise judgment in establishing your mitigation plans. Don't get fired, don't let people die (if you are a professional). The next few slides will define each of these common fallacies and provide some guidance on how to avoid or mitigate the fallacy. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Zachman – “Drowning projects in bubbles and boxes” Zachman's Definition of Architecture: A set of design artifacts, or descriptive representations, that are related for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). “A Practical Guide to Federal Enterprise Architecture”, Chief Information Officer Council, GAO, February 2001 The most common conceptual design fallacy is to include implementation or elaborations in the conceptual model. This includes the use of standards and technical jargon in place of rationale oriented statements. This both distracts the reader from comprehending the conceptual plan and invites controversy unnecessarily. Zachman in this famous quote is referring to the fact that the business executors need to understand any conceptual design. They cannot do so if the conceptual model contains too much detail / information. This second Zachman quote is an example of a purpose that you should create for your conceptual design. Whenever there is a questions as to the level of detail required, refer to your purpose and as if it is advanced or retarded by this detail. The reference quoted is useful in assisting conceptual designers from using too much detail. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Zachman – “Drowning projects in bubbles and boxes” 36 Categories of information Planner / owner level all that is applicable Too distracting Ok, so if we are to avoid drowning projects in bubbles and boxes, what information is appropriate for a conceptual design and what is not. Zachman provides us with a conceptual model of all of the categories of information that exist to describe an enterprise. In all there are 36 categories. Only the 12 information categories that apply to the planner or owner need to be considered in conceptual design process. In most cases, the CONOPS can proceed at just the planner level with a concentration on the "Why", "When" and "How" columns. Supporting concepts can be drawn from the "What" and "Who" columns with "Where" column information. Be careful to include only those categories that contribute to the conceptual design so as not to provide a distraction for the reader. The principles of CT previously covered can be of immense help id selection exactly what categories of information need to be included in a conceptual design. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Instead of Zachman – KEEP IT SIMPLE
Intention Information Activities Roles The Business Profit Documents Workflow Personnel Automation Rationale Data Capabilities Users/Actors This table provides some specific categories of information to be considered in any conceptual design as an alternative to the more comprehensive Zachman model. The table cells in blue are topical and those in black are specifics. Let's consider a few examples from this set of recommended topics. The major conceptual categories in a CONOPS are listed in the first row. The single most important conceptual category is intention. -Intention of owner / user in procuring the system -How the business makes profit -The reason for wanting to automate some aspect of the business The concept of information that the system processes or that influences the system's behavior is the next most important concept. The business aspect of information is the documents the business uses to conduct the business The data that the automation will process forms the information conceptual category of for automation And so on. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Lack of Focus In Illustrations
OV-4 Naval Command Structure JFACC JFMCC Operational Command / Control Tactical Control CSG Air Related Organizations Non Air Related Organizations Carrier Strike Group Organizations Another major conceptual design fallacy is the lack of focus. This illustration is an example we have seen before. The first version of the diagram appears to be a statement of everything the conceptual designer discovered about the organization in question. This is a common problem since it requires very little thought. The second version focuses on a single aspect of the first drawing, the fact that air related operations in the naval command structure is under dual command. Remember that conceptual designs are argumentative. To be successful, arguments must be clear and focused on the controversy, the evidence and the warrants. Dual Command of Air Related Operations What is the point? Clear Focus On Interoperability Requirement / Challenge © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies OO Versus Procedural Versus SOA…
Architecture is concerned with user interface Conceptual Design is concerned with the user’s cognitive view of his business and automation’s role in it. Orthogonal OO / Procedural / SOA are software design methods OO / SOA is about relating groups of executables Procedural is about characterizing a single executable This next conceptual fallacy is representative of unwarranted spillover of technical controversy into the world of concepts. What I am trying to illustrate is that technical controversy is almost always orthogonal to conceptual design and architecture as illustrated by the definition of these concepts I have placed on this slide. The 00 versus procedural controversy is slowly being displaced by the SOA versus stovepipe controversy in popularity today. Although cloud service provisioning versus in house service provisioning is coming up fast. When performing a conceptual design, these technical controversies are a tempest in a teapot and should be paid no attention. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Use of UML Cartoons
UML seduces SE into too much detail UML seduces SE into jargon to make the user feel stupid Software IS NOT Systems Another fallacy that derives from the technical heritage of most people benighted into conceptual design is the use of familiar technical artifacts where conceptual artifacts are needed. In this illustration we have another example from the software world. The current fad in software development artifacting is UML and its companion unified method. The problem with this fallacy is that engineering artifacts too easily seduce the SE into creating too much detail. The SE starts designing instead of conceptualizing. Similarly, engineering artifacts seduce the SE into using SE jargon instead of the user / owner oriented terminology. We know from previous discussions that this may have the effect of making the user fell stupid. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Use of UML Cartoons - Aggregation
Concept of Aggregation is confusing to User / Owner Part is contained in whole Concept of whole is embodied in real code Parts are real, whole has no separate existence Concept of whole has no real manifestation VS Let's consider this UML example further, namely the difficulty of the user community dealing with the notion of aggregation. In this slide we can see how the notion of UML Aggregation can be very confusing for a user / owner to comprehend, yet it is a central concept in UML. Further Information: INCOSE Insight, Volume 7, Issue 2, July 2012, Semantic Dictionary and Concept Model, Michael Dickerson, David Oliver and Joseph Skipper © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Use of UML Cartoons - Generalization Classes have attributes (data) and methods (executable code) Notion of Inheritance means copy attributes and methods = shared data and code Real physical things have properties that result from their unique construction / composition Kind of does not mean inheritance. A real thing’s structure and behavior could be a result of significantly different design than a thing it is a kind of (airplane vs. car for example). VS Concept of Generalization is also confusing to User / Owner Another key principle of UML and most engineering rendering methods is the notion of generalization. This slide suggests some considerations for a technician to consider when trying to express technical notions in the conceptual domain. As illustrate, some technical concepts do not map at all into the business conceptual domain. The reference presented in these last two slides deals with this topic in more detail. Further Information: INCOSE Insight, Volume 7, Issue 2, July 2012, Semantic Dictionary and Concept Model, Michael Dickerson, David Oliver and Joseph Skipper © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Ontology – Another Confusing Concept Is addressed by Stakerholder Concern Viewpoint Has a Represented by specific Uses to evaluate CONOPS Views Rendered / addressed by specific Here we address another popular technical concept that is fallacious when used in operational conceptual design. Ontology / Semantic Web... are all technical concepts that address machine "understanding" and "conceptualization", usually in reference to information search / retrieval. This drawing presents an example of an Ontology, one that is very much like a conceptual data model. What makes this a particularly attractive fallacy, is that it deals with concepts and relationships among concept. So it should be applicable to conceptual design, no? NO! Products / Model Structured, language-independent network of concepts for a Particular domain and / or its subset © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Ontology – Another Confusing Concept Arcane way to define user interface and behavior Another fancy word to make users feel stupid Systems don’t do semantics, they can only poorly simulate semantics Concentrate on the users’ operational model of the problem domain and related metaphors Understand the user’s operational model Architecture should match this operational model The user, not the system, brings meaning to the system Here is a list of arguments that support: No, ontology is not an appropriate conceptual modeling tool for operational conception designs. Review each bullet point since it is well stated on the slide. © 2012 Joseph F Iaquinto, PE

Common Conceptual Design Fallacies Reuse – Is It Worth The Expense?
The Hype of Reuse Reuse is cheaper Reuse reduces testing Reuse is easier than building your own Reuse can be: Fine grained Medium grained Large scale Reuse is consistent with line by line coding The Reality of Reuse Reuse is more expensive Using = understanding complexity Making = building generality Can you trust a reused concept? Reuse requires extensive study, fixing misunderstanding Reuse should be large scale only: JTF, GIG… Otherwise too costly. Yes, conceptual design should include development system implications. Line by line is no longer necessary The final technical concept that leads to fallacies if applied to the operational conceptual design domain is that of reuse. Reuse today is both openly discussed and disguised in a wrapper called SOA. Let's review the claims and refutes on this slide, one by one. © 2012 Joseph F Iaquinto, PE

Big Failure Modes – Systemantics Defined
Systemantics, The Underground Text of System Lore, How Systems Really Work and How They Fail, John Gall, ISBN: or –1-1 Motivation Recognize when a problem is a manifestation of the incumbent system and not innate How to do no harm – Oh Yea? Thought provoker when doing system level FMEAs Do not panic, its all a joke All system engineers should read John Gall. This book, referenced on this slide, documents the really big failure modes of systems — many of which have to do with conceptual design. I will not address all of the failure modes John discusses, but I will cover a few of my favorites. From this sample you should be able to develop your own compensatory methods. Review the bullet points under motivation. © 2012 Joseph F Iaquinto, PE

Big Failure Modes – Systemantics New Systems Mean New Problems
New system means a new entity to be dealt with Maintenance Energy supply… Existing systems feel the impact and require different attention System of systems: what if our trading partner sends us bad data? This is a particularly well know failure mode of systems, but one that is universally ignored. Here are some compensatory ideas. When you construct a conceptual design, make sure you give due consideration to what effects the system you are trying to define at the conceptual level will have on its environment (built mostly, but natural as well) and create concepts to compensate. You may need to specify capabilities whose sole purpose is to mitigate the new problems that you expect will be created by the operational changes that are your goal. The last bullet on this slide is a warning to those of you involved in SOA!! © 2012 Joseph F Iaquinto, PE

Big Failure Modes – Systemantics
Big Failure Modes – Systemantics Systems Tend to Expand to Fill the Known Universe All engineers are optimists; thus, they underestimate the concept If a system is useful, it must be “enhanced” to add forgotten and new capability Systems expand and encroach (IRS example) Once institutionalized it is hard to terminate a system Here are some compensatory methods to help deal with the blob effect. When creating the conceptual design of a new system, be quite deliberate about creating not only adaptability into the system, but also a limit to its growth. When creating the conceptual design of an enhancement to an existing system, study whether you should be enhancing the existing system, replacing the existing system, or creating a new complementary system rather than enhance the existing system. When creating the conceptual design of an enhancement to an existing system, carefully consider retiring behaviors and information from that system as a part of the enhancement. In other words, can the system be reduced in size or functionality as a result of changing operational needs? So you many (or most likely should) need to specify what capabilities need to be removed from a system in the CONOPS and discuss why, operationally, this is justified. You may need to write scenarios that permit discussion of how the system will support operations after the prescribed reductions as well as the desired additions. © 2012 Joseph F Iaquinto, PE

Big Failure Modes – Systemantics
Big Failure Modes – Systemantics Complex Systems Exhibit Unexpected Behavior Systems display antics This effect is compounded by multiple “designers” and “users” Unexpected ways to fail (Unintended consequence) Unexpected ways to operate (functions not designed in but require maintenance and extension) This failure mode was the genesis of systemantics. Unintended consequences are sometime the result of inexperience or of a lack of sufficient industriousness in analysis. While performing your scenario analysis be sure to take the effort to ponder and identity potential consequences of your proposed changes to the system. In addition, if you lack the necessary experience to deal with this situation, find someone who does and recruit their assistance. It is essential, even at the conceptual design level to perform Failure Modes and Effects Analysis. This is nothing more than a structured process for identifying ways in which the system under definition can fail due its design. Address both top level effects of failures of proposed capabilities as well as top level effects of combinations of capabilities that result in un-intended capabilities. © 2012 Joseph F Iaquinto, PE

Big Failure Modes – Systemantics Systems’ Do Not Naturally Scale
? A Large System, Produced by Expanding The Dimensions of a Smaller System, Does Not behave Like the Smaller System Adding more system resources to overcome performance problems frequently makes problem worst Hardware is cheap is a major trap to the unwary engineer This systemantic failure mode is particularly important in any conceptual design effort that involves reuse of existing systems and system components. A system can experience behavioral changes when its "dimensions" are scaled up or down. A classic example of this is aircraft. Either completely avoid conceptual designs which specify scaling or perform considerable analysis to predict the effects of the scaling on both the system and its environment. If the objective of the conceptual design is to improve performance of an existing system, be very careful to perform an analytical / simulation investigation of the factors of performance for the existing system. This will provide a rational basis for the conceptual changes you propose in order to improve performance. Perform an analytical / simulation investigation on the proposed system to evaluate how the performance change reflects your original goals. The more analytical you can be the better the chance that the proposed changes will produce the desired change in performance. Question all conceptual design assumptions with regard to scalability and make sure you have a valid and correct argument to support your claim that you have properly scaled the system. © 2012 Joseph F Iaquinto, PE

Big Failure Modes – Systemantics Countering them with FMEAs
Clearly all failure modes, including the really big ones must be addressed. The common method for eliminating failure modes is a process known as Failure Modes and Effects Analysis or FMEA. This is an example of a simple, hardware FMEA. One can extend this analysis to any level of abstraction. © 2012 Joseph F Iaquinto, PE

A Process for Defining a CONOPS
Session 3 A Process for Defining a CONOPS In the next 4 sessions we will walk through a recommended 5 step process for conducting a conceptual design as applied to the operational conceptual design. The main objective of these next 4 sessions is to provide you with a set of detailed tasks or checklists that you can follow or tailor to produce a CONOPS. In this session we will deal with the most important and difficult task in operational conceptual design, the discovery and development of basic concepts. © 2012 Joseph F Iaquinto, PE

Topics of Session 3 The Process for Defining A CONOPS
Develop the Basic Concepts Define the Problem Define the Roles and Responsibilities Define the Business Events Define the Representative Scenarios Define the Operational Capabilities Verify and Validate CONOPS Document CONOPS Some Useful Heuristics These are the topics in this session starting with discovery of the problem. © 2012 Joseph F Iaquinto, PE

Develop Basic Concepts Relationships of Fundamental CONOPS Concepts
Business Problem Leads to Facilitated By Causes Intention Activities (Scenarios) System Under Definition Provides Used By Executed By Roles Operational Capabilities There are 6 classes of concepts that make up an operational conceptual design or CONOPS as illustrated in the slide. The problem can be defined in terms of each of these concepts. "Intention" refers to the business intention behind the operations without regard to the automation. That is to say, why we are engaged in this enterprise AND what we hope to gain by commissioning the construction of the system that forms the subject of the CONOPS. "Activities (Scenarios)" refers to the business activities or processes that are either currently conducted in the execution of the business or are anticipated to be those activities conducted once the system is available. The "Roles" conceptual category refers to the business executor roles who execute the abovementioned Activities whether or not their efforts are to be augmented by the system. "Information" is the information needed and produced by the aforementioned activities. In most cases this information is embodied in documents, both paper and electronic. "System Under Definition" is the subject of the CONOPS. It may include only the envisioned system or both the envisioned system and the incumbent system (especially if the envisioned system is a modification of an incumbent systems). The "Operational Capabilities" conceptual category refers to the ways in which the system will enable the roles in their execution of their activities. Utilize Information © 2012 Joseph F Iaquinto, PE

A Process for defining the CONOPS

Define The Problem In Business Terms The Single Most Important Concept
Understanding the business and how it makes money / profit (the value chain) is the single most important activity in creating any conceptual design, especially CONOPS. The problem statement must be made in this context. The problem statement can only be understood in this context. Essentially we need to understand how the business conducts itself, how it measures its success and what business goal is motivating the creation of a new system or system modification. © 2012 Joseph F Iaquinto, PE

Define The Roles and Responsibilities
How is the business organized? What are the roles that categorized what the people do? What are the business activities executed by the people? What skills are implicit (or explicit) for each role Elaborating upon the topic of understanding the roles, we find 7 sub-topics that need to be addressed. The first sub-topic deals with the first level of clustering of roles into business units as well as both the formal and informal relationships among these business units. The second sub-topic looks into each of the role clusters and defines what each role within each organizational unit is in terms of what the people who occupy the role do to execute the business — what are their business goals and objectives. The next sub-topic complements the definitions of the roles by elaborating the activities these roles are responsible for execution as well as any measures of quality. The last sub-topic on this slide further decomposes each role into a set of skills that must be available within the business context of the role. © 2012 Joseph F Iaquinto, PE

What is the relationship between the tasks and the activities? What is the World View / Concepts of the business and how the system works from the viewpoint of each role? What are the relationships among roles and locations? Continuing from the last slide, the next sub-topic defines the relationships between the tasks and the activities that are conducted by the business. This is to say, what tasks do each of the aforementioned roles execute in their performance of the activities of the business. The second sub-topic is very language oriented. Each role, in fact each person, has a mental model of both the business and their role in the business. It is essential that these mental models be understood for each role, but also for all of the influential (formal and informal) individuals in the enterprise. Most often, the geographic dispersal of roles is important in forming and understanding operational concepts. Thus, it is essential to model the roles by location and the relationships among roles at a location and between / among locations. © 2012 Joseph F Iaquinto, PE

Beware of what people tell you! There is a propensity amongst the inexperienced to simply ask people what their roles are what business functions they perform and what mission do they support. Information collected from this activity can be useful, but it is also very misleading. Focus groups, IPTs and interviews are no substitute to observation, logic and experience. They are frequently are the cause of complete failure of the conceptual design process. © 2012 Joseph F Iaquinto, PE

Define The “Business Event”
Business Events Are Central to Creating A CONOPS Therefore we are going to spend a great deal of time elaborating the concept of the business event. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Exploitation of Business Events and the CONOPS
People live in the business world and respond to business events, not the technical world Business events being the initiator of business processes can serve as a conceptual anchor Business events require an understanding of the intention of the business before the business reaction can be understood Business events are the wellspring of the concepts needed for the conceptual design Business events can be exploited as a major source of the information we need in order to create and document a CONOPS. Business events serve as a conceptual anchor through out this entire process. Our analysis of business events and business reaction to these events requires that we understand the intention of the business. Yes, we must create, or conceptually design a CONOPS before we document it. As in all written activities the act of documenting will invoke our reflective loop with the resulting refinement of the conceptual design. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Definition
What are the business events Identify the business transactions Look for transaction “initiators” Remember to include all “exceptions” Induce “representative” transactions Understand the importance of the transactions in running the business Once we understand the people involved in the enterprise we can turn our attention to the business events. The best starting point to identifying the business events are the business transactions. Business transactions are better known to both the people who execute the business as well as their customers. For example, mention banking and the transaction "deposit check" quickly comes to mind. For our toy example, one transaction is "mow the grass". Once the transactions are listed, one can begin to look for the initiators of the transaction. These are candidate business events. From our toy example, the transaction "mow the grass" is usually initiated by an event such as "grass becomes over 4 inches long". Frequently overlooked are the business events that deal with exceptions. In most businesses these exception related business events drive most of the effort in the business. From our example, one such exception could be that the "mower stalls". If the number of transactions becomes onerous (say more than 6), it is advisable to induce representative transactions. The "deposit check" example cited earlier is really this kind of representative or categorical transaction. For each transaction or group of transactions it is important to reason about the importance of the transaction from the business execution standpoint. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Use Business Language to Name Events
How are they conceptualized by the business execution folks Language Nomenclature Metaphors Relationship to division of labor Relationship to information Relationship to location Here are some rules for defining business events so that they are business oriented. By definition, business events must be business oriented as recognized by the business execution folks. Use the language of the business in defining business events. Business events nomenclature frequently relate to the division of labor, for example the organization accounts payable respond to the payment request event. The business nomenclature for information and locations is a source of business event nomenclature. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Understanding How Business Reacts to Events
Discover the artifact driven reactions Interviews (caution) “Time and Motion Studies” i.e., observation Benchmark (study competitors) Read the literature Certain business reactions are artifact driven. That is to say the reaction to the business event is limited by technological, political or cultural bias. The methods of business event reactions listed on this slide are all biased to providing artifact driven business event reactions. We have already discussed the limitation of interviews. Nearly all people who execute the business processes of the enterprise have a world view that is conditioned by the artifacts associated with their day to day life. Time and motion studies (observations) observe the enterprise execution within the context of itself, not in any desired or future context. Another way to identify artifact driven reactions is to study competitors and how they react to business events. Frequently the reaction processes of competitors will be significant different when they are artifact driven and remarkably similar when they are innate. This is a method the Romans used to formulate their theory of natural law. If the industry has been written about, which is quite common, the literature serves as another means of identifying business reactions that are artifacts of technology, etc. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Understanding How Business Reacts to Events
Discover the innate reactions Analysis (Critical Thinking) of artifact driven reactions Inductive reasoning based on Benchmarks Interview domain experts Historical analysis (how was it done in the past) There are a number of ways of discovering innate business reaction concepts. We have studied (or at least introduced) CT. By applying CT to business reaction descriptions, one can separate the innate behaviors from the artifact driven behaviors. For example, one can apply inductive reasoning based upon a set of benchmarks. In other words by documenting a set of business event reactions from different benchmark organization, one can induce what is innate in these business processes. In all domains, there are experts who have contemplated the domain to the point of understanding what is artifact in established practice and what is innate. These people can help establishing innate reactions. Some business types have been in execution for a very long time. By studying the progression of business event reaction tasks through time, one can often establish innate business processes from those that are the result of artifacts. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Examples
A business event is something that happens in life that forces the business to respond (stimulus / response) Wind tears a house’s siding off A UFO enters protected airspace A grocery shopper arrives at the checkout station with a basket of groceries The F16 will not start A teenager arrives at the DMV counter seeking a driver’s permit This slide restates the definition of the business event and provides some toy examples. The business event is the stimulus that causes a response from the business. These examples address a variety of business situations. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Relationship of Business Events to Roles & Information
People live in the business world and respond to business events, not the technical world The business events and business responses are people’s areas of expertise The business events and business responses tend to be innate (NOT ALWAYS) The people who respond to the business event define the CONOPS “roles” The information used by the people who respond to business events define the CONOPS “information” A study of business events is the primary means by which the SE establishes the business roles and the business information which form two of the most important topics in the CONOPS. The business executors respond to business events and are relatively insensitive to the technical world. Business events and the responses people make to them reveal their areas of expertise and suggest role definition. The best guidance we have for identifying what is innate in the business is observing the business events and the applicable business response. However, this must be studied critically since artifacts do exist at this level of abstraction in the business. The roles we define in the CONOPS should abstract the people who respond to business events and the nature of their responses. The business information we define in the CONOPS is derivable from an abstraction of the information people use in their response to business events. © 2012 Joseph F Iaquinto, PE

Define the “Business Events” Business Event ≠ Technical (system) event – Example 1
A customer goes to the bank to withdraw money A customer inserts their ATM card into the ATM card reader This slide provides a word of caution. Business events are not the same thing as a technical or system event. The event on the left is a business event. The event on the right is a system event that is heavily laden with artifact related to the ATM. Failure to recognize this will lead to systems that are not useful to the business community. ≠ © 2012 Joseph F Iaquinto, PE

Define the “Business Event” Business event ≠ Technical (system) event – Example 2
A dangerous vessel of unknown intention comes too close to a protected ship A significant sonar signature occurs on a protected ship Here is another example of a business event as contrasted to a technical or system event. This is another reason that UML scenarios are not appropriate in the context of a CONOPS. UML scenarios are at too technical a level of abstraction and can too easily seduce the SE into confusing technical events for business events. ≠ © 2012 Joseph F Iaquinto, PE

Define the “Business Event” The Description
Change Business Tempo New Information Demand A Response Abstract Business speak The ability to recognize or formulate business events is critical to success in the production of the CONOPS. Here are some tips that can be useful in recognizing a business event. First it must be at a level of abstraction consistent with executors of the business understanding its definition and description. Similarly, it must be in business speak, not techno-babble. There are three parts to a properly formed business event description. The first part is a Change in some aspect of the business that occurs at business tempo. This change, of course, must be of significance to the business, but also it must be of significance to the motivation driving the CONOPS. The change must bring with it some New Information that is significant to both the business and the motivation driving the CONOPS. Finally, this Change must demand a response from the business, usually involving some processing and transformation of the New Information. © 2012 Joseph F Iaquinto, PE

Define the “Business Event” Potential sources of business events
External Customers Government Trading Partners Advisories Internal Use this category carefully (1000 person company rule) Analyze decision making results Temporal Usually derivable from an External Source Business cycle (end of period accounting) Technical cycle (machinery / production / …) This slide suggests some potential sources of business events. External sources include such entities as: Customers (place order), the Government (legal regulation), Trading Partners (responding to previous requests, sales calls), and Adversary (competitive product introduction...). Internal sources are actually less reliable for defining events, but could still prove useful. Remember that an organization, once it reaches 1000 employees, no longer needs input from the outside. It is better to observe than it is to ask. Therefore, it is best that we observe the business operations especially the decision making. The passing of time is another source of event data. Temporal events are usually imposed upon the business by external source, but not always. Business and technical cycles are frequently a source of business events. An example is the end of an accounting period as imposed by the IRS. The example of a technical cycle may be an annual model changeover in the car business. © 2012 Joseph F Iaquinto, PE

Define Representative Scenarios Purpose of scenarios
Representative scenarios are carefully selected to represent the “important” activities of the business Scenarios frame the problem or issue being addressed by the development effort Scenarios permit us to explore alternative “futures / solutions” Scenarios are conceptual -> can be used to challenge currently held concepts Scenarios draw the “stakeholders” into both the problem definition and the proposed solution Scenarios form the basis of analysis for CONOPS. One must carefully select the representative scenarios to represent aspects of the business that are important from the standpoint of the system under definition. The scenarios must cover all aspects of the CONOPS intended for the system under definition; thus, it frames the problem. This is perhaps the most important use of scenarios, to permit the exploration how the system under definition can facilitate the business. Scenarios are themselves concepts. Scenarios must engage the business stakeholders in the process of problem definition and system definition. © 2012 Joseph F Iaquinto, PE

Define the Representative Scenarios Problem of defining scenarios
Select scenarios that permit the identification of all of the operational capabilities of the system. The main problem in constructing scenarios is insuring that all of the operational capabilities that the system under definition must manifest must be covered in the set of all representative scenarios. If you must, cheat so that this happens. © 2012 Joseph F Iaquinto, PE

Define the Representative Scenarios The solution to defining scenarios
Define a scenario for each Business Event. When sequences of Business Events are important, include in the definition of the scenario the accommodation of these sequences. Remember rainy day business events and sequences of business events Insure all roles, activities and information elements of the CONOPS are addressed The best way to insure you have covered all of the system behaviors in your representative set of scenarios is to insure your scenarios can accommodate all of the business events of interest. Start by defining a scenario for each Business Event. Define scenarios for all significant (have significant consequences) rainy day scenarios and their resulting business events. Check your work by insuring that all of your previously defined / discovered roles, business information elements and activities are addressed or are part of at least one of your representative scenarios. © 2012 Joseph F Iaquinto, PE

Define the Representative Scenario Characteristics of a good scenario
Tightly woven story based upon the interaction of a few critical operational concepts Tool to allows business domain experts to express / envision how the business will change as a result of the system’s existence Tool to allow business “roles” to rehearse their jobs in the proposed future (while it is still very malleable) Here are some guidelines for writing effective scenarios. Limit the number of operational concepts you mean to explore in any one scenario. One concept are best, a few critical ones are maximum. The viewpoint and language of your scenario must encourage the business domain experts (business executors) to place themselves into the scenario to the point where they can envision from their worldview exactly how the system would change the business. The description of the participation of the business roles in the execution of the business given the system exists must be of sufficient fidelity as to allow business execution personnel to rehearse their roles in the context of their contemporary roles. This should be of sufficient fidelity as to permit active participation of business executors in evolving the scenario. © 2012 Joseph F Iaquinto, PE

Define the Representative Scenario Scenario warning – Repeated!
A conceptual scenario is NOT a software (UML) scenario or use case! Different Motivation Different Level Of Abstraction Different Viewpoint As software intense systems have come to dominate complex system design, we find more people entering System Engineering with a software background. This has created a problem since these people do not have the SE experience necessary to see why their SW development methods and tools are no longer appropriate. Thus, I am repeating this warning directed at SW engineers who are relatively new to SE. Using UML scenarios in place of SE scenarios will always lead to failure in the CONOPS. © 2012 Joseph F Iaquinto, PE

Define the Representative Scenarios Scenario writing rules
Write a story in English prose Avoid technical jargon Use business jargon Avoid technical specification - ese Write the story about the business, but highlight the execution of the business Keep the owner’s perspective Describe the business tasks, roles and responsibilities Provide necessary background information Keep your discussion of the system abstract and in business execution and profitability terms Don’t forget the rainy day aspects of the scenario Sell, sell, sell! There are four primary rules to follow when writing scenarios. First, tell a story. Every scenario is a short science fiction story. You should make your story both captivating and entertaining. Second, explain how the business will be influenced by the new system. Third, the language of the story should be from the problem or business domain, not technical. Address business concepts that are of interest to your targeted stakeholders, for example profit. For government work you will need to use your best CT skills to define profit. Fourth, you are describing a real world possibility. Therefore, you must account for rainy days in your story. © 2012 Joseph F Iaquinto, PE

Define the Representative Scenarios Scenario example
Automotive Radio System The modern automotive driver has a challenging workload. Usually faced with heavy traffic, the driver has to be alert to many threats and continuously deal with them. When navigating to a new location, the driver has the additional task of identifying waypoints and taking appropriate action at each. The operation of the vehicle’s entertainment system compounds this workload problem. Each year, thousands of deaths and injuries together with millions of dollars in property damage is directly attributable to the consequence of this workload on the driver. To address this situation, an entertainment system remote control system is proposed. While operating the vehicle the driver can make mode selections, station selections, volume adjustments, and quality of sound adjustments without removing his hands from the vehicle’s controls or his eyes from the road. In addition, these entertainment operations will require no more than a single hand or finger motion for each adjustment. This system is not intended for a deaf driver or one who suffers from numbness of the fingers or hands. This is an example of a real scenario taken from a CONOPS written by the Ford Motor Company. Notice how it satisfies all of the rules just discussed. Also notice that it is fair to discuss the business problems we are addressing in the context of a scenario. © 2012 Joseph F Iaquinto, PE

Behavioral Requirements
Define the Operational Capabilities Operational Capabilities Flow From Scenarios ... Scenario Behavioral Requirements Representative scenarios are not only useful to engage the business executors in the system definition process; they are also useful in guiding the derivation of the operational capabilities. One can directly infer both constraints and behavioral requirements from scenarios. The behavioral requirements can further be elaborated into functional requirements. This approach assures that the operational requirements you derive are justified in terms of the original problem set. Functional Requirements Constraint Requirements Functional Requirements Functional Requirements © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities A Three View Model of Operational Capabilities
Structures Functions Behaviors This slide illustrates the views that need to be constructed into the operational requirements. Generally, operational requirements need to be defined by constructing three views of the requirements: the structural, functional and behavioral views of the system under definition. The structure view defines the parts of the system that are sensible to the enterprise executors. From our toy example, structure would be the Automower, its blade, a battery and others. The function view defines what the system is to does from the viewpoint of the enterprise executor. For our toy example this would be cut the grass, change the blade, charge the battery, etc. The behavior view defines when and how the system manifests its functions from the viewpoint of the enterprise executor. For our toy example this would be "charge the battery after each use", etc. © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Definition of the three views
Where are activities “physically implemented? What does it do? When and how does it perform its function? This slide summarizes what we just discussed regarding the 3 view of the operational requirements. We will now discuss a set of guideline to aid in the construction of each view. © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Operational Capability Structure View Guidelines
Where activities are physically implemented Frequently (and incorrectly) considered the “Architecture” Generally presented as annotated (noun phrase) block diagrams From business viewpoint Engineering Planning Department vs. Map Server Accounts Payable vs. Oracle Server Express structure only to define or explain basic concepts One can think of the structure view as where the functions are physically implemented. It also consists of the relationships among these structural parts. This set of boxes and lines is sometimes mistakenly called the "architecture“. It is not. The language used in the structure view is, of course, taken from the problem domain, in other words the business domain. This is a conceptual design; thus, do not be too specific in your use of language. The structure is to be expressed in basic concepts. © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Operational Capability Function View Guidelines
What does it do? Generally presented as descriptive or prescriptive verb phrases Can be supported by block diagrams to show functional relationships (usually temporal or combinatorial) From business viewpoint Retrieve Map vs. Query Map Database Identify customer vs. Enter Customer Query Functions are highly conceptual for a CONOPS Part of DODAF Architecture Model (OV-5, SV-4, SV-5) The functional view presents a picture of what the system is supposed to do, of course from an operational or business or user centric viewpoint. You are all familiar with the cryptic verbal phrases used to express functions? Just remember the language needs to be the business language. It is always a good idea to graph the functions. Never forget that this is conceptual and not a system design! Although this view is less likely to be confused with architecture, it should be noted that it is not architecture. It is part of a real architecture © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Operational Capability Behavior View Guidelines
When and how does it perform its function? Generally presented as conditional phrases Should be supported by specialized block diagrams (state charts and state transition diagrams) From business viewpoint When beginning an Operations Plan vs. When the Ops Plan button is pressed When the customer asks to place an order vs. When the customer order entry from is submitted Behaviors are expressed as business concepts for a CONOPS Behaviors serve to organize functions by intended use / business event Part of DODAF Architecture Model (OV-6, SV-10) If one were to rank views by their importance, this is the most important one for operational requirements. This view is generally expressed as conditional phrases: "when the blade is dull, the operator will change the blade". The graphics used to illustrate behavior is rather specialized, and generally not accessible to business execution personnel. Nevertheless, there are circumstance in which it is desirable to prepare statecharts or sequence diagrams. The conditional phrases must be in business language. The behavior express in this view are always conceptual and expressed in terms of business concepts. Behaviors are categories for clustering operational functions. Frequently these categories are based upon either intended use or business events, but they may have other basis. © 2012 Joseph F Iaquinto, PE

Behaviors serve to organize functions by intended use / business event
Define the Operational Capabilities Behavior – The Mysteries of States and Modes Behaviors serve to organize functions by intended use / business event Behaviors can have names Behaviors can associate hierarchically A named behavior is a Mode A named child or sub behavior is a State This 2 level hierarchy is sufficient for any CONOPS! Behaviors are used to cluster functions. Behaviors in turn are clustered. The first level of clustering or refinement is Mode. A mode may contain one or more States. States are conceptual. The State is the second level of clustering or refinement. A state can contain one or more Behaviors. Two levels of abstraction are all that are generally needed for a CONOPS © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Behavior - An example of Modes and States
Command Communications System Normal Operations Mode Crisis Operations Mode Disaster Recovery Mode Most people have a little difficult understand states and modes. This diagram provides an example that is actually pretty canonical. Walk through the 3 levels of the diagram. Attack Classification State Repel State Resource Recovery State © 2012 Joseph F Iaquinto, PE

Resource Re-Allocation
Define the Operational Capabilities An example of States and Modes - Functions Repel State Retrieve Attack Specific Operations Plans Allocate Resources According to Plan Employ Resources In this example we see how functions can be clustered into states. Locate Available Resources Analyze Impact Of Resource Re-Allocation Re-Assign Applicable Resources © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Initial Conceptual Design Always Requires Refinement
Refinements CONOPS Goals Conceptual Analysis The initial conceptual design is probably only 50% correct. Curing this problem requires a deliberate, thoughtful and experience based refinement in order to raise its correctness to acceptable levels. This requires a clear definition and understanding of the goal or goals we had in mind when we postulated the need for the system we are attempting to define in the CONOPS. It also requires the willingness and the mental agility to invent refinements based upon a rational (that CT thing again) comparison of the original goals to the results of our conceptual analysis. This refinement loop should be executed until the correctness of the CONOPS is within acceptable levels within the context of available resources. A possible outcome of this refinement is the termination of the entire effort to acquire the system under definition! Always be sensitive to this eventuality and have the courage to make the appropriate recommendation supported by analysis. Some Checklists © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Basic Concepts Checklist
Metaphors make sense to users Language understandable to users Users believe goals accomplished The SE cannot be referencing the user community continuously during the conceptual design process; thus, the SE can develop a language disconnect with the users. Some language disconnects cannot be recognized by the user until the complete conceptual design is available for review. The SE may not completely understand the usage of metaphors in their natural environment. Thus, the business execution community or users must aid in the evaluation the appropriateness of the use of metaphors and language in general in the conceptual design. Perhaps even more importantly, do the users believe that the goals they have are met with the operational conceptual design prepared by the SEs. Compounding the last point is the fact that a proper CONOPS does occasional change the business process, the roles, the information, etc. This may cause change resistance from the user community who almost by definition have a limited imagination. Thus, checking for goal accomplishment may require prototyping and time-and-motion studies. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Representative Scenarios Checklist
Correct Each scenario is acceptable to users Inappropriate artifacts eliminated Innate characteristics are consented to Complete set All Business Events Handled All Applicable Scenarios Present Users believe they can execute scenarios Users have walked through each scenario Users have confirmed proper handling of business events Another cornerstone of our operational conceptual design are the representative scenarios. The slide contains a checklist for you to use to insure you have a good set of scenarios. Each of the representative scenarios should be correct according to the users. As a set, the representative scenarios should be complete. It is especially important to have the user community validate the postulated set business events. It is a very common situation that all of the business events are not known to an enterprise's business and line management. If possible have the users walk through at least the key or most important scenarios with a mockup of the system under definition present to support the CONOPS. Use of simulation modeling as well as prototyping tools should be considered. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Operational Capabilities Checklist
Understandable Users understand what, where and how new business process will work Users understand capabilities metaphors Correct Users understand how system works Users agree that capabilities benefit process No unacceptable unintended consequences Complete Users can accomplish intended use with these capabilities We need to do a similar analysis for the operational capabilities. The operational capabilities are stated in the user / enterprise executioner's language (including metaphors). This must be tested with the participation of the user. More importantly, the users must recognize the utility of the capabilities in the context of their current and new business processes. A recommended correctness test is listed on the slide. Again, all of this must be tempered by the fact that the user's may be troubled by change itself, and one must gauge their response accordingly. Bottom line, can you convince the users that they can accomplish their intended use? Corollary — did you consider all of the intended uses when formulating the conceptual design?!? © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Checklist to insure topical coverage
Emergent capabilities analysis System capabilities stated in business terms Analyze combinations of interconnected system capabilities (Aggregate Business Objects identified) Analyze new capabilities and their relationship to the interconnected system capabilities (Data Transformation) Analyze correctness of description of individual behavioral contribution to expected aggregate behavior Insure that sufficient maintenance scenarios exist to avoid system failures that result from subsystem maintenance Insure that sufficient legal and accounting scenarios exist Ensure complete coverage of all aggregate capabilities Here is a checklist you can use to insure a CONOPS that is interoperability & integration significant has been correctly formulated. Review each point with the students. Emphasize the fact that any CONOPS that defines systems with significant interoperability & integration content must contain scenarios that address the maintenance of the sub-systems. There may be an intended use of the system that consists of provisioning behavior to other systems. If this is the case, scenarios that address this situation (provisioning of behavior) must to be added to the set of representative scenarios © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Problem Solution Checklist 1
Compare As-Is with To-Be Select significant business events Select interesting anomalies Quantify process improvement and compare to goals ROI Computations Socio-political “profit” Popular social issues Environment Public safety This slide presents a specific checklist for refining scenarios to insure the process improvement desired is achieved. Since an improvement over existing practice motivates the construction of the system, a side by side scenario comparison is indicated. The CONOPS must document specific goals and objectives for process improvement. It must also contain rationalized estimates of the performance gains expected from the documented scenarios. This must include an argument about the ROI improvement. It must also include the socio-political profit which may be a more important intention than any financial gain. The slide lists some example topics. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Problem Solution Checklist 2
Provide adequate justification for process changes? Operational Capabilities defined sufficiently to prove process improvements Discussion of cost of Operational Capabilities as appropriate Solve the business problem Do the Operational Capabilities still solve the business problem Have they introduced new business problems This slide presents a specific checklist for refining operational capabilities to insure the process improvement desired is achieved. The CONOPS must offer arguments that support the assertion that the required operational capabilities are necessary and sufficient to provide the intended process improvements. Discussion of actual costs of implementing the proposed operational capabilities and the expected process cost savings may be appropriate in limited circumstance. Rather, the focus of the argument should be how the proposed operational capabilities solve the business problem for which the system under definition is being procured. Most important, but often forgotten the analysis of the preliminary operational capabilities is what new business problems are addressed by these new capabilities. Conceptual FMEAs are a must to insure all significantly undesirable consequences have been compensated for. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Unintended Consequences Checklist
Check for them with process FMEA Define Unintended Consequences to avoid Search top down for them Search traditional bottom up for them Eliminate them with process re-engineering Leverage experienced users to detect them Solicit history of Unintended Consequences Define severity of Unintended Consequence Have them check your work Now that we have opened Pandora's box, lets consider a checklist for identifying unintended consequences our CONOPS may have in achieving process improvement. A conceptual process FMEA is essential to this effort. All SEs should be very skilled and productive in the art of conceptual system and conceptual process FMEAs. Not only should the FMEA be conducted in its traditional bottom up direction, but also in top down direction. Particularly scary unintended consequences should be searched for explicitly. Tell story of Ford EcoStar fire. Do not ignore the results of your process FMEA. Both postulate and execute conceptual compensatory actions. Experienced users can be of assistance, but they are not replacement for good engineering practice. Remember you, not the user are responsible for achieving the intended use of the system. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Security Checklist
Scenarios Vulnerability analysis (Conceptual FMEA) Policy conformance Operational Capabilities Certification implications Structure Functions Behaviors Vulnerability analysis (Design FMEA) Incident response capabilities present and adequate Once again, one can identify refinements based upon a study of the scenarios and operational requirements against the intended use. Yes, process and design FMEAs are again a very valuable tool for refining the CONOPS, this time for security consideration. Too much attention is paid to security policy and standards document management. Too little is paid to actually performing the analysis. Recall that the essence of security is: - Availability of resources when needed Privacy of information associated with resources If your system is to be subject to a certification process, then the operational capabilities must be examined in depth and refined appropriately to insure success of certification. Realize that certification and operational security are not the same thing, so both analyses must be performed. Make sure that scenarios and resulting operational capabilities whose purpose is to provide incident response are present and effectively defined in the CONOPS. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Reliability, Availability, Safety, Maintainability Checklist
Scenarios Reliability Threads Performance Metric Definition Business process oriented – NOT technology oriented System level FMEAs Reliability / Availability / Maintainability System level Safety Analysis (cousin to FMEA) Operational Capabilities Design FMEA Design Safety Analysis Design Maintainability Analysis Design Performance Analysis Maintainability Capabilities Yes, RAMS is very much related to security. However, a separate analysis is needed to cover the topic adequately. Essential to success in this area is the definition of RAMS objectives. These must be selected and defined in the CONOPS and justified in terms of the intended use. Yes, yes, the value of the FMEA method is again apparent. You should be noting a pattern in these slides. The pattern is perform analysis of anything that is important to you or your customer, in addition to any analysis that needs to be preformed to conform to established practice. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Political Concept Checklist
Scenarios Clarify Roles and Responsibilities (OV-4) Understand traditional (As-Is) situation Understand required political changes Share with all affected organizations Respect, record and address turf / NIH / power issues Operational Capabilities Traditional (As-Is) provisioning Where does the information reside Where does the structure reside What is the profit to provision operational capabilities What is the cost of provision operational capabilities In some contexts, conceptualization about political objectives is the single most important activity in producing a CONOPS. The checklist on this slide for both scenarios and operational capabilities should cover most situations; however, you need to be sensitive to and address specific political factors in both the business you are building the system for and the business that will be doing the building. It is possible the business that will be financing the system needs to be accommodated as well. Remember that all new systems or modifications to systems exist to facilitate human enterprise. Thus, it is inevitable that they will cause political change. The CONOPS should address this explicitly and discuss compensatory actions in both the scenarios and the operational capabilities. © 2012 Joseph F Iaquinto, PE

Your role in this is professorial
Document CONOPS Remember that the design has been completed, your job now is to present the results to both the business and development communities Your role in this is professorial We have arrived at the last step in the conceptual design process. Basically, we have to re-cast our conceptual design into a form that is both self explanatory and accessible to others. The "others" are a spectrum of stakeholders from business executors to design engineers and technicians. Your job in documenting the CONOPS is not that of a simple scribe. Your job is to insure that the conceptual model you have striven so hard to create is faithfully adopted by all of the stakeholders, no matter how un-informed about your effort they are. You are not simply documenting, you are indoctrinating. © 2012 Joseph F Iaquinto, PE

Document CONOPS Widely Accepted Templates
CJCSI B Appendix A to Enclosure E NASA DI-P100 Concept Data Item Description DI-IPSC Operational Concepts Desc. (OCD) DI-MCCR-80023 Concepts of Operations Document ANSI/AIAA G Guide to preparation of OCD Software Productivity Consortium SPC MC, OCD Template IEEE Std System Definition-ConOps Tenix Defense Systems Development of Operational Concepts Descriptions Here is a list of currently active and widely accepted templates for documenting System Definition CONOPS. Don't forget there is also the Military CONOPS we discussed earlier, but these do not address that class of CONOPS. Unfortunately, they are similar, but also different. Let's have a comparative look at them and define a template that is a tailored version of all of these. The IEEE standard is my personal favorite and will have great influence on our final product. © 2012 Joseph F Iaquinto, PE

Document CONOPS Crude Comparison
This chart provides a crude, but complete comparison among the various standards. There is sufficient similarity to allow one to cluster like topics within these templates into the same row. For example row 1 illustrates a common theme of Scope or Introduction — row 9 illustrates the notion of reference documents. We will exploit this commonality of themes with a proposed template. © 2012 Joseph F Iaquinto, PE

Document CONOPS Essential template
Scope: Identification System Overview Document Overview System Concepts: Intention (Intended use) Roles Activities Docs Relationships CONOPS Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Operational Scenarios: Key business events Anomalies accounted for Selected representative This slide presents a recommended essential template. It follows the IEEE template closely. The order is top to bottom, right to left. A detailed discussion of each section of the essential template can be found in the like named section of the IEEE template. The Scope section contains the usual introductory material that (1) names the business and system under definition, provides an overview of the business aspects to be effected by the system and in that context the system and finally an overview of this document. The problem description section is very business centric. It defines the business as it exists currently with emphasis on those aspects of the business one wishes to change. After first carefully defining the business context, the business problem that is the focus of this CONOPS is stated. Finally the intended solution to the business problems is stated with definitive goals and quantative objectives. Remember, this section is entirely business centric. There is exactly NO technical discussion. The third section simply lists the documents that were referenced in this CONOPS. They may be simply listed or organized in some fashion. The fourth section defines the business and system concepts, that is to say it defines the language with which the CONOPS will be constructed. The minimum essential set of concept categories are: Intention (Intended Use) — why are we writing this CONOPS Roles — what business roles are important in this CONOPS? Documents — what business documents (information) are important in this CONOPS Activities — what business activities / processes are important in this CONOPS? This is the topic in which key business events are identified. Relationships — how are the previously defined concepts related? The fifth section defines the operational scenarios that will be used to explain the business execution after introduction of the system under definition. This section contains a complete, definitive set of business events. It also includes any business anomalies that must be addressed by the scenarios. Finally it describes in business detail each representative scenario. If important, the rules for selection of the representative scenarios may appear in this section. The sixth section provides the analysis of the Operational Scenarios of the last section in the form of Operational Capabilities. The operational capabilities are defined in terms of their structure, behaviors and functions within behaviors. This entire document could be only a few pages long! Remember the shorter, the better. Well, usually. Documents: Referenced Operational Capabilities: Structure Behaviors Functions within Behaviors © 2012 Joseph F Iaquinto, PE

Document CONOPS Use of UML Methods and Graphics
UML, a collection of legacy graphics – BAD IDEA UML is intended for a lower level of abstraction UML is software centric (see Session 3) Legacy graphics can be used with appropriate abstraction; however, too easy to be seduced into design UML best used to flow down from CONOPS / Architecture / System Requirements Specification to implementation I am intentionally belaboring this topic. UML is not compatible with conceptual design as we are using the term here. All you folks with training, education or experience in software development, please take note. This slide presents some reasons for why it is a bad idea to use UML in a CONOPS. By legacy graphics I mean that UML is a collection, some would say Frankensteinish, collection of diagrams commonly found in Engineering practice. Therefore, some of these diagrams may be adaptable to our purposes. I recommend that you reserve use of UML for system level considerations such as requirements definition and system specification. © 2012 Joseph F Iaquinto, PE

Document CONOPS Use DODAF Graphics
DODAF is a collection of more legacy graphics – USE WITH GREAT CAUTION Architecture is role / user “interface” DODAF Views include implementation (Avoid SVs, TVs) AVs can address intention, present basic concepts OVs are usually safe OV-1 the high level operational concept graphic (Intention) OV-2 operational node connectivity (Roles and Relationships) OV-3 Information Exchange (Information / Documents) OV-4 Command Relationships Chart (Roles) OV-5 Activity Model (Activities) OV-6 Behavioral Models (Activities / Operational Capabilities) OV-7 Logical Data Model: Subvert it into information model With appropriate judgment, DODAF graphics can be used effectively to illustrate CONOPS. However, you must exercise great caution since DODAF is frequently used to represent system architecture and design stuff. As a generally guideline, only the OV's, may be used safely. In the slide I present a mapping between OV classes and the element of information commonly found in a system definition CONOPS. © 2012 Joseph F Iaquinto, PE

Document CONOPS Alternatives to Paper Documents
Of all requirements documents, CONOPS is most suitable to prose Automation is essential to productively employ system engineering to most projects given the cost of system engineering Storyboards and full movies are now a practical way to express CONOPS (Demo) Executable specifications provide support for verification and validation The business roles (executors) must be able to participate In many ways, the use of paper documents to record system definition information of any kind is so archaic as to be 50's mentality. Although the CONOPS is most suited to prose documents, among all classes of system definition documents, it is also the most likely to benefit from more modern multi-media presentations. Prose is foreign to most business execution personnel, especially decision makers. Storyboards and movies are a real alternative today. I have a video CONOPS to show you that satisfies all of the requirements of a system definition CONOPS. SHOW MOVIE Executable CONOPS are another modern form that should be considered as an alternative to brain dead documents. Data repositories such as SA are another alternative for rendering CONOPS. The key is that whatever form is chosen for the documentation, it must be accessible to all business roles especially decision makers. © 2012 Joseph F Iaquinto, PE

Some Useful Heuristics
Know the business and how it earns profit Users as a integral part of the CONOPS team Beware of user inputs The single most important CONOPS related concept is the concept of profit. No CONOPS can be designed and written without a clear concept of the value chain and profit. It is important to have users on the conceptual design team to serve as both an information source and a sounding board for idea. As we stated before, it is hazardous to listen to user inputs: -Historical bias -Political bias -Artifact induced bias © 2012 Joseph F Iaquinto, PE

Bring order to chaos (Conceptualize!!) Unique and important performance requirements which will shape system design Major business concepts which will affect system design Attitude toward initial budget and its influence on structure of system Implications of change / growth on long range performance of system Genius is in finding and discarding irrelevant or trivial information Conceptualization is the bringing of order to chaos! This slide presents five heuristics that aim to make order out of the chaos usually associated with unstructured problems. All important performance properties of the system under description should have their own concepts. All major business concepts and only those business concepts need to be modeled in the operational conceptual design — use judgment. Financial concepts must be considered and formulated consistently within the operational conceptual model (see the concept of competitive in price with conventional push mowers in our toy example). Changing environments routinely cause system failures; thus, one must formulate operational concepts that mitigate these potential failures. The chaos of system design derives from the blizzard of information bombarding the SE. The only defense against this is for the SE to apply genius in discarding irrelevant or trivial information while clustering relevant information into concepts. © 2012 Joseph F Iaquinto, PE

Take your time and play with the problem Don’t just think happy path Investigate alternative concepts with critical thinking Use judgment & experience to organize instead of paralyze Maintain conceptual integrity Verify and validate the CONOPS We have been discussing some specific heuristics aimed at identifying concepts for use in the CONOPS. Let's turn our attention to general concepts about concept formulation! If necessity is the mother of invention, play is the father of creativity. Not meetings, not processes, not collaboration, not world peace. Play. Play takes time; thus, creativity takes time. Don't just think happy path. Rainy day business scenarios need to be constructed and operational concepts formulated. Remember that in this stage of our conceptual design we are at the business / basics and context level of abstraction. CT can be used to not only identify potential concepts but also to select among alternative concepts. In order to do this you must first have a set of propositions (another type of concept) about how the business needs to adapt to address the problem and hand what the system under definition needs to do to support this. We have all heard of the paralysis by analysis syndrome. This is not a consequence of analysis; it is a consequence of having incompetent System Engineers doing the analysis. You need to apply experience and judgment to focus your conceptualization efforts on the solving the problem. If you are not up to this, find someone whom to apprentice yourself to. We spent considerable time discussion conceptual integrity. The smallest anomaly in integrity could ruin the entire conceptual design and CONOPS. The basic concepts of the CONOPS should be tested and refined before investing the effort of the next 5 steps. Prepare a verification and validation plan for your basic concepts just as you would for a set of design requirements. © 2012 Joseph F Iaquinto, PE

Engineering is an Associative Behavior The Role of Doctrine MIT eBusiness Process Handbook Microsoft Patterns and Practices RosettaNet EDI Collaborative Process Patterns for e-Business Look in the Literature This slide provides a rich set of sources for operational concepts and operational capabilities. Those of you interested in SOA based systems might want to investigate RosettaNet for inspiration. In the end, it all rests on your cleverness and experience. Your cleverness conditioned by experience © 2012 Joseph F Iaquinto, PE

An Example Illustration of some of the elements of a conceptual design
Session 4 An Example Illustration of some of the elements of a conceptual design This session will present a brief example of a conceptual operational design, in fact the construction of a CONOPS. This example is in addition to the one provided as a complete CONOPS. This example is from a rather trendy class of examples wherein existing applications are to be integrated via a web front end. By web front end, we mean that the primary human machine interface is the web browser. The web browser may or may not have custom code added to facilitate its use. Among other concepts, this example is an example of an SOA. © 2012 Joseph F Iaquinto, PE

Topics For Session 4 Example
The CONOPS The System Requirements Specification The Architecture This is going to be a bit of a whirl wind session, but you should be able to use what follows as an example in your work. Some guidance will be given regarding the definition of system requirements based upon the CONOPS. We will also show the transition from CONOPS to Enterprise Architecture in this example. Our first topic is problem definition. © 2012 Joseph F Iaquinto, PE

An Example Web Provisioning
Specification Status This example addresses a common problem in providing customers with attractive purchase choices. Following this picture clockwise, the customer interacts with customer care system in order to specify their product needs and track status of previous orders. The customer care system interacts with the factory that in turn interacts with suppliers and transportation. Transportation finally delivers the product to the customer. Product © 2012 Joseph F Iaquinto, PE

An Example Define the Problem
A manufacturer of semi-custom goods (computers, watches, automobiles…) wishes to provide a custom order service. The customer can express their requirements for the product and receive in real time a cost and availability date. Thus, they can tailor the product to suit their needs, budget and expected delivery date. In turn, the company is an assembler of parts fabricated by other supplier companies. The key business concept is this notion of providing semi-custom goods at lowest price. The second major business concept is that the customer can directly interact with the enterprise's customer care system to both specify the product and react to the consequences of his choice. The last major business concept is that the business is not a fabricator of parts, only an assembler of parts. © 2012 Joseph F Iaquinto, PE

Intention Buy neat, affordable stuff that I have a role in ‘designing’
Make neat stuff Make money Beat the competition All of the intentions stated on this slide are business intentions. However, they are divided into two classes. The first is the most important class and that is the customer intention upon which the entire enterprise is focused. All systems must have a customer's intended use. This is to say, why the customer is interested in the system under definition. In fact, the customer is the source of funding for the system, so the system must be ultimately justified in terms of how it supports the customer's intended use of the enterprise. Tell story of Direct TV’s change in DVR policy that is blamed upon the “movie studios”. The second class of intention is illustrated on the right side of the drawing. This models the intended use of the system by the enterprise and its suppliers. Usually the enterprise intended use statements are a bit more precise than those I have written. © 2012 Joseph F Iaquinto, PE

Roles Product Requestor Transporter Transaction Modeler Product Maker
This next slide identifies those roles in the enterprise that are most important in the system's definition. The Product Requestor is our euphemism for the customer. The Transporter is our metaphor for the set of enterprise resources and acquired services that address the movement of raw material, work in process and finished goods. The Transaction Modeler role addresses the enterprise resources that create, update and complete business transactions between the enterprise and the customer and the enterprise and its suppliers. The Product Maker assembles the custom products prior to delivery to the customer. The Component Maker fabricates the parts of the custom products as customized by the customer. Component Maker © 2012 Joseph F Iaquinto, PE

Responsibilities / Activities
Determine what you want - intend Research the product options Select the set of options desired Check for price / availability Order product Assemble product Fabricate product parts Ship product Bill for the product Receive the product and insure correctness Pay the bill Produce research materials (quotes) Here is a list of example activities for our enterprise that are all related in some fashion to the system under definition. I have only named and listed them here. If this were for real, each would have to be defined in detail. For example the "Research the product options" activity might include a set of sub-tasks that need to be executed. Some of them might be: Select the catalog that contains the class of product desired Lookup the specific product desired Create a list of product features that can be customized For each feature that can be customized, select a catalog of options... © 2012 Joseph F Iaquinto, PE

Define the Business Events
Request Product Options Product Requestor Product Research Results Provided Request for quote for catalog item This is where some magic happens. You must depend upon your creativity, the CT skills and your judgment to carry out this step. By studying the basic concepts defined in the first step, we will postulate a set of business events. Business events frequently cluster around Roles as they perform Activities. Business events usually happen between and among Roles as illustrated on this slide. Response to request for quote for catalog item Component Maker © 2012 Joseph F Iaquinto, PE

Define the Business Events: Define the Required Information
Product specification form Product features form Price estimate report Shipping estimate report Available features / price report(s) Order form Invoice report This slide provides an example of two classes of information: information the Product Requestor would use in executing the enterprise and information the Product Maker would use. Notice that at the enterprise level, the information is exactly the business objects (real world objects) that the enterprise executor handles in conducting some activity. A description of each element of information in terms perceptive to the enterprise would normally be a part of this effort. For the purpose of brevity they are omitted here. For example, the Product Requestor would manipulate a business object titled "Order form". It is appropriate to define the "Order Form" in terms of what individual elements of information make up this form. One such individual element might be the "customer name" field. It is important to make note of what behaviors are associated with what individual elements of information. This is an important example of the Relationships we need to define. It is equally important to make note of what information is associated with which of the activities discussed on the last slide. Parts description form Request for quote form Parts availability report © 2012 Joseph F Iaquinto, PE

Define the Representative Scenarios
Product Requestor researches available products and determines what they want, can afford and can wait to order Component Maker provides catalog (component specifications)to the Product Maker Product Requestor places a specific order for a product Transporter transports product to Product Requestor Product Requestor receives product Product Maker provides desired component specifications (new or changed) to the Component Maker Transaction Modeler issue invoice to the Product Requestor In this slide there is some more magic. Clearly, familiarity with the business is essential in postulating Scenarios. Notice that this list is a list of titles for scenarios. Further notice that these titles are rich in concepts. For example the first title makes use of role concepts, activities concepts and implicitly, information concepts. Each of these titles needs to be expanded into a description that is also in terms of concepts. As I have warned before, this is not a UML type scenario, but rather a traditional enterprise level scenario. The focus is on the enterprise, not the system under definition. © 2012 Joseph F Iaquinto, PE

Define Operational Capabilities
Unusual Capability Product specification form Specifies Desired Verifies and Pays Invoice Role Standard Capability Information This slide expands the discussion of relationships. All relationship concepts must be carefully "discovered" and expanded upon as required to support a necessary and sufficient set of operational concepts. One word of warning. It is important to capture all of the relationships that are relevant to the system under definition. However, the greatest room for error is associated with "unusual" relationships rather than those that are "standard practices" within the enterprise. This slide illustrates a pair of relationships, one an accounting standard practice (which should be well understood by the conceptual engineer). The other is not standard practice, and is in fact of paramount importance to the enterprise given it follows directly from the intended use. Tell Ford RDS radio story. The use of judgment and CT is essential in completing this part of the CONOPS. The formula is simple, the activity is not. Warning: Study unusual capability rather than be completely distracted by “standard practice” ones © 2012 Joseph F Iaquinto, PE

Define Operational Capabilities Modes and States
Product Research Mode When Product Requestor is discovering the available product / features, costs and delivery schedule AND comparing them to their requirements as they refine these requirements Defining Needs State When Product Requestor is formulating their needs for the product and refining these needs in response to what they find is available as product options Investigating Product Options State When Product Requestor is interacting with the system to determine what product features are available and at what cost, delivery schedule Once we have the scenarios, we can "mine" them for the operational capabilities. Scenarios naturally describe behavior. The conceptual engineer should always exploit this serendipitous situation by first identifying and defining the modes and states from the scenarios. The first point on this slide is a mode that I have mined from the scenario titled "Product Requestor researches available products and determines what they want, can afford and can wait to order”. The following two concepts are states that exist within this mode. In particular the "Defining Needs" and the "Investigate Product Options" states. As one can see from the slide, these operational capabilities are operational capabilities of the enterprise, not of the system under description alone. However, if done correctly, these statements of operational capabilities are very suggestive of the capabilities needed of the system under definition. © 2012 Joseph F Iaquinto, PE

Define Operational Capabilities Fragment of Modes and States analysis
Defining Needs Investigating Product Options Evaluating Candidate Product Specify Product Options Specify Shipping Options Product Research Mode Specify Payment Options This is a simple statechart, not intended to be consumed within the business execution community. Statecharts should be reserved for conceptual designers only. Notice that 2 related modes are illustrated, and their modality is noted by containment. Within each mode is a set of states whose membership in a specific mode is denoted by containment. In this diagram, the transitions are not labeled. But when doing a conceptual design, one must label the transitions. An example would be the transition between "Define Needs" and "Investigate Product Options" which is "Needs Finalized". The solid circles denote terminal states, in this case terminating a mode. Order Product Mode © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Operational Functions
Defining Needs State Search: Form: request classes of products by general operational characteristics – show all 3000# jacks Report: show class of products with salient operational characteristics organized to best suit Product Requestor Select specific product from calls that is most suitable for the intended use of the product Investigating Product Options State Select: Form: request list of options for the selected product, perhaps by class – show all saddle options for 3000# jacks Report: show list of options for a particular product with cost and delivery indicators Select specific option from the options that is most suitable for the intended use of the product Let's take stock of where we are, or in good symphony form, let's restate the theme. First we identified the basic concepts of the business domain for a small number of classes of concepts, for example Roles. Then we used the Activities class of concepts to define business scenarios — in response to all of the necessary and sufficient Business Events (which fall out of the Activities definitions). From this we start on a simple course of elaboration. Business Events are elaborated into Business Scenarios. Business Scenarios are elaborated into Business Modes. Business Modes are elaborated into Business States. Business States are elaborated into Business Functions which we can also call Operational Functions. Business / Operational Functions are simply a "to do" list for the business execution personnel when they are in the state under investigation. This slide provides an example of a couple of Business Functions. Although I have deliberately chosen language that is system descriptive, I am also forced to use business descriptive language (the third sub-bullet under each state). As always, those business functions that most "obviously" are allocated to the business executor may in an alternative or future universe be allocated to the system under definition. © 2012 Joseph F Iaquinto, PE

Define the Operational Capabilities Business Information
Defining Needs General Product Inventor Including User Level Characteristics General Product Search Form Repository of Previous Search Requests General Product Availability Report We can easily recall the process of elaboration that led to the business functions that we have listed for the "Defining Needs" state of the last slide, right? Now we can take one more step in refinement and that is to elaborate the business functions into the Business Information concepts as illustrated on this slide. The form and report I listed on this slide should be no surprise since I chose loaded language on the last slide. However, the element of business information that is represented by the cylinder titled "General Product Inventory" is less obvious. Clearly the operational conceptual designer must have some knowledge of the technology that is being appealed to for use in the system under definition. The various search business functions defined on the last slide clearly indicate to the knowledge designer that this general product inventory is needed. Clearly the operational conceptual designer must have some knowledge of the business executor's potential inclinations. This is expressed by the element of business information in the cylinder titled "Repository of Previous Search Requests". This last element of information is two levels of inference from the information that can be literally read from the scenario statements. Once again, we have demonstrated that conceptual design requires creativity. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS
Political Concept Correct? Acceptable to User? Acceptable to Business? Interoperability Accomplished? Undesirable Consequences Compensated? We will limit ourselves to 5 important topics to address in performing the conceptual analysis. In the interest of brevity, we will address each topic on one slide per topic. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Political Concept Correct?
Do not underestimate the importance of either politics or your responsibility for building acceptable political concepts into the CONOPS. This slide lists 3 of the most important political concept questions to be used to insure refinement of the CONOPS leads to a politically correct CONOPS. The "curse of dimensionality" political concept has to do with the number of human interactions required for correct operation of the enterprise. Each additional organization or person to be involved in the solution brings a potential set of interactions with all of the other organizations or people. It there are 2 people involved, there is one interaction interface. If there are 3 people, there are 3 interfaces. If there are 4 people there are 6 interfaces, etc. What do we need to do with the CONOPS to insure that the Product Maker as the middleman or coordinator works? Should this be changed? The remaining political problem is that the factory is dependent upon its suppliers and the transportation organization; thus, there needs to be concepts that address change propagation and other interaction issues. Concept avoids “curse of dimensionality” Product Maker is “middleman” or coordinator There is a political problem, can you “see” it? © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Acceptable to User?
Role Acceptable?: Product Requester for Example (need address all roles) Activities Assigned to Role Acceptable? Determine intent (requirements) Research what is available based Evaluate what is available and determine suitability Place order Pay for order Information Related to Role Understandable and Acceptable? Product specification form Product features available report… Business Events Related to Role Acceptable? Product Research Result Provided (Timely, consistent with process?) Scenarios cover all those important to each Role The question of whether the initial CONOPS is acceptable to the user is remarkably complex. This is reflected in how full this slide is. The most important role allocation is that of the customer or Product Requester on the slide. If the responsibilities and privileges assigned to the customer are not acceptable, nothing else matters! Thus, this slide is dedicated mostly to an exploration of this one role. For example, do the activities assigned to the customer need refinement? Is the business information related to the customer role correct? Are the business events associated to the customer necessary and sufficient? Do the scenarios cover the behavior of the customer role adequately? © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Acceptable to the Business
Evaluate Conceptual Design Against Intention Intention of All Roles Product Requestor: Affordable, Available Custom Product (Minimum time / effort to complete order?) Component and Product Makers Profitable Market Share Missions and Goals Oops – Missing Role: Government Regulators Complies with regulations Maximizes Tax, etc. revenue Our next topic is acceptability to the business. The intention of the business in acquiring the system under definition is the basis for performing this analysis. Any applicable governance, especially government regulations, must also be considered and addressed in the CONOPS. This may lead to entirely new scenarios being created. © 2012 Joseph F Iaquinto, PE

Verify and Validate Interoperability Accomplished
This topic of refinement continues to increase in importance. This slide does not list check points for SOAs, so you will need to add them if this is important in your individual circumstance. This is not a technical interface drill, it is a conceptual interoperability drill. Therefore the level of abstraction is at: Business events Elements of Information Consistency among elements of information There are also important political considerations that have been partially covered in a previous slide. All Business Events Identified to Permit Scenario Execution? All Information Items Identified to Permit Scenario Execution? Information Items Consistent with Individual System Capabilities? DO NOT CONSIDER TECHNICAL INTERFACE! © 2012 Joseph F Iaquinto, PE

Verify and Validate Undesirable Consequences Compensated?
Request Component Price Request Price Price Quote = z Price Quote = x Invoice = x + Δ Payment = z Undesirable Consequence = lose money Compensation: New Role of “Legal Contractor” The most important consideration for the conceptual engineer is the control of unintended consequences. The more complex the business, the more opportunity for such consequences. This slide illustrates a common source of unintended consequences — the organization of organizations. This particular instance of this consequence is an inconsistency between a quote from a supplier and what the supplier invoices for the part after delivery. The consequence is the loss of money by the manufacturer. There are almost an infinite variety of un-intended consequences resulting from the interaction of multiple political units. Continuing our example, the compensatory action is the definition of a new Role to manage the legal aspects of the organization of organizations. The general rule stated in this slide is applicable to this situation as well as enterprises that make use of SOAs or SOSs or “Cloud Computing”. General Rule: Design Organization of Organizations Before Getting Systems or Development Engineering Involved! © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Let’s try the Happy Path first
Customer finds features they want Customer specifies the product Customer orders the product Customer receives the product Customer pays for the product We make a profit This list of sub-topics to address in pursuit of V&V under happy should be familiar to you now. Notice that these points can form the basis of the scenarios we postulate for V&Ving the happy path. © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Customer finds features they want – Information Check
Search Results Required Information: Product specification form Product features form Product availability / options report This slide addresses the happy path related to a customer finding the product that they are looking for. Observe that it is scenario based. In fact we are cogitating upon the customer product / features search scenario. We previously presented the first two items of information as conceptual information in the CONOPS. Notice that we did not list the third one, so we have found a defect in our original CONOPS. Of course, to complete this example and drive toward a complete CONOPS we would need to repeat this analysis for all of the major concepts in the CONOPS. As you can see from even this limited example, considerable CT is required in order to complete the V&V of the conceptual design. Repeat analysis for intention, roles, activities, relationships… © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Customer specifies the product – Role Check
Specification Status Required Roles: Product Requestor Transaction Modeler Product Maker Component Maker Here is a happier or sadder (depending upon your philosophy) example V&V of the conceptual design. This time we are testing for completeness of the roles within the context of the same scenario we just made use of. Yes, a single scenario can be used to check a number of concepts. In this case we could not think of any additional roles needed to complete the scenario. Again we would repeat this analysis for all of the essential concepts. Repeat analysis for information, intention, activities, relationships… © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS Let’s try a Rainy Day
Customer finds some features Customer specifies a set of features that cannot be built Customer orders the product Customer expects receipt of the product What do we do with this transaction?? Ok, let's try a rainy day approach. This list of scenarios contains an anticipated situation wherein we have an error in out business process that permits specification of something that cannot be built. So, how would we handle this kind of transaction?? © 2012 Joseph F Iaquinto, PE

Verify and Validate CONOPS What do we do with this transaction
Verify and Validate CONOPS What do we do with this transaction? - Information Invalid Order Placed Assisted Order Help Required Information: Order Entry Form Order Form Error Report Product Specification Detailed Error Report Product Specification Assisted Form Online Chat Multi-Form This graphic is a visual metaphor for the rainy day scenario we introduced on the last slide. I have chosen to explore the troublesome transaction from the information concept viewpoint. By reasoning about this situation, one can postulate the list of business objects illustrated. Notice that 4 new business objects have been discovered by considering this rainy day scenario and only its information model aspect. This explosion of concepts resulting from contemplating rainy day scenarios is typical. Tell automotive engine controller story. Repeat analysis for intention, roles, activities, relationships… © 2012 Joseph F Iaquinto, PE

Document CONOPS Topics
CONOPS Outline SRS Outline Architectural Artifacts OV-1 OV-2 OV-3 OV-4 OV-5 OV-6b OV-7 We will now look at an example of how one would organize the CONOPS "document" for our example. In the interest of generality, we will also look at how the CONOPS would flow into the system requirements. Finally, we will explore how the CONOPS influences the architectural artifacts for our example. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS Outline Sketch
Scope: Identification System Overview Document Overview System Concepts: Intention (Intended use) Roles Activities Docs Relationships CONOPS Problem Description: Current Business Situation Business Problem Goals / Objectives for Solution Operational Scenarios: Key business events Anomalies planned for Selected representative Just as a reminder, here is the canonical CONOPS outline we discussed earlier today. The next several slides will in order address each of the blocks on this slide. Documents: Referenced Reference Operational Capabilities: Structure Behaviors Functions within Behaviors © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - Scope
Identification Acme Custom Self-Serve Order System System Overview Purpose –To offer customers custom products at least cost Approach – Web to interface to customer and partners (main scenario) Legal – contracts with partners to provide fixed firm quotes Document Overview Name each section and state its purpose The first block is the scope block. Notice that it is important to state a succinct name for the system under definition. This provides a shorthand notation to be used throughout the document. In the system overview section, the BUSINESS purpose of the CONOPS (not the system) should be stated in a manner that minimizes ambiguity. In the system overview section, the BUSINESS approach should be clearly stated. It is common that technology plays an important role in this section since it frequently is the reason why the approach is now feasible. For all business situations, but especially those that involve interoperation of any kind with a different political unit, there needs to be a separate presentation of the legal approach taken in this CONOPS. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - Problem Description
Competition moves to custom products Customers like control of what they order Offer custom products at standard product costs Do so by superior process Reduced labor (saved pay) Reduced order fulfillment time (saved interest) Ease of order entry to customer Partners more easily interact with us Recall from the concepts discussion of this example presented earlier that the primary problem concepts are as stated in red. This notion of providing custom products at off the shelf price is the central motivation behind this CONOPS. Our business problem, providing custom products at off the shelf pricing, leads to a business approach which is nothing more than an elaboration of the business problem. The last bullet point names the business vision then elaborates it into a set of more easily addressed business problems. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - Problem Description
Current Business Situation What does the company now offer customers (Standard products from a catalog) What is the company’s competitive advantage (Low cost due to standardization) How profitable is the company (Cash cow) How does the company currently interact with partners and customers Business Problem What is the competition doing (Flexible manufacturing upgrade to plants) How does this effect our profit, R&D, and market share (Customers migrating) Goals / Objectives for Solution This is a good place to put a formal, tailored decision making process description Customer service / market share goals (Custom products at standard products price) Profit goals (Better processes to keep profits high) Reduce need for clerical labor Customer self service Partner catalog / quote function fully automated… Here we can see a sketch of what the problem description would look like for our example CONOPS. Notice that the three canonical components of the problem description are in this sketch: The current business situation The business problem resulting from this current business situation The goals / objectives for the solution I have sketched example themes in parenthesis after each topic. This is a structured way to actually build the CONOPS in general and this section in particular. For example, the topic of "What the competition is doing" has the example specific response of "Flexible manufacturing upgrade to plants". The "goals / objectives for solution" topic is critical to the CONOPS effort. Most fundamentally, it provides the touchstone of our CT process. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - References
Documents: Referenced Established Industry Standards Established Industry Specific Trade Agreements Reference Architectural Process of the year This canonical CONOPS topic is rather simple. Unfortunately it does not lend itself to our example, so I have placed a few common categories for the document topics listed. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - System Concepts
Intention (Intended use) Leapfrog flexible manufacturing to custom products at standard product cost Effective customer self service Effective partner self service Roles Product Requestor Transaction Modeler Etc. Activities Product Requestor Activities Determine what you want Research the product options Information (Docs) Relationships Let's now turn our attention to the System Concepts section of the CONOPS. Once again I have listed the canonical sub-topics of this section along with some very sketchy notes stating how our example would be addressed within the related topic. Notice once again that the intention or intended use topic is completely business oriented. Even if a technological innovation has allowed us to seriously consider this business intended use, we do not mention it in this section. As an alternative to a simple list of the 5 major categories of system concepts, one could substitute a small number of categorical scenarios wherein one defines the intention, roles, activities, information and relationship as an organic set in the context of the categorical scenario. CAUTION — the use of bullet points is simply an abbreviation of the gist of each of the topic and is not to be considered complete. Bullet points, such as those used in viewgraph slide, are too superficial to be of any use in a CONOPS and of limited use in a presentation. When actually writing the CONOPS, make sure each is expanded into a complete thought. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - Operational Scenarios
Representative Operational Scenarios: Key business events Emergent key business events Key business events of the Customer orders product scenario Key business events of the Partner initially provides catalog of parts Etc. Selected representative Customer orders product Partner initially provides catalog of parts Partner updates catalog of parts Customer order is fulfilled Anomalies planned for Partner’s provided catalog data does not match actual part specifications (e.g. price) Customer places an invalid order (parts are incompatible) This next section of the CONOPS is the actual focus of the CONOPS. All the previous information in the CONOPS has simply been to improve the comprehensibility of this section. Notice that the topics have been listed in an order that appear natural to me; however, you can use any order. The first major topic states that the key business events are to be addressed. Some of the most interesting business events are those that emerge from more than one business or system. This will take the most CT; however, becoming conscience of this class of events is critical to the success of the business. As we have previously discovered, the business events aid in the identification of representative scenarios, the next topic on this slide. You should be familiar with the though process for creating the 4 representative scenarios presented, by now. Finally, one documents the anomalies identified during the process of exploring the representative scenarios as well as those that come to mind. © 2012 Joseph F Iaquinto, PE

Document CONOPS CONOPS - Operational Capabilities
Structure Product Requestor’s Web Browser Transaction Modeler’s Transaction Monitoring, Order Entry… System Product Maker’s CAM (Computer Aided Manufacturing) System Component Maker’s Supply Chain System Transporter’s Dispatching and Tracking System Behaviors Product Research Mode Defining Needs Investigating Product Options Evaluating Candidate Product Functions within Behaviors Defining needs Search Report… In this slide we elaborate upon the example scenarios (as sketched on the previous slide) by defining the operational capabilities they suggest. Notice that the three canonical subtopics have listed and a few thoughts from the example CONOPS provided. Notice that each of these topics must start with a diagram. For example, the complete structure diagram of the enterprise as related to the operational scenarios should lead off this section. Ditto for the behaviors and functions topics. Notice that I have organized the Behaviors section by modes and states. Remember that the functions listed within the behaviors are as business oriented as possible. Avoid writing shall statements that are more suitable to an SRS than to a CONOPS. The operational capabilities are indeed the end result of the entire operational conceptual design. The CONOPS is the instrument by which they can be viewed within the context of their derivation. © 2012 Joseph F Iaquinto, PE

2. General System Description
The System Requirements Specification System Requirements Specification Outline 1. Introduction 2. General System Description 3. System Capabilities 4. System Interfaces For the sake of this argument, let's accept the IEEE std 1233 as correct. This is illustrated in the diagram. We will take each section in turn and relate it to the material in the CONOPS. IEEE Std 1233, 1998 Edition © 2012 Joseph F Iaquinto, PE

The System Requirements Specification SRS – Introduction
CONOPS Scope SRS Introduction Scope: Identification Acme Custom Self-Serve Order System System Overview Purpose –To offer customers custom products at least cost Approach – Web to interface to customer and partners (main scenario) Legal – contracts with partners to provide fixed firm quotes Document Overview Name each section and state its purpose 1.1 System Purpose 1.2 System Scope 1.3 Definitions, Acronyms 1.4 References 1.5 System Overview CONOPS Documents Documents: Referenced Established Industry Standards Established Industry Specific Trade Agreements Reference Architectural Process of the year In this illustration, I have elaborated the SRS introduction and related it to the CONOPS. Notice that one can completely write the SRS Introduction by referring to the CONOPS first two sections and reorganizing the material found there in. To make the SRS more useful, one can introduce more technical approach concepts into the scope, definitions and overview sections. © 2012 Joseph F Iaquinto, PE

The System Requirements Specification SRS – General System Description
SRS General Sys Desc System Concepts 2.1 System Context 2.2 System modes and states 2.3 Major System Capabilities 2.4 Major System Conditions 2.5 Major System Constraints 2.6 User Characteristics 2.7 Assumptions and Dependencies 2.8 Operational Scenarios Operational Capabilities In this illustration I have mapped the information contained in the CONOPS to the section of the SRS. The system concepts related to intention and roles (large scale roles) directly support the writing of the System Context section of the SRS. Sections 2.2 through 2.5 of the SRS are clearly abstractions from the Operational Capabilities of the CONOPS. From one viewpoint, the purpose of the CONOPS is to generate this information in some structured fashion. The Representative Scenarios from the CONOPS clearly copy directly over into section 2.8 of the CONOPS. Representative Operational Scenairos © 2012 Joseph F Iaquinto, PE

The System Requirements Specification SRS – System Capabilities, Conditions,…
3.1 Physical 3.2 System Performance Characteristics 3.3 System Security 3.4 Information Management 3.5 System Operations 3.6 Policy and Regulation 3.7 System Life Cycle Sustainment Operational Capabilities Section 3 of the SRS can be considered an elaboration of the CONOPS Operational Capabilities. Section 3.2 in particular is organized identically as the CONOPS operational capabilities section. Representative operational scenarios form a sound, defensible context for sections 3.5 and 3.6 as well as supporting the derivation of section 3.6. Representative Operational Scenairos Section 3.2 in particular is organized by capability © 2012 Joseph F Iaquinto, PE

Package system requirements by operational capability!
The System Requirements Specification SRS – 3.2 System Performance Characteristic Defining Needs State Search Capability The system shall tag products and parts by a general operational characteristic indicative of use The system shall store products by general operational characteristics The customer shall be presented with a search form which contains a list of available general operational characteristics from which the user can select The shall retrieve products and parts by Boolean combinations of product and part characteristics, including general operational characteristic In these next two slides, we will further elaborate our example. In SRS section 3.2 we present the basic system characteristics. Recall that we are packaging system functions by operational capability. In turn, operational capability is packaged by Modes and States. Here we have an example of the elaboration of the "Define Needs State". Within the "Define Needs State" we have the 'Search Capability". The four system functional requirements follow from the application of CT and experience. They should be almost self-evident. Package system requirements by operational capability! © 2012 Joseph F Iaquinto, PE

The System Requirements Specification SRS – 3.3 System Security
Defining Needs State Search Capability The system shall retain all “sold” product and parts and their characteristics for a period of 10 years The system shall restrict access to product and part operational characteristics by customer and service level purchased The system shall not lose any partially configured products The system shall restrict access to partially configured products to the customer who originally created the partial configuration A great deal of attention is being given to "security" and "cyber security" today. This slide jumps on that bandwagon for our example. Notice that we are addressing the same State ("Defining Needs State") and Operational Capability ("Search Capability") as in the last slide. The difference is that we have cogitated about security and produced requirements that address that topic. Always consider denial of service attacks on friendlies when performing rainy day scenarios on this topic. Package system requirements by operational capability! © 2012 Joseph F Iaquinto, PE

The Architecture Architecture – OV-1
Specification Status You have seen this drawing before. Along with the prose / commentary this is an OV-1. Product Viewpoint: Mission Intention © 2012 Joseph F Iaquinto, PE

Product specification form Product features form Bill of laden Shipping Options Form Request for quote Parts order Shipping options report Shipping cost form Using many of the concepts that we defined in the CONOPS, we can produce an OV-2. As stated on the slide, our viewpoint is the relationship of roles to information. The fact that roles are associated with locations provides some generalization of this slide. Parts description form Parts availability reports Price estimate report Product catalog Viewpoint: Relationship of Role to Information © 2012 Joseph F Iaquinto, PE

Information Item Description Source Designation Exchange Attributes Product Specification Form Contains the customer’s product detailed requirements Product Requestor Transaction Modeler HTTPS Customer sensitive 0.5 second response Carrying the Information Concept into DODAF world provides us with a high level OV3. Clearly, this OV-3 could guide its own elaboration into a more detailed OV-3. Viewpoint: Information Needed © 2012 Joseph F Iaquinto, PE

Order placement Order fulfillment Using our conceptual roles and their conceptual relationships, we can formulate a high level OV-4. This capitalizes upon the fact that political organizations frequently associate by role. Two classes of interfaces can be noted on this OV-4 by making use of abstractions of the conceptual information discovered during the CONOPS. Viewpoint: Role to Role Relationship © 2012 Joseph F Iaquinto, PE

Request Search Form Submit Search Form in Context Perform Search Report Parts Found Select Parts Accept Order We can make use of our conceptual activities from the conceptual design in order to create a high level OV-5. Notice that we have made use of not only the conceptual activities, but also the conceptual roles in creating this diagram. Viewpoint: Role to Activity and Activities Performed © 2012 Joseph F Iaquinto, PE

The Architecture Architecture – OV-6b
Defining Needs Investigating Product Options Evaluating Candidate Product Specify Product Options Specify Shipping Options Product Research Mode Specify Payment Options Clearly, since we spend considerable time in constructing the Mode, States and Operational Capabilities during the conceptual design, we can create the OV-6b rather easily. Here is an illustration you have already seen! Viewpoint: Mission Driven Activity Grouping Order Product Mode © 2012 Joseph F Iaquinto, PE

Product Specification Form Customer specifies general product features 1 n Product Features Form Price Estimation Report 1 1 Our conceptual information model can easily be transformed into a conceptual OV-7 as illustrated in this figure. For of those or you who have a data modeling background (education, experience or both), you might find it helpful to construct formal conceptual information models during the conceptual engineering process. However, be very careful to keep you language, business language. Don’t make use of data modeling terms or diagrams in the CONOPS. I have chosen to annotate this OV-7 with the applicable conceptual business rules. This can frequently be of use to the reader. Customer specifies customizable product features Customized product has an estimated price until purchased © 2012 Joseph F Iaquinto, PE

System Engineering Can Be Affordable Conclusion
This concludes our discussion of conceptual design in general and CONOPS in particular. As system design and implementation becomes easier and more abstract, the conceptual design process moves closer to the implementation. As we have seen during this tutorial, its importance in assuring that the business receives the anticipated benefits is critical. Although the conceptual design process requires considerable thought, judgment and experience; if done at a correct level of abstraction it is relatively inexpensive. This makes the CONOPS a very profitable enterprise for the business community. So System Engineering can be affordable and beneficial. However, we need to migrate our efforts up the ladder of abstraction. Making effective CONOPS is one way to do this. © 2012 Joseph F Iaquinto, PE

Keep Conceptual Design Abstract Soon Be Able To Implement Directly!
Problem Definition Concept of Operations (CONOPS) Software Auto-Generation Hardware Fabricator The future of conceptual design is bright. With the ever increasing capabilities in the software auto-generation (for example MatLab, Businessware, etc) and hardware fabrication (...) market, we can forecast a continuing decline in the need for system level requirements and specifications. This will eventually drive most of engineering to the system level of abstraction. It will also empower SE's by permitting direct fabrication of end systems. System © 2012 Joseph F Iaquinto, PE

A Simple process for doing the conceptual design (CONOPS)

The Toy Example The Auto-Mower
For simplicity and to avoid invoking emotional responses, we will use a toy example throughout this discussion of the process of doing a CONOPS. In the handouts you will find a complete CONOPS document example. The Toy system is a major enhancement to the traditional push lawn mower. For those of you who attended a prior EA tutorial of mine, this is the CONOPS portion of the EA for the Automower. The originating concept of our example is the provisioning of a remote control lawn mower whose purpose is to reduce the effort necessary to mow the lawn of a typical suburban homestead in order to extend homeownership to a broader population. © 2012 Joseph F Iaquinto, PE

The Conceptual Design Featuring The Concept Of Operations

Similar presentations

Presentation on theme: "The Conceptual Design Featuring The Concept Of Operations"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Conceptual Design Featuring The Concept Of Operations

Similar presentations

Presentation on theme: "The Conceptual Design Featuring The Concept Of Operations"— Presentation transcript:

Similar presentations

About project

Feedback