System Requirements Analysis

By Jeffrey O. Grady

System Requirements Analysis gives the professional systems engineer the tools to set up a proper and effective analysis of the resources, schedules and parts needed to successfully undertake and complete any large, complex project. This fully revised text offers readers the methods for rationally breaking down a large project into a series of stepwise questions, enabling you to determine a schedule, establish what needs to be procured, how it should be obtained, and what the likely costs in dollars, manpower, and equipment will be to complete the project at hand.

System Requirements Analysis is compatible with the full range of popular engineering management tools, from project management to competitive engineering to Six Sigma, and will ensure that a project gets off to a good start before it's too late to make critical planning changes. The book can be used for either self-instruction or in the classroom, offering a wealth of detail about the advantages of requirements analysis to the individual reader or the student group.

• Written by the authority on systems engineering, a founding member of the International Council on Systems Engineering (INCOSE)
• Complete overview of the basic principles of starting a system requirements analysis program, including initial specifications to define problems, and parameters of an engineering program
• Covers various analytical approaches to system requirements, including structural and functional analysis, budget calculations, and risk analysis

• Language: English
• Publisher: Elsevier Science
• Release date: Sep 19, 2013
• ISBN: 9780124171305

Jeffrey O. Grady

Jeffrey O. Grady is the Owner of JOG System Engineering, a consulting and teaching company, and an Adjunct Professor at the University of California, San Diego. He was formerly the manager of systems development at GD Space Systems. He is the author of ten books in the systems engineering field. Jeff is an INCOSE Fellow, Founder, and ESEP. Jeff worked as an employee for Librascope, Ryan Aeronautical, General Dynamics Convair, and General Dynamics Space Systems. He has consulted in systems engineering for many companies, developing military and commercial products. He has taught hundreds of system engineering courses for universities, short course companies and for his own company.

Book preview

System Requirements Analysis

Second Edition

Jeffrey O. Grady

JOG System Engineering, San Diego, CA, USA

Table of Contents

Cover image

Title page

Copyright

List of Illustrations

List of Tables

List of Acronyms

Preface

1. Introduction

1.1 Introduction to Systems Requirements

1.2 Models and the Mind

1.3 System Development Process Overview

1.4 Process Variations

1.5 An Overview of the Proposed Modeling Prescription

2. Requirements Foundation

2.1 Requirements Fundamentals

2.2 Requirements Traceability Relationships

2.3 Requirements Allocation, Margins, and Budgets

2.4 Requirements Analysis Strategies

3. The Functional Problem Space Model

3.1 System Beginnings

3.2 Toward a General Theory of Structured Analysis

3.3 Functional Analysis

3.4 Performance Requirements Analysis and Allocation

3.5 Product Entity Structure Synthesis

3.6 Interface Identification

3.7 Functional Analysis Alternatives

3.8 The Application of Functional Analysis to Software

3.9 Physical Process Modeling

3.10 RAS-Complete and RAS-Centered Analysis

3.11 Model Documentation

4. A Variety of Software Models

4.1 Introduction

4.2 Computer Processing-Oriented Analysis

4.3 Data-Oriented Analysis

4.4 Object-Oriented Analysis

4.5 The Unified Modeling Language Model

4.6 System Modeling Using the DoD Architecture Framework

5. Joint Solution Space Modeling

5.1 Interface Requirements Analysis

5.2 Specialty Engineering Requirements Analysis

5.3 Environmental Requirements Analysis

6. Universal Architecture Description Frameworks

6.1 Movement Toward a General Solution

6.2 Functionally Based UADF

6.3 MSA-PSARE-Based UADF

6.4 UML–SysML-based UADF

6.5 UPDM Selectively Extended to a UADF

6.6 Mixed Methods if You Must

7. Specification Content Standards

7.1 Specification Development Fundamentals

7.2 General Specification Style Guide

7.3 Performance Specification Content Guidance

7.4 Detail Specifications

7.5 Interface Specifications

7.6 Parts, Materials, and Processes Specifications

7.7 Applicable Document Analysis

8. Requirements Management

8.1 Process Overview from a Management Perspective

8.2 Requirements Risk Management

8.3 Requirements Value Management

8.4 Requirements Integration

8.5 Interface Requirements Management

8.6 Requirements Verification Management

8.7 Specification Development, Review, and Approval

9. Computer Applications

9.1 The Computer Tool Infrastructure

9.2 Computer Applications

10. Closing

10.1 Where Have We Been?

10.2 The Future

Bibliography

Copyright

Elsevier

32 Jamestown Road, London NW1 7BY

225 Wyman Street, Waltham, MA 02451, USA

Copyright © 2014, 2006 Elsevier Inc. All rights reserved

No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangement with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions

This book and the individual contributions contained in it are protected under copyrightby the Publisher (other than as may be noted herein).

