The Systems Approach

Defining the "systems approach" is, at times, difficult, but basically it simply recognizes that all the elements of a system must work together, which requires a systematic and repeatable process for designing, developing, constructing, and operating the system. This systematic and repeatable process involves determining the architecture of the system so that, at a minimum, the final design satisfies all the requirements as defined by the customer and agreed to by the provider. The key features of the systems approach are shown in Exhibit 8-2.

Exhibit 8-2: Key system engineering process elements.

The system engineering process is conceptually straightforward and, on the surface, simple. But putting the process in place and executing it can be a significant endeavor because each of these process elements have embedded in them several, and sometimes complex, subelements. A description of each of these elements will aid the understanding of the process.

Requirements Analysis

The requirements analysis process is one that should be continuous. The traditional course of requirements analysis is that stated customer needs are identified, a project plan is developed, and, to the best extent possible, the project team delivers. The problem with that approach is that the project organization may not have the resources or technical capability to deliver all of the customer's stated requirements. In addition, the customer is very likely to change the requirements anyway as the project progresses, making a matchup of resources and requirements difficult, if not impossible.

Given enough time, a match between a developer's resources and a customer's expectations is eventually met on every project deliverable. The problem is that the matchup often occurs too late in the development process. In other words, projects that unsuccessfully meet their cost, schedule, or performance goals usually are those in which the resources or expectations matchup occurs after approval is given to initiate product development. On the other hand, when a customer's needs and a developer's resources are matched before product development starts, the more likely the development is to meet cost and schedule objectives.

There are three factors that are key to matching needs and resources before product development begins. First, the developer must employ the technique of systems engineering to identify gaps between resources and customer needs before committing to a new product development. Second, customers and developers have to be flexible. In this instance, flexibility means that the customer needs to be willing to reduce or defer the requirements to future programs long enough so that the developer can make an investment to increase knowledge about a technology or design feature before beginning product development. Third, the roles and responsibilities of the customer and the product developer should be clearly defined and matched to enhance communication and information flow. The objective here is for the developer to be able to significantly influence or even determine product requirements. However, this is done in complete concert with the customer.

When these factors are not present at a project launch, the development of the project deliverable often begins without a match between the developer's resources and the customer's needs. This results in schedule slips and budget overruns.

Functional Analysis

The system functions and subfunctions have to be identified and analyzed. This is the basis for identifying alternatives for meeting system performance and design requirements. Generally, the customer provides at least the high-level functional requirements of the desired product. But a thorough analysis of the customer's stated needs and use or mission of the product will reveal that some of the functions are not needed. Likewise, there are other functions not conceived that should be included in the requirements lists. This process also is an ongoing effort since functionality may change as the development process unfolds. An important result of an ongoing and iterative functional analysis process is that true value engineering can occur. That is, the worth of a required function can be evaluated for possible modifications or deletion.

In the early stages of developing a system, it is best to separate the "how" from the "what" of the system requirements. This approach allows the systems engineer to consider a number of alternative ways to satisfy a requirement, thus optimizing the final solution.

Once the functional analysis is complete, each of these requirements must match a functional element of the system, and vice versa.

Allocation

The primary output of functional analysis is that each identified function and subfunction can be allocated to a set of performance and design requirements. That is, these functions and subfunctions are decomposed in such a way that all the functions and subfunctions and all generic information and data flows among and between them are traceable to a system requirement. If it is determined that a function or subfunction does not support a system requirement, then that function or subfunction is extraneous and has no purpose for the system or the requirement is poorly written.

Synthesis (Architecture Design)

The architectural design of a system is the centerpiece of the total systems engineering process. Simply stated, it is a synthesis procedure that normally requires the formulation of alternative system architectures and a requirements analysis to verify that potential architectures satisfy the stated requirements.

