
2 minute read
PPI SYEN FORUM
PPI SyEN Forum
Selected correspondence from readers, authors, and contributorsPPI SyEN FORUM Selected correspondence from readers, authors, and contributors
PPI SyEN FORUM offers the opportunity for feedback and discussion on topics around systems engineering – especially those that have been (or should be) addressed in PPI SyEN. Please send your email to PPISyEN@ppi-int.com
Addressing Important Concepts by Robert Halligan
Recently I had a delegate on a course that asked for clarificaion on the following concepts. These concepts are often confused/misunderstood in the SE world so I thought it would be worthwhile to repeat them here.
1. The difference between CONOPS, CONUSE and OCD
For a given system, a CONUSE and an OCD are the same thing, a system-centric description of intended use in terms of users and their characteristics, uses, for each user and use how it is to be used, and the external conditions intended or expected during use. For a given Capability/Enterprise/Business system, a CONOPS is an operational solution description, a description of that part of the solution that serves an end-use purpose, in terms of key solution elements, their key characteristics and the concept of their interoperation to achieve key Capability/Enterprise/Business outcomes. The term is only used for systems that are a mixture of humans and technology (usually) or entirely human (occasionally).
2. The difference between: Allocated Baseline, Functional Baseline and Product Baseline
The baselines you mention are always with reference to a given system (system of interest) that may in context be a subsystem. Functional Baseline: a terrible but common name for a baselined problem definition. Allocated Baseline: a design baseline one physical level below the system that is the subject of the baseline, populated by the requirements specifications of the solution elements at that level, including the data describing how the solution elements are to be configured with respect to one another to comprise the whole. Product Baseline; a design baseline containing all the necessary information from which the system can be built, populated by the requirements specifications of the solution elements at all physical levels, including the data describing how the solution elements are to be configured with respect to one another to comprise the whole, through the physical levels. In practice, this means the identification and specification of all parts and materials and associated configuration data, including, for developmental software elements, software construction down to lines of code and compilation data. The Product Baseline excludes the design of the production system, unless the system of interest is a production system! These are general engineering definitions. Each of these baselines may or may not include specification of the requirements for evidence of the system being in compliance.