Notices

Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary.

Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein.

In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.

To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.

British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Cataloging-in-Publication Data

A catalog record for this book is available from the Library of Congress

ISBN: 978-0-12-417107-7

For information on all Elsevier publications visitour website at store.elsevier.com

This book has been manufactured using Print On Demand technology. Each copy is produced to order and is limited to black ink. The online version of this book will show color figures where appropriate.

List of Illustrations

List of Tables

List of Acronyms

ABD Architecture block diagram

ASCII American standard code for information interchange

ASIC Application specific integrated circuit

BIT Built-in test

CAD Computer-aided design

CAIV Cost as an independent variable

CAM Computer-aided manufacturing

CASE Computer-aided software engineering

CCB Configuration control board

CDR Critical design review

CDRL Contract data requirements list

CDROM Compact disk read-only memory

CEP Circular error of probability

CFD Control flow diagram

CI Configuration item

CM Configuration management

CMM Capability maturity model

CONOPS Concept of operations

COTS Commercial off the shelf

CPC Corrosion prevention and control

CPM Critical path method

CRL Concept requirements list

CSCI Computer software configuration item

CSCSC Cost schedule control system criteria

C4ISR Command, control, communications, computers, intelligence, surveillance, and reconnaissance

DBS Drawing breakdown structure

DCA Design constraints analysis

DCIF Design constraints identification form

DCSM Design constraints scoping matrix

DDP Development data package

DFD Data flow diagram

DID Data item description

DMA Database modeling analysis

DoD Department of Defense

DoDAF Department of Defense Architecture Framework

DPA Deployment planning analysis

DRA Deployment requirements analysis

DSMC Defense Systems Management College

DTC Design to cost

DTE Development test and evaluation

EADL Enterprise applicable document list

ECP Engineering change proposal

EDD Enterprise definition document

EFFBD Enhanced functional flow block diagram

EIA Electronics Industry Association

EID End item description

EIT Enterprise integration team

EMC Electromagnetic compatibility

EMD Engineering and manufacturing development

EME Electromagnetic environment

EMI Electromagnetic interference

EMP Electromagnetic pulse

ERB Engineering Review Board

ERD Entity relationship diagram

ESD Electrostatic discharge

EW Electromagnetic warfare

E3 Electromagnetic environmental effects

FA Functional analysis

FAA Federal Aviation Administration

FCA Functional configuration audit

FDA Food and Drug Administration

FFBD Functional flow block diagram

FFD Functional flow diagram

FMECA Failure modes effects and criticality analysis

FRACAS Failure reporting, analysis, and corrective action system

FRAT Functions requirements architecture test

FRB Failure Review Board

GFE Government furnished equipment

GFP Government furnished property

GPS Geographic positioning system

GIDEP Government Industry Data Exchange Program

GUI Graphical user interface

HAHST High-altitude high-speed target

HERF Hazards of electromagnetic radiation to fuel

HERO Hazards of electromagnetic radiation to ordinance

HERP Hazards of electromagnetic radiation to personnel

HOL Higher order language

HP Hatley Pirbhai

HPM High-power microwave

HW Hardware

ICAM Integrated computer-aided manufacturing

ICBM Intercontinental ballistic missile

ICD Interface control document

ICWG Interface control working group

ICWT Interface control working team

IDEF Integrated definition

IEEE Institute of Electrical and Electronics Engineers

IMP Integrated master plan

IMS Integrated master schedule

INCOSE International Council on Systems Engineering

IO Input–Output

IOC Initial operating capability

IPO Input process output

IPPT Integrated product and process team

IRD Interface requirements document

IRFNA Inhibited red fuming nitric acid

ITER International thermonuclear experimental reactor

JOGSE JOG System Engineering

LCC Life-cycle cost

LCT Lowest common team

LOX Liquid oxygen

LSA Logistics support analysis

MBS Manufacturing breakdown structure

MID Modeling ID

MoD Ministry of Defense

MoDAF Ministry of Defense Architecture Framework

MOE Measure of effectiveness

MRA Manufacturing requirements analysis

MSA Modern structured analysis

MTBF Mean time between failures

MTBM Mean time between maintenance

MTTR Mean time to repair

NASA National Aeronautics and Space Administration

NATO North Atlantic Treaty Organization

NCOSE National Council on Systems Engineering

OMG Object modeling group

OOA Object-oriented analysis

ORD Operational requirements document

OTE Operational test and evaluation

PCA Physical configuration audit

PCB Parts control board

PDR Preliminary design review

PERT Program evaluation and review technique

PIT Program integration team

PMP Parts materials and processes

PMP Parts materials and processes selection list

PPEM Process product entity matrix

PSARE Process for system architecture and requirements engineering

PSL Program specifications library

QFD Quality function deployment

RAS Requirements analysis sheet

RID Requirement ID

RS Raw score (in a trade study)

SAC Strategic air command

SADT Structured analysis definition tool

SAR System architecture report

SBD Schematic block diagram

SCA Sneak circuit analysis

SCD Specification change notice

SDR System design review

SEMP Systems engineering management plan

SEP System engineering plan

SESM Specialty engineering scoping matrix

SOW Statement of work

SRA System requirements analysis

SRD System requirements document

SRR System requirements review

SRS Software requirements specification

SW Software

SysML System modeling language

TAAF Test analyze and fix

TBD To be determined

TBR To be resolved

TLCSC Top-level computer software component

TPM Technical performance measurement

TQM Total quality management

TRA Teledyne Ryan Aeronautical

TSA Traditional structured analysis

TV Trade value (in a trade study)

UADF Universal architecture description framework

UML Unified modeling language

UPDM Unified process for DoDAF MoDAF

USAF United States Air Force

USA United States of America

USSR Union of Soviet Socialist Republics

UV Utility value (in a trade study)

VCRM Verification cross reference matrix

VDC Volts DC

VPA Verification planning analysis

WBS Work breakdown structure

WT Weight (in a trade study)

Preface

The serious study of the practice of how to determine the appropriate content of a specification is a seldom-appreciated pastime. Those who have the responsibility to design a product would prefer a greater degree of freedom than permitted by the content of a specification. Many of those who would manage those who would design a product would prefer to allocate all of the project funding and schedule to what they consider more productive labor. These are the attitudes, of course, that doom a project to defeat but they are hard to counter no matter how many times repeated by design engineers and managers. A system engineer who has survived a few of these experiences over a long career may retire and forget the past but we have an enduring obligation to work toward changing these attitudes while trying to offer younger system engineers a pathway toward a more sure success in requirements analysis and specification publishing.

This is the third attempt I have made to capture the essence of an effective process for accomplishing requirements analysis to expose the proper content of a specification. The first attempt was a book published by McGraw-Hill in 1993 with the title System Requirements Analysis. It was based on work done at General Dynamics Space Systems Division as the Systems Development Department Manager. The method was dominated by functional analysis. Since that time I have been the owner of JOG System Engineering, a system engineering consulting and training enterprise for which I have taught the subject of this book over 120 times at universities, in private and public courses for short course companies, and at companies through direct sale by my company. As a result I have been exposed to many theories about how to teach others how to do this work and have tried to capture the good ideas and to ignore the bad ones as the book has progressed to another publisher, and two more recent editions of the book.

For a very long time I have been convinced that all requirements should be derived through modeling but there have been so many different models developed beyond the functional method I used exclusively as a younger man. In 2009 it finally dawned on me that all of the very smart people who have developed new models could be right. Each of these models seems to expose the same central ideas but each has its own unique strengths. I was fortunate in having a paper titled Universal Architecture Description Framework published in Systems Engineering, the Journal of the International Council on Systems Engineering Volume 12, Number 2, Summer 2009 not long after I had turned in the manuscript for the previous Elsevier book under this title. It has required the past several years to polish the edges of the ideas expressed in that paper through exposure to critical comment from students in tutorials and courses on this subject.

The result is captured in this edition integrated with the complete story. That story includes three Universal Architecture Description Framework (UADF) that are immediately identifiable: functional, MSA-PSARE, and UML-SysML. Plus a fourth possible candidate in the form of an extended unified process for DoDAF MoDAF (UPDM). The book includes an encouragement that an enterprise select one of these UADF, select a tool set compatible with it, educate personnel in the application of the model and tool set, and over time continue to improve through repetition of a common process on all programs.

This book also improves upon an earlier proposition that all requirements derived through modeling be traceable to the modeling artifacts from which they were derived requiring a unique means of identifying every artifact from which requirements could be derived no matter the UADF selected. The suggestion is also advanced that a development program should capture the modeling artifacts in a fashion that they can be retained in a configuration-managed baseline in a set of paper documents or computer files.

Each of the UADF offered is formed by a set of problem-space models and solution-space models. The former deals with the problem one is trying to solve expressed in functional or behavioral descriptions, while the latter deals with the physical perspective after the product entities and interfaces have been identified through application of the problem-space models. The solution-space models cover interface, specialty engineering, and environmental requirements while problem-space models are employed in identifying product entities, interfaces, and performance requirements related to them.

Recent consulting experiences have helped me clarify exactly why programs have so much difficulty accomplishing verification work affordably and the problem occurs at the hand off between requirements work and verification work related to the assignment of principal engineers for each verification task. The story on solving this problem begins in this book and is carried forth in a new edition of my System Verification book.

1

Introduction

The first chapter begins with an introduction to the work this volume focuses on. Many of the subject-matter words the reader will find throughout the book are defined and explained. One of the key ideas that supports the use of the word affordability is that the book encourages the use of models and shows ways that all requirements appearing in all specifications can be derived from models and in the second section we will introduce the idea of modeling. Requirements work is what a program begins with, so it is appropriate to discuss the management infrastructure within which it and later program phases will occur. Some variations on a central theme are also discussed. Closing out this chapter will be an insight into a proposed prescription for achieving an effective system development process that is affordable to apply while producing good program results.

The overall objective of the book is to show system engineers how to accomplish the early program work related to developing the program peculiar specifications needed to define the problem that must be solved through design, procurement, and manufacture. A companion volume titled System Verification completes the story by covering how a program may determine and to what extent the manufactured product complies with the content of the specifications.

The book and its first chapter begin with an introduction to the work this volume focuses on. Many of the subject matter words the reader will find throughout the book are defined and explained. One of the key ideas that support the use of the word affordability is that the book encourages the use of models and shows ways that all requirements appearing in all specifications can be derived from models and in the second chapter we will introduce the idea of modeling. Requirements work is what a program begins with so it is appropriate to discuss the management infrastructure within which it and later program phases will occur. Some variations on a central theme are also discussed. Closing out this chapter will be an insight into a proposed prescription for achieving an effective system development process that is affordable to apply while producing good program results.

The overall objective of the book is to show system engineers how to accomplish the early program work related to developing the program-peculiar specifications needed to define the problem that must be solved through design, procurement, and manufacture. A companion volume titled System Verification completes the story by covering how a program may determine to what extent the manufactured product complies with the content of the specifications.

1.1 Introduction to Systems Requirements

1.1.1 What Is a System?

This book deals with man’s efforts to develop systems. Many definitions of the word system have been offered, but in the broadest and most simple sense, any two or more entities interacting cooperatively to achieve some common goal, function, or purpose constitutes a system. Thus systems are composed of entities that interact together through relationships and with their environment. The content of this book applies most appropriately to man-made systems that are organized collections of entities that interact synergistically via the interfaces connecting them to achieve preplanned goals in accordance with a predetermined plan or process. Generally, in these kinds of systems, no subset of the system resources operating independently can totally achieve the same system goal or purpose, because we tend to create them in a least-cost configuration. The key to system existence, and the superior performance of a system over an unorganized collection of independent objects, is the purposeful cooperative interaction that occurs among the multiple system resources via the interfaces that connect them. So any one system must consist of entities interconnected by relationships, most often referred to as interfaces. A system also interacts with its environment through interfaces.

There exist natural systems in our universe, such as the ultimate system, the universe itself, the climatic system on Earth, and the human circulatory system. These systems evolved through natural processes not requiring any human engineering activity, and a good thing because there were no humans when many of these systems evolved. Some readers may prefer to recognize that natural systems were actually put in place by God. The author neither poses a counterargument to that premise nor recognizes that there would be any significant difference in the content of this book if that were the case. Natural systems can be characterized using techniques described in this book, but we must recognize one fundamental difference between natural and man-made systems. Natural systems are not designed by people, they simply must be understood and described by people and this is perhaps more of a job for scientists than engineers.

This situation is changing, however. We are manipulating natural systems to an increasingly powerful extent, bordering on redesign on a small scale. As a result, there will likely be an increasing application in the future for organized system engineering methods in natural system fields like biotechnology, agronomy, weather, and aquifers. The requirements impact analysis approach discussed in this book in association with engineering change proposals and environmental requirements analysis may apply to these situations more than we would care to think about. A TRW (Thompson, Ramo, Woolridge who were the three gentlemen forming this company) systems engineer working on the Yucca Mountain nuclear waste storage site once told the author that the developer first had to identify the degree of isolation provided between the stored material and the local aquifer offered by government furnished property (GFP) before determining what man-made features were required. The author asked how GFP was involved and the engineer replied—No, God-furnished property.

A man-made system is developed to achieve a preplanned function, goal, or purpose. These systems require engineering development work to convert the preplanned function, goal, or purpose into a practical solution composed of physical hardware elements that can be manufactured and assembled from available materials. Most often, these systems will also include computer software and, commonly, human operators who interact with the hardware and software to guide the system toward its function, goal, or purpose. Finally, these systems will include relationships implemented through interfaces between the product entities composing the system. Figure 1.1 shows three ways systems are illustrated at the very top level and related to their environment using models that we will discuss in this book.

Figure 1.1 The ultimate system abstraction. (A) traditional, (B) modern structured analysis, and (C) unified modeling language.