The problem attendant to this step is that one has to define constraints around the acceptable alternatives; otherwise, the job of determining the right solution becomes unmanageable. For example, if there are ten functional areas planned for a system, and there are to be, say, three design choices for each area, then theoretically there are a total of 3¹⁰ or 59,049 possible architectures. Designing this many alternatives for a system makes no sense, so the typical approach is to narrow the field of possibilities by adding constraints, usually with the input from and approval of the customer. The most common alternative constraints approach is to target a low-cost, minimum effectiveness solution at one end of the spectrum, a high-performance, high-cost solution at the other, and perhaps a third solution midway between the two to start the alternative identification process. The idea is to find a baseline alternative somewhere in between these upper and lower constraints that meets all the system requirements without being unaffordable or too technologically challenging. The end result of this identification process will produce between three and five viable alternatives. Exhibit 8-3 explains how the alternatives are designed against the key functional requirements.

Exhibit 8-3: Developing architectures against system functions and requirements.

The next step in the process is to determine which of the alternatives offers the best solution to the customer's requirements against the provider's capabilities.

Optimization (Preferred Design)

Once the alternative candidates are defined, a process of evaluating them against each other, using functional requirements to define the evaluation criterion, begins. Usually, a rating system is developed using the customer's stated needs and preferences. For example, the customer may be less interested in cost than performance, in which case the final system may be closer to the upper constraint of Exhibit 8-3. Another desired characteristic of any system is its maintainability. Generally, this is important as an evaluation criterion. Other characteristics that are used as evaluation criteria are meantime-between-failure, guaranteed-in-operation time, or minimum downtime. Whatever the criterion used, each system alternative is evaluated on a scale to determine an overall rating for the alternative. Exhibit 8-4 demonstrates how this evaluation matrix is developed.

Exhibit 8-4: Rating alternative architectures.

		Alternative Architectures
Evaluation Criteria	Criteria Weights (W)	Alternative A		Alternative B		Alternative C
		Rating	W R	Rating	W R	Rating	W R
Criterion 1	0.10	9	.90	5	.50	5	.50
Criterion 2	0.08	4	.32	6	.32	8	.64
Criterion 3	0.11	8	.88	4	.44	7	.77
Criterion 4	0.15	3	.45	7	1.05	9	1.35
Criterion 5	0.16	4	.64	8	1.28	6	.96
Criterion 6	0.09	6	.54	9	.81	5	.45
Criterion 7	0.11	9	.99	7	.77	7	.77
Criterion 8	0.10	6	.60	7	.70	4	.40
Criterion 9	0.10	5	.50	5	.50	8	.80
TOTALS	1.00		5.82		6.37		6.64

Criteria weights are subjective in that the weights and, for that matter, the ratings, are an individual's or team's best guess. However, much of the subjectivity is eliminated, or at least reduced, because all the alternatives are measured against the same criteria. Hence, although this scheme provides no useful results if applied against one system, applying it against several systems provides the best solution in a relative comparison.

Usually, the customer will, through either a brainstorming process or through historical records, or both, determine the evaluation criteria and then rank them according to the importance she perceives each will have in determining the final product. Wherever possible, the provider should be involved with this process because of the expertise that is needed about existing technology, life-cycle cost, maintainability, and so on. When the matrix is developed and each alternative is evaluated, the alternative with the highest score is the one most likely to provide the best value to the customer—best value in this case defined as meeting all the requirements.

Once a decision is made to pursue a particular alternative architecture, the important step of generating specifications for all the subsystems can begin.

Specification Generation

Specifications are usually thought of in an engineering sense, that is, a description of a product reduced to its most basic dimensions and operating parameters. In the IT world, this definition of specifications is valid for most project deliverables, but specification can also describe the functional capabilities of a product. In most instances, it is better to avoid using hard, technical measures in favor of more functional descriptions. In our earlier discussion of statements of work, we pointed out that an SOW is, in fact, a specification.

At this stage of project and product planning, specifications are generated for all the subsystems, regardless of whether the specifications describe precise engineering dimensions, the functional requirements of the system, or both. This step can be an iteration point as well. This is because even though the preferred alternative has been chosen through trade-off and other analyses processes, specification generation often uncovers flaws in the architecture, which may require a modification to the design or even coopting another approach over the preferred one.

These sections described the key elements of the systems engineering process, but what is the relationship of systems engineering and project management? How do the two fit together? Are they completely separate disciplines? The next section answers these questions.