Process Issues in the Development of Solutions to Problems: Relationships Between Key Documents and the Development Process.

Abstract

These notes describe key aggregations of information used in the engineering of systems, common document types and names used to communicate this information, and key interrelationships. In particular, relationships are explored between a System of Interest (SOI), the System Requirements Specification (SRS) for that system, an Architectural Design Description (ADD) for that system, one or more Operational Concept Descriptions (OCD), each for an element of the solution to the SOI, and one or more System (or software) Requirements Specifications for an element of the solution to the SOI.

1. Example System

The system in Figure 1 will be used as an example in these notes.

2. Generic Document Types

Generic document types are defined below:

System Requirements Specification (SRS): a specific record of the required characteristics of a system, i.e. the characteristics that any solution is required to possess. Usually also includes any goals.

Operational Concept Description (OCD): a system-centric description with respect to that system of:

• the intended users of the system (human and/or elements of technology)
• the intended uses of the system
• how it is intended that the system be used
• the conditions, external to the system, within which it is intended that the system be used.

Architectural Design Description (ADD, e.g., SSDD, CONOPS, IEEE 1471 Design Description, etc.): with reference to a system, the identification of the elements of the solution, together with the key characteristics of each element and the concept of interoperation of the elements to satisfy requirements.

3. Relationships Between Key Documents

SOI System Requirements Specification (SRS), SOI Architectural Design Description (ADD), Aircraft System Requirements Specification (SRS), and Aircraft Operational Concept Description (OCD) are related as follows.

The SOI SRS states the top-level problem, incorporating the requirements to be satisfied by any solution. Other aspects of the problem definition include measures of effectiveness (MOEs), targets or goals with respect to the MOEs, and value relationships.

The SOI ADD describes the selected concept of a solution to solve the problem, i.e. to satisfy the SOI SRS.

The Aircraft OCD, being system centric with respect to the aircraft, describes the users of the aircraft, its uses, how each use is to be accomplished, and the external (to the aircraft) conditions during use of the aircraft. The OCD describes intended interaction of the aircraft with a subset of the other elements of the SOI architecture as described in the SOI ADD, together with, potentially, interaction with things outside of the boundary of the SOI.

Many requirements of the SOI may be (inevitably will be) satisfied through interaction of elements within the SOI architecture, including the aircraft. Some of these elements will NOT interact directly with the aircraft, e.g. a ground transportation system. The complete solutions to a number of SOI requirements will inevitably comprise:

a. requirements on the aircraft;

b. requirements on things with which the aircraft will interact, and therefore things which are addressed in the OCD for the aircraft; and

c. requirements on SOI system elements, elements that will not interact with the aircraft and that are not addressed in the OCD.

An approach that develops requirements on the aircraft based primarily on the OCD for the aircraft is missing vital information input, and is missing vital SOI solution decision-making in relation to the SOI.

An approach that develops requirements on the aircraft based primarily on the aircraft OCD can be described as:

a. decide to use an aircraft as a part of the SOI solution (OK);

b. decide and record conceptually the role of the aircraft in this solution (users, uses, how to be used, conditions during use) (OK);

c. in the light of b. above, go farming for aircraft requirements (not OK!)

This is a particularly unreliable approach to creating a SOI solution! Or aircraft requirements.

A second issue is that an OCD is an operational CONCEPT description, as distinct from detail. It is inevitable that aircraft requirements will exist that do not have their origins in the content of the OCD, simply for reasons of level of detail.

A third issue is that an OCD is concerned with the use part of the system life cycle. However, requirements can, and usually do, originate from any and all parts of the system life cycle. Beyond its inherent unsuitability as a sound basis for deriving requirements from the use part of the system life cycle, an OCD usually provides no coverage of the rest of the life cycle.

By contrast, a reliable approach to developing requirements on the aircraft is to create, for each SOI requirement, using design processes and design skills, requirements on the applicable SOI system elements, requirements that are a complete and optimum set. This set of requirements constitutes an optimum design to satisfy the SOI requirement, consistent with the chosen concept of solution described in the ADD. Optimum aircraft requirements are a subset of this optimum set of requirements representing an optimum SOI design.

Note that, when Commercial-Off-The-Shelf (COTS) or other non-developmental elements of a solution are chosen, their possessed characteristics must be reconciled with requirements developed as above.

SOI design skills (but not aircraft design skills) are needed to perform this work competently. This is the nature of the engineering of system solutions to problems.