Figure 1.1A illustrates the ultimate abstraction for a system in the form of a single block that represents the complete system. It interacts with a system environment and internally within itself to achieve the system function, goal, or purpose. To simplify this phrase let us agree to simply refer to the function of a system being its goal or purpose. The system environment consists of everything that influences the system that exists in the Universe, less the system itself. The system function, stated in a customer need statement, is the requirement that is assigned to the system block in this diagram. It is the ultimate requirement for the system that can be mindlessly brought into imaginary existence by the allocation of the customer need to an entity called the system. We often speak of decomposition of the system need, and this is where the decomposition process starts, with the ultimate requirement. The two fundamental blocks shown in Figure 1.1 are interrelated by three different kinds of interfaces identified as I1, I2, and I3 that will be explained in a later section.

Using a functional modeling process we can progressively decompose or partition the functionality represented by the need into lower-tier functionality as a means of gaining insight into what the system and its parts must accomplish and how well it and its many elements must perform. The decomposition process stops when we have identified all of the system resources that will yield to detailed design by a single design agent or team in the producing enterprise or can be procured from a single supplier. In the late 1990s, the author, trying to impress a manager on the International Thermonuclear Experimental Reactor (ITER) program, then based in La Jolla, California, and thus encourage him to purchase a system engineering training program, showed the manager his schematic block diagram (SBD) of the universe. The author, thinking that the universe included everything there was, illustrated only one block on the diagram containing everything rather than the two-block arrangement shown in Figure 1.1A. The diagram in question will appear in the section dealing with environmental requirements analysis. The manager looked at the diagram briefly and said, You may have forgotten a few wormholes. A contract was not forthcoming so that may not have been a good marketing technique. Chapter 3 of this book covers the functional analysis (FA) approach depicted in Figure 1.1A in considerable detail. Performance requirements are derived from functions and allocated to product entities thereby identifying lower-tier system entities.

Figure 1.1B offers the ultimate system view from the perspective of an adherent of modern structured analysis (MSA) used for many years, and to this day, by some to develop computer software. The system, whatever it may become during the development process, is shown interacting with several (three in this case) external entities called terminators. This is a very useful diagram no matter what modeling approach one might employ. A context diagram can also be used to identify all of the parties interested in the development effort, often called stakeholders. In the case of MSA these terminators relate to sources and destinations of information. When we extend MSA to the process for system architecture and requirements engineering (PSARE), initially called Hatley–Pirbhai modeling, in Chapter 4 we will find that the terminators can be information, energy, or material because PSARE was developed so as not be limited to software development as MSA was intended.

Figure 1.1C illustrates a system from the perspective of an adherent of system modeling language (SysML) or unified modeling language (UML). Actors interact with the system through what are called use cases achieving specific benefits in so doing. Modeling artifacts are then employed to describe these benefits from which requirements are derived. Chapter 4 also covers the model depicted in Figure 1.1C.

This book covers three comprehensive modeling approaches coordinated with the three top-end views in Figure 1.1. A forth modeling approach, also addressed in the book involves over 50 modeling artifacts and the author cannot think of a simple view of the overall process that could be included in Figure 1.1. The U.S. Department of Defense (DoD) has shown great interest in a development model named DoDAF for DoD Architecture Framework. This interest has been extended through cooperation with the UK Ministry of Defence (MOD) under the acronym MODAF. It was initially developed to model large-scale information systems but was initially not appropriate as a comprehensive general system modeling approach like the other three brought together in Chapter 6. Chapter 4 provides an overview of this process in the interest of completeness and recognizes the continuing work being done since 2004 by the Unified Process for DoDAF MoDAF (UPDM) RFC Group composed of several companies in cooperation with the U.S. DoD and UK MOD to advance the use of the modeling artifacts of UML-SysML rather than whatever modeling artifacts the customer, team, or program prefers. In Section 6.5, we also extend the model so that it may be used as a single model that can be used to define the system architecture and support derivation of all requirements that will populate specifications no matter how the system is to be implemented in terms of hardware, software, and people doing things.

The author maintains that all requirements appearing in specifications should be derived through modeling. The author’s set of comprehensive modeling approaches started with three useful models for doing this work covered in Chapters 3 through 5 with the beginnings for them noted in Figure 1.1. With the emergence of UPDM the author has grudgingly added it to form a forth comprehensive modeling approach from which an enterprise may select a single model and encourage its employees to become proficient in using that one model on all programs.

The book focuses the modeling artifacts thus described on four specific universal architecture description frameworks (UADFs) in Chapter 6 and offers encouragement that a systems development enterprise select one, coordinate it with an effective tool set, qualify its employees to effectively use the selected modeling methods and selected tools, and manage the whole well. In a nutshell, this is the beginning of the prescription for achieving affordability and success in requirements and verification. Chapter 6 offers an extended version of UPDM as a forth UADF such that an enterprise required by contract to employ DoDAF may use the UPDM version extended to include modeling elements that support environmental and specialty engineering modeling to also support specification content development in a single modeling approach.

