Case study

Case study

Introduction

Systems engineering concepts—including methods, processes and systems management to enable trustworthy implementation of processes and methods to ensure quality products and services—are very important for success today. The material to follow was brought together with two major considerations:

In the teaching of systems engineering, case studies are potentially very instructive in that they relate aspects of the real world to the student through exposure to realities in the world of professional practice. Frequently, the bad examples are even more valuable than the good ones, since they emphasize the penalties for not following the proper concepts and processes of systems engineering.

In teaching systems engineering, there has previously been little distinction between the duties and responsibilities of public sector, government, and private sector, industry, activities. There is also a third sector, comprised of nonprofit organizations, which may often need to be distinguished from for-profit private sector organizations.

Case Study

What follows is a list comprising at least one systems engineering concept within each of the 27 elements of the case study concept framework matrix. These concepts are written in the spirit of being requirements for good systems engineering; thus they are written as “shall statements.” Each of the concepts is associated with at least one illustration or vignette of a situation, in this instance drawn from a multitude of different cases, which would in an actual application be characteristic of a specific case history. Essentially, then, the trajectory of these composite situations across the rows and columns of the matrix would form the skeleton of a full case history. These are intended for augmentation and revision as experience with this effort is gained. Some of these situations are decades old, and the current focus on evolutionary acquisition and system families should provide even more current and broad scope illustrations. Perhaps this list might ultimately become a set of useful Heuristics for a Body of Knowledge of Systems Engineering Concepts and Practices.

Requirements Management

Contractor

SE concept: Requirements shall flow down in a coherent and traceable manner from the top level to all lower levels of the system being engineered.

Case study: The flow-down of requirements was often slowed by the lack of early lifecycle systems modeling capabilities on the part of the contractor, so there were many paragraphs with TBDs (“to be determined” elements instead of quantitative specifications). As the TBDs stubbornly refused to be quantified, program management “incentivized” their determination by coupling pay raises with how many TBDs were eliminated. The response by the engineers was to “temporarily” eliminate these TBDs by removing the paragraphs in which they were imbedded, thereby creating “silent specs” with the hope to fill them in when the analysis was complete. Time passed, and the engineers were transferred to other programs without warning their successors of the silent specs. Some of these specs should have been passed on to a key subcontractor but were not. The result of this was that the systems-level test failed, the prime contractor lost schedule and over $100M in ...