The modeling capability of the problem space components of these four UADF are effective in: (1) identifying needed functionality or behavior, (2) deriving appropriate performance requirements from that functionality, (3) identifying the product entities that the system should consist of, and (4) identifying the interface relationships that will have to exist between the product entities and between the system and its environment. We will have to add to each of the first three UADF an additional trio of solution space models to complete the work begun under the problem space components of these three UADF. The three problem space models are covered in Chapters 3 and 4. In addition to these modeling capabilities they must be combined with the solution space models covered in Chapter 5 for interface, specialty engineering, and environmental requirements though MSA-PSARE, UML-SysML (and therefore UPDM) do include adequate interface modeling capability. All or parts of these three models can be coordinated with any of the three UADF to form four complete models each one of which is comprehensive meaning that it may be used to derive all requirements for all entities in a system no matter how we decide to implement the system in terms of hardware, software, and people doing things. These four UADF are then brought together in Chapter 6.

1.1.2 Types of Systems

The central premise of this book is that new systems are most advantageously developed using modeling but this is a conditional premise. There are different kinds of systems and the same development approach will not necessarily work equally well for all kinds. In the search for a truly comprehensive and universal development approach it has been concluded from a study of many systems that all development programs and the systems they create may be partitioned into three sets: (1) unprecedented, (2) precedented, and (3) mixed.

1.1.2.1 Development of Unprecedented Systems

An unprecedented development situation is realized when an enterprise must develop a new system of a kind they have no experience in developing. The problem may be either universally unprecedented (no one has ever solved the problem) or locally unprecedented (the developer has never solved the problem before). Clearly, this work will be more difficult if no one has ever developed a system of this kind as in the case of the first stealth aircraft, the first locomotive, or the first electric lighting system. While the author encourages that unprecedented systems can most effectively be developed using the methods covered in this book involving an opening modeling approach to clearly define the problem as a precedent to solving it, some very smart people have in the past been very successful in the solution of unprecedented problems using an intuitive approach that does not entail a lot of order and discipline. There are those among us who still believe that the practice of systems engineering is a costly and unnecessary indulgence despite the avalanche of data showing the life-cycle cost trace of programs where an effective systems engineering approach was accomplished early, while possibly costing more in the beginning over a program experimenting with the alternatives, reduces later program development and life cycle use cost substantially. In this book we will set these champions aside because they are the exception and can only be successful where they have adequate financial resources to weather early failures. Most customers would prefer an organized development plan be applied following a tried and proven approach. Such an approach calls for the development of a set of specifications coordinated with a concurrent effort to identify design concepts that validate the content of those specifications leading them to a determined effort to design products that comply with the content of the specifications.

There are many ways to prepare and publish specifications all of which, the good and the bad, will be discussed in this book. But, if we wish to be able to do so affordably and successfully we must use modeling. The author believes the more unprecedented the problem space the more emphatically imperative it is that modeling be done well, despite the counterclaims by some people suggested in the previous section.

The problem and solution space modeling approaches, covered in many books that have been practiced on many programs can be effective in piecewise modeling subsets of a total problem space that will be the basis for a particular unprecedented system on a development program. This book will point out that none of these modeling approaches are comprehensive permitting just one of them to be used for the derivation of every requirement for every part of every system in which you might become involved in developing. Section 1.5 offers an affordable prescription involving the application of one of four comprehensive modeling approaches within the context of an overall effective systems development infrastructure. Chapters 3–5 of this book offer detailed descriptions of the parts of these four model sets and Chapter 6 provides chapters that focus on each of the four.

1.1.2.2 Development of Precedented Systems

If we are faced with a precedented problem space where a development action taking place at some time in the past produced a system that can be observed functioning somewhere in the world but either the program did not capture the modeling basis or the work products that were created have been lost, we may choose to precede the selective design process with an overall problem space modeling development process using one of the four UADF suggested in this book.

Precedented problems do exist combined with development enterprise situations that can encourage the application of problem space modeling to precedented developments also. In his consulting work, the author encountered one case where an enterprise was planning a new product development with a well-understood historical precedent but found that their competition was winning the marketing battles based on the performance of their product in three specific areas. The enterprise chose to establish a system engineering department where there had never been one previously and applied a clean sheet of paper approach employing modeling and effective requirements analysis techniques. This enterprise realized that one expression of insanity is continuing to do what you are doing expecting a different outcome. They chose to change their development approach to adopt an effective system development process calling for the application of an effective systems requirements effort as the beginning.

Today, the money is commonly not available to undertake substantial unprecedented development efforts and we find organizations like the U.S. DoD embracing spiral development rather than the traditional waterfall approach that permits evolution of new capabilities using a cyclical or evolutionary approach to satisfying the ultimate need and uniting families of previously independent systems characterized by weak linkages into Earth circling systems that are able to apply tremendous leverage to hostile forces. Much of this work revolves around the development or knitting together of precedented systems.

The reality today is that many military, space, and commercial systems that are developed are heavily precedented based on a prior history of development of similar systems that exist in the real world and can be observed functioning if one simply travels to a particular place on Earth. The development of the 2014 Chevrolet will likely be such a development unless General Motors has a breakthrough in a new form of propulsion between now and then. It is also likely that the B52 will pass through at least one more development effort before all models finally take up final residence in the Tucson, AZ bone yard.

In the case where the problem space modeling and specifications exist for the old system, we can dispense with trying to re-create it. We should first make sure we clearly understand the need associated with the new system being developed. We can then compare the functionality of the new system with the old system functionality and then apply the functional differential to the existing product entity structure.

The process of applying the functional differential to the old product entity structure is accomplished in this and the prior case by determining for each entity in the old product entity structure which of the following apply.

1. Okay as is.

2. Suitable for use with modification.

3. Unsuitable for use in the new system and may require replacement or reconfiguration of the system to accomplish the related functionality elsewhere.

4. There exists nothing in the existing system that can accomplish new functionality calling for the addition of a new item to the system.

We will accept the design of all of those elements from the old system that are determined to be okay as is. Those items that must be modified will require an analysis to determine how that should be done. Any new items will similarly require some form of analysis. Our analysis should explore the needed functional differential resulting in an update of the available models for the results, editing of the product entity and interface models accordingly, and editing of the specifications previously prepared for the new and modified system entities. That is, we will accomplish a problem and solution space modeling activity on the new and modified entities resulting in an effective model for the new system. If the complete system data set is missing including the engineering drawings, a more radical approach will be required probably involving reverse engineering all of the product entities as well as the problem and solution space modeling and specifications.

1.1.2.3 Development of Systems with a Mixed Legacy

Systems are commonly composed of systems and some parts of large systems may fall into the unprecedented case while other parts are properly precedented in nature. That is of no mind because any system view will fall into only one class at the level it is being considered. Subordinate elements of that system may partition between the two classes but at the level of interest it will be one or the other. In a large development, or the integration across previously developed systems being accepted into a grander view of a system, one will commonly find a mix of classes but each can be dealt with in accordance with a set of rules that apply to precedented and unprecedented systems within its own scope. This is a very common case in many systems today where we find needs being satisfied by linking together several previously independently developed systems. At one time the U.S. Navy did not view a complete ship as a system but now a ship is but a node in a grand system with its parts linked together into networks.

1.1.2.4 Emergent Behavior

In the first section of this book it was said that a system was an organized collection of entities that interact synergistically via the interfaces connecting them to achieve preplanned goals in accordance with a predetermined plan or process. Enterprises involved in the development of some systems today and in particular military systems that are said to be systems of systems often find that unexpected features, functions, characteristics, or opportunities emerge over the development period or even in early testing and operation. It may seem that this occurrence contradicts the earlier claim. The reality is that we do the best we can with what we can know early in the development of a new system or collection of systems but it is very hard to know everything of interest about a system under development by multiple organizations at the time when it would be most helpful for the smooth evolution of the overall program.

The author maintains that one of the modeling approaches covered in this book offers the best opportunity for the timely selection or discovery of characteristics of systems no matter how complex the problem space and program organizational structure. But, it is critically important that the system engineers doing the modeling work early in the development effort really understand what they are doing in their modeling work relative to their customer’s mission intent. A slavish devotion to modeling and computer implementations of those models is not a healthy attitude. We model in an effort to understand a problem space. Persons doing this work should have a broad enough perspective to deal with both the realities of that problem space and the modeling of it without becoming lost in the model of the space.

Many managers and system engineers refer to many systems having emergent behaviors meaning that over time during development, verification, and use a system may be detected to possess characteristics that were not consciously intended. Some of these characteristics may be advantageous and others less so. Should our development efforts be intended to exclude any emergent behaviors? In the development work associated with systems that do require a large degree of complexity it may be more than the development force can do to consciously identify and exclude all such behavior. We might be better off to model and develop a system to the best of our ability to satisfy the customer need while maintaining an interest in identifying any capabilities not intended and either excluding those found to be disadvantageous and encouraging those that are advantageous.

1.1.3 The Word Affordable

The word affordable and the term system development are not thought to properly fit into the same sentence by many people some of whom have had to pay the price for development of a system. The fact is that systems, whatever they are, can be developed well or badly, affordably or outrageously expensively. That customers deserve well and affordable but do not always get that combination is true. This book makes the claim that it is possible, however, to achieve both characteristics in a delivered system. It is a fact that money spent well in early development work can reduce the slope of the cost curve later in development and significantly reduce life-cycle cost. Granted, one may have to spend more money in the beginning to achieve this outcome but the total program cost will be less.

1.1.4 Onward to a Model

This ultimate view of a system and its environment shown in Figure 1.1 is important because in developing new (unprecedented) systems we commonly do not have knowledge of the details. What we have is a very high-level view of our need and most often from an operational perspective dealing with solving a particular problem. This top-level beginning point happens to fit together well with the ideas of Louis Sullivan, an architect in the late nineteenth and early twentieth centuries, who thought that … form should ever follow function. That is, in developing a solution to a complicated problem we should first try to understand the needed functionality and base the form of the solution on that functionality. Thus in our modeling efforts we will first attempt to understand the customer’s need as the ultimate expression of system function or behavior. We will then apply decomposition of that functionality and a means by which we can associate functionality with product entities at the system and subordinate levels.

So far the book has used the word modeling several times and the word will appear many more times because the book is based on the reality that when we develop systems that have few precedents we have no current model in our existing reality because we have never developed a similar system. The top-level models illustrated in Figure 1.1 express three different modeling approaches that have evolved over the past 50 years and to those we will add one more. Each of these four modeling approaches offers interesting insights into an effective system development process but the time is long past when we should find a single universal way to model systems. It is a goal of this book to do so even if we have to accept four as a temporary plateau.

In so doing, the book must also provide methods for understanding the needed relationships between the product systems and the environment in terms of the environmental influences on the product as well as what is called environmental impact, which covers the negative influences on the natural environment by our system. The environment is actually much grander than the natural environment. In addition to the natural environment, we need to consider hostile systems effects, cooperative systems interfaces, and noncooperative systems influences. Also, certain aspects of some systems interact with the natural environment to feed back potentially damaging effects called self-induced environmental effects.

We must deal with one other kind of system while developing systems, the system that gives birth to the product system, that we humans are members of. There was a time when engineers believed that it was sufficient to optimize the product at the system level. We should recognize that we need to optimize at the aggregate system level, including the product and the process. In this book, we consider two components of this creator system: the processes, such as manufacturing, quality assurance, materials, logistics, and the programmatic aspect, including the organizational arrangement, funding, scheduling, and management of the process.

1.1.5 The Fundamental System Relation

Many attempts have been made to identify the essence of a system. The model offered here is no better than any other, only the one that the author of the book has used as a frame of reference to sort out what is important in a requirements analysis process description. The model uses elementary set theory but is not intended as a serious mathematical system through which systems are defined and designed. It has exerted some influences the author is probably not aware of in shaping this requirements analysis process description. Ideally, this influence has been in a positive direction. But, if, in the reader’s opinion, this is not the case, this brief explanation of the author’s mental model of system development may be helpful in understanding why the author went astray from the reader’s expectations.

While a field engineer operating on the opposite side of the world from his company, often alone, the author found it necessary to carry a lot of system information in his head. It was not convenient to carry several volumes while flying operational missions as a technical advisor on unmanned reconnaissance aircraft launch missions staged from a DC-130 during the Vietnam War. While it was not possible to remember all the details of the operations and maintenance processes for any given model, it was possible to remember a framework into which things fit, so that, when questions were posed by the customer about particular operations and maintenance practices, answers came to mind as an extension of his economical system context. Some of this information was also classified and could not be easily carried about in paper form. The model exposed here grew out of that experience as a means to quickly identify important information about new systems and organize this information, minimizing its volume in a model to conform to the author’s normal limited memory capacity.

Are there some fundamental entities we can use as a basis for the development of systems? Can we identify some finite list of system descriptors from which all other descriptors can be expanded? This book offers six such descriptors to which every other characteristic of a system can be linked. Systems consist of entities and relations among those entities, and our definition of a system must absolutely establish whether or not any given object is in the system. If it is not, it is in the system’s environment. If it is in the system environment, it will either exert an influence on the system or not. If it does not, it can be disregarded. The entities that compose a system can be organized into a hierarchical tree structure. The complete set of entities that form a system when organized in this manner are collectively referred to as the product entity structure. This always begins with the block illustrated in Figure 1.1A called the system. The system comprises two or more subordinate elements. Each of these may be composed of two or more elements and so on down through the system structure to detailed parts and materials. We will see shortly why it is necessary to organize a system in this hierarchical fashion.

Each of the elemental system descriptors is assigned a modeling ID (MID), such that traceability can be identified and retained for the modeling source from which all requirements were derived. So, product entity is one of these fundamental system descriptors and its MID is a sting of characters beginning with the letter A. At one time the author referred to the product entity structure as a depiction of the system architecture but has come to agree with many other people who more appropriately apply the word architecture in a much broader context to include not only what the system is physically composed of but all of the descriptive modeling elements.

The entities, parts, or objects of the system must interact in useful ways for the aggregate of entities to qualify as a system. The medium for this interaction is called an interface. Each interface element is characterized by two terminals and a media connecting them. An interface is completed either via an element of