SYSTEMS ENGINEERING HANDBOOK
A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

SYSTEMS ENGINEERING HANDBOOK
A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES

INCOSE-TP-2003-002-03
INCOSE SYSTEMS ENGINEERING HANDBOOK, version 3

June 2006

Edited by:

Cecilia Haskins

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

This INCOSE Technical Product was prepared by the Systems Engineering Handbook Development Team of the International Council on Systems Engineering (INCOSE). It is approved by INCOSE for release as an INCOSE Technical Product. Copyright © 2006 by INCOSE, subject to the following restrictions: Author use: Authors have full rights to use their contributions in a totally unfettered way with credit to this INCOSE Technical Product. Abstraction is permitted with credit to the source. INCOSE use: Permission to reproduce this document and use this document or parts thereof by members of INCOSE and to prepare derivative works from this document for INCOSE use is granted, with attribution to INCOSE and the original author(s) where practical, provided this copyright notice is included with all reproductions and derivative works. Content from ISO/IEC 15288:2002(E) are used by permission, and are not to be reproduced other than as part of this total document. External use: This document may not be shared or distributed to any non-INCOSE third party. Requests for permission to reproduce this document in whole or part, or to prepare derivative works of this document for external and commercial use, should be addressed to the INCOSE Central Office, 2150 N. 107th St., Suite 205, Seattle, WA 98133-9009 USA. Electronic version use: Any electronic version of this Systems Engineering Handbook is to be used for personal use only and is not to be placed on a non-INCOSE sponsored server for general use. Any additional use of these materials must have written approval from INCOSE. Permissions: INCOSE has granted permission to member companies of the INCOSE Corporate Advisory Board to post and use this document internally, subject to the external use restriction.

ii
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3 Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

Preface
Objective The INCOSE Systems Engineering Handbook, version 3 (SEHv3), represents a shift in paradigm toward global industry application consistent with the Systems Engineering Vision. The objective for this document is to provide an updated description of the key process activities performed by systems engineers. The intended audience is the new systems engineer, an engineer in another discipline who needs to perform systems engineering or an experienced systems engineer who needs a convenient reference. The descriptions in this handbook show what each systems engineering process activity entails, in the context of designing for affordability and performance. On some projects, a given activity may be performed very informally (e.g., on the back of an envelope, or in an engineer’s notebook); on other projects, very formally, with interim products under formal configuration control. This document is not intended to advocate any level of formality as necessary or appropriate in all situations. The appropriate degree of formality in the execution of any systems engineering process activity is determined by: a. the need for communication of what is being done (across members of a project team, across organizations, or over time to support future activities), b. the level of uncertainty, c. the degree of complexity, and d. the consequences to human welfare. On smaller projects, where the span of required communications is small (few people and short project life cycle) and the cost of rework is low, systems engineering activities can be conducted very informally (and thus at low cost). On larger programs, where the cost of failure or rework is high, increased formality can significantly help in achieving program opportunities and in mitigating program risk. In a project environment, work necessary to accomplish project objectives is considered “in scope;” all other work is considered “out of scope.” On every project, “thinking” is always “in scope.” Thoughtful tailoring and intelligent application of the systems engineering process described in this handbook is essential to achieve the proper balance between the risk of missing project technical and business objectives on the one hand, and process paralysis on the other. Chapter 10 provides tailoring guidelines to help achieve that balance.

iii
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

It is the intention of the SEHv3 steering committee that appendices will be developed to elaborate on significant topics, and that these appendices will be available on-line to members in the INCOSE Product Asset Library (IPAL). The addition of these on-line descriptions, work sheets, checklists, and how-to guides will evolve over time, and it is anticipated that all INCOSE members, working groups, and Corporate Advisory Board member companies will contribute to the creation of this resource. Actual content will be under the control of the IPAL working group. Approved: Terje Fossnes, Chair, INCOSE SEHv3 Development Team Kevin Forsberg, Co-Chair, INCOSE SEHv3 Development Team Eric Aslaksen, INCOSE Associate Director, Technical Review Samantha Brown, INCOSE Technical Director

iv
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Acknowledgments The INCOSE Systems Engineering Handbook version 3 development team owes a debt of gratitude to all the contributors to prior editions (versions 1, 2, and 2a). The framework they provided gave a solid basis for moving ahead with this version. However this present document represents a significant departure from its predecessors since the goal was to create a shorter document consistent with the international standard ISO/IEC 15288:2002(E) – Systems engineering – system life cycle processes. As a result, we will not list all the contributors to earlier versions; interested readers are referred to the acknowledgment pages in those documents. We want to thank the two co-chairs who worked with us in the formative stages of this handbook: John Leonard and Jim Chism. They provided valuable guidance and leadership in the difficult transition from a handbook based on the earlier versions to one based on ISO/IEC 15288. It would be difficult to accurately characterize the specific contributions of each of the volunteers – section leads, steering committee, authors, and reviewers. Many served in multiple roles. A great deal of effort and enthusiasm was provided by the section leads and key authors, most of who also served on the steering committee. We acknowledge them in alphabetical order: Karen Bausman, Joe Carl, Sandy Friedenthal, Karl Geist, Ken Kepchar, Mike Krueger, Harold Kurstedt, Sean O’Neill, Mike Persson, Mary Redshaw, Andy Schuster, L. Mark Walker, and Jim Whalen. The steering committee also included the following people: Howard Eisner, Gerard Fisher, Richard Kitterman, David Long, William Mackey, and Paul Robitaille. The review team lead by Erik Aslaksen included in alphabetical order: Jonas Andersson, Lily Birmingham, Samantha Brown, John Clark, Michael Eagan, Ayman El-Fatatry, Patrick Hale, Jorg Lalk, Harold Lawson, Virginia Lentz, William Miller, Juan Miro, John Muehlbauer, Robert Peffer, Robert Porto, John Quitter, Tom Strandberg, Dan Surber, and David Walden. In addition, representatives from the INCOSE Hampton Roads Area Chapter, the Swedish chapter, the Requirements Working Group, and the AIAA Technical Committee on Systems Engineering provided comments. One of the requirements for this handbook is that it looks and reads as if it were written by a single person, and the reviewers all felt this objective has been met successfully. The co-chairs wish to thank our editor, Cecilia Haskins, for her dedication, and contributions to achieve this result. We apologize in advance if we omitted anyone from this list in the final minutes before going to production. Gratefully, Terje Fossnes and Kevin Forsberg v Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

vi
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Table of Contents
1 SyStemS engineering Handbook Scope ......................................................1.1 1.1 1.2 1.3 1.4 1.5 1.6 2 2.1 2.2 2.3 2.4 2.5 2.6 3 Purpose ....................................................................................................1.1 Application...............................................................................................1.1 Contents ...................................................................................................1.1 Format ......................................................................................................1.4 Definitions of frequently used terms .......................................................1.4 References ................................................................................................1.5 Introduction .............................................................................................2.1 Definition of systems engineering...........................................................2.1 Origins of systems engineering .............................................................. 2.2 Systems of systems ................................................................................. 2.2 Use of systems engineering .................................................................... 2.5 Value of systems engineering ..................................................................2.7

SyStemS engineering overview ...................................................................2.1

generic Life cycLe StageS ............................................................................3.1 3.1 Introduction .............................................................................................3.1 3.2 Life Cycle Characteristics .......................................................................3.1 3.2.1 Three Aspects of the Life Cycle ..........................................................3.1 3.2.2 Decision Gates .................................................................................... 3.2 3.3 Life Cycle Stages .................................................................................... 3.3 3.3.1 Pre-Concept Exploratory Research Stage ...........................................3.6 3.3.2 Concept Stage.......................................................................................3.7 3.3.3 Development Stage ..............................................................................3.7 3.3.4 Production Stage ................................................................................. 3.8 3.3.5 Utilization Stage.................................................................................. 3.8 3.3.6 Support Stage ...................................................................................... 3.8 3.3.7 Retirement Stage ..................................................................................3.9 3.4 Development Stage Approaches ..............................................................3.9 3.4.1 Plan-driven Development ....................................................................3.9 3.4.2 Incremental and Iterative Development .............................................3.10 3.4.3 What is best for your organization? ................................................... 3.11 3.5 Introduction to three cases ....................................................................3.12 3.5.1 Case 1: Radiation Therapy; the Therac-25 ........................................3.13 3.5.2 Case 2: Joining two countries; the Øresund Bridge ..........................3.14 3.5.3 Case 3: Prototype system; The Super-high-speed train in China ..... 3.17

4

tecHnicaL proceSSeS ......................................................................................4.1 4.1 4.2 4.3 Introduction .............................................................................................4.1 Stakeholder Requirements Definition Process ....................................... 4.2 Requirements Analysis Process ............................................................. 4.4 vii Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

Edited by Foxit Reader INCOSE Systems Engineering Handbook v. 3 Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7

Architectural Design Process ..................................................................4.7 Implementation Process ......................................................................... 4.9 Integration Process ................................................................................4.11 Verification Process ...............................................................................4.13 Transition Process..................................................................................4.14 Validation Process .................................................................................4.16 Operation Process ..................................................................................4.17 Maintenance Process .............................................................................4.19 Disposal Process ....................................................................................4.21 Introduction .............................................................................................5.1 Project Planning Process ........................................................................ 5.2 Project Assessment Process.....................................................................5.4 Project Control Process .......................................................................... 5.5 Decision-Making Process ........................................................................5.7 Risk and Opportunity Management Process ..........................................5.9 Configuration Management Process ..................................................... 5.11 Information Management Process ........................................................5.13 Introduction .............................................................................................6.1 Enterprise Environment Management Process ...................................... 6.2 Investment Management Process ........................................................... 6.5 System Life Cycle Processes Management Process ...............................6.7 Resource Management Process .............................................................6.10 Quality Management Process................................................................6.12 Acquisition Process ...............................................................................6.15 Supply Process .......................................................................................6.18

project proceSSeS ...........................................................................................5.1

enterpriSe and agreement proceSSeS ........................................................6.1

enabLing SyStemS engineering proceSS activitieS .................................7.1 7.1. Decision Management .............................................................................7.1 7.1.1. Decision Gates .....................................................................................7.1 7.1.2 Making Difficult Decisions..................................................................7.3 7.1.3 Trade Study and Sensitivity Analysis ..................................................7.5 7.2 Requirements Management .....................................................................7.6 7.2.1 Elicit and Capture Requirements .........................................................7.6 7.2.2 Systems Modeling Language (SysML)................................................7.7 7.2.3 Concept of Operations .........................................................................7.8 7.2.4 Define systems capabilities and performance objectives .................. 7.10 7.2.5 Technical Performance Measures ...................................................... 7.11 7.2.6 Define other non-functional requirements......................................... 7.12 7.3 Risk and Opportunity Management ...................................................... 7.12 7.3.1 Concepts ............................................................................................. 7.13 7.3.2 Risk Identification .............................................................................. 7.15 viii Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

7.3.3 7.3.4 7.3.5 7.3.6 8

Risk Assessment ................................................................................ 7.16 Risk Handling .................................................................................... 7.17 Risk Tracking and Control ................................................................. 7.17 Risk Mitigation .................................................................................. 7.18

SyStemS engineering Support activitieS ..................................................8.1 8.1 Acquisition and Supply............................................................................8.1 8.2 Architectural Design .............................................................................. 8.2 8.2.1 Interoperability Analysis .................................................................... 8.3 8.2.2 Manufacturing and Producibility Analysis ........................................ 8.4 8.3 Configuration Management .................................................................... 8.5 8.4 Information Management ....................................................................... 8.6 8.5 Investment Management .........................................................................8.7 8.5.1 Define the Business Case .....................................................................8.7 8.5.2 Cost-Effectiveness Analysis ............................................................... 8.8 8.5.3 Life Cycle Cost Analysis..................................................................... 8.9 8.6 Project Planning.....................................................................................8.11 8.7 Quality Management .............................................................................8.11 8.7.1 Process Compliance Reviews ............................................................8.12 8.7.2 Quality Assurance..............................................................................8.12 8.8 Resource Management ..........................................................................8.13 8.9 Validation ...............................................................................................8.15 8.10 Verification ............................................................................................8.15

9

SpeciaLty engineering activitieS ...............................................................9.1 9.1 Design for Acquisition Logistics – Integrated Logistics Support ..........9.1 9.1.1 “-ilities” influencing the system design ...............................................9.2 9.1.2 “-ilities” analysis methods ...................................................................9.4 9.2 Electromagnetic Compatibility Analysis ................................................9.6 9.3 Environmental Impact Analysis ..............................................................9.6 9.4 Human Factors .........................................................................................9.7 9.5 Mass Properties Engineering Analysis ...................................................9.9 9.6 Modeling, Simulation, and Prototyping ................................................ 9.10 9.6.1 Modeling and Simulation ................................................................... 9.10 9.6.2 Types of Models ................................................................................. 9.11 9.6.3 Prototyping.........................................................................................9.12 9.7 Safety & Health Hazard Analysis .........................................................9.13 9.8 Sustainment Engineering Analysis ....................................................... 9.14 9.9 Training Needs Analysis .......................................................................9.15

10 taiLoring overview .....................................................................................10.1 10.1 Introduction ...........................................................................................10.1 10.2 Tailoring Process ...................................................................................10.1 10.2.1 Inputs to the Tailoring Process ..........................................................10.2 ix Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

10.2.2 Tailoring Process Activities ...............................................................10.3 10.2.3 Control of the Tailoring Process ........................................................10.4 10.2.4 Enablers of the Tailoring Process ......................................................10.5 10.2.5 Outputs from the Tailoring Process ...................................................10.5 10.3 Traps in Tailoring ..................................................................................10.5 appendix a: SyStem Life cycLe proceSS n-Squared cHart per iSo/iec 15288 ..................................................................................... a ppendx-1 . appendix b: acronym LiSt ...................................................................... appendx-3 appendix c: termS and definitionS ...................................................... appendx-5 . appendix d: comment form ................................................................. appendx-11

x
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

List of Figures and Tables figure 1-1 tabLe 1-1 figure 1-2 tabLe 2-1

System Life Cycle Processes Overview per ISO/IEC 15288 ............. 1.2 Systems Engineering Process Activities Overview ............................1.3 Sample of Context Diagram for Process..............................................1.4

Important Dates in the Origins of Systems Engineering as a Discipline ..................................................................................... 2.2 figure 2-1 Example of the multitude of perceivable systems-of-interest in an aircraft and its environment of operation within a Transport Systemof-Systems ........................................................................................... 2.4 figure 2-2 Digital Camera and Printer Systems of Systems ................................ 2.5 figure 2-3 Committed Life Cycle Cost against Time .......................................... 2.6 figure 2-4 In the last century, the time from prototype to significant market penetration is dramatically reduced.....................................................2.7 figure 2-5 Cost and schedule overruns correlated with systems engineering effort ................................................................................................... 2.8 figure 3-1 tabLe 3-1 figure 3-2 figure 3-3 figure 3-4 figure 3-5 figure 4-1 figure 4-2 figure 4-3 figure 4-4 figure 4-5 figure 4-6 figure 4-7 figure 4-8 figure 4-9 figure 4-10 figure 4-11 figure 4-12 figure 5-1 tabLe 5-1 figure 5-2 figure 5-3 figure 5-4 figure 5-5 figure 5-6

Generic Business Life Cycle .............................................................. 3.2 Life cycle stages, their purposes, and decision gate options ...............3.4 Comparison of life cycles.................................................................... 3.5 Left side of the Vee model ...................................................................3.6 Right side of the Vee ........................................................................... 3.8 IID and Evolutionary Development1 ................................................. 3.11 Context of Systems Engineering Technical Processes1 ......................4.1 Context Diagram for Stakeholder Requirements Definition Process ............................................................................... 4.2 Context Diagram for the Requirements Analysis Process ................. 4.5 Context Diagram for the Architectural Design Process......................4.7 Context Diagram for the Implementation Process ............................. 4.9 Context Diagram for the Integration Process ....................................4.11 Context Diagram for the Verification Process ...................................4.13 Context Diagram for the Transition Process .....................................4.15 Context Diagram for the Validation Process .....................................4.16 Context Diagram for the Operation Process......................................4.18 Context Diagram for the Maintenance Process ................................ 4.20 Context Diagram for the Disposal Process....................................... 4.22 Project Management/Systems Engineering Overlap ...........................5.1 Acronym List........................................................................................5.1 Context Diagram for the Project Planning Process ............................ 5.2 Context Diagram for the Project Assessment Process ........................5.4 Context Diagram for the Control Process............................................5.6 Context Diagram for the Decision-making Process ........................... 5.8 Context Diagram for the Risk Management Process ........................5.10 xi Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

figure 5-7 figure 5-8 figure 6-1 figure 6-2 figure 6-3 figure 6-4 figure 6-5 figure 6-6 figure 6-7 figure 6-8 figure 7-1 figure 7-2 figure 7-3

Context Diagram for the Configuration Management Process .........5.12 Context Diagram for the Information Management Process ............5.14 Key Success Factors for Enterprise Processes ................................... 6.2 Enterprise Environment Management Process Context Diagram ..... 6.3 Investment Management Process Context Diagram .......................... 6.5 SLC Processes Management Process Context Diagram .................... 6.8 Resource Management Process Context Diagram ............................6.10 Quality Management Process Context Diagram ...............................6.13 Acquisition Process Context Diagram ...............................................6.16 Supply Process Context Diagram ......................................................6.19

Decision Gates synchronize project activities .....................................7.2 Decision Tree for a “Bid – No Bid” Decision .......................................7.4 Requirements elicitation captures the needs of stakeholders, operators and users across systems boundaries ..................................7.7 figure 7-4 SysML Diagram Types ........................................................................7.8 figure 7-5 TPM Monitoring ................................................................................ 7.12 figure 7-6 Level of risk depends upon both likelihood and consequences ........ 7.13 figure 7-7 Typical Relationship among the Risk Categories .............................. 7.14 figure 8-1 figure 8-2 figure 8-3 figure 8-4 figure 8-5 figure 8-6 figure 8-7 figure 9-1 figure 9-2 figure 9-3 figure 9-4

Example of Alternative Architectural Concepts ................................ 8.2 Requirements changes are inevitable ................................................. 8.5 AP233 facilitates data exchange ..........................................................8.7 Life Cycle Cost Elements (not to scale) .............................................. 8.9 Banner from Ford quality campaign..................................................8.13 Shorter delivery time with concurrent development vs. traditional ...........................................................................................8.14 A test platform for analyzing battery performance at high loads ...........................................................................................8.17

Generic Context Diagram for Specialty Engineering Activities.........9.1 Acquisition Logistics Activities...........................................................9.2 The Spitfire: A perfect balance of -ilities? ...........................................9.5 Ergonomics Engineering Minimizes Risks to System Stakeholders .........................................................................................9.8 figure 9-5 Unique Teapot Shown on Book Cover .................................................9.9 figure 9-6 Protective clothing for Hazmat Level A and bird flu ........................ 9.14 figure 10-1 Tailoring requires balance between risk and process ........................10.2 figure 10-2 Tailoring Process Context Diagram...................................................10.2

xii
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

1 Systems Engineering Handbook Scope
1.1 Purpose
This handbook defines the discipline and practice of systems engineering (SE) for student and practicing professional alike. This handbook provides an authoritative reference to understand the discipline in terms of content and practice.

1.2 Application
This handbook is consistent with ISO/IEC 15288: 2002(E) – Systems engineering – System life cycle processes (hereafter referred to as ISO/IEC 15288) to ensure its usefulness across a wide range of application domains – man-made systems and products, as well as business and services. ISO/IEC 15288 is an international standard that is a generic process description, whereas this handbook further elaborates the processes and activities to execute the processes. Before applying this handbook in a given organization or project, it is recommended that the tailoring guidelines in Chapter 10 be used to remove conflicts with existing policies, procedures and standards already in use. Processes and activities in this handbook do not supercede any international, national, or local laws or regulations. For organizations including much of commercial industry that does not follow the principles of ISO/IEC 15288 to specify their life-cycle processes, this handbook can serve as a reference to practices and methods which have proven beneficial to the systems engineering community at large and which can add significant value in new domains if appropriately selected and applied. Material to support the application of processes and activities described in this handbook is available to INCOSE members through the INCOSE Process Asset Library (IPAL). The IPAL is currently under development and ultimately will contain additional supporting text, tailoring guidance and implementation material (such as checklists and work product templates from a number of application domains) for each handbook chapter. The handbook and IPAL are intended to be used together.

1.3 Contents
This chapter defines the purpose and scope of this handbook. Chapter 2 provides an overview of the goals and value of using systems engineering throughout the systems life cycle. Chapter 3 describes an informative life cycle model with six stages: Concept, Development, Production, Utilization, Support, and Retirement. ISO/IEC 15288 identifies four process groups to support systems engineering. Each of these process groups is the subject of a chapter. A graphical overview of these processes is given in Figure 1-1.
Page 1.1 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

ENTERPRISE PROCESSES Enterprise Environment Management Planning

PROJECT PROCESSES Assessment Configuration Management Control Information Management

Investment Management System Life Cycle Processes Management Resource Management

Decision-making

Risk Management

Process Guidelines
Stakeholder Requirements Definition

TECHNICAL PROCESSES Requirements Analysis

Architectural Design

Quality Management

Implementation

Integration

AGREEMENT PROCESSES Acquisition

Verification

Transition

Validation

Operation

Maintenance

Supply

Disposal

Figure1-1 System Life Cycle Processes Overview per ISO/IEC 15288

Figure 1-1 System Life Cycle Processes Overview per ISO/IEC 15288 Technical Processes (Chapter 4) include stakeholder requirements definition, requirements analysis, architectural design, implementation, integration, verification, transition, validation, operation, maintenance, and disposal. Project Processes (Chapter 5) include planning, assessment, control, decision-making, risk management, configuration management, and information management. Enterprise Processes (Chapter 6) include enterprise management, investment management, system life cycle processes management, resource management, and quality management. As Figure 1-1 illustrates, the outputs of the system life cycle processes management process directs the tailoring of the Technical and Project processes. Agreement Processes (included in Chapter 6) address acquisition and supply. Activities that support these processes are further described in Chapters 7-9 – see Table 1-1 for an overview of topics. Enabling Systems Engineering Activities (Chapter 7) elaborates on requirements management, risk and opportunity management, and decision-making. System Life Cycle Processes Activities (Chapter 8) discusses selected topics within acquisition and supply, architectural design, configuration management, information management, investment management, project planning, quality management, resource management, validation, and verification. Specialty Engineering Activities (Chapter 9) contains practical information about topics such as acquisition logistics and human factors engineering.
Page 1.2 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Appendix A contains an n-squared analysis of the processes showing where dependencies exist in the form of shared inputs or outputs. Agreement processes are not included because their interaction with the other processes is most subject to enterprise tailoring. Other appendices included with this document provide a glossary of terms and acronyms. Errors, omissions and other suggestions for this handbook can be submitted to INCOSE using the User Feedback Form at the end of this document. Not every process will apply universally. Careful selection from the material that follows is recommended. Reliance on process over progress will not deliver a system. If you are not familiar with tailoring concepts, please read Chapter 10 before using this handbook

Table 1-1 Systems Engineering Process Activities Overview
Systems Engineering Process Activity 7.0 7.1 7.2 7.3 8.0 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 9.0 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 Enabling System Engineering Decision Management Requirements Management Risk and Opportunity Management Systems Engineering Support Acquisition and Supply Architectural Design Configuration Management Information Management Investment Management Project Planning Quality Management Resource Management Validation Verification Specialty Engineering Activities Design for Acquisition Logistics Electromagnetic Compatibility Environmental Impacts Human Factors Mass Properties Modeling, Simulation, & Prototype Safety/Health Hazards Sustainment Engineering Training Need Analysis Trade studies and project reviews System requirements Recognizing opportunities and risks Procurement business relationships Technical analysis Control of changes through life Project archives and info exchange Estimation and analysis of costs Managing technical activities Product and process assessment Skills and resource availability User concurrence – correct system Requirements met – system correct Integrated logistics support solutions Electro-magnetic protections Care for the biosphere and humans Human capabilities and well-being Physical characteristics of the system Early validation and testing Minimum risk to users Continued use of system Basis for training requirements Focus Through Life Through Life Through Life Through Life Development Stage Through Life Through Life Through Life Through Life Through Life Development Stage Through Life Through Life Development Stage Development Stage Development Stage Development Stage Development Stage Development Stage Through Life Through Life Development Stage When it is most Useful

Page 1.3 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

1.4 Format
A common format has been applied in Chapters 4 through 6 to the elaboration of the system life cycle processes found in ISO/IEC 15288. Each process is illustrated by a context diagram. A sample is shown in Figure 1-2. To understand a given process, the reader is encouraged to find the complete information in the combination of diagrams and text. The following heading structure provides consistency in the discussion of these processes. • Purpose • Description • Inputs – this section discusses all inputs, including Controls and Enablers • Outputs • Process Activities • Common approaches and tips – endnotes contain additional readings
Controls
Directives Constraints

Inputs
-Data -Material

Activities
A process is an integrated set of activities that transforms inputs into desired outputs.

Outputs
- Processed data

-Products and services

Enablers
Resources (infrastructure, including workforce) Tools and technologies

Figure 1-2 Sample of Context Diagram for Process
Figure 1-2 Sample of Context Diagram for Process 1.5 Definitions of frequently used terms

This section contains the definition of some terms used frequently throughout this
TEMPLATE Chapter 4 handbook. Definitions in italics have been taken from ISO/IEC 15288. A full glossary

of definitions is found in Appendix B. Term
Activity Enabling system Enterprise

Definition set of actions that consume time and resources and whose performance is necessary to achieve or contribute to the realization of one or more outcomes a system that complements a system-of-interest during its life cycle stages but does not necessarily contribute directly to its function during operation that part of an organization with responsibility to acquire and to supply products and/or services according to agreements

Page 1.4 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Term
Organization Process Project Stage System System element System-of-interest

Definition a group of people and facilities with an arrangement of responsibilities, authorities and relationships set of interrelated or interacting activities that transform inputs into outputs an endeavor with start and finish dates undertaken to create a product or service in accordance with specified resources and requirements a period within the life cycle of a system that relates to the state of the system description or the system itself a combination of interacting elements organized to achieve one more stated purposes a member of a set of elements that constitutes a system the system whose life cycle is under consideration Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE)

Systems Engineering

1.6 References
The following documents have been used to establish the framework and practical foundations for this handbook. • INCOSE, Systems Engineering Handbook, version 2a, June, 2004. • ISO/IEC 15288: 2002(E), Systems engineering – System life cycle processes, Geneva: International Organization for Standardization, issued 1 November 2002. • ISO/IEC TR 19760: 2003(E), Systems Engineering – A guide for the application of ISO/IEC 15288, Geneva: International Organization for Standardization, issued 15 November 2003.

Page 1.5 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

Page 1.6 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3 Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

2 Systems Engineering Overview
2.1 Introduction
This chapter offers a brief overview of the discipline of Systems Engineering, beginning with some definitions, an abbreviated survey of the origins of the discipline and discussions of the value of applying systems engineering. Systems are pervasive in our daily life. They are tangible in that they exist in the products we use, the technologies we employ, the services we procure, and in the fabric of society.

2.2 Definition of systems engineering
Systems engineering is a profession, a process, and a perspective as illustrated by these three representative definitions. Systems engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect. (Ramo 1 ) Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system. (Eisner 2 ) Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. (INCOSE 3 ) Certain keywords emerge from this sampling – interdisciplinary, iterative, sociotechnical, and wholeness. The systems engineering perspective is based on systems thinking. Systems’ thinking occurs through discovery, learning, diagnosis, and dialog that lead to sensing, modeling, and talking about the real-world to better understand, define, and work with systems. Systems thinking is a unique perspective on reality — a perspective that sharpens our awareness of wholes and how the parts within those wholes interrelate. A systems thinker knows how systems fit into the larger context of day-to-day life, how they behave, and how to manage them. Systems thinking recognizes circular causation, where a variable is both the cause and the effect of another and recognizes the primacy of interrelationships and non-linear and organic thinking — a way of thinking where the primacy of the whole is acknowledged. The systems engineering process has an iterative nature that supports learning and continuous improvement. As the processes unfold, systems engineers uncover the real requirements and the emergent properties of the system. Complexity can lead to unexpected and unpredictable behavior of systems, hence, one of the objectives is to minimize undesirable consequences. This can be accomplished through the
Page 2.1 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

inclusion of and contributions from experts across relevant disciplines coordinated by the systems engineer. Since systems engineering has a horizontal orientation, the discipline (profession) includes both technical and management processes. Both processes depend upon good decision making. Decisions made early in the life cycle of a system, whose consequences are not clearly understood, can have enormous implications later in the life of a system. It is the task of the systems engineer to explore these issues and make the critical decisions in a timely manner. The role of the systems engineer is varied and Sheard4 is one source for a description of these variations.

2.3 Origins of systems engineering
The modern origins of systems engineering can be traced to the 1930’s followed quickly by other programs and supporters.5 Table 2-1 offers a thumbnail of some important highlights in the origins and history of the application of systems engineering. Table 2-1 Important Dates in the Origins of Systems Engineering as a Discipline
1829 1937 1939-1945 1951-1980 1956 1962 1969 1994 2002 Rocket locomotive; progenitor of main-line railway motive power British multi-disciplinary team to analyze the air defense system Bell Labs supported NIKE development SAGE Air Defense System defined and managed by MIT Invention of systems analysis by RAND Corporation Publication of A Methodology for Systems Engineering Jay Forrester (Modeling Urban Systems at MIT) Perry Memorandum urges military contractors to adopt commercial practices such as IEEE P1220 Release of ISO/IEC 15288

With the introduction of the international standard ISO/IEC 15288 in 2002, the discipline of systems engineering was formally recognized as a preferred mechanism to establish agreement for the creation of products and services to be traded between two enterprises – the acquirer and supplier. But even this simple designation is often confused in a web of contractors and subcontractors as the context of most systems today is as a part of a “system of systems.”

2.4 Systems of systems
“Systems-of-Systems” (SoS) are defined as an interoperating collection of component systems that produce results unachievable by the individual systems alone.6 The systems considered in ISO/IEC 15288 are man-made, created and utilized to provide services in defined environments for the benefit of users and other stakeholders. These systems may
Page 2.2 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

be configured with one or more of the following: hardware, software, humans, processes (e.g., review process), procedures (e.g., operator instructions), facilities, and naturally occurring entities (e.g., water, organisms, minerals). In practice, they are thought of as products or services. The perception and definition of a particular system, its architecture and its system elements depend on an observer’s interests and responsibilities. One person’s systemof-interest can be viewed as a system element in another person’s systemof-interest. Conversely, it can be viewed as being part of the environment of operation for another person’s system-of-interest.7 Figure 2-1 illustrates these concepts. The Global Positioning System (GPS), which is an integral part of the navigation system on board an aircraft, is a system in its own right rivaling the complexity of the air transportation system. Another characteristic of SoS is that the component systems may be part of other unrelated systems. For instance, the GPS may be an integral part of automobile navigation systems. The following challenges all influence the development of systems of systems: 1. System elements operate independently. Each system in a system of systems is likely to be operational in its own right. 2. System elements have different life cycles. SoS involves more than one system element. Some of the system elements are possibly in their development life cycle while others are already deployed as operational. In extreme cases, older systems elements in SoS might be scheduled for disposal before newer system elements are deployed. 3. The initial requirements are likely to be ambiguous. The requirements for a system of systems can be very explicit for deployed system elements. But for system elements that are still in the design stage, the requirements are usually no more explicit than the system element requirements. Requirements for SoS mature as the system elements mature. 4. Complexity is a major issue. As system elements are added, the complexity of system interaction grows in a non-linear fashion. Furthermore, conflicting or missing interface standards can make it hard to define data exchanges across system element interfaces. 5. Management can overshadow engineering. Since each system element has its own product/project office, the coordination of requirements, budget constraints, schedules, interfaces, and technology upgrades further complicate the development of SoS. 6. Fuzzy boundaries cause confusion. Unless someone defines and controls the scope of a SoS and manages the boundaries of system elements, no one controls the definition of the external interfaces.
Page 2.3 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

7. SoS engineering is never finished. Even after all system elements of a SoS are deployed, product/project management must continue to account for changes in the various system element life cycles, such as new technologies that impact one or more system elements, and normal system replacement due to preplanned product improvement.

Air Transport System
Ticketing System Air traffic control system

Ground Transportation System

Airports system

Fuel distribution system

Aircraft System
Airframe system Propulsion system Flight control system Navigation system Life support system Air Crew

Global positioning receiver system

Display system

Maritime Transport System

Figure 2-1 Example of the multitude of perceivable systems-of-interest in an aircraft and its environment of operation within a Transport System-of-Systems8 A Camera as an Example of a System-of-Systems – Not all SoS involve an environment as complex as the air transportation system. A digital camera may seem simple, but it is a system of systems with rigidly controlled interfaces. Multiple camera bodies, from simple fixed focus digital cameras to sophisticated single lens reflex cameras have a common interface to digital memory cards. The full single-lens reflex camera system has many different models of camera bodies which interface with 50 or more lens systems and multiple flash units. To be a commercial success these simple to sophisticated camera systems are designed to conform to external interfaces for standard commercial batteries, compact flash memory cards, interface cables, computers, and printer software as illustrated in Figure 2-2. In the context of SoS, systems are enclosed in the white boxes, system elements are displayed in the gray area.

Page 2.4 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

EOS Digital Cameras
(with Direct Print) PC Card Adapter

Computers

PictBridge Compatible Printers
(with Direct Print)

EOS-1Ds Mark II

CF/SD* Card Reader

PC Compatible Computer

EOS-1D Mark II

CF/SD* Cards

Inkjet Photo Printer
Macintosh Computer

EOS 20D

USB Cable (FireWire IFC-200D4/ D44 or IFC-450D4/D44 cable for EOS 1Ds Mark II and EOS 1D Mark II)

USB Cable

EOS Digital Rebel XT

USB Cable Interface Cable IFC-300PCU/IFC-400PCU (EOS-1Ds Mark II, 1D Mark II, 20D, Digital Rebel XT, Digital Rebel)

Compact Photo Printer

EOS Digital Rebel

Figure 2-2 Digital Camera and Printer Systems of Systems9 Part of the systems engineer’s job in the SoS environment is to be aware of and mitigate the risk of each of these seven challenges. Focus is placed on controlling the interfaces between system elements and external systems. It is especially important to ensure that the interfaces are still operational when an older component system is replaced with a newer version. Verification and validation processes play a critical role in such transitions.

2.5 Use of systems engineering
As can be readily inferred from the nature of the earliest projects, the systems engineering discipline emerged as an effective way to manage complexity and change. Both complexity and change have escalated in our products, services, and society. Reducing the risk associated with new systems or modifications to complex systems continues to be a primary goal of the systems engineer. This is illustrated in Figure 2-3. The percentages along the time line represent the actual life cycle cost (LCC) accrued over time – which means that the concept phase of a new system averages 8% of the total LCC. The curve for committed costs indicates the amount of LCC committed by the decisions taken. The curve indicates that when 20% of the

Page 2.5 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

actual cost has been accrued, 80% of the total LCC has already been determined – based on a statistical analysis performed on projects in the US DoD as reported by the Defense Acquisition University. The light arrow under the curve reminds us that errors are less expensive to remove early in the lifecycle.
Cumulative Percentage Life Cycle Cost against Time

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

Committed Costs

95% 85%
500-1000X

70%

Co

s

E t to

a xtr

fe De ct 20-100X
Prod/Test

cts

Operations Through Disposal

3-6X

Develop Design Concept

100% 50%

8%

15%

20%
Time

Figure 2-3 Committed Life Cycle Cost against Time 10 This figure also demonstrates the consequences of taking early decisions without the benefit of good information and analysis. Systems engineering extends the effort performed in concept exploration and design to exceed the percentages shown in the cumulative effort step-curve and reduce the risk of hasty commitments without adequate study. The recursive nature of modern development means that the execution of the various life cycle phases is not linear as illustrated – but the consequence of ill-formed decisions is the same. Another factor driving the need for systems engineering is that the time from prototype to significant market penetration of a new product has dropped by more than a factor of four in the past 50 years (Figure 2-4). Complexity has an impact on innovation. Few new products represent the big-bang introduction of new invention – most products and services are the result of incremental improvement. This means that the life cycle of today’s products and services is longer and subject to increasing uncertainty. A well-defined systems engineering process becomes critical to establishing and maintaining a competitive edge in the 21st century.

Page 2.6 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

100 90 80
Penetration into the market (%)
TV (1926) Electricity (1873) Radio (1905) Phone (1876)

70
Car (1886)

60 50 40 30 20 10
Mobile Phone (1983)

Microwave (1953) Personal Computer (1975) Videorecorder (1952)

Internet (1975)

Source: Microsoft

0 0 10 20 30 40 50 60 70 80 90 100 110 120 years

Figure 2-4 In the last century, the time from prototype to significant market penetration is dramatically reduced 11

2.6 Value of systems engineering
A study researching the return on investment from using systems engineering was conducted by the INCOSE Systems Engineering Center of Excellence beginning in 2001. The results uncovered an inverse correlation between cost and schedule overruns and the amount of systems engineering effort (SEE). As illustrated in the graph to the left in Figure 2-5, cost overrun lessens with increasing SEE and appears to minimize at something greater than 10% SEE. Variance in the cost overrun also lessens with increasing SEE. At low SEE, a project has difficulty predicting its overrun, which may be between 0% (actual = planned) and 200% (actual = 3 x planned). At 12% SEE, the project cost is more predictable, falling between minus 20% (actual = 0.80 x planned) and 41% (actual = 1.41 x planned). The dashed lines are the 90th percentile when assuming a normal distribution. Schedule overrun on the reported projects is illustrated in the right-hand graph in Figure 2-5. Two effects are apparent: • Schedule overrun lessens with increasing SEE. Overrun appears to minimize at something greater than 10% SEE, although few data points exist to support a reliable calculation. The solid line is the least-squares trend line for a second order curve.

Page 2.7 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Variance in the schedule overrun also lessens with increasing SEE. At low SEE, a project has difficulty predicting its overrun, which may be between minus 35% (actual = 0.65 x planned) and 300% (actual = 4 x planned). At 12% SEE, the project cost is more predictable, falling between minus 22% (actual = 0.78 x planned) and 22% (actual = 1.22 x planned). The dashed lines are the 90th percentile when assuming a normal distribution. Additional work is underway to collect more data about the value of applying systems engineering to a project. These initial results indicate that systems engineering effort can be a positive factor in controlling cost overruns and reducing the uncertainty of project execution.
3.0 3.0

90% Assurance (1.6 ) Actual/Planned Schedule
2.6 2.6

Actual/Planned Cost

Average Schedule Overrun
2.2 1.8 1.4 1.0 0.6 0% 4% 8% 12% 16% 20% 24%

2.2 1.8 1.4 1.0 0.6 0% 4% 8% 12% 16% 20% 24% 28%

SE Effort = SE Quality * SE Cost/Acual Cost

SE Effort = SE Quality * SE Cost/Acual Cost

Figure 2-5 Cost and schedule overruns correlated with systems engineering effort 12

An Allegorical Tale
Upon casual reading, systems engineers appear to be responsible for everything that happens on a project and systems engineering appears to introduce excessive process overhead and non-value added activities. A senior systems engineer at a major US company visited all of the divisions with the goal of increasing the use of good system engineering practices. His message included all the things that SE can/should do in commercializing products. His message also included a strong bias towards planning and documentation. Over a period of months he visited with Division Managers, Chief Engineers, Program Managers and Senior Engineers. He returned completely depleted of his enthusiasm. The problem was that the message was totally rejected because it either looked like useless work or way beyond anything they could afford to do from a time and dollars perspective. Some time later another senior systems engineer visited many of the same people with the same purpose but a different message. The message this engineer delivered was that big gains could be made by focusing on the most important customer needs and using a select group of synergistic system engineering tools/practices. This time the message was well received.

Page 2.8 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

The lesson: “Systems engineering is a multi-disciplinary effort that involves both the technical effort and technical project management aspects of a project. Enterprises seeking to incorporate the benefits of processes outlined in ISO 15288 will remember that application of those processes, and the enablers discussed in this handbook, requires vision and practical application of the principles.”13
1 Federal Aviation Agency (USA FAA) Systems Engineering Manual, definition contributed by Simon Ramo 2 Eisner, Howard, Essentials of Project and Systems Engineering Management 3 INCOSE, Systems Engineering Handbook, version 2a, June, 2004, page 11 4 Sheard, Sarah, “Twelve Roles of SE” Proceedings of the 6th Annual INCOSE International Symposium, 1996. 5 Hughes, Thomas P., Rescuing Prometheus, Chapter 4, pp. 141-195, Pantheon Books, New York, 1998 6 Krygiel, Annette J. Behind the Wizard’s Curtain, CCRP Publication Series, July, 1999, p 33 7 ISO/IEC 15288, page 52 8 ISO/IEC 15288, page 53 9 Canon EOS Digital Camera Brochure 10 Defense Acquisition University, 1993 11 Microsoft 12 Honour, Eric, (2004), Understanding the Value of Systems Engineering, Proceedings of the 14th Annual INCOSE International Symposium, 1996, available online from the INCOSE Systems Engineering Center of Excellence (SECOE), http://www.incose.org/secoe. 13 Submitted by handbook review team

Page 2.9 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

Page 2.10 of 10
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

3 Generic Life Cycle Stages
3.1 Introduction
Every man-made system has a life cycle, even if it is not formally defined. In keeping with increased awareness of environmental issues, the life cycle for any system-ofinterest must encompass not only the development, production, and usage stages but also provide early focus on the retirement stage when decommissioning and disposal of the system will occur. The role of the systems engineer encompasses the entire life cycle for the system-ofinterest. The systems engineer works closely with the project manager in tailoring the generic life cycle, including the decision gates, to meet the needs of their specific project. Per ISO/IEC 15288: “6.3 – The purpose and outcomes shall be defined for each stage of the life cycle. The life cycle processes and activities are selected, tailored as appropriate, and employed in a stage to fulfill the purpose and outcomes of that stage.” The purpose in defining the system life cycle is to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner. This is usually done by defining life cycle stages, and using decision gates to determine readiness to move from one stage to the next. Skipping phases and eliminating “time consuming” decision gates can greatly increase the risks (cost and schedule), and may adversely affect the technical development as well by reducing the level of systems engineering effort as discussed in Section 2.6. Systems engineers orchestrate the development of a solution from requirements determination through operations and system retirement by assuring that domain experts are properly involved, that all advantageous opportunities are pursued, and that all significant risks are identified and mitigated. Systems engineering tasks are usually concentrated at the beginning of the life cycle, but both commercial and government organizations recognize the need for systems engineering throughout the systems life span, often to modify or change a system product or service after it enters production or is placed in operation.

3.2 Life Cycle Characteristics
3.2.1 Three Aspects of the Life Cycle Every system or product life cycle consists of the business aspect (business case), the budget aspect (funding), and the technical aspect (product). The systems engineer creates technical solutions that are consistent with the business case and the funding
Page 3.1 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

constraints. System integrity requires that these three aspects are in balance and given equal emphasis at all decision gate reviews. For example, when the Iridium project started in the late 1980s the concept of satellite-based mobile phones was a breakthrough, and would clearly capture a significant market share. Over the next dozen years, the technical reviews ensured a highly successful technical solution. In fact, in the first decade of the 21st century, the Iridium project is proving to be a good business venture for all except for the original team who had to sell all the assets — at about two percent of their investment — through the bankruptcy court. The original team lost sight of the competition and changing consumer patterns that substantially altered the original business case. Figure 3-1 highlights two critical parameters that engineers sometimes lose sight of: time to break even (indicated by red circle) and Return on Investment (ROI; indicated by green line (lower curve)).
Business Development, Marketg System Engineering Design Production Order intake Return on investment Operation

Accumulated $,

Investments

Revenues

- 10

-5

5

10
Break even

15

20

years

Figure 3-1 Generic Business Life Cycle 1 3.2.2 Decision Gates Decision gates, also known as control gates, are often called “Milestones” or “Reviews.” All decision gates are both reviews and milestones; however, not all reviews and milestones are decision gates. Decision gates address the following questions: • Does the project deliverable still satisfy the business case? • Is it affordable? • Can it be delivered when needed? Decision gates represent major decision points in the system life cycle. They ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed and placed under configuration control.
Page 3.2 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

The primary objectives of decision gates are to: • Ensure that the elaboration of the business and technical baselines are acceptable and will lead to satisfactory verification and validation. • Ensure that the risk of proceeding to the next step is acceptable. • Continue to foster buyer and seller teamwork. Decision gate approval follows review by qualified experts and involved stakeholders and is based on hard evidence of compliance to the criteria of the review. Detailed information about the decision gate activity is provided in chapter 7.1. There are at least two decision gates in any project: authority to proceed and final acceptance of the project deliverable. The project team needs to decide which life cycle stages are appropriate for their project and which decision gates beyond the basic two are needed. Each decision must have a beneficial purpose; “pro-forma” reviews waste everyone’s time. Even in agile development frequent interaction with the customer may minimize, but not eliminate, the need for decision gates. The consequences of conducting a superficial review, omitting a critical discipline, or skipping a decision gate altogether are usually long-term and costly.

3.3 Life Cycle Stages
ISO/IEC 15288 states: “6.2 - A life cycle model that is composed of stages shall be established. The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the scope, magnitude, and complexity, changing needs and opportunities.” Table 3-1 lists the six life cycle stages that are identified in ISO/IEC 15288. The purpose of each is briefly identified in the table, and the options from decision gates events are indicated. Note that stages can overlap, and the utilization and support stages run in parallel. Note also that the outcome possibilities for decision gates are the same for all decision gates, from the first in the concept review to the last one in the retirement stage. Subsequent chapters of this handbook will define processes and activities to meet the objectives of these lifecycle stages.

Page 3.3 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Table 3-1 Life cycle stages, their purposes, and decision gate options2
LIFE CYCLE STAGES
CONCEPT

PURPOSE
Identify stakeholders’ needs Explore concepts Propose viable solutions Refine system requirements Create solution description Build system Verify and validate system Produce systems Inspect and test [verify] Operate system to satisfy users’ needs Provide sustained system capability Store, archive, or dispose of the system

DECISION GATES

DEVELOPMENT

PRODUCTION UTILIZATION SUPPORT RETIREMENT

Decision Options – Execute next stage – Continue this stage – Go to a preceding stage – Hold project activity – Terminate project

Figure 3-2 compares the life cycle stages of the ISO/IEC 15288 to other life cycle viewpoints. For example, the Concept Stage is aligned with the commercial project’s Study Period; and with the Pre-systems Acquisition and the Project Planning Period in the US Departments of Defense and Energy, respectively. Typical decision gates are presented in the bottom line. Various life cycle models such as the waterfall, spiral, Vee, and agile development models are useful in defining the start, stop, and activities appropriate to life cycle stages. The Vee model is used to visualize the system engineering focus, particularly during the concept and development stages. The Vee highlights the need to define verification plans during requirements development, the need for continuous validation with the stakeholders, and the importance of continuous risk and opportunity assessment.

Page 3.4 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Typical High-Tech Commercial Systems Integrator Study Period
User Concept Requirements Definition Definition Phase Phase

Implementation Period
Verification Phase

Operations Period
Deployment Phase Operations and Maintenance Phase Deactivation Phase

System Acq Source Development Specification Prep Select. Phase Phase Phase Phase

Typical High-Tech Commercial Manufacturer Study Period
Product Product Requirements Definition Phase Phase Product Development Phase

Implementation Period
Engr Model Phase Internal Test Phase External Test Phase

Operations Period
Full-Scale Manufacturing, Deactivation Production Sales, and Phase Phase Support Phase

ISO/IEC 15288
Utilization Stage Concept Stage Development Stage Production Stage Support Phase Retirement Phase

US Department of Defense (DoD) 5000.2
A B C System Development & Demonstration IOC FOC

Pre-systems Acquisition
Concept and Technology Development

Systems Acquisition
Production and Deployment

Sustainment
Operations and Support (including Disposal)

US Department of Energy (DoE) Project Planning Period
Pre-Project Preconceptual Planning Conceptual Design

Project Execution
Preliminary Design Final Design Construction

Mission
Acceptance Operations

Typical Decision Gates

New Initiative Approval

Concept Approval

Development Approval

Production Approval

Operational Approval

Deactivation Approval

Figure 3-2 Comparison of life cycles3 The Vee model provides a useful illustration of the systems engineering activities during the life cycle stages. In the Vee model, time and system maturity proceed from left to right. The core of the Vee depicts the evolving baseline from user requirements agreement to identification of a system concept to definition of systems components that will comprise the final product. With time moving to the right and with the system maturity shown vertically, the evolving baseline defines the left side of the core of the Vee, as shown in figure 3-3. As entities are constructed, verified and integrated, the right side of the core of the Vee is executed.

Page 3.5 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Off-core user discussions and approvals (In-process validation)
“Are the proposed baselines acceptable?”

Approved Baseline Baseline Verification Baseline Being Considered
“How to prove it’s built right”

Planned Verification

“Time Now”
(Vertical Line) With upward and downward iterations as required

Baselines to be Considered

Baselines to be Verified Core of the Vee
Plans, specifications, and products are under progressive configuration management

Time and Baseline Maturity Off-Core opportunity & risk management investigations and actions
“How are the opportunities and risks of the proposed baselines being resolved?”

Figure 3-3 Left side of the Vee model 4 Since one can never go backward in time, all iterations in the Vee are performed on the vertical “time now” line. Upward iterations involve the stakeholders and are the in-process validation activities that assure that the proposed baselines are acceptable. The downward vertical iterations are the essential off-core opportunity and risk management investigations and actions. In each stage of the system life cycle the systems engineering process iterates to ensure that a concept or design is feasible, and that the stakeholders remain supportive of the solution as it evolves. In the following paragraphs, the text in italics has been taken from ISO/IEC 15288, Appendix B, where detailed activities and outcomes for each life cycle stage are itemized. 3.3.1 Pre-Concept Exploratory Research Stage The Pre-Concept Exploratory Research Stage is sometimes referred to as the User Requirements Definition Phase. In many industries, it is common for research studies to lead to new ideas or enabling capabilities which then mature into the initiation of a new project (system-of-interest). A great deal of creative systems engineering is done in this exploratory stage, and the systems engineer leading these studies is likely to follow a new idea into the Concept Stage, perhaps as project champion. Often the PreConcept activities identify the enabling technologies. As discussed in chapter 2, if the work is done properly in early stages of the life cycle, it is possible to avoid recalls, and rework in later stages.

Page 3.6 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

3.3.2 Concept Stage Purpose: The Concept Stage is executed to assess new business opportunities and to develop preliminary system requirements and a feasible design solution. This stage is a refinement and broadening of the studies, experiments, and engineering models pursued during the Pre-Concept Stage. The processes described in this handbook are requirements-driven, as opposed to product driven. Thus, the first step is to identify, clarify, and document stakeholders’ requirements. If there was no PreConcept stage, that effort is done here. During the Concept Stage, the team begins in-depth studies that evaluate multiple candidate concepts and eventually provide a substantiated justification for the system concept that is selected. As part of this evaluation mockups may be built (for hardware) or coded (for software), engineering models and simulations may be executed, and prototypes of critical components may be built and tested. Prototypes are helpful to verify the feasibility of concepts and to explore risks and opportunities. These studies expand the risk and opportunity evaluation to include affordability assessment, environmental impact, failure modes, and hazard analysis. Key objectives are to provide confidence that the business case is sound and the proposed solutions are achievable. The systems engineer coordinates the activities of engineers from many disciplines. Early validation efforts align requirements with stakeholder expectations. The systems capabilities specified by the stakeholders will be met by the combination of system elements. Problems identified for individual hardware parts or software modules should be addressed early to minimize the risk that, when these entities are finally designed and verified, they fall short of the required functionality or performance. Many projects are driven by eager project champions who want “to get on with it.” They succumb to the temptation to cut short the concept stage, and they use exaggerated projections to support starting detailed design without adequate understanding of the challenges involved. Many commissions reviewing failed systems after the fact have identified insufficient or superficial study in the concept stage as a root cause of failure. 3.3.3 Development Stage Purpose: The Development Stage is executed to develop a system-of-interest that meets acquirer requirements and can be produced, tested [verified], evaluated, operated, supported, and retired. The development stage includes development, and integration, verification and validation (IV&V) activities. Figure 3-4 illustrates the evolving baseline as system components are integrated and verified. A source of additional information about IV&V and the significance for project cost and risk when these activities are optimized was the subject of the European Union SysTest5 program.
Page 3.7 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Off-core User Approval of Baseline and Baseline Modification
“Is the verified performance acceptable?”

Defined System Performance Defined Entity Performance

Baseline Validation
“Are we building the right thing?”

Baselines to be Verified

Baseline Verification
“Are we building it right?”

Baseline Being Verified

Core of the Vee
Plans, specifications, and products are under progressive configuration management

Baselines Verified

Time and Baseline Maturity “Off-Core” Verification Problem Investigation and Resolution
“is the problem cause understood?”

Figure 3-4 Right side of the Vee 6 3.3.4 Production Stage Purpose: The Production Stage is executed to produce or manufacture the product, to test [verify] the product, and to produce related supporting and enabling systems as needed. Product modifications may be required to resolve production problems, to reduce production costs, or to enhance product or system-of-interest capabilities. Any of these may influence system requirements, and may require system re-verification or re-validation. All such changes require systems engineering assessment before changes are approved. 3.3.5 Utilization Stage Purpose: The Utilization Stage is executed to operate the product, to deliver services within intended environments and to ensure continued operational effectiveness. Product modifications are often planned for introduction throughout the life cycle. Such upgrades enhance the capabilities of the system. These changes should be assessed by systems engineers to ensure smooth integration with the operational system-of-interest. The corresponding technical process is the Operations Process. 3.3.6 Support Stage Purpose: The Support Stage is executed to provide logistics, maintenance, and support services that enable continued system-of-interest operation and a sustainable service.
Page 3.8 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Modifications may be proposed to resolve supportability problems, to reduce operational costs, or to extend the life of a system. These changes require systems engineering assessment to avoid loss of system capabilities while under operation. The corresponding technical process is the Maintenance Process. 3.3.7 Retirement Stage Purpose: The Retirement Stage is executed to provide for the removal of a systemof-interest and related operational and support services, and to operate and support the retirement system itself. Systems engineering activities in this stage are primarily focused on ensuring that disposal requirements are satisfied. In fact, planning for disposal is part of the system definition during the concept stage. Experience in the 20th century repeatedly demonstrated the consequences when system retirement and disposal are not considered from the outset. Early in the 21st century, many countries have changed their laws to hold the creator of a system-of-interest accountable for proper end-oflife disposal of the system.

3.4 Development Stage Approaches
Per ISO/IEC 15288: “6.3 - Different organizations may undertake different stages in the life cycle. However, each stage is conducted by the organization responsible for that stage with due consideration of the available information on life cycle plans and decisions made in preceding stages. Similarly, the organization responsible for that stage records the decisions made and records the assumptions regarding subsequent stages in the life cycle.” A discussion of System Life Cycle Stages does not imply that the project should follow a predetermined set of activities or processes unless they add value toward achieving the final goal. Representations of stages tend to be linear in graphical depictions, but this hides the true incremental and iterative nature of the underlying processes. Illustrations which follow imply full freedom to choose a development model and are not restricted to a waterfall or other plan-driven methods. For the development stage, as for all stages, the organization will select the processes and activities that suit the project needs. 3.4.1 Plan-driven Development The requirements/design/build/test/deploy paradigm is considered the traditional way to build systems. On projects where it is necessary to coordinate large teams of people working in multiple companies, plan-driven approaches provide an underlying framework to provide discipline to the development processes. Plan-driven methods are characterized by a systematic approach that adheres to specified processes as the system moves through a series of representations from requirements through
Page 3.9 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

design to finished product. There is attention to the completeness of documentation, traceability from requirements, and verification of each representation after the fact. The strengths of plan-driven methods are predictability, stability, repeatability, and high assurance. Process improvement focuses on increasing process capability through standardization, measurement, and control. These methods rely on the “master plans” to anchor their processes and provide project-wide communication. Historical data is usually carefully collected and maintained as inputs to future planning to make projections more accurate.7 Safety-critical products, such as the Therac-25 medical equipment described in section 3.5.1, can only meet modern certification standards by following a thorough, documented set of plans and specification. Such standards mandate strict adherence to process and specified documentation to achieve safety or security. However, unprecedented projects or projects with a high rate of unforeseeable change, predictability and stability degrade, and a project may incur significant investment trying to keep documentation and plans up-to-date. 3.4.2 Incremental and Iterative Development Incremental and iterative development (IID) methods have been in use since the 1960’s.8 They represent a practical and useful approach which allows a project to provide an initial capability followed by successive deliveries to reach the desired system-of-interest. The goal is to provide rapid value and responsiveness. This approach is generally presented in opposition to the perceived burden associated with using any process, including those defined in this handbook. This development approach is used when the requirements are unclear from the beginning or the customer wishes to hold the system-of-interest open to the possibilities of inserting new technology. Based on an initial set of assumptions a candidate system-of-interest is developed, and then assessed to determine if it meets user needs or requirements. If not, another evolutionary round is initiated. This process is repeated until there is a satisfied user, or until the investor runs out of interest or money. Most literature agrees that IID methods are best applied to smaller, less complex systems or to system elements. The focus is on flexibility, and allowing selected events to be taken out of sequence when the risk is acceptable. Tailoring in this way highlights the core activities of product development. The features that distinguish IID from the plan-driven approaches are velocity and adaptability. While market strategies often emphasize that “time to market” or speed is critical, a more appropriate criterion is “velocity,” which considers direction in addition to speed. By incorporating the customer into their working-level teams, the project receives continuous feedback that they are going in a direction that satisfies
Page 3.10 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

the customer’s highest needs first. One downside is that reactive project management with a customer that often changes direction can result in an unstable, chaotic project. On one hand, this approach avoids the loss of large investments in faulty assumptions; on the other hand, emphasis on a tactical viewpoint may generate shortterm or localized solution optimizations. A specific IID methodology called evolutionary development9 is common in research and development environments. Figure 3-5 illustrates how this approach was used in the evolution of the tiles for the NASA Space Shuttle.10
System PDR

Incremental/Linear and Evolutionary Development Single or Multiple Deliveries
Incre 1+2 Incre 1 Verif. & Incre Verif. & Possible 1+2 Possible TRR Delivery Delivery Incre 1 TRR

System Accept System TRR & Deliver

Increment 2 PDR Increment 1 PDR

Increment 3 PDR

Integrate 1+2+3

Version 1

Version 2

Version 3

Code. Fab. Assemble

Increment 3 Evolutionary Development

Figure 3-5 IID and Evolutionary Development11 3.4.3 What is best for your organization? Conway’s law suggests that effective systems design emerges from system-oriented organizations. One of the earliest books on Systems Engineering Management 12 identified three simple criteria for such an organization; facilitate communications, streamline controls, and simplify paperwork. The way to effective systems engineering management is not “in the direction of formal, formidable, massive documentation. It does, however, reside in the direction of creating a total environment which is conducive to the emergence and effective utilization of creative and inventive talents oriented toward achieving a system approach with a minimum of management encumbrances.” 13 According to the Merriam-Webster’s Dictionary, a process can be defined as “a series of actions or operations conducing to an end.” Is process the way a company operates—from marketing to human resources, to actual development—or the way a developer produces design or code, or tests the software? Does the process refer to management, engineering, or both? Does process imply a lot of formalism and expanding effort for writing and reading documents, instead of product development? The best answer is that it depends on the situation. A “one size fits all” approach
Page 3.11 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

does not work when defining processes. One would hardly expect to find the same processes used in a startup e-commerce company as in NASA. The intended goal shapes a process in terms of scope (namely, the stages and activities covered) and organizational level. Depending on the perspective, processes are defined for entire organizations, teams, or an individual. In any case, the process should help by guiding people on what to do—on how to divide and coordinate the work—and by ensuring effective communication. Coordination and communication, for example, form the main problems in large projects involving many people—especially in distributed projects where people cannot communicate face to face.14 For a given organizational level, the process varies with the project’s goals and available resources. At a high level, the company’s business strategy determines the business approach. The main goals of time to market, minimum cost, or higher quality and customer satisfaction set the priorities. The company’s size; the number, knowledge, and experience of people15 (both engineers and support personnel); and hardware resources determine how to achieve the goal. The application domain and the corresponding system requirements together with other constraints form another main factor. The space shuttle or nuclear plant control software embedded in a complex system have different safety and reliability constraints than a word processor running on a PC; software for a car has different time response constraints than a payroll system. Whenever someone (be it an individual or a company) wants to reach a desired end, they must perform a series of actions or operations. They must consider the order of these actions, their dependencies, who will perform them, what they require and what they will generate, how long it will take to complete them, and what tools they will employ. Thus, they do follow a process, be it predefined or ad hoc. Because all these process components (activities, products, agents, tools) and their interactions (information flow, artifacts flow, control, communication, timing, dependencies, and concurrency) can vary, processes will differ — even if they have the same level, scope, and goal. So why should an organization care about processes? 16 To understand, evaluate, control, learn, communicate, improve, predict, and certify the work performed. What can organizations do to processes? They can document, define, measure, analyze, assess, compare, and change them. But the most difficult question of all is, “What is best for my organization?” That answer may be contained in this handbook.

3.5 Introduction to three cases
Real-world examples are provided throughout this handbook. They draw from diverse industries and types of systems. Three case studies have been selected used to illustrate the diversity of systems to which systems engineering principles and practices can be applied; medical therapy equipment, a bridge, and a super-high-speed train. They represent examples of failed, successful, and prototype systems that all define(d) the state-of-the-art. They may be categorized as medicine, infrastructure
Page 3.12 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

and transportation applications; in the manufacturing and construction industry domains; with and without software elements; complex; and subject to scrutiny both in the development and utilization stages as all have a need to be safe for humans and are constrained by government regulations. 3.5.1 Case 1: Radiation Therapy; the Therac-25 Therac-25, a dual-mode linear medical accelerator was developed by the medical division of Atomic Energy Commission Limited (AECL) of Canada, starting in 1976. The completely computerized system became commercially available in 1982. This new machine could be built at lower production cost, resulting in lower prices for the customers. A series of tragic accidents led to the recommended recall, and discontinuation of production of the system. Summary of product features and history The Therac-25 was a medical linear accelerator. A linear accelerator (LINAC) is a particle accelerator, capable of increasing the energy of electrically charged atomic particles. The charged particles are accelerated by the introduction of an electric field, producing beams of particles, or radiation, which are then focused by magnets. LINACS are used to treat cancer patients by exposing malignant cells to radiation. Since malignant tissues are more sensitive than normal tissues to radiation exposure, a treatment plan can be developed that permits the absorption of an amount of radiation that is fatal to tumors but causes relatively minor damage to surrounding tissue. Therac-25 was a revolutionary design comparing to its predecessors, Therac6 and Therac-20, both with exceptional safety records. It was based on a doublepass concept that allowed a more powerful accelerator to be built into a compact and versatile machine. AECL designed Therac-25 to fully utilize the potential of software control. While Therac-6 and Therac-20 were built as stand-alone machines and could be operated without a computer, Therac-25 depended on a tight integration of software and hardware. In the new, tightly coupled system, AECL used software to monitor the state of the machine and to ensure its proper operations and safety. Previous versions had included independent circuits to monitor the status of the beam as well as hardware interlocks that prevented the machine from delivering doses of radiation that were too high, or from performing any unsafe operation that could potentially harm the patient. In Therac-25, AECL decided not to duplicate these hardware interlocks since software already performed status checks and handled all the malfunctions. This meant that the Therac-25 software had far more responsibility for safety than the software in the previous models. If in the course of treatment, the software detected a minor malfunction it would pause the treatment. In this case, the procedure could be restarted by pressing a single “proceed” key. Only if a serious malfunction was detected was it required to completely reset the treatment parameters in order to restart the machine.

Page 3.13 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Software for Therac-25 was developed from the Therac-20’s software, which was developed from the Therac-6’s software. One programmer, over several years, evolved the Therac-6 software into the Therac-25 software. A stand-alone real-time operating system was added along with application software written in assembly language and tested as a part of the Therac-25 system operation. In addition, significant adjustments had been made to simplify the operator interface and minimize data entry, since initial operators complained that it took too long to enter a treatment plan. At the time of its introduction to market in 1982, Therac-25 was classified as a Class II medical device. Since the Therac-25 software was based on software used in the earlier Therac-20 and Therac-6 models, Therac-25 was approved by the Federal Drug Administration under Pre-Market Equivalency. Six accidents involving enormous radiation overdoses to patients took place between 1985 and 1987. Tragically, three of these accidents were the direct cause of the death of the patient. This case is ranked in the top ten worst software-related incidents on many lists. Details of the accidents and analysis of the case is available from many sources.17,18,19 3.5.2 Case 2: Joining two countries; the Øresund Bridge The Øresund Region is composed of eastern Denmark and southern Sweden and since 2000 is linked by the Øresund Bridge. The area includes the two major cities Copenhagen and Malmø, has a population of 3 million, and counts as Europe’s eight largest economic center. One fifth of the total Danish and Swedish GNP (Gross National Product) is produced in the region. The official name of the bridge is translated “the Øresund Connection” to underscore the full integration of the region. For the first time ever, Sweden is joined permanently to the mainland of Europe by a 10-minute drive or train ride. The cost for the entire Øresund Connection construction was calculated at 30.1 billion DKK the investment expected to be paid back by 2035. The Øresund Bridge is the world’s largest composite structure, has the longest cablestayed bridge span in the world carrying motorway and railway traffic, and boasts the highest freestanding pylons. The 7.9 km (5 mi) long bridge crosses the international navigation route between the Baltic Sea and the North Sea. A cable-stayed high bridge rises 57 m (160 feet) above the surface of the sea, with a main span of 490 m (0.3 miles). Both the main span and the approach bridges are constructed as a two-level composite steel-concrete structure. The upper deck carries a four-lane motorway, and the lower deck carries a two-track railway for both passenger trains and freight trains. The rest of the distance is spanned by the artificial island Peberholm (“Pepper” islet, named to complement the Saltholm islet to the north) and a tunnel on the Danish side that is the longest immersed concrete tunnel in the world. Since completion, Peberholm has become a natural habitat for colonies of rare birds, one of the largest of its kind in Denmark and Sweden.

Page 3.14 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Nations other than Denmark and Sweden also contributed to this project. Canada provided a floating crane, aptly named Svanen (the swan), to carry prefabricated bridge sections out to the site and place them into position. Forty-nine steel girders for the approach bridges were fabricated in Cádiz, Spain. A specially designed catamaran was built to handle transportation of the foundations for the pylons, which weighed 19,000 tons each. The project began with well-defined time, budget, and quality constraints. The design evolved over more than seven years, from start to delivery of final documentation and maintenance manuals. More than 4000 drawings were produced. The consortium dealt with changes as necessary using a combination of technical competence and stakeholder cooperation. Notably, there were no disputes and no significant claims against the owners at the conclusion and this has been attributed to the spirit of partnership. From the beginning, the owners defined comprehensive requirements and provided definition drawings as part of the contract documents, to ensure a project result that not only fulfilled the quality requirements on materials and workmanship, but also had the envisioned appearance. The contractor was responsible for the detailed design and for delivering a quality assured product in accordance with the owners’ requirements. Selected Requirements The following are representative of the requirements levied at the start of the project: Schedule: Design life 100 years; Construction time Apr. 1996 - Apr. 2000 Railway: Rail load UIC 71; Train speed 200 km/h Motorway: Road axle load 260 kN; Vehicle speed 120 km/h Ambient environment: Wind speed (10 min) 61 m/s; Wave height 2.5 m; Ice thickness 0.6 m; Temperature +/- 27 ºC Ship impact: to pylons 560 MN; to girder 35 MN Constraints In addition to established requirements, this project crossed national boundaries and was thereby subject to the legislations of each country. Technical requirements were based on the Eurocodes, with project specific amendments made to suit the national standards of both countries. Special safety regulations were set up for the working conditions, meeting the individual safety standards of Denmark and Sweden. The railway link introduced yet another challenge. In Denmark, the rail traffic is right handed as on roadways, whereas the trains in Sweden pass on the left hand
Page 3.15 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

side. The connection needed to ensure a logical transition between the two systems, including safety aspects. In addition, the railway power supply differs between the two countries, thus it was necessary to develop a system that could accommodate power supply for both railway systems. Bridge Design involves many disciplines The design of a major cable-stayed bridge with approach spans for both road and railway traffic involves several disciplines as illustrated by this partial list: geotechnical engineering; aerodynamics; foundation engineering; wind tunnel tests; design of piers and pylons; design of composite girders; design of cables and anchorages; design of structural monitoring system; ship impact analysis; earthquake analysis; analysis of shrinkage and creep of concrete; ice loads analysis; fatigue analysis; pavement design; mechanical systems; electrical systems; comfort analyses for railway passengers; traffic forecast; operation and maintenance aspects; analysis of construction stages; risk analysis for construction and operation; quality management; and environmental studies and monitoring. Risk Management Comprehensive risk analyses were carried out in connection with the initial planning studies, including specification of requirements to secure all safety aspects. Important examples of the results of these studies for the Øresund Bridge were: • Navigation span was increased from 330 m to 490 m • Realignment and deepening of the navigation channel to reduce groundings • Introduction of pier protection islands Risks were considered in a systematic way, using contemporary risk analysis methods such as functional safety analyses using fault tree and “what if” techniques. Three main issues were considered under the design-build contract: • General identification and assessment of construction risks • Ship collision in connection with realignment of navigation channel • Risks in connection with 5 years bridge operation by contractor A fully quantified risk assessment of the human safety and traffic delay risks was carried out for a comprehensive list of hazards including: fire; explosion; train collisions and derailments; road accidents; ship collisions and groundings; aircraft collisions; environmental loads beyond design basis; and, toxic spillages. An example of a consequence of this analysis was the provision of passive fire protection on the tunnel walls and ceilings.

Page 3.16 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Environmental Considerations Both Denmark and Sweden are proud of being among the cleanest industrial countries in the world. Their citizens, and therefore the politicians, would not allow for any adverse environmental impact from the construction or operation of a bridge. The Great Belt and Øresund Strait both constitute corridors between the salty Kattegat and the sweeter water of the Baltic Sea. Any reduction in water exchange would reduce the salt content, and, therefore, the oxygen content, of the Baltic Sea and would alter its ecological balance. The Danish and Swedish Authorities decided that the bridge should be designed in such a way that the flow-through of water, salt and oxygen into the Baltic was not affected. This requirement was designated the zero solution. In order to limit impacts on the local flora and fauna in Øresund during the construction, the Danish and Swedish authorities imposed a restriction that the spillage of seabed material from dredging operations should not exceed 5% of the dredged amounts. The zero solution was obtained by modeling with 2 different and independent hydrographical models. In total, 18 million cubic meters of seabed materials were dredged. All dredged materials were reused for reclamation of the artificial peninsula at Kastrup and the artificial island, Peberholm. A comprehensive and intensive monitoring of the environment was performed in order to ensure and document the fulfillment of all environmental requirements. In their final status report from 2001 the Danish and Swedish Authorities concluded that the zero solution as well as all environmental requirements related to the construction of the link had been fulfilled. Continual monitoring of eel grass and common mussels showed that, after a general but minor decline, populations had recovered by the time the bridge was opened. Overall, the environment paid a low price at Øresund and the Great Belt, because it was given consideration throughout the planning and construction phases of the bridges. This award-winning bridge is the subject of numerous articles and a PhD thesis, where details of the construction history and collaboration among all the stakeholders are provided.20,21,22 3.5.3 Case 3: Prototype system; The Super-high-speed train in China Shanghai Transrapid is the first commercial high-speed commuting system using the state-of-the-art electromagnetic levitation (or maglev) technology. The train runs from Shanghai’s financial district to Pudong International Airport, and the total track length is about 30 kilometers (20 miles). The train takes 7 minutes and 20 seconds to complete the journey, and can reach almost 200 mph (320 km/h) in 2 minutes, and reaches its maximum speed of 267 mph (430 km/h) within 4 minutes. The Shanghai Transrapid project took 1.2 billion USD (10 billion Yuan) and 2.5 years to complete the track. Construction began in March 2001, and public service commenced on January 1, 2003. Critics argue that the speed over such a short distance is unnecessary and that the line may never recoup this cost.
Page 3.17 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Prior to this installation, many countries had argued over the feasibility of maglev trains. They do not have wheels or use a traditional rail. Rather, powerful magnets lift the entire train about 10 millimeters above the special track, called a guideway, since it mainly directs the passage of the train. Electromagnetic force is used to make the train hover, and to provide vertical and horizontal stabilization. The frequency, intensity and direction of the electrical current in the track control the train’s movement, while the power for the levitation system is supplied by the train’s onboard batteries, which recharge whenever the train is moving. Maglev trains also do not have an onboard motor. The guideway contains a built-in electric motor that generates an electromagnetic field that pulls the train down the track. Putting the propulsion system in the guideway rather than onboard the trains, makes the cars lighter, which enables the train to accelerate quickly. The super-high speeds are attained largely due to the reduction of friction. Despite the high speed, the maglev system runs more quietly than a typical commuter train, consumes less energy and is nearly impossible to derail because of the way the train’s underside partially wraps around the guideway, like a giant set of arms hugging the train to the elevated platform. Passengers experience a comfortable and quiet ride due to the maglev technology and the specially designed window; noise level is less than 60 decibels at a speed of 300 km/h. The Chinese authorities considered the economical operation, low energy consumption, less environmental impact, and high speed when choosing a solution suitable for ground transport between hubs that range from hundreds to over one thousand kilometers apart. But the same solution also needed to be suitable for modern mass rapid passenger transportation between a center city and adjacent cities. Despite the many advantages, in 1999 the technology was considered to be in an experimental stage, not yet proven by commercialized operation, its technological superiority, safety and economic performance remaining to be proved. The current line is the result of a compromise; it was built as a demonstration to verify the maturity, availability, economics and safety of a high speed maglev transportation system. The basic technology to create a maglev system has been around since 1979, but until this project it had never been realized – mostly due to the expense of developing a new train system. Many experts believe that super-fast steel-wheel rail systems – such as those in France and Japan – have reached the limits of this technology and can not go any faster. Maglev proponents describe the system as “the first fundamental innovation in the field of railway technology since the invention of the railway” and are watching proposals for maglev installations in Germany and the USA.23,24,25,26

1 Used with permission of H. Stoewer 2 ISO/IEC 15288, Table D-1, page 57 3 Figure provided by Kevin Forsberg, CSM. Page 3.18 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4 Forsberg, K., H. Mooz, H. Cotterman, Visualizing Project Management, 3rd Ed., J. Wiley & Sons, 2005. p. 111 5 SysTest, Systems Verification, Validation and Testing Methodology Guidelines, Contract: G1RD-CT2002-00683, http://www.incose.org/secoe/0105.htm 6 Forsberg, K., H. Mooz, H. Cotterman, Visualizing Project Management, 3rd Ed., J. Wiley & Sons, 2005. p. 115 7 Boehm, B. and R. Turner. Balancing Agility and Discipline. Addison-Wesley, 2004. 8 Larman, C, V.Basili, “Iterative and Incremental Development: A Brief History,” IEEE Software, My/Jn 2003. 9 Gilb, T., Competitive Engineering, Elsevier, 2005, p. 358. 10 “If I Could Do That, Then I Could…,” by K. Forsberg, Proceedings of Fifth NCOSE Summer Symposium, 1995. 11 Forsberg, K., H. Mooz, H. Cotterman, Visualizing Project Management, 3rd Ed., J. Wiley & Sons, 2005. p. 358 12 Chase, W. P., Management of System Engineering. John Wiley & Sons, 1974. 13 Ibid. p 147. 14 Lindvall, Mikael and Ioana Rus, “Process Diversity in Software Development” IEEE Software Jl/Au 2000. 15 Cockburn, A. “Selecting a Project’s Methodology”. IEEE Software, Jl/Au 2000, p. 64-71 16 McConnell, Steve. “The Power of Process” IEEE Computer, May 1998 17 Jacky, Johathan. “Programmed for Disaster.” The Sciences 29 (1989) : 22-27. 18 N. Leveson, C. S. Turner. “An Investigation of the Therac-25 Accidents.” IEEE Computer, Vol. 26, No. 7, 1993, pp. 18-41. 19 Porrello, Anne Marie. Death and Denial: The Failure of the THERAC-25, A Medical Linear Accelerator. Downloaded from URL: http://www.csc.calpoly.edu/~jdalbey/SWE/Papers/ THERAC25.html. 20 Nissen, J. The Øresund Link. The Arup Journal, 31(2), pp37-41, 2/1996. 21 Jensen, J. S. The Øresund Bridge – Linking Two Nations. URL: www.cowi.dk 22 Website of the Øresund Bridge Consortium, URL: osb.oeresundsbron.dk 23 “China’s Supertrain Takes to Tracks.” BBC News Online: Asia-Pacific. 9 Aug. 2002. 29 May 2003. http://news.bbc.co.uk/2/hi/asia-pacific/2182975.stm. 24 McGrath, Dermot. “China Awaits High Speed ‘Maglev.’” Wired News, 23 Jan 2003. http://www. wired.com/news/technology/0,1282,57163,00.html. 25 “Transrapid.” Transrapid International. 23 May 2003 www.transrapid.de. 26 Website of Shanghai Maglev Transportation Development Company, URL: www.smtdc.com/en/gycf4.asp.

Page 3.19 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

Page 3.20 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4 Technical Processes
4.1 Introduction
The ISO/IEC 15288 technical processes are invoked throughout the life cycle stages of a system. Technical processes are used to establish requirements for the system as the basis for the efforts to create an effective product or service; to sustain the system through its useful life; and to support retirement of the system. Figure 1-1 illustrates the relationship of the technical processes to the Agreement, Enterprise and Project Processes. Without the technical processes, the risk of project failure would be unacceptably high. In his opening keynote at the 15th Annual INCOSE International Symposium, Riley Duren of Jet Propulsion Laboratory, California, stressed that systems engineering is a way of thinking about and solving challenges and that systems engineers are the GLUE that hold the elements of complex space programs together. To achieve good results, systems engineers involve themselves in nearly every aspect of a project, pay close attention to interfaces where two or more systems or system elements work together, and establish an interaction network with stakeholders and other organizational units of the enterprise. Figure 4-1 shows the critical interactions for systems engineers.
Ref. Prof H Stoewer

SYSTEM ENGINEERING ENVIRONMENT
PROJECT MANAGEMENT AND CONTROL BUSINESS ENGINEERING AND PROCUREMENT

PRODUCTION MANAGEMENT

SYSTEMS ENGINEERING ENVIRONMENT

STAKEHOLDERS, CUSTOMERS, MARKETS

PRODUCT ASSURANCE, QUALITY AND SAFETY

INTERFACES – INVOLVEMENT INTERACTION
SPECIALISTS ENGINEERING

OPERATIONS, MAINTENANCE, SERVICING

Figure 4-1 Context of Systems Engineering Technical Processes1 Technical processes enable systems engineers to coordinate the interactions between engineering specialists, systems stakeholders and operators, and manufacturing. They also address conformance with the expectations and legislated requirements of society. These processes lead to the creation of a full set of requirements that address the desired capabilities within the bounds of performance, environment, external interfaces, and design constraints.

Page 4.1 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.2 Stakeholder Requirements Definition Process
4.2.1 Purpose

The purpose of the Stakeholder Requirements Definition Process is to elicit, negotiate, document, and maintain stakeholders’ requirements for the system-of-interest within a defined environment. 4.2.2 Description

A stakeholder is any entity (individual or organization) with a legitimate interest in the system. Typical stakeholders include operators, enterprise decision-makers, parties to the agreement, regulatory bodies and society-at-large. When direct contact is not possible, systems engineers find agents, such as marketing or non-governmental organizations to represent the concerns of a class of stakeholders, such as consumers, or future generations. The Stakeholder Requirements govern the system’s development; and they are an essential factor in further defining or clarifying the scope of the development project. If an enterprise is acquiring the system, this process provides the basis for the technical description of the deliverables in an agreement – typically in the form of a systemlevel specification and defined interfaces at the system boundaries. In the next process (Requirements Analysis Process), the verification criteria are added to this definition. Requirements management is the subject of a section in Chapter 7. Figure 4-2 is the context diagram for this process.
Controls
-Agreements - Project procedures & processes

Activities
- Identify legitimate stakeholders

Inputs
-Stakeholders’ needs -Project Constraints

-Elicit requirements -Define constraints -Build scenarios and concept documents -Resolve requirements problems -Confirm and record requirements -Establish and maintain traceability

Outputs
- System solution constraints

- Traceability Matrix - Validation criteria - Concept documents

Enablers
- Enterprise Infrastructure

-Enterprise Policies, Processes & Standards

Figure 4-2 Context Diagram for Stakeholder Requirements Definition Process
Figure 4-2 Context Diagram for Stakeholder Requirements Definition Process

4.2.3

Inputs

The inputs to this process include the description of users’ needs or services that the system will provide, cost, schedule, and solution constraints, terms and conditions of
Page 4.2 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

the agreement, and industry specifications and standards. This process is governed by project plans and enterprise standards, guidelines, policies, procedures, and reporting mechanisms. 4.2.4 Outputs

The outputs of this process consist of formally documented and approved stakeholder requirements that will govern the project, including: required system capabilities, functions and/or services; quality standards; cost and schedule constraints; concept of operations; and concept of support. The outputs should include measures of effectiveness and suitability that will be used for assessing the realized system and enabling systems. Validation criteria may specify who will perform validation activities, and the environments of the system-of-interest and enabling systems. Other outputs establish the initial baseline for project scope and associated agreements. The following are instances of concept documentation: • Concept of Production describes the way the system will be manufactured. • Concept of Deployment describes the way the system will be delivered and installed. • Concept of Operations describes the way the system works from the operator’s perspective. • Concept of Support describes the desired support infrastructure and manpower considerations for maintaining the system after it is deployed. This includes specifying equipment, procedures, facilities and operator training requirements. • Concept of Disposal describes the way the system will be removed from operation and retired. 4.2.1 Process Activities This process includes the following activities: • Identify stakeholders who will have an interest in the system throughout its entire life cycle. • Elicit system services and capabilities – what the system must accomplish and how well. • Identify constraints imposed by agreements or interfaces with legacy enabling systems. • Establish critical and desired system performance – thresholds and objectives for system performance parameters that are critical for system success and those that are desired but may be subject to compromise in order to meet the critical parameters • Establish measures of effectiveness and suitability – measures that reflect overall customer/user satisfaction (e.g. performance, safety, reliability, availability, maintainability, and workload requirements).

Page 4.3 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Analyze requirements for clarity, completeness and consistency. • Negotiate modifications to resolve unrealizable or impractical requirements. • Establish a traceability matrix to document how the formal requirements are intended to meet the stakeholder objectives and achieve stakeholder agreement. • Record and maintain stakeholder requirements throughout the system life cycle, and beyond for historical or archival purposes. n Common approaches and tips: • Use scenarios to define the concept documents – bound the range of anticipated uses of system products, the intended operational environment and interfacing systems, platforms or products. Scenarios help identify requirements that might otherwise be overlooked. Social and organizational influences also emerge from using scenarios. • Once established, the stakeholders’ requirements are placed under configuration control. • Establish good relationships and open communications between systems engineers and stakeholders. This is helpful when negotiations begin to refine and clarify the set of requirements. • Identify all stakeholders; it is critical to identify and include key system stakeholders in this process including the development/design team. • Avoid designing a final solution or establishing unjustified constraints on the solution. • Avoid acceptance of unrealistic or competing objectives. • Write clearly and create statements with quantifiable values.2 • Capture source and rationale for each requirement.3

4.3 Requirements Analysis Process
4.3.1 Purpose

The purpose of the Requirements Analysis Process is to review, assess, prioritize, and balance all stakeholder and derived requirements (including constraints); and to transform those requirements into a functional and technical view of a system description capable of meeting the stakeholders’ needs. This view can be expressed in a specification, set of drawings or any other means that provides effective communication.

Page 4.4 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.3.2

Description

Requirements analysis is an interim process: the output of the process must be compared for traceability and consistency with the Stakeholder Requirements, before being used to drive the Architectural Design Process, without introducing implementation biases. Figure 4-3 is the context diagram for Requirements Analysis.
Controls
- Natural and societal laws - Project procedures & processes

Inputs
-Stakeholder requirements -System Solution Constraints - Traceability Matrix

Activities
- Define functional boundary - Define performance objectives -Identify architectural constraints -Define non-functional requirements -Maintain traceability and baseline

Outputs
- Functional Requirements -Performance Requirements -Architectural constraints -Traceability Matrix -Verification criteria

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards

Figure 4-3 Context Diagram for the Requirements Analysis Process 4.3.3 Inputs
Figure 4-3 Context Diagram for Requirements Analysis Process

The primary input to the Requirements Analysis Process is the baseline documented during the Stakeholder Requirements Definition Process. Additional inputs to the Requirements Analysis Process include applicable statutes, regulations, and policies; the intended operational use and utilization environment for the system; any design or enterprise constraints; manufacturing; life cycle support considerations; design considerations (e.g. applicable standards, environmental and safety concerns, etc.); and any decisions or data resulting from previous phases of development. 4.3.4 Outputs

The output of Requirements Analysis is a technical description of characteristics the future system must have in order to meet Stakeholder Requirements – not a specific solution – which will be evolved in subsequent development processes. The project team derives additional requirements resulting from analysis of the input Stakeholder Requirements as required to meet project and design constraints; defines the functional boundaries for the system to be developed; and identifies and documents any interfaces and information exchange requirements with systems external to the functional boundaries. The total set of requirements encompasses the functional, performance, and non-functional requirements and the architectural constraints. Any decisions taken are documented in the information repository.

Page 4.5 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.3.5

Process Activities

This process includes the following activities: • Define and specify the functional boundary and performance. This will specify what the system should be able to do (functional requirements) when fielded and operated in its intended operating environment. The levels and measures of performance (MOP) for the top-level system functional requirements required to satisfy the system Measures of Effectiveness (MOE) are determined from the following: • Selected Standards – identify standards required to meet quality or design considerations imposed as defined stakeholder requirements or derived to meet enterprise, industry, or domain requirements • System Boundaries – clearly identify system elements under design control of the project team and/or enterprise and expected interactions with systems external to that control boundary • External Interfaces – functional and design interfaces to interacting systems, platforms, and/or humans external to the system boundary • Utilization Environment(s) – identify all environmental factors (natural or induced) that may affect system performance, impact human comfort or safety, or cause human error for each of the operational scenarios envisioned for system use • Life Cycle Process Requirements – conditions or design factors that facilitate and foster efficient and cost-effective lifecycle functions (i.e. Production, Deployment, Transition, Operation, Maintenance, Reengineering/Upgrade, and Disposal) • Design considerations – including human-systems integration (manpower, personnel, training, human factors, safety), system security requirements (e.g. information assurance, anti-tamper provisions), and potential environmental impact • Design constraints – including physical limitations (e.g. weight, form/fit factors) and defined interfaces with interacting systems and host platforms external to the system boundary • Define Verification Criteria – concurrent with analysis, to ensure verifiable requirements • Maintain continuity of configuration control and traceability. n Common approaches and tips: • Integrated Product Teams (with acquirer-supplier participation) are an effective practice to bring together the necessary expertise.4 • Use failure modes, effects, and criticality analysis (FMECA) or hazard analysis to identify the critical system level requirements. See chapters 7 and 9 for additional discussion about identifying the non-functional requirements. • Use specially designed requirements management tools.5 • Begin from the very beginning to maintain requirements traceability.
Page 4.6 of 24

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Avoid deriving requirements that are not consistent with other requirements or constraints. • Create templates for constructing requirements statements.6

4.4 Architectural Design Process
4.4.1 Purpose

The purpose of the Architectural Design Process is to synthesize a system solution that satisfies the requirements. 4.4.2 Description

The Architectural Design Process requires the participation of systems engineers joined by relevant specialists in the system domain. When alternative solutions present themselves, technical analysis and decisions are taken as part of this process to identify a set of system elements. Integration is defined for the system, not the individual system elements. Figure 4.4 is the context diagram for the Architectural Design Process.
Controls
-Agreements - Project procedures & processes

Inputs
-Functional and performance requirements -Architectural constraints -Traceability Matrix - Interfacing systems specifications

Activities
- Define logical architecture - Partition system functions -Evaluate off-the-shelf system elements -Evaluate alternative designs -Document interfaces; integration plan

Outputs
- Architecture design baseline -System element descriptions -Interface requirements -Traceability Matrix -Verification strategy

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards

Figure 4-4 Context Diagram for the Architectural Design Process 4.4.3 Inputs
Figure 4-4 Context Diagram for Architectural Design Process

TEMPLATE Chapter 4

Architectural design begins from the baseline functional and performance requirements, architectural constraints, and traceability matrix. Specifications for enabling systems are used to drive interface design. Specifications for reusable system elements are used when designing for product lines.

Page 4.7 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.4.4

Outputs

The result of this process is an architectural design that is placed under configuration management. This baseline includes: • System element detailed descriptions • Requirements assigned to system elements and documented in a traceability matrix • Interface requirements and a plan for system integration and verification strategy 4.4.5 Process Activities The following processes contribute to architectural design: • Define a consistent logical architecture – capture the logical sequencing and interaction of system functions or logical elements • Partition system requirements and allocate them to system elements with associated performance requirements – consider off-the-shelf solutions that already exist. • Evaluate alternative design solutions – see chapter 7 for a discussion of trade studies • Identify interfaces between system elements and with external and enabling systems • Define the system integration strategy. • Document and maintain the Architectural Design and relevant decisions made to reach agreement on the baseline design. • Establish and maintain the traceability between requirements and system elements. • Define Verification and Validation Criteria for the system elements. n Common approaches and tips: • Modeling techniques such as SysML, discussed in chapter 7, are useful in deriving a logical architecture. • Use an Integrated Product Team for analysis and review; working together as a team helps break down communications silos and facilitates decision-making. • Architecture and Design Patterns can be useful for establishing a system framework. • System elements can be developed in a top-down partitioning exercise that allocates the functional elements to physical or virtual system elements. Ideally, interface requirements between these system elements are minimized. At the same time, off-the-shelf or previously developed system elements are considered within the constraints of the contracting strategy. • During this process, consider emergent properties, feature interactions, and human-machine interactions.7

Page 4.8 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.5 Implementation Process
4.5.1 Purpose

The purpose of the Implementation Process is to design, create or fabricate a system element conforming to that element’s detailed description. The element is constructed employing appropriate technology and industry practices. This process straddles the Development and Production stages. 4.5.2 Description

During the Implementation Process, engineers follow the requirements allocated to the system element to design, fabricate, code, or build each individual element using specified materials, processes, physical or logical arrangements, standards, technologies, and/or information flows outlined in detailed drawings or other design documentation. Requirements are verified and stakeholder requirements are validated. If subsequent configuration audits reveal discrepancies, recursive interactions occur with predecessor activities or processes as required to correct them. Figure 4-5 is the context diagram for the Implementation Process.
Controls
-Agreement - Government & Industry standards

Inputs
-Design requirements -Verification criteria - Validation criteria

Activities
- Define implementation strategy - Realize the system element -Provide evidence of compliance -Package and store; supply

Outputs
-Integration constraints - Implementation strategy -System element supplied -Initial operator training

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards

Figure 4-5 Context Diagram for the Implementation Process
Figure 4-5 Context Diagram for the Implementation Process

4.5.3

Inputs

The system element requirements and the associated verification and validation criteria TEMPLATE Chapter 4 are input to this process from the Architectural Design Process. Execution of the Implementation Process is governed by • government and industry standards, terms of any agreements • conditions of the agreement for packaging, storage, and initial operator training (PHS&T) – see discussion of PHS&T in Chapter 9 • enterprise safety practices and other guidelines

Page 4.9 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.5.4

Outputs

Outputs from this process include: • Refined Implementation Strategy and Integration Constraints • System element – verified and validated – supplied according to agreement • Detailed drawings and codes and material specifications • Updated design documentation – as required by corrective action or adaptations caused by acquisition or conformance to regulations • Operator/Maintenance training manuals and initial staff of trained users and maintainers according to agreement 4.5.5 Process Activities Implementation Process activities begin with detailed design and include developing an Implementation Strategy that defines fabrication/coding procedures, tools and equipment to be used, implementation tolerances, and the means and criteria for auditing configuration of resulting elements to the detailed design documentation. In the case of repeated system element implementations (such as for mass manufacturing or replacement elements) the implementation strategy is defined/refined to achieve consistent and repeatable element production; and it is retained in the project decision database for future use. As required, data for training users on correct and safe procedures for operating and maintaining that element — either as a standalone end item or as part of a larger system—are developed and added to the project database. Detailed product, process, material specifications (“Build-to” or “Code-to” documents) and corresponding analysis are completed. • Conduct peer reviews and unit testing – inspect and test software for correct functionality, white box testing, etc. in accordance with software/hardware best practices • Conduct hardware conformation audits – compare hardware elements to detailed drawings to assure that each element meets its detailed specifications prior to integration with other elements in higher configuration items or assemblies • Draft training documentation – to support operating, conducting failure detection and isolation, and maintaining system components, subsystems, and the system as appropriate • Train initial operators and maintainers – on the use of elements that provide a human-system interface or require maintenance actions at the element level n Common approaches and tips: • Keep the Integrated Product Team engaged to assist with configuration issues and redesign. • Inspections are a proactive way to build in quality.8 • In anticipation of improving process control, reducing production inspections, and lowering maintenance activities, many manufacturing firms use Design for Six Sigma, or Lean Manufacturing.

Page 4.10 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Conduct hardware conformation audits or system element level hardware testing; ensure sufficient software unit testing prior to integration. • Validate simulations; interface simulator drivers should be representative of tactical environments.

4.6 Integration Process
4.6.1 Purpose

The purpose of the Integration Process is to realize the system-of-interest by progressively combining system elements in accordance with the architectural design requirements and the integration strategy. This process is successively repeated in combination with the Verification and Validation Processes as appropriate. 4.6.2. Description The Integration Process includes activities to acquire or design and build enabling systems needed to support the integration of system elements and demonstration of end-to-end operation. This process confirms all boundaries between system elements have been correctly identified and described, including physical, logical, and human-system interfaces; and confirms that all functional, performance, and design requirements and constraints are satisfied. Interim assembly configurations are tested to assure correct flow of information and data across interfaces to reduce risk, and minimize errors and time spent isolating and correcting them. Figure 4-6 is the context diagram for the Integration Process.
Controls
-Agreements - Project procedures & processes

Inputs
-Architectural design requirements - Supplied system elements - Integration Plan

Activities
- Define integration strategy -Receive system elements and enabling systems per scheduled deliveries -Integrate system elements -Record integration information

Outputs
- Verifiable system - Results of integration testing - Problem resolution records

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards -Integration enabling systems

Figure 4-6 Context Diagram for the Integration Process
Figure 4-6 Context Diagram for Integration Process TEMPLATE Chapter 4

Page 4.11 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.6.3

Inputs

Inputs for this process include: • Integration plan • Integration technology constraints • Enabling systems – Integration tools, facilities, and test equipment • Applicable system elements, interface, and assembly requirements specifications 4.6.4 Outputs Outputs for this process include: • Integration test and analysis results, including areas of non-conformance • Updated interface requirements specifications • Validated internal interfaces • Completed subsystem or system ready for verification • Product assembly drawings and manufacturing tool drawings 4.6.5 Process Activities:

Activities in the Integration Process include: • Schedule Integration Testing Tools and Facilities • Assemble system elements according to the integration plan • Validate Interfaces – confirm correct flow of information across internal interfaces through “black box testing” at each successive level of assembly • Test and analyze Assemblies – confirm correct functionality of assembled products through integration testing and analysis at each successive level of assembly • Document integration testing and analysis results • Document and control the architectural baseline – this includes capturing any modifications required during this process n Common approaches and tips: • Keep the Integrated Product Team engaged to assist with configuration issues and redesign. • Maintain configuration control over including drawings, specifications, interface control drawings, and published analyses. • Define an integration strategy that accounts for the schedule of availability of system elements, including human operators, and is consistent with fault isolation and diagnosis engineering practices.

Page 4.12 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.7 Verification Process
4.7.1 Purpose

The purpose of the Verification Process is to confirm that all requirements are fulfilled by the system elements and eventual system-of-interest, i.e. that the system has been built right. This process establishes the procedure for taking remedial actions in the event of non-conformance. 4.7.2 Content/Description

The Verification Process confirms that all elements of the system-of-interest perform their intended functions and meet the performance requirements allocated to them. Verification methods include test, inspection, analysis, and demonstration and are discussed in more detail in chapter 8. Verification activities are determined by the perceived risks, safety, and criticality of the element under consideration. A key outcome of the Planning Process is the creation of project procedures and processes that specify the forms of system assessments (conformation audits, integration testing, verification, and validation) in appropriate project documents (e.g. systems engineering plans, schedules, and specifications). Specification of verification criteria takes place as the requirements are written, but the creation of a procedure to assess compliance is part of this process. Figure 4-7 is the context diagram for the Verification Process.
Controls
-Agreements - Project procedures & processes

Inputs
-Baseline system requirements -Verification criteria -Requirements Verification Traceability Matrix (RVTM) -System element to be verified

Activities
-Define strategy for systems verification -Create, maintain RVTM -Conduct verification to demonstrate compliance with requirements -Analyze, record verification, and corrective action information

Outputs
-Requirements Verification Traceability Matrix (RVTM) -Report results of verification and corrective actions taken

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards

Figure 4-7 Context Diagram for the Verification Process 4.7.3 Inputs
Figure 4-7 Context Diagram for the Verification Process

TEMPLATE Chapter 4

Within the guidelines of enterprise policies and established project directives, system elements are verified against the baseline requirements and the information is maintained in a Requirements Verification Traceability Matrix.
Page 4.13 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.7.4

Outputs

The outputs of this process are documentation of the verification results, a record of any corrective actions recommended, Design Feedback/Corrective Actions taken, and evidence that the system element or system satisfies the requirements, or not. 4.7.5 Process Activities

The Verification Processes include: • Develop verification procedures • Schedule/confirm/install verification enabling systems • Execute verification procedures • Document verification results and enter data into traceability matrix n Common approaches and tips: • The requirements verification traceability matrix is frequently used as a single point of accountability for tracing a requirement back to the source of the need and forward through the life cycle to assess that the need has been met. • Beware the temptation to reduce verification activities due to budget or schedule overruns – remember the message of Figure 2-3 – discrepancies and errors are more costly to correct later in the life cycle.9 • Avoid conducting verification late in the schedule when there is less time to handle discrepancies, or too early, before development is complete.

4.8 Transition Process
4.8.1 Purpose

The purpose of the Transition Process is to transfer custody of the system and responsibility for system support from one organizational entity to another. This includes (but is not limited to) transfer of custody from the development team to the organizations that will subsequently operate and support the system. Successful conclusion of the Transition Process typically marks the beginning of the Utilization Stage of the system-of-interest. 4.8.2 Description

The Transition Process installs a verified system in the operational environment along with relevant enabling systems, such as, operator training systems, as defined in the agreement. As part of this process, the acquirer accepts that the system provides the specified capabilities in the intended operational environment prior to allowing a change in control, ownership, and/or custody. While this is a relatively short process, it should be carefully planned to avoid surprises and recrimination on either side of the agreement; and transition plans should be tracked and monitored to ensure
Page 4.14 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

all activities are completed to both parties’ satisfaction. Figure 4-8 is the context diagram for the Transition Process.
Controls
-Agreements - Project procedures & processes

Inputs
-System-of-interest - Installation Plan - Prepared operational environment

Activities
-Prepare Installation procedures -Prepare operational site -Install the system -Acceptance acknowledgement -Document results; anomalies; recommendations

Outputs
- Installation procedures

-Results from final acceptance activities -Installed System

Enablers
- Enterprise Infrastructure

-Enterprise Policies, Processes & Standards -Access to operational environment

Figure 4-8 Context DiagramContextthe Transition Process for Diagram for the Transition Process Figure 4-8 4.8.3
TEMPLATE Chapter 4

Inputs

Availability of the system-of-interest together with enabling systems is prerequisite to begin the Transition Process. Installation and commissioning of the system includes human operators, and is conducted according to agreements, and applicable health, safety, security and environmental regulations. 4.8.4 Outputs

At the conclusion of the Transition Process the system is installed, acceptance criteria are met or discrepancies documented with recommended and agreed corrective actions. 4.8.5 Process Activities

The Transition Processes include: • Prepare a transition strategy including operator training and logistics support. • Train the users in the proper use of the system; affirm users have the knowledge and skill levels necessary to perform Operation and Maintenance activities. • Receive final confirmation that the system—as operated and maintained by the intended users—meets their needs. This process typically ends with a formal, written acknowledgement that the system has been properly installed and verified, that all issues and action items have been resolved, and that all agreements pertaining to development and delivery of a fully supportable system have been satisfied fully or adjudicated.
Page 4.15 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Post-implementation problems are documented and may lead to corrective actions or changes to the requirements. n Common approaches and tips: • When acceptance activities can not be conducted within the operational environment, a representative locale is selected. • This process relies heavily on quality assurance and configuration management documentation.

4.9 Validation Process
4.9.1 Purpose

The purpose of the Validation Process is to confirm that the realized system complies with the stakeholder requirements. System validation is subject to approval by the project authority and key stakeholders. This process is invoked during the Stakeholders Requirements Definition Process to confirm that the requirements properly reflect the stakeholder needs and to establish validation criteria, i.e. that the right system has been built. This process is also invoked during the Transition Process to handle the acceptance activities. 4.9.2 Description

The Validation Process performs a comparative assessment as a means to determine if stakeholders’ requirements and defined measures of effectiveness have been correctly translated into technical design specifications and measures of performance. Validation criteria are selected based upon the perceived risks, safety and criticality. Figure 4-9 is the context diagram for the Validation Process.
Controls
-Agreements - Project procedures & processes

Inputs
-Integrated System Released for Validation -Validation Criteria for stakeholders requirements

Activities
-Define validation procedures -Ensure system readiness -Demonstrate conformance to stakeholder requirements -Recommend corrective actions -Attain stakeholder acceptance

Outputs
- Validation Procedures

- Reported results of validation activities and corrective actions taken

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards

Figure 4-9 Context Diagram for the Validation Process
Figure 4-9 Context Diagram for the Validation Process

Page 4.16 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.
TEMPLATE Chapter 4

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.9.3

Inputs

When stakeholder requirements are elicited, validation criteria are applied before proceeding. After the system-of-interest is verified, it is subjected to the validation criteria. The previously established requirements traceability matrix is maintained. The activities are governed by the agreements, project procedures, and appropriate enterprise policies. 4.9.4 Outputs

The primary outputs of the Validation Process are • Validation activity results • Design feedback/corrective actions • Approved system baseline 4.9.5 Process Activities

The following activities are part of the Validation process. • Develop validation procedures that demonstrate that the system is fit for its purpose and satisfies the stakeholders’ requirements. • Ensure readiness to conduct validation – system, enabling systems, and trained operators. • Conduct validation to demonstrate conformance to stakeholder requirements. • Document validation results and enter data into traceability matrix • If anomalies are detected, analyze for corrective actions, detect trends in failure to find threats to the system and evidence of design errors. n Common approaches and tips: • Validation methods during the concept phase include developing assessment scenarios exercising all system modes, and demonstrating system-level performance over the entire operating regime. The system design team uses the results of this activity to forecast success in meeting the expectations of users and the acquirer, as well as to provide feedback to identify and correct performance deficiencies before implementation.10

4.10 Operation Process
4.10.1 Purpose The purpose of the Operation Process is to use the system to deliver its services. This process is often executed concurrent with the Maintenance Process.

Page 4.17 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

4.10.2 Description The Operation Process sustains system services by supplying personnel to operate the system, monitoring operator-system performance, and monitoring the system performance. When the system replaces an existing system, it may be necessary to manage the migration between systems such that persistent stakeholders do not experience a breakdown in services. The Operation Stage of a system usually accounts for the largest portion of the total life cycle cost. If system performance falls outside acceptable parameters, this may indicate the need for corrective actions, in accordance with the Concept of Support and any associated agreements. When the system or any of its constituent elements reach the end of their planned or useful life, the team may enter the Disposal Process. Figure 4-10 is the context diagram for the Operation Process.
Controls
-Agreements - System Concept Documents

Activities Inputs
-Accepted system - Operational procedures - Consumables - Execute concept of operations -Maintain qualified staff -Obtain consumable materials -Monitor operations; assess performance -Determine appropriate actions -Collect operator and stakeholder satisfaction feedback

Outputs
- Ongoing system services -Results of monitoring system performance -Recommendations for corrective, remedial or preventive actions

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards -Operational environment and enabling systems

Figure 4-10 Context4-10 Context Diagram for theOperation Process Figure Diagram for the Operation Process
TEMPLATE Chapter 4

4.10.3 Inputs The Operation Process identifies and analyzes operational performance in the context of agreements, stakeholder requirements and organizational constraints. Concept documents generated early in the life cycle are used to direct the activities of this process. 4.10.4 Outputs Outputs of the Operation Process include: • Operational strategy – including staffing and sustainment of enabling systems and materials • System performance reports (statistics, usage data, and operational cost data)
Page 4.18 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• System trouble/anomaly reports with recommendations for appropriate action • Operational availability constraints – to influence future design and specification of similar systems or reused systems-elements 4.10.5 Process Activities Activities of the Operation Process include: • Provide operator training • Track system performance and account for operational availability • Perform operational analysis • Manage operational support logistics • Document system status and actions taken • Report malfunctions and recommendations for improvement n Common approaches and tips: • The Operations Process corresponds to a life cycle phase called the Utilization Stage. • Depending on the nature of agreements between different organizations, the development team may continuously or routinely communicate with users to determine the degree to which delivered services continue to satisfy their needs. The system may exhibit unacceptable performance when system elements implemented in hardware have exceeded their useful life or changes in the operational environment affect system performance. In the event of system failures or anomalies, it may be necessary to conduct engineering investigations to identify the source(s) of the failure and determine appropriate corrective actions. Systems engineers can assist in these activities.

4.11 Maintenance Process
4.11.1 Purpose The purpose of the Maintenance Process is to sustain the system through its useful life. 4.11.2 Description The Maintenance Process includes the activities to provide operations support, logistics, and material management. Based on feedback from ongoing monitoring of the operational environment, problems are identified and corrective, remedial or preventive actions are taken to restore full system capability. This process also contributes to the Requirements Analysis Process when considerations of constraints imposed in later life cycle stages are used to influence the system requirements and architectural design.
Page 4.19 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Controls
-Agreements - System Concept Documents

Activities Inputs
-Accepted system - Maintenance procedures - Spare parts and replaceable materials - Define maintenance strategy - Define design constraints imposed by maintenance -Implement Maintenance and Logistics support procedures; reporting -Perform maintenance actions -Maintain documentation

Outputs
- Maintenance Strategy

-Maintenance design constraints -Ongoing system services -Logistics service records - Maintenance history records

Enablers
- Enterprise Infrastructure

-Enterprise Policies, Processes & Standards -Operational environment & enabling systems

Figure 4-11 Context Diagram for the Maintenance Process Figure 4-11 Context Diagram for the Maintenance Process 4.11.3 Inputs
TEMPLATE Chapter 4

The Maintenance Process identifies and analyzes maintenance and support activities in the context of agreements, stakeholder requirements and organizational constraints. Concept documents generated early in the life cycle are used to direct the activities of this process. 4.11.4 Outputs The following are outputs of the Maintenance Process. • Maintenance strategy – accounts for the system’s technical availability, replacements for system elements and logistical support, maintenance personnel training and staff requirements • Maintenance constraints (to influence system requirements before design) • Reporting of failures and recommendations for action • Failure and lifetime performance data 4.11.5 Process Activities The following activities occur under the Maintenance Process. • Establish a maintenance strategy • Define maintenance constraints on system requirements • Obtain the enabling systems, system elements and other services used for maintenance of the system, monitor replenishment levels of spare parts, and manage the skills and availability of trained maintenance personnel • Implement problem reporting and resolution procedures – including scheduled replacement of system elements prior to failure (preventive maintenance) • Maintain a history of failures, actions taken, and other trends to inform
Page 4.20 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

operations and maintenance personnel, and other projects creating or utilizing similar system elements • Monitor customer satisfaction with system and maintenance support n Common approaches and tips: • The Maintenance Process corresponds to a life cycle phase called the Support Stage. • Use historic data and performance statistics to maintain high levels of reliability and availability; and provide input to improve the design of operational and future systems. • Planning for Maintenance begins early in the system life cycle with the development of supportability criteria. These criteria, which include reliability and maintainability requirements as well as personnel, training, facilities, etc. are included in the defined stakeholder requirements or system specification to ensure that they are considered in the system design. Chapter 9 contains a detailed discussion of acquisition logistics. • Maintain configuration management control throughout the Utilization and Support Stages in support of the Maintenance Process.

4.12 Disposal Process
4.12.1 Purpose The purpose of the Disposal Process is to remove a system element from the operational environment with the intent of permanently terminating its use; and to deal with any hazardous or toxic materials or waste products in accordance with applicable guidance, policy, regulations, and statutes. 4.12.2 Description This process is implemented in the Disposal Stage, but Disposal is a life cycle support process because concurrent consideration of disposal during the Development Stage generates requirements and constraints that must be balanced with defined stakeholders’ requirements and other design considerations. Environmental concerns are driving the designer to consider reclaiming the materials or recycling them into new systems. Regulatory reporting requirements are addressed by this process. Figure 4-12 is the context diagram for the Disposal Process.

Page 4.21 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Controls
-Agreements -System Concept Documents -Government and regulatory agencies -Industry standards for disposal

Activities Inputs
-Depleted system element -Production and operational environments -System Disposal Plan - Define disposal strategy - Impose disposal constraints on requirements -Deactivate the system (element) -Remove system (element) from operational environment -Maintain archival documentation of disposal; residual hazards

Outputs
- Disposal strategy

-Disposal constraints on requirements -Retired system element - Documentation as required

Enablers
- Enterprise Infrastructure -Enterprise Policies, Processes & Standards -Disposal enabling systems

Figure 4-12 Context Diagram for the Disposal Process
Figure 4-12 Context Diagram for the Disposal Process

4.12.3 Inputs
TEMPLATE Chapter 4

The Disposal Process works on a depleted system or system elements (for example, batteries) and implements the disposal plan according to applicable environmental laws, regulations, and policy. Stakeholder agreements and industry standards for disposal can also govern decision-making for this process. If production and operational environments must be restored to former conditions, details of the initial state are relevant. 4.12.4 Outputs The first application of the Disposal Process results in a set of constraints on the system requirements and a strategy for disposal of the system and relevant system elements. The outcome from retirement or disposal may include an inventory of system elements for reuse/storage, and any documentation required by regulation or enterprise standards. 4.12.5 Process Activities As required, Disposal Process activities include deactivating the elements to be terminated; disassembling the elements for ease of handling; removing the elements and any associated waste products from the operational site; removal of materials from storage sites; and consigning the elements and waste products for destruction or permanent storage. The Disposal Process also includes any steps necessary to return the environment to an acceptable condition; handling all system elements and waste products in an environmentally sound manner in accordance with applicable legislation, organizational constraints, and stakeholder agreements; and documenting

Page 4.22 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

and retaining records of Disposal activities as required for monitoring by external oversight or regulatory agencies. n Common approaches and tips: • The project team conducts analyses to develop solutions for ultimate disposition of the system, constituent elements, and waste products based on evaluation of alternative disposal methods available. Methods addressed should include storing, dismantling, reusing, recycling, reprocessing and destroying end products, enabling systems, system elements, and materials. • Disposal analyses include consideration of costs, disposal sites, environmental impacts, health and safety issues, responsible agencies, handling and shipping, supporting items, and applicable federal, state, local, and host nation regulations. • Disposal analyses support selection of system elements and materials that will be used in the system design; and they should be readdressed to consider design and project impacts from changing laws and regulations throughout the project life cycle. • Disposal Strategy and design considerations are updated throughout the system life cycle in response to changes in applicable laws, regulations, and policy • Consider donating an obsolete system; many items, both systems and information, of cultural and historical value have been lost to posterity because museums and conservatories were not considered as an option during the disposal stage. • Concepts such as Zero Footprint and Zero Emissions drive current trends toward corporate social responsibility that influence decision-making regarding cleaner production and operational environments and eventual disposal of depleted materials and systems.11 • The ISO 14000 series includes standards for Environmental Management Systems and Life Cycle Assessment.12 • Instead of designing cradle-to-grave products, dumped in landfills at the end of their 'life,' a new concept is transforming industry by creating products for cradle-to-cradle cycles, whose materials are perpetually circulated in closed loops. Maintaining materials in closed loops maximizes material value without damaging ecosystems.13

1 Used with permission, Professor Heinz Stoewer. 2 Gilb, T., Competitive Engineering, Elsevier, 2005. 3 Hook, I., Customer-Centered Products: Creating Successful Products Through Smart Requirements Management, Amacon, 2000. 4 Martin, J. N., Systems Engineering Guidebook, CRC Press, 1996. 5 see results of INCOSE vendor survey at www.incose.org/ProductsPubs/products/toolsdatabase.aspx Page 4.23 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6 7 8 9 10 11 12 13

an example is Gilb’s Planguage format, see URL www.gilb.com ISO 13407: Human-centered design processes for interactive systems Gilb, T., and Dorothy Graham, Software Inspection. Addison-Wesley Longman, 1993. SysTest, Systems Verification, Validation and Testing Methodology Guidelines, Contract: G1RD-CT2002-00683, http://www.incose.org/secoe/0105.htm Ibid. see URL: www.zerofootprint.net/ and www.zeri.org/ see URL: www.iso-14001.org.uk/ see URL: www.mcdonough.com/

Page 4.24 of 24
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5 Project Processes
5.1 Introduction
Within the system life cycle, the creation or upgrade of products and services is managed by the conduct of projects. For this reason, it is important to understand the contribution of systems engineering to the management of the project. Systems engineers continually interact with project management as illustrated in Figure 5-1 below. PROJECT

SYSTEMS ENGINEERING System Architecture Technical Coordination Systems Integration

Task Definitions

PROJECT PLANNING AND CONTROL Project Planning Resource Allocation Financial Contact Management

Risk Management Customer Interaction

Figure 5-1 Project Management/Systems Engineering Overlap1 The processes described in this section are applied according to the risk and complexity of the project. These processes fall in two categories; project specific processes include project planning, project assessment, and project control; life cycle processes, which apply both inside and outside the project context, include decisionmaking, risk management, configuration management, and information management. Many of these latter processes are found throughout an enterprise as they are essential to generic management practices. This chapter of the handbook focuses on processes relevant to the technical coordination of a project. Table 5-1 contains an acronym list for acronyms that appear in the context diagrams in this chapter. Table 5-1 Acronym List
CMP IMP QMP RMP SEP WBS Configuration Management Plan Information Management Plan Quality Management Plan Risk Management Plan Systems Engineering Plan Work Breakdown Structure
Page 5.1 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.2 Project Planning Process
5.2.1 Purpose

Project planning establishes the direction and infrastructure necessary to assess and control the progress of a project. This process identifies the details of the work and the right set of personnel/skills/facilities with a schedule of need for resources from within and outside the enterprise. 5.2.2 Description

Project planning starts with a statement of need, often expressed in a project proposal. The planning process is performed in the context of the enterprise. Enterprise processes establish and identify relevant policies and procedures for managing and executing a technical effort; identifying the technical tasks, their interdependencies, risks and opportunities, and providing estimates of needed resources/budgets. This is also the point in the process to determine the need for resources and specialists during the project life-cycle to improve efficiency/effectiveness and decrease cost over-runs. For example during product design, various disciplines work together to evaluate parameters such as manufacturability, testability, operability and sustainment against product performance. In some cases, project tasking is concurrent to achieve the best results. Figure 5.2 is the Planning Process Context Diagram.
Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Inputs
-Proposals -Project Constraints - Roles & Responsibilities - Resource Requirements Forecast

Activities
- Define Scope, Objectives, and Constraints - Define WBS, Work Packages, Schedules & Budgets -Prepare Project Plans -Establish Project Structure, Roles & Responsibilities

Outputs
- Project Plans, WBS & Data Dictionary - SEP, tailored CMP, IMP, RMP & QMP - Key Personnel & Resources - Project Performance Measures

Enablers
- Enterprise Project Procedures & Processes -Enterprise Infrastructure

Figure 5-2 Context Diagram for the Project Planning Process
Figure 5-2 Context Diagram for the Project Planning Process

5.2.3

Inputs

The primary inputs to the planning process are the project proposal and technical results from the initial concept exploration stage. Project resources are derived from and require coordination with the enterprise. The enterprise also provides the contextual policies, procedures and standards.
Page 5.2 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.2.4

Outputs

Principle outputs from planning are a work breakdown structure (WBS), a data dictionary, project milestones, task descriptions with completion criteria and work authorizations, a detailed budget, a project quality plan, identification of required technical reviews and their completion criteria, methods for controlling changes, risk assessment and methodology, identification of other technical plans and documentation to be produced for the project. An important outcome of planning is the Systems Engineering Plan. This plan identifies the activities to be accomplished, key events that must be satisfied at decision gates throughout the project, work packages that define the working schedule and the assignment of required resources (people, equipment and facilities) that define the project budget. Each decision gate will have a list of activities or tasks that must be successfully completed prior to entering the decision gate. This plan references other planning instruments that are tailored for use on the project such as the Configuration Management, Risk Management, and Information Management Plans discussed in later sections of this chapter. 5.2.5 Process Activities

Process activities include: • Analyze project proposal and related agreements to define project scope • Identify project objectives and project constraints • Define Key Events that provide structure for the project. Once the key events are established, the tasks and activities that need to be completed prior to each event are identified • Define top-level work packages for each task and activity identified. Each work package should be tied to resources required including procurement strategies. Develop project schedule based on objectives and work estimates • Define costs and estimate project budget • Prepare a Systems Engineering Plan; tailor the quality, configuration, risk and information management plans to meet the needs of the project. • Tailor the enterprise risk management processes and practices in accordance with the agreements and the Systems Engineering Plan to establish a systematic approach for identifying and handling risk. • Tailor the enterprise configuration management processes and practices in accordance with the agreements and the Systems Engineering Plan to establish a systematic approach for identifying and handling change requests • Establish tailoring of enterprise procedures and practices to carry out planned effort. Chapter 10 contains a detailed discussion on tailoring. n Common approaches and tips: • Integrated product development teams are used frequently to break down communications and knowledge stovepipes within organizations.2
Page 5.3 of 16

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Creation of the WBS is an activity where systems engineering and project management intersect.3 • Skipping or taking shortcuts in the planning process reduces the effectiveness of other project processes. • Even agile project management methods include planning – the cycles may be shorter and more frequent, but planning is an essential process. • Incorporate risk assessment early in the planning process to identify areas that need special attention or contingencies. Always attend to the technical risks. • The Project Management Institute is a source of guidelines for project planning.4

5.3 Project Assessment Process
5.3.1 Purpose

This process collects and evaluates the status of the project comparing the results achieved against the plan to assess the maturity of the project. Assessments are scheduled periodically and for all milestones and decision gates. The intention is to maintain good communications within the project team and with the stakeholders, especially when deviations are encountered. 5.3.2 Description

The Project Planning Process identified details of the work effort and expected results. Project assessment collects data to evaluate the adequacy of the project infrastructure, the availability of necessary resources, and compliance with project performance measures. A discussion of the creation and assessment of Technical Performance Measures (TPM) is found in chapter 7. Figure 5-3 is the context diagram for the Project Assessment Process.
Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Inputs
- Project Plans - Key Personnel & Resources -Project Performance Measures -Prior Project Status

Activities
-Collect project status -Assess project team -Assess project performance -Conduct management and technical reviews -Monitor critical tasks -Monitor new technologies -Analyze deviations from plan

Outputs
- Project Performance Measures assessment -Recommendations for adjustments to project plans -Risk assessment situations -Change requests

Enablers
- Enterprise Project Procedures & Processes - Enterprise Infrastructure

Figure 5-3 Context Diagram for the Project Assessment Process
Figure 5-3 Context Diagram for the Project Assessment Process

Page 5.4 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.3.3

Inputs

The planning outputs provide the basis for ongoing evaluation of the progress and achievements of a project against performance requirements, costs, schedule, and overall business objectives. The enterprise provides the contextual policies, procedures and standards for project assessment. 5.3.4 Outputs

The outcome of project assessment is information on the health and maturity of the project work effort. Results of this process are used to make decisions regarding future work and technical options. 5.3.5 Process Activities

Activities within this process include: • Determine actual and projected cost against budget; actual and projected time against schedule and deviations in project quality • Evaluate the effectiveness of personnel • Evaluate the adequacy and the availability of the project infrastructure • Evaluate project progress against established criteria and milestones • Conduct required reviews, audits, inspections to determine readiness to proceed to next milestone • Monitor critical tasks and new technologies – see Risk Management section below • Make recommendations for adjustments to project plans; these are input to the project control process and other decision-making processes • Communicate status as designated in the agreements, policies and procedures n Common approaches and tips: • One way for project management to remain updated on project status is to conduct regular team meetings; short standup meetings on a daily or weekly schedule are effective for smaller groups. • Prevailing wisdom suggests that “what gets measured gets done,” but projects should avoid the collection of metrics that are not used in decision-making and detract from doing real work. • The Project Management Institute is a source of guidelines for project assessment.

5.4 Project Control Process
5.4.1 Purpose

The Project Control Process uses project assessment to direct the efforts of the project. This includes redirecting the project when deviations from the plan are uncovered, or the project does not reflect the anticipated maturity.
Page 5.5 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.4.2

Description

The rigor of the project control process is directly dependent on the complexity of the system-of-interest. Project control involves both corrective and preventive actions taken to ensure that the project is performing according to the plans and schedules, and within projected budgets. Assessments also monitor the technical progress of the project, and may identify new risks or areas that require additional investigation. The Project Control Process may trigger activities within the other process areas in this chapter. See Figure 5-4 for the Project Control Process Context Diagram.
Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Inputs -Project assessments; personnel, resources, performance

Activities
- Initiate corrective / preventive actions - Problem resolution - Decision to proceed

Outputs
- Project Corrective Action (if needed) -Decision to proceed (or not)

Enablers
- Enterprise Project Procedures & Processes - Enterprise Infrastructure

Figure 5-4 Context Diagram for Figure 5-4 Context Diagramthe Control Process for the Control Process

5.4.3

Inputs

Results of the project assessment process are analyzed to determine the maturity of the project and identify any deviations from the plans or technical performance of the product. The project is guided by the enterprise policies, procedures, and standards. 5.4.4 Outputs

New directions are communicated to both project team and customer, when appropriate. If assessments are associated with a decision gate, a decision to proceed, or not to proceed, is taken. 5.4.5 Process Activities

The activities within this process include: • Analyze assessment results • Initiate corrective actions when the assessment indicates deviation from approved plan • Initiate preventive actions when the assessment indicates a trend toward deviation

Page 5.6 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Initiate problem resolution when the assessment indicates non-conformance with performance success criteria • Establish work items and changes to schedule to reflect the actions taken • Negotiate with suppliers for any goods or services acquired from outside the enterprise • Make the decision to proceed, or not to proceed, when assessment supports a tollgate or milestone event n Common approaches and tips:

• Project teams need to identify critical areas and control them through monitoring, risk management or configuration management. • An effective feedback control process is an essential element to enable the improvement of project performance. • Agile project management techniques schedule frequent assessments and make project control adjustments on tighter feedback cycles than other plan-drive development models. • Tailoring of enterprise processes and procedures should not jeopardize any certifications. Processes must be established with effective review, assessment, audit, and upgrade as discussed in chapter 6.

5.5 Decision-Making Process
5.5.1 Purpose

Decisions are made throughout the life cycle of every system whenever alternative courses of action exist. Milestones and decision gates mark the most formal decisions. Less formal decisions require less structure, bud documenting all decisions, with their rationale, supports future decision-making. 5.5.2 Description

As the system progresses from early concept definition throughout sustainment, decisions are needed to direct the focus of all personnel toward the desired result. Every decision involves an analysis of the alternative options, the selection of a course of action, and recording of the eventual decision with supporting documentation. Decisions come from many sources and range from programmatic to highly technical. Different strategies are appropriate to each category of decision. A more complete discussion of decision gates and decision-making strategies is found in chapter 7. All decisions are taken within the context of an enterprise. Some decisions are made within the context of other processes, for example approval of an engineering change proposal within the Configuration Management Process. See Figure 5-5 for the Decision-making Process Context Diagram.
Page 5.7 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Inputs -Problem or decision gate -History of prior decisions - Assessment from all relevant persons

Activities
-Define strategy; success criteria -Define alternatives -Involve relevant persons -Make and record decision

Outputs - Strategy -Preferred course of action -Decision rationale documents

Enablers
- Enterprise Project Procedures & Processes - Enterprise Infrastructure

Figure 5-5 ContextContext Diagramfor the Decision-making Process Diagram for the Decision-making Process Figure 5-5 5.5.3 Inputs

Decisions related to decision gates are taken on a pre-arranged schedule. Other requests for a decision may arise from any stakeholder. Decisions should be taken in consideration of prior history and all relevant persons should be involved in the decision-making activities. The enterprise provides the contextual policies, procedures and standards. 5.5.4 Outputs

The approved decision is documented along with rationale, assumptions, constraints and supporting analysis, recorded and communicated. 5.5.5 Process Activities

Decision-making Process activities include: • Identify the need for a decision and the strategy for making the decision, including desired outcomes and measurable success criteria • Identify all personnel with knowledge and experience relevant to the decision • Evaluate the consequences of alternative choices using the selected strategy and optimize the decision • Record the decision made with the relevant data and supporting documentation • Communicate new directions from the decision n Common approaches and tips: • Decision support systems have been developed to assist decision makers in considering the implications of various courses of action. • Failure to maintain a history of prior studies and decisions can result in wasted effort when old questions reappear.

Page 5.8 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.6 Risk and Opportunity Management Process
5.6.1 Purpose

Risk and opportunity management is a disciplined approach to dealing with uncertainty that is present throughout the entire systems life cycle. The objective is to achieve a proper balance between risk and opportunity. This process is used to understand and avoid the potential cost, schedule, and performance/technical risks to a system, and to take a proactive and structured approach to anticipate negative outcomes, respond to them if they occur; and to identify potential opportunities that may be hidden in the situation. Enterprises manage many forms of risk and the risk associated with system development is managed in a manner that is consistent with the enterprise strategy. 5.6.2 Description

Every new system or modification of an existing system is based on pursuit of an opportunity. Risk always is present in the life cycle of systems, and the risk management actions are assessed in terms of the opportunity being pursued. The system may be intended for technical accomplishments near the limits of the state of the art, creating technical risk. Risk can also be introduced during architectural design caused by the internal interfaces that exits between the system elements. System development may be rushed to deploy the system as soon as possible to exploit a marketing opportunity or meet an imminent threat, leading to schedule risk. All systems are funding-limited so that cost risk is always present. Risk can develop within a project, since (for example) technical risk can create schedule risk, which in turn can create cost risk. Chapter 7 contains a more detailed discussion of these four risk categories; technical, schedule, cost and programmatic. Ambient risk is often neglected in project management. The ambient risk is defined as the risk caused by and created by the surrounding environment (ambience) of the project5. Project participants have no control over ambient risk factors, but can learn to observe the external environment and eventually to take proactive or reactive action to minimize the impact of the environment on the project. The typical issues are time dependent processes, rigid sequence of activities, one dominant path for success and little slack. Projects are subject to uncertainty; an uncertain event may be harmful if it occurs (threats), another may assist in achieving objectives (opportunities). Dealing with both types of uncertainty under the single heading of “risk management” minimizes process and overhead and expands organizational and personal commitment towards finding and capturing opportunities. Since traditionally, project managers think of risks as threats alone, it may be a change to begin recognizing opportunities. If opportunities are handled along with threats, risk management language needs to be balanced with terms for opportunities such as “exploit”, “share”, “protect” and
Page 5.9 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

“enhance”. Project managers may need encouragement to be open to opportunities and to manage both threats and opportunities proactively. Typical strategies for coping with risk include transference, avoidance, acceptance or taking action to reduce the anticipated negative effects of the situation. Most risk management processes include a prioritization scheme whereby risks with the greatest negative effect and the highest probability of occurrence are handled before those deemed to have lower negative consequences and lower probability of occurrence. The objective of risk management is to balance the allocation of resources such that the minimum amount of resources achieves the greatest risk mitigation (or opportunity realization) benefits. See Figure 5-6 for the Risk Management Process Context Diagram.
Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Inputs
-Project risk assessments -Prior Risk Matrix - Project plans & performance

Activities
-Identify risk items -Quantify and prioritize risk items -Specify strategy for each risk item -Communicate risk status and actions

Outputs - Risk Matrix; status, priority, strategy -Risk mitigation action plan

Enablers
- Enterprise Project Procedures & Processes - Enterprise Infrastructure

Figure 5-6 Figure 5-6 ContextContext Diagramforthe Risk Management Process Diagram for the Risk Management Process

5.6.3

Inputs

In the Project Planning Process, a Risk Management Plan is tailored to satisfy the individual project procedures for risk management. In many cases, risk situations are identified during the project assessment process. A risk management process establishes documentation, often maintained as a risk matrix, which includes a description, priority, mitigation, responsible person, and status of each risk item. 5.6.4 Outputs

The Risk Matrix contains the findings of the Risk Management Process. For selected risks, an action plan is produced to direct the project team to properly respond to the risks. If appropriate, change requests are generated to mitigate technical risk. 5.6.5 Process Activities

Process activities include: • Identify and define risk situations • Analyze risks for likelihood and severity in order to determine the magnitude
Page 5.10 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

of the risk and its priority for handling • Define handling scheme and resources for each risk, including identification of a person who will be responsible for continuous assessment of the status of the situation • Using the criteria for acceptable and unacceptable risk, generate a plan of action when the risk threshold exceeds acceptable levels • Maintain a record of risk items and how they were handled • Maintain transparent risk management communications n Common approaches and tips: • One rule of thumb for identifying risks is to pose each risk candidate in a “if , then ” format. This form helps to determine the validity of a risk and to assess its magnitude or importance. If the statement does not make sense or cannot be put in this format, then the candidate is probably not a true risk. For example, a statement that describes a situation but not a consequence implies that the potential event will not affect the project. Similarly, a statement of potential consequence without a clear situation description is worthy of more attention. • Document everything so if there are unforeseen issues and challenges during execution you can recreate the environment within which the planning decisions were made and know where to update the information to correct the problem. • Negative feedback toward personnel who identify a potential problem will discourage the full cooperation of engaged stakeholders, and could result in failure to address serious risk-laden situations. Conduct a transparent risk management process to encourage suppliers and other stakeholders to assist in the risk mitigation efforts. Some situations can be difficult to categorize visà-vis probability and consequences – involve all relevant stakeholders in this evaluation to capture the maximum variety in viewpoints. • Many analysis completed throughout the technical processes, such as FMECA, may identify candidate risk elements. • The metrics for risk management vary by organization and by project. As with any metric, use measurements or statistics that help manage the risk. • The Project Management Institute is a good source for more information on Risk Management. • The Institute of Risk Management has generated The Risk Management Standard.6 • See Forsberg, et. al. for additional reading on opportunity management. 7

5.7 Configuration Management Process
5.7.1 Purpose

The objective of configuration management is to ensure effective management of
Page 5.11 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

the evolving configuration of a system, both hardware and software, during its life cycle. Fundamental to this objective is the establishment, control, and maintenance of software and hardware baselines. Baselines are reference points for maintaining development and control. These baselines, or reference points, are established by review and acceptance of requirements, design, and product specification documents. The creation of a baseline may coincide with a project milestone or decision gate. As the system matures and moves through the life cycle stages the software or hardware baseline is maintained under configuration control. 5.7.2 Description

Configuration Management ensures that product functional, performance, and physical characteristics are properly identified, documented, validated, and verified (establishing product integrity); that changes to these product characteristics are properly identified, reviewed, approved, documented, and implemented; and that the products produced against a given set of documentation are known. See chapter 8 for additional discussion relevant to configuration management. Evolving system requirements are a reality that must be addressed over the life of a system development effort, and throughout the Utilization and Support Stages of the system. See Figure 5-7 for the Configuration Management Process context diagram.
Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Activities Inputs
-Configuration baseline(s) -Change requests -CMP -Identify items for configuration management -Assess and control changes to items -Communicate status of controlled items

Outputs - Configuration baseline(s)
-Baseline control -Documented status and impact of change request

Enablers
- Enterprise Project Procedures & Processes - Enterprise Infrastructure

Figure 5-7 Context Diagram for the Configuration Management Process 5.7.3 Inputs

Figure 5-7 Context Diagram for the Configuration Management Process

In the Project Planning Process, a Configuration Management Plan is tailored to satisfy the individual project procedures for configuration management. In many cases, the need for change requests is identified during the project assessment process.

Page 5.12 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.7.4

Outputs

The primary output of the configuration management process is the maintenance of the configuration baseline for the system and system elements. Items are placed under formal control as part of the decision-making process. The required configuration baseline documentation is developed and approved in a timely manner to support required systems engineering technical reviews, the system’s acquisition and support strategies, and production. This documentation is maintained throughout the life of the system. The configuration management process formally documents the impact to any process, organizations, decisions, products, and services affected by a given change request. 5.7.5 Process Activities

Process activities include: • Identify system elements that are maintained under configuration control • Maintain enough information to ensure system/product integrity • Establish a configuration control cycle that incorporates evaluation, approval, validation, and verification of engineering change requests • Develop and maintain configuration control documentation • Perform Configuration Audits associated with milestones and decision gates to validate the baselines n Common approaches and tips: • Establish a configuration control board with representation from all stakeholders and engineering disciplines participating on the project – see chapter 8 for more details. • Begin the configuration management process in the infancy phases of the system and continue through until disposal of the system.

5.8 Information Management Process
5.8.1 Purpose

Information Management ensures that information is properly stored, maintained, secured, and accessible to those who need it thereby establishing/maintaining integrity of relevant system life cycle artifacts. 5.8.2 Description

Information exists in many forms, and different types of information have different value within an enterprise. Information assets, whether tangible or intangible, have become so pervasive in contemporary organizations that they are indispensable. The impact of threats to secure access, confidentiality, integrity, and availability of information can cripple the ability to get work done. As information systems become
Page 5.13 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

increasingly interconnected, the opportunities for compromise increase.8 The following are important terms in Information Management: • Information is what an organization has compiled or its employees know. It can be stored and communicated, and it might include customer information, proprietary information, and/or protected (e.g. by copyright, trademark, or patent) and unprotected (e.g. business intelligence) Intellectual Property. • Information assets are intangible information and any tangible form of its representation, including drawings, memos, e-mail, computer files, and databases. • Information security generally refers to the confidentiality, integrity, and availability of the information assets. • Information security management includes the controls used to achieve information security and is accomplished by implementing a suitable set of controls, which could be policies, practices, procedures, organizational structures, and software functions. • Information Security Management System is the life-cycle approach to implementing, maintaining, and improving the interrelated set of policies, controls, and procedures that ensure the security of an organization's information assets in a manner appropriate for its strategic objectives. Information management provides the basis for the management of and access to information throughout the system life cycle, including after disposal if required. Designated information may include enterprise, project, agreement, technical, and user information. The mechanisms for maintaining historical knowledge in the prior processes – decision-making, risk and configuration management – are under the responsibility of information management. See Figure 5-8 for the Information Management Process Context Diagram.
Controls
-Enterprise Strategic Plan -Enterprise Policies & Standards

Inputs -System-relevant information -Data dictionary -IMP

Activities -Identify information to be managed -Define representations -Transform, maintain, publish information

Outputs - Published, current, valid system information

Enablers
- Enterprise Project Procedures & Processes - Enterprise Infrastructure

Figure 5.8 Information Management Process

Figure 5-8 Context Diagram for the Information Management Process

Page 5.14 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5.8.1

Inputs

In the Project Planning Process, an Information Management Plan is tailored to satisfy the individual project procedures for information management. An information management plan identifies the system-relevant information to be collected, retained, secured, and disseminated, with a schedule for retirement. 5.8.2 Outputs

The output of this process is the availability for use and communication of all relevant systems artifacts in a timely, complete, valid and, if required, confidential manner. 5.8.3 Process Activities

Process activities include: • Establish/maintain a system data dictionary – see project planning outputs • Define system-relevant information, the storage requirements, access privileges and the duration of maintenance • Define formats and media for capture, retention, transmission, and retrieval of information • Identify valid sources of information and periodically obtain artifacts of information • Maintain information according to security and privacy requirements • Retrieve and distribute information as required • Archive designated information for compliance with legal, audit and knowledge retention requirements • Retire unwanted, invalid or unverifiable information according to organizational policy, security, and privacy requirements n Common approaches and tips: • Identify information-rich artifacts and store them for later use even if the information is informal such as a design engineer’s notebook. • Information management delivers value to the organization and the project by using a variety of mechanisms to provide access to the contents of data repositories. Email, web-based access through intranets, and database queries are a few examples. • ISO 17799 "Code of Practice for Information Security Management" is an international standard that provides a best practices framework for implementing security controls. • ISO 10303, STandard for the Exchange of Product model data (STEP) includes Application Protocol (AP) 239 Product Lifecycle Support (PLCS), which addresses information requirements for complex systems; this topic is discussed in chapter 8.9

Page 5.15 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

1 Kossiakoff, Alexander and William N. Sweet (2003). Systems Engineering; Principles and Practice, NJ: Hoboken: John Wiley & Sons, Inc., page 91. 2 Martin, J. N., Systems Engineering Guidebook, CRC Press, 1996. 3 Forsberg, K., et. al., Visualizing Project Management, 3 ed. John Wiley & Sons, 2005, p. 198-219. 4 see URL: www.pmi.org 5 Fossnes, T., (2005), Lessons from Mt. Everest Applicable to Project Leadership. Proceedings of the 15th Annual INCOSE International Symposium, Rochester, NY. 6 See URL: www.theirm.org 7 Forsberg, K., et. al., Visualizing Project Management, 3 ed. John Wiley & Sons, 2005, p. 223-253. 8 STSC Crosstalk, http://www.stsc.hill.af.mil/crosstalk/2003/05/brykczynski.html 9 see URL: www.plcs-resources.org

Page 5.16 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6 Enterprise and Agreement Processes
6.1 Introduction
Enterprise processes are the purview of the organization and are used to direct, enable, control, and support the system life cycle. This chapter and the ISO/IEC 15288 focus on the capabilities of an organization relevant to the realization of a system; they are not intended to address general business management objectives, although sometimes the two overlap. Within the enterprise, organizational units cooperate to develop, implement, deploy, operate, maintain and dispose of the system-of-interest. Enabling systems may also need to be modified to meet the needs of new systems; developed or acquired if they do not exist. Examples include development, manufacturing, training, testing, transport, maintenance and disposal systems that support the system-of-interest. Every enterprise claims interfaces with industry, academia, customers, partners, etc. An overall objective of enterprise processes is to identify these external interfaces and establish the parameters of these relationships, including identifying the inputs required from the external entities and the outputs that will be provided to them. This network of relationships provides the context of the business environment of the enterprise and access to future trends and research. Some relationships are defined by the exchange of products or services. There are six Enterprise Processes identified by ISO/IEC 15288. They are: Enterprise Environment Management, Investment Management, System Life Cycle Processes Management, Resource Management, and Quality Management. Discussion of these processes and their interfaces is the topic of this chapter. The enterprise will tailor these processes and their interfaces to meet specific strategic and communications objectives. There are two Agreement Processes identified by ISO/IEC 15288: the Acquisition Process, and the Supply Process. These processes are discussed in the closing sections of this chapter. They are included in this chapter because they conduct the essential business of the enterprise, namely the buying and selling of products and services. They establish the relationships between enterprises relevant to the acquisition and supply of products and services. Agreements may exist between organizational units internal or external to the enterprise. Figure 6-1 illustrates the critical success factors for enterprise and agreement processes.1

Page 6.1 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Strategy

People

Market

Resources
Figure 6-1 Key Success Factors for Enterprise Processes

6.2 Enterprise Environment Management Process
6.2.1 Purpose

The purpose of the Enterprise Environment Management Processes is to establish and maintain a set of policies and procedures at the enterprise level that support the organization’s ability to acquire and supply products and services. 6.2.2 Description

The work of the organization is accomplished through projects. These projects are conducted within the context of the enterprise – the enterprise environment. This environment needs to be defined and understood within the organizations and the project to ensure alignment of the working units and achievement of overall enterprise strategic objectives. This process exists to establish, communicate, and continuously improve the system life cycle (SLC) process environment. Figure 6-2 contains the context diagram for the Enterprise Environment Management Process.

Page 6.2 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Controls
- Gov/Corp Laws & Regulations - Enterprise Strategic Plan

Inputs
-Trends and Research from Relationships Network -Assessment of SLC processes

Activities
- Establish Business Area Plans - Establish SLC Policies & Procedures - Identify roles, responsibilities & authorities - Define Business Progress Criteria - Conduct Periodic Reviews of SLC - Communicate Policies & Procedures

Outputs
- SLC Management Policies/Procedures - SLC Management Accountability/Authority - Policy for improvement of SLC processes

Enablers
- Enterprise Tactical Plan - Enterprise Infrastructure

Figure 6-2 Enterprise Environment Management Process Context Diagram 6.2.3 Inputs
Figure 6-2 Enterprise Environment Management Process Context Diagram

The network of relationships include: Government, Industry, and Academia. Each of these external interfaces provide unique and essential information for the enterprise to succeed in business and meet the continued need and demand for improved and effective systems and products for the customers. It is up to the enterprise environment management process to fully define and utilize these external entities and interfaces, i.e. their value, importance and capabilities that are required by the enterprise. • Legislative, regulatory, and other government requirements • Industry systems engineering and management related standards, training, capability maturity models • Academic education, research results, future concepts and perspectives, requests for financial support The enterprise environment is built on the existing enterprise infrastructure, including facilities, personnel and knowledge. Integration and interoperability of supporting systems, such as financial, human resources, and training, is critically important to execute the enterprise strategic objectives. Feedback from active projects is used to refine and continuously improve the enterprise environment. 6.2.4 Outputs

The essential products from this process support the systems life cycle (SLC) processes in the form of policies, procedures, guidance, and directions needed for the enterprise to provide the most cost effective environment for a portfolio of systems over their life cycle. This includes:

Page 6.3 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• SLC strategic plans, policies, procedures, directives, guidance – for example, templates for management plans such as configuration, information, and risk management plans • Accountability & authority for all systems engineering & management processes within the enterprise • Roles & Responsibilities defined for systems engineering & management processes within the enterprise • Review criteria for process improvement (including assessments, approvals/ disapprovals, recommendations) 6.2.5 Process Activities

This process includes the following activities: • Establish Business Area plans – use the strategic objectives to identify candidate projects to fulfill them • Establish SLC policies, processes, procedures – consistent with the enterprise and business area plans • Define Roles, Responsibilities & Authorities – align the portfolio of projects • Define the decision-making criteria that determine entering and exiting each stage of the SLC – expressed in terms of business achievements • Conduct periodic reviews of the SLC models used by projects – use assessments to confirm the adequacy and effectiveness of the SLC processes • Disseminate policies and procedures throughout the enterprise. n Common approaches and tips: • The process of developing the business area plans helps the enterprise to assess where it needs to focus activities and resources to meet present and future strategic objectives. Include representatives from relevant stakeholders in the enterprise community. • Manage the network of external relationships – assign personnel to identify standards, industry & academia research and other sources of enterprise management information and concepts needed by the enterprise. • Establish an enterprise architecture – integrating the infrastructure of the enterprise can make the execution of routine business activities more efficient. • Establish an enterprise communication plan – most of the processes in this handbook include dissemination activities. An effective set of communication methods is needed to ensure that all stakeholders are well-informed. • Base the policies and procedures on an Enterprise level strategic plan that provides a comprehensive understanding of the Enterprise’s goals, objectives, stakeholders, competitors, future business, and technology trends. • Work continually to improve the SLC processes.

Page 6.4 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6.3 Investment Management Process
6.3.1 Purpose

The purpose of the Investment Management Process is to initiate and sustain investments in projects that meet the objectives of the organization and to cancel or redirect investments for projects that do not. 6.3.2 Description

Projects create the products or services that generate income for an enterprise. The conduct of successful projects requires an adequate allocation of funding and resources and the authority to deploy them to meet project objectives. Most business entities mange the commitment of financial resources using well defined and closely monitored processes. The Investment Management Process also performs ongoing evaluation of the projects in its portfolio. Based on periodic assessments, projects are determined to justify continued investment if they • are progressing toward achieving established goals; • are complying with project directives from the enterprise; • are conducted according to approved plans; and, • are providing a service or product that is still needed and providing acceptable investment returns. Otherwise, projects may be redirected, or in extreme instances, cancelled. Figure 6-3 shows the context diagram for the Investment Management Process.
Controls
- Gov/Corp Laws & Regulations - Enterprise Strategic Plan

Activities Inputs
-Investment Opportunities -Agreements -Active Projects Portfolio -Stakeholder Requirements -Project Assessments
- Establish New Business Opportunities

Outputs
- Qualified Investment Opportunities - Allocated Resources & Budgets - Defined Project Management Authority - Investment Direction (sustain, cancel projects)

- Define Projects (authority, outcomes, resources) - Identify Project Interfaces - Specify Reporting, Review Requirements - Authorize Project Execution – initiate, continue, cancel - Evaluate Ongoing Projects

Enablers
- Enterprise Tactical Plan - Enterprise Infrastructure

Figure 6-3 Investment Management Process Context Diagram
Figure 6-3 Investment Management Process Context Diagram

Page 6.5 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6.3.3

Inputs

Investment opportunities are not all equal. Enterprises are limited in the number of projects that can be conducted concurrently. Some investments are not well aligned with the overall strategic plan of the enterprise. For these reasons, opportunities are evaluated against the portfolio of existing agreements and ongoing projects, and taking into consideration the attainability of the stakeholders’ requirements. The enterprise investment decisions are built on the existing enterprise infrastructure, including facilities, personnel and knowledge. Efficient use of these resources is achieved by exploiting opportunities to share enabling systems or to use a common system element on more than one project. These opportunities are enabled by good communications within the enterprise infrastructure. 6.3.4 Outputs

The successful implementation of the Investment Management Process results in the following outputs: • Qualified investment opportunities result in the initiation of new project(s) • Resources and budgets are identified and allocated to the projects • Project management accountability and authorities are defined • Projects meeting assessment criteria are sustained • Project not meeting assessment criteria are redirected or terminated 6.3.5 Process Activities

This process includes the following activities: • Identify and assess investment opportunities consistent with the enterprise strategic plan. • Initiate projects; define project management accountabilities and authorities, identify expected project outcomes. • Allocate adequate funding and other resources. • Identify opportunities for multi-project synergies. • Specify project reporting requirements and review schedule that govern the progress of the project. • Evaluate ongoing projects to provide rationale for continuation, redirection or termination. n Common approaches and tips: • When investment opportunities present themselves, prioritize them based on measurable criteria such that projects can be objectively evaluated against a threshold of acceptable performance. • The expected project outcomes should be based on clearly defined criteria that are measurable to ensure than an objective assessment of progress can be
Page 6.6 of 22

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

determined. Specify the investment information that will be assessed for each milestone. Initiation should be a formal milestone that does not occur until all resources are in place as identified in the project plan. • Establish a program office or other coordination organization to manage the synergies between active projects in the enterprise portfolio. Complex and large enterprise architectures require the management and coordination of multiple interfaces and make additional demands on investment decisions. These interactions occur within and between the projects. • Include risk assessments in the evaluation of ongoing projects. Projects that contain risks that may pose a challenge in the future might require redirection. Cancel or suspend projects whose disadvantages or risks to the organization outweigh the investment. • Include opportunity assessments in the evaluation of ongoing projects. Addressing project challenges may represent a positive investment opportunity for the enterprise. Avoid pursuing opportunities that are inconsistent with the capabilities of the organization and its strategic goals and objectives or contain unacceptably high technical risk, resource demands, or uncertainty. • Allocate resources based on the requirements of the projects; otherwise, the risk of cost and schedule overruns may have a negative impact on quality and performance of the project. • Establish effective governance processes that directly support investment decision-making and communications with project management.

6.4 System Life Cycle Processes Management Process
6.4.1 Purpose

The purpose of the System Life Cycle Process Management Process is to establish a set of proven and effective system life cycle processes and make them available for use by the enterprise. 6.4.2 Description

This process provides integrated, system life cycle (SLC) processes necessary to meet the enterprise’s strategic plans, policies, goals and objectives for all projects and all system life cycle stages. The processes are defined, adapted and maintained to support the requirements of the enterprise, systems engineering organizational units, individual projects and personnel. SLC processes are supplemented by recommended methods and tools. The resulting guidelines in the form of enterprise policies and procedures are still subject to tailoring by projects, as discussed in chapter 10. Figure 6-4 is the context diagram for this process.

Page 6.7 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Controls
- Gov/Corp Laws & Regulations - Enterprise Strategic Plan

Activities Inputs
-Best practices from industry and academia -SLC process assessments from ongoing projects -Tailoring trends -Establish processes for each SLC stage -Establish tailoring guidelines -Identify appropriate methods & tools -Establish SLC process performance measures for assessment -Monitor execution of SLC processes -Identify and implement improvements -Communicate enterprise SLC guidelines

Outputs
- Enterprise SLC process guidelines - Enterprise Policies for use, tailoring of SLC processes - SLC process performance measures

Enablers
-INCOSE SE Handbook -SLC Standards & Tools - Enterprise Infrastructure

Figure 6-4 SLC Processes Management Process Context Diagram 6.4.3 Inputs
Figure 6-4 SLC Processes Management Process Context Diagram

This handbook and relevant standards, new knowledge from research, and industry sponsored knowledge networks are examples of the sources from which the SLC processes are extracted. Enterprise strategy plans and infrastructure are used to ensure consistency in the eventual recommendations. Assessments from projects and trends collected from tailoring processes provide constructive input for improvements to an enterprise’s SLC implementation. 6.4.4 Outputs

The successful implementation of this process results in the following outputs: • Enterprise SLC process guidelines in the form of enterprise policies and procedures • Enterprise policies and procedures for applying the SLC processes and adapting them to meet the needs of individual projects • Performance criteria and measures that indicated the degree to which SLC processes are used • Enterprise SLC Processes Improvement Plan 6.4.5 Process Activities

The process activities include: • Identify sources (enterprise, corporate, industry, academia, stakeholders and customers) of SLC process information. • Distill the information from multiple sources into an appropriate set of SLC processes that are aligned with the enterprise plans and infrastructure. • Establish SLC Process Guideline in the form of Plans, Policies, Procedures,
Page 6.8 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Tailoring Guidance, Models, and Methods and Tools for controlling and directing the SLC processes. • Define, integrate, and communicate SLC process roles, responsibilities, authorities, requirements, measures, and performance criteria based on the SLC process guidelines. • Identify opportunities to improve the enterprise SLC guidelines on a continuing basis based on individual project assessments, individual feedback, and changes in the enterprise strategic plan. • Communicate with all relevant organizations regarding the creation of and changes in the SLC guideline. n Common approaches and tips: • Development of an SLC Processes intranet and information database with essential information provides an effective mechanism for disseminating consistent guidelines, providing announcements about enterprise related topics as well as industry trends, research findings, and other relevant information. This provides a single point of contact for continuous communication regarding the SLC Guidelines and encourages the collection of valuable feedback and the identification of enterprise trends. • Establish an enterprise center of excellence for SLC Processes. This organization can become the focal point for the collection of relevant information, dissemination of guidelines, and analysis of assessments and feedback. They develop checklists and other templates to support project assessments to ensure that the pre-defined measures and criteria are used for evaluation. • Methods and Tools for enabling the application of SLC Processes must be effective and tailored to the implementation approach of the enterprise and its projects. Create a responsible organization to coordinate the identification and development of partnerships and/or relationships with tool vendors and working groups. They can recommend the use of methods and tools that are intended for the purpose to help personnel avoid confusion and frustration, and wasting valuable time and money. These experts may establish an integrated tool environment between interacting tools to avoid cumbersome (and inaccurate) data transfer – see chapter 8.4. • Including stakeholders, such as engineering and project management organizations, as participants in developing the SLC guidelines increases their commitment to the recommendations and incorporates a valuable source of enterprise experience. • Develop alternative SLC guidelines based on the type and scope, complexity, and risk of a project decreases the need for tailoring by engineering and project organizations. • Provide clear guidelines for tailoring and adaptation. • Estimating techniques for life cycle cost are described in chapter 8.5.

Page 6.9 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6.5 Resource Management Process
6.5.1 Purpose

The purpose of the Resource Management Process is to create and maintain a pool of resources for projects. 6.5.2 Description

Projects all need resources to meet their objectives. Financial resources are addressed under the Investment Management Process, but all other resources are provided under this process. Resource is a generic term for all materials, services, facilities, and personnel needed by a project. Non-human resource services include tools, databases, communication systems, financial systems and information technology. Project planners determine the resources needed by the project. They attempt to anticipate both current and future needs. The Resource Management Process provides the mechanisms whereby the enterprise infrastructure is made aware of project needs and the resources are scheduled to be in place when requested. While this can be simply stated, it is less simply executed. Conflicts must be resolved, personnel must be trained, employees are entitled to vacations and time away from the job, equipment must be purchased and sometimes repaired, buildings are refurbished, and information technology services are in a state of constant change. The enterprise resource management organization collects the needs, negotiates to remove conflicts, and is responsible for providing the enabling enterprise infrastructure without which nothing else can be accomplished. Since resources are not free, their costs are also factored into investment decisions. Figure 6-5 is the context diagram for the Resources Management Process.
Controls
- Gov/Corp Laws & Regulations - Enterprise Strategic Plan

Inputs
-Enterprise Resource needs from projects -Skills needs from roles & responsibilities -Portfolio of active Projects -Project Assessments

Activities
-Collect resource needs from projects -Provide resource infrastructure support -Manage personnel to staff projects -Motivate staff -Establish training needs and schedule -Manage non-personnel resources -Allocate resources to ongoing projects -Manage conflicts in project requests

Outputs
-Enterprise Resources -Enterprise Resource Allocation - Enterprise Training Plan, Skills Matrix and Career Development Plan

Enablers
-Enterprise Policies & Procedures -Enterprise Infrastructure -Enterprise Tactical Plan

Figure 6-5 Resource Management Process Context Diagram
Figure 6-5 Resource Management Process Context Diagram

Page 6.10 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6.5.3

Inputs

Resource management collects the needs of all the projects in the active portfolio. Personnel needs are evaluated against available people with the pre-requisite skills to determine if training or hiring activities are indicated. Other assets are scheduled or if necessary acquired. Trends in the market may suggest changes in the composition of project teams and the supporting IT environment. The availability and suitability of the enterprise infrastructure is one of the critical project assessments and provides feedback for improvement – and reward – mechanisms. All enterprise processes require mandatory compliance with government and corporate laws and regulations. Decision-making is governed by the enterprise strategic plan. 6.5.4 Outputs

The primary objective of this process is to provide a resource pool to the enterprise. This is complicated by the number of sources for requests, the need to balance the skills of the labor pool against the other infrastructure elements (e.g. computer-based tools), the need to maintain a balance between the budgets of individual projects and the cost of resources, the need to keep apprised of new or modified policies and procedures that might influence the skills inventory, and myriad unknowns. Resources are allocated based on requests and conflicts are negotiated. The goal is to provide personnel, materials and services to a project when they are needed to keep the project on target and on budget. A key concern is keeping project personnel from becoming over-committed, especially persons with specialized skills. Skills inventory and career development plans are important documentation that can be validated by engineering and project management. 6.5.5 Processes Activities

This process includes the following activities: • Manage resource availability to ensure enterprise goals and objectives are met. Conflicts and resource shortfalls are identified with recommendations for resolution. • Provide resources to support all projects – the enterprise infrastructure. • Keep employees motivated, content in their career progression, current with their training, and appropriately allocated using techniques that are within acceptable enterprise and corporate guidelines and constraints. • Control multi-project resource management communications to effectively allocate resources throughout the enterprise, identify potential future or existing conflict issues and problems with recommendations for resolution. n Common approaches and tips: • Motivate staff; consider using an integrated product development team environment as a means to reduce the frequency of project rotation; recognize
Page 6.11 of 22

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

progress and accomplishments and reward success; establish apprentice and mentoring programs for newly hired employees and students. • Maintain a pipeline of qualified candidates that are interested in joining the organization as employees or temporary staff. Focus recruitment, training and retention efforts on personnel with experience levels, skills and subject matter expertise demanded by the projects. Personnel assessments should review proficiency, motivation, ability to work in a team environment, as well as the need to be retrained, reassigned or relocated. • Qualified personnel and other resources may be hired temporarily/leased – insourced or outsourced – in accordance with the investment strategy. • Encourage personnel to engage in external networks as a means of keeping abreast of new ideas and attracting new talent to the organization. • Maintain an enterprise career development program that is not sidetracked by project demands. Develop a policy that all personnel receive training or educational benefits on a regular cycle. This includes both undergraduate and graduate studies, in-house training courses, certifications, tutorials, workshops, and conferences. • Remember to provide training on enterprise policies and procedures and SLC processes. • Establish a resource management information infrastructure with enabling support systems and services to maintain, track, allocate and improve the resources for present and future enterprise needs. Computer-based human resource, equipment tracking, facilities allocation and other systems are recommended for organizations over 50 people. • Attend to physical factors, including facilities and human factors, such as ambient noise level and computer access to specific tools and applications. • Begin planning in early life cycle stages for utilization and support resource requirements for system transition; manpower, facilities, infrastructure, information/data storage and management. • Use the slack time in the beginning of a project to obtain and train the necessary people to avoid a shortfall of skilled engineers, technologists, managers, and operations experts.

6.6 Quality Management Process
6.6.1 Purpose

The purpose of the Quality Management Process is to make visible the goals of the enterprise toward customer satisfaction. Enterprise policies and procedures govern the products, services, and implementations of the system life cycle (SLC) processes to assure that they meet quality objectives and customer requirements.

Page 6.12 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6.6.2

Description

Since primary drivers in any project are time, cost, and quality, inclusion of a Quality Management Process is essential to every organization. Many of the SLC processes are concerned with quality issues, and this forms some of the justification for exerting time, money, and energy into establishing these processes in the organization. Application of this handbook is one approach toward inserting a quality discipline into an organization. The Quality Management Process establishes, implements, and continuously improves the focus on customer satisfaction and enterprise goals and objectives. There is a cost to managing quality as well as a benefit. The effort and time required to manage quality should not exceed the overall value gained from the process. Chapter 8 contains additional discussion of the importance to the organization, and activities for implementing this process. Figure 6-6 is the context diagram for the Quality Management Process.
Controls
- Gov/Corp Laws & Regulations -Enterprise Strategic Plan -Agreements

Activities Inputs
-Best practices from industry and academia -Project assessments -Quality plans from ongoing projects -Tailoring trends -Establish enterprise quality management policies, standards, procedures, goals, and objectives -Define responsibilities and authority for quality management -Assess customer satisfaction -Monitor project quality plans -Identify and implement improvements -Communicate enterprise QM guidelines

Outputs
-Enterprise quality management guidelines - Enterprise QM authority - Recommendations for action when quality goals not achieved

Enablers
-Standards addressing quality - Enterprise Infrastructure

Figure 6-6 Quality Management Process Context Diagram 6.6.3 Inputs
Figure 6-6 Quality Management Process Context Diagram

Enterprise strategic documentation including quality policy, mission, strategies, goals and objectives are essential inputs for analysis and synthesis of quality impacts, requirements and solutions. Existing agreements also provide direction regarding the appropriate level of attention given to quality within the organization. Project assessments include measurements that can be evaluated to determine the performance of a project team and the progress toward a quality outcome. Trends in tailoring of project-specific quality plans provide clear indications of potential improvements in the overall enterprise guidelines.
Page 6.13 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

The team of people working in this process will also find a wealth of material in ISO standards and other sources. 6.6.4 Outputs

The successful implementation of the Quality Management Process results in the following outcomes: • Enterprise Quality Management Guidelines include the set of policies and procedures that apply to quality practices within the organization, within individual projects, and as part of the execution of SLC processes. These guidelines define goals and quality objectives for processes and systems that are measurable and objective. • Accountability and authority for quality management is assigned within the organization and realistic resources are provided. • Customer satisfaction is closely monitored and appropriate actions are taken when quality goals are not achieved. 6.6.5 Process Activities

This process includes the following activities: • Establish Quality Management Guidelines – Policies, Standards, and Procedures • Establish enterprise and project quality management goals & objectives • Define Responsibilities & Authorities • Monitor Customer Satisfaction against compliance with requirements and objectives • Evaluate project assessments and recommend appropriate action when indicated • Continuously improve the Quality Management Guidelines • Maintain open communications within the organization n Common approaches and tips: • Management commitment to quality is reflected in the strategic planning of the enterprise – the rest of the organization will follow. Everyone in the Enterprise should know the Enterprise’s quality policy. • Quality is a daily focus – not an afterthought! • Development of a Quality Management intranet and information database with essential information provides an effective mechanism for disseminating consistent guidelines, providing announcements about enterprise related topics as well as industry trends, research findings, and other relevant information. This provides a single point of contact for continuous communication regarding the Quality Management Guidelines and encourages the collection of valuable feedback and the identification of enterprise trends. • Analyze statistics from process audits, tests and evaluations, product
Page 6.14 of 22

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

discrepancy reports, customer satisfaction monitoring, accident and incident reporting, and the implementation of changes to items of a product (e.g. recalled product and/or production lines). • Quality Management is big business. A plethora of standards, methods, and techniques exist to help an organization. A short list includes the ISO 9000 series, Total Quality Management (TQM), and Six-Sigma (statistical process control). Quality according to ISO 9000 is the “Ability of a set of inherent characteristics of a product, system, or process to fulfill requirements of customers and other interested parties.” 2 • A successful strategy is to aim at achieving customer satisfaction primarily by preventing non-fulfillment of requirements. Ideally, customer satisfaction is linked to compliance with requirements – two signals that the process is not working are situations where the project is compliant but the customer is unhappy, or the project is not compliant and the customer is happy. • The consistent involvement and commitment of top management with timely decision-making is mandatory for the quality program. This is reflected in staffing and training of project auditors.

6.7 Acquisition Process
6.7.1 Purpose

The Acquisition Process is invoked to establish an agreement between two enterprises under which one party acquires products or services from the other. The acquirer experiences a need for an operational system, for services in support of an operational system, for elements of a system being developed by a project, or for services in support of project activities. The goal is to find a supplier that can meet that need. 6.7.2 Description

The role of the acquirer demands familiarity with the Enterprise, Project, and Technical Processes as it is through them that the supplier will execute the agreement. An acquirer enterprise applies due diligence in the selection of a supplier to avoid costly failures and impacts to the enterprise budgets and schedules. This section is written from the perspective of the acquirer enterprise. Figure 6-7-1 is the context diagram for the Acquisition Process.

Page 6.15 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Controls
- Gov/Corp Laws & Regulations -Enterprise Strategic Plan -Enterprise Acquisition Policy

Activities Inputs
-Acquirer need -Supplier candidates -Supplier enterprise -Establish an Acquisition Plan -Identify need in request for proposal -Evaluation responses; select supplier -Negotiate agreement -Assess agreeement execution -Accept delivery of product or service - Determine compliance with agreement - Render payment

Outputs
- Supplier selected -Agreement executed -Agreement satisfied -Payment rendered

Enablers
- Enterprise Infrastructure -Agreement specialists -Available funds

Figure 6-7 Acquisition Process Context Diagram
Figure 6-7 Acquisition Process Context Diagram

6.7.3

Inputs

The Acquisition Process begins with the identification of a need that can not be met within the organization encountering the need, or a need that can be met in a more economical way by a supplier. The organization identifies candidate suppliers that could meet this need, and the acquisition personnel identify a plan for procuring the system-of-interest. During creation of a request for proposal, inputs are received from the project management and engineering personnel in the organization with the need. These same personnel participate in the evaluation of the responses and offer recommendations for the selection of supplier. The selection criteria documented in the acquisition plan are used to drive this decision. Legally executed agreements must comply with government and other directives. The acquirer enterprise will adopt standard practices related to the negotiation of agreements. It is important to note that availability of adequate funding is essential to beginning the acquisition process. 6.7.4 Outputs

The following are outcomes of the Acquisition Process. • Acquisition Plan – include objective selection criteria and a schedule of milestones • List potential suppliers – suppliers may be internal or external to the acquirer enterprise • Recommendations from evaluation of responses to request for proposal – formal documentation, or less formal inter-organizational interactions, e.g. between design engineering and marketing
Page 6.16 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Supplier selected – using selection criteria; rank suppliers by their suitability to meet the overall need; establish supplier preferences and corresponding justifications • Negotiated agreement – formal contracts, or less formal inter-organizational work orders • System-of-interest (product or service) delivered according to delivery conditions of agreement • Acquirer payments or other compensations rendered • Responsibility for system-of-interest transferred from supplier to acquirer • Communication between acquirer and supplier • Acquisition strategies regarding agreements 6.7.5 Process Activities The following activities take place under the Acquisition Process: • Manage Acquisition Process activities –decision-making for agreements, relationship building and maintenance, interaction with Enterprise management, responsibility for the development of plans and schedules, final approval authority for deliveries accepted from supplier. When an acquisition process cycle concludes, conduct a final review of performance to extract lessonslearned for continued process performance. • Develop and maintain Acquisition Plans, Strategies, Policies, Procedures to meet the enterprise goals and objectives and the needs of the project management and technical systems engineering organizations. • Select appropriate suppliers – willing to conduct ethical negotiations, able to meet technical obligations, willing to maintain open communications throughout the acquisition process. • Evaluate supplier responses to request for proposal – system-of-interest meets acquirer needs and complies with industry and other standards. Assessments from the Investment and Quality Management Processes, and recommendations from the requesting organization are necessary to determine the suitability of each response and the ability of the supplier to meet the stated commitments. • Select the preferred supplier based on acquisition criteria. • Negotiate agreement – acquirer commits to specify requirements for system-ofinterest, participate in verification, validation and acceptance activities, render payment according to the schedule, participate in exception and change control procedures, and contribute to transparent risk management procedures. The agreement will establish criteria for assessing progress toward final delivery. • Maintain communications with supplier, stakeholders, and other organizations regarding the project. • Assess execution of agreements to identify risks and issues, progress towards mitigation of risks, adequacy of progress toward delivery, evaluation cost and schedule performance, and determine potential undesirable outcomes for the enterprise. Amend agreements when impacts on schedule, budget, or performance are identified.
Page 6.17 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Accept delivery in accordance with all agreements and relevant laws and regulations. • Render payment or other agreed consideration in accordance with agreed payment schedules. • Accept responsibility in accordance with all agreements and relevant laws and regulations. n Common approaches and tips: • Establish acquisition guidance and procedures that inform acquisition planning, including recommended milestones, standards, assessment criteria and decision gates. Include approaches for identifying, evaluating, choosing, negotiating, managing and terminating suppliers. • Establish a point of responsibility within the enterprise for monitoring and controlling individual agreements. This person maintains communication with the supplier, and is part of the decision-making team to assess progress in the execution of the agreement. The possibility of late delivery or cost overruns should be identified and communicated into the enterprise as early as noted. • Define and track metrics that measure the progress on agreements. Appropriate metrics requires the development of tailored metrics/measures that do not drive unnecessary and costly efforts but do provide the information needed to assure the progress is satisfactory and key issues and problems are identified early to allow time for resolution with minimal impact to the delivery and quality of the product and service. • Include technical representation in the selection of the suppliers to critically assess the capability of the supplier to perform the required task; this helps reduce the risk of contract failure and its associated costs, delivery delays, and increased resource commitment needs. Past performance is highly important but changes to key personnel should be identified and evaluated. • Communicate clearly with the supplier about the real needs; avoid conflicting statements, or making frequent changes in the statement of need that introduce risk into the process. • Maintain traceability between the supplier’s responses to the acquirer’s solicitation; this can reduce the risk of contract modifications, cancellations or follow-on contracts to fix the product or service.

6.8 Supply Process
6.8.1 Purpose

The Supply Process is invoked to establish an agreement between two enterprises under which one party supplies products or services to the other. Within the supplier enterprise, a project is conducted according to the recommendations of this handbook with the objective to provide a product or service that meets the contracted
Page 6.18 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

requirements. In the case of a mass produced product or service, a marketing function may represent the acquirer and establish customer expectations. 6.8.2 Description

The supply process is highly dependent upon the Enterprise, Project, and Technical Processes as it is through them that the work of executing the agreement is accomplished. This means that the supply process is the larger context in which the other processes are applied under contract. This section is written from the perspective of the supplier enterprise. Figure 6-8 is the context diagram for the Supply Process.
Controls
- Gov/Corp Laws & Regulations -Enterprise Strategic Plan -Enterprise Agreement Policy

Activities Inputs
-Acquirer enterprise -Acquirer request - Identify acquirer with request -Evaluate and respond to request -Negotiate agreement -Execute agreement (project) -Deliver product or service; transfer responsibility to acquirer -Receive and acknowledge payment

Outputs
-Request response -Agreement executed -Agreement satisfied -Payment received

Enablers
-Enterprise Infrastructure -Agreement specialists

Figure 6-8 Supply Process Context Diagram
Figure 6-8 Supply Process Context Diagram

6.8.3

Inputs

The products and services available for acquisition are determined within the enterprise strategic plan. Legally executed agreements must comply with government and other directives. A supplier connects with another party with the desire to acquire their products or services. The supplier enterprise will adopt standard practices related to the negotiation of agreements. During the evaluation of the request from the acquirer, inputs are received from project management and engineering organizations, including potential sub-suppliers. 6.8.4 Outputs

The following are outcomes of the Supply Process. • Identification of potential acquirers • Response to acquirer request for proposal – formal documentation, or less formal inter-organizational interactions, e.g. between design engineering and marketing
Page 6.19 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Negotiated agreement – formal contracts, or less formal inter-organizational work orders • System-of-interest (product or service) delivered according to delivery conditions of agreement • Acquirer payments or other compensations received and acknowledged • Responsibility for system-of-interest transferred between acquirer and supplier • Communication between acquirer and supplier • Supplier strategies regarding agreements 6.8.5 Process Activities

The following activities take place under the Supply Process: • Manage Supply Process activities – decision-making for agreements, relationship building and maintenance, interaction with Enterprise management, responsibility for the development of plans and schedules, final approval authority for deliveries made to acquirer. When a supply process cycle concludes, conduct a final review of performance to extract lessons-learned for continued process performance. • Develop and maintain Supply Plans, Strategies, Policies, Procedures to meet the enterprise goals and objectives and the needs of the project management and technical systems engineering organizations. • Select appropriate acquirers – willing to conduct ethical negotiations, able to meet financial obligations, willing to maintain open communications throughout the supply process. • Evaluate acquirer requests and prepare a response – a satisfactory response proposes a system-of-interest that meets acquirer needs and complies with industry and other standards. Assessments from the Investment, Resource Management, and Quality Management Processes are necessary to determine the suitability of this response and the ability of the enterprise to meet these commitments. • Negotiate agreement – supplier commits to meet requirements for systemof-interest, meet delivery milestones, verification, validation and acceptance conditions, accept payment schedule, execute exception and change control procedures, and maintain transparent risk management procedures. The agreement will establish criteria for assessing progress toward final delivery. • Execute the agreement – start a project and invoke the other processes defined in this handbook. • Maintain communications with acquirer, sub-suppliers, stakeholders, and other organizations regarding the project. • Assess execution of agreements to identify risks and issues, progress towards mitigation of risks, adequacy of progress toward delivery, evaluation cost and schedule performance, and determine potential undesirable outcomes for the enterprise.

Page 6.20 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

• Deliver in accordance with all agreements and relevant laws and regulations. • Receive and acknowledge payment or other agreed consideration in accordance with agreed payment schedules. • Transfer responsibility in accordance with all agreements and relevant laws and regulations. n Common approaches and tips: • Agreements fall into a large range from formal to very informal based on verbal understanding. Contracts may call for a fixed price, cost plus fixed fee, incentives for early delivery, penalties for late deliveries, and other financial motivators. • Relationship building and trust between the parties is a non-quantifiable quality that, while not a substitute for good processes, makes the human interactions agreeable. • Develop technology white papers or similar documents to demonstrate and describe to the (potential) acquirer the range of capabilities in areas of interest. Use traditional marketing approaches to encourage acquisition of mass produced products. • Maintain an up-to-date internet presence, even if the enterprise does not engage in electronic commerce. • When expertise is not available within the enterprise (e.g. legal and other governmental regulations, laws, etc.), retain subject matter experts to provide information and specify requirements related to agreements. • Invest sufficient time and effort into understanding acquirer needs before the agreement. This can improve the estimations for cost and schedule and positively affect agreement execution. Evaluate any technical specifications for the product or service for clarity, completeness and consistency. • Involve personnel who will be responsible for agreement execution to participate in the evaluation of and response to the acquirer’s request. This reduces the start-up time once the project is initiated, which in turn is one way to recapture the cost of writing the response. • Make a critical assessment of the ability of the organization to execute the agreement; otherwise, the high risk of failure and its associated costs, delivery delays, and increased resource commitment needs will reflect negatively on the reputation of the entire enterprise. • Institute for supply management has useful guidance for purchasing and marketing.3

1 ©2001 Jack Ring and A. Wayne Wymore 2 http://www.iso.ch/iso/en/iso9000-14000 3 http://www.napm.org/

Page 6.21 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

Page 6.22 of 22
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

7 Enabling Systems Engineering Process Activities
Systems Engineering Process Activities are covered in three chapters: • Chapter 7 – Enabling Systems Engineering Activities • Chapter 8 – Systems Engineering Support Activities • Chapter 9 – Specialty Engineering Activities Chapter 1 (Table 1-1) provides summary guidance to the process activities covered in these chapters for those who may not be familiar with all of them. From a sampling of the literature 1 in Systems Engineering from 1962 to the present, a common set of process activities emerges. This is the same set as that identified by a joint project between The American Institute of Aeronautics and Astronautics (AIAA) and INCOSE in which they are referred to as “enabling 2” processes. The enabling processes are Decision Management, Requirements Management, and Risk and Opportunity Management. When tailoring a project, most of these activities will be essential to every system life cycle.

7.1. Decision Management
This section on Decision Management gives a glimpse into decision gates, making difficult decisions, and trade studies. 7.1.1. Decision Gates

A decision gate is an approval event in the project cycle, sufficiently important to be defined and included in the schedule by the project manager, executive management, or the customer. Entry and exit criteria are established for each gate at the time they are included into the project management baseline. Decision gates ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed. Proceeding beyond the Decision Gate before the project is ready entails risk, as comically illustrated in Figure 7-1. The project manager may decide to accept that risk, as is done, for instance, with long-lead item procurement.

Page 7.1 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Figure 7-1 Decision Gates synchronize project activities3 The project business case issues of market demand, affordability, and realistic schedules are important decision criteria influencing concept selection, and they should be updated and evaluated at every decision gate. Inadequate checks along the way can set up subsequent failures – usually a major factor in cost over-runs and delays. At each gate the decision options are: Acceptable: Proceed with the next stage of the project; Or Acceptable with reservations: Proceed and respond to action items; Unacceptable: Do not proceed; continue this stage and repeat the review when ready; Unacceptable: Return to a preceding stage; Unacceptable: Put a hold on project activity; Unsalvageable: Terminate the project. Upon successful completion of a decision gate, some artifacts (documents, models, or other products of a project cycle stage) have been approved as the basis upon which future work must build. If the project is large or long enough, or entails high risk, these artifacts are placed under configuration management. Decision gate descriptions should identify the: • Purpose of the decision gate • Host and chairperson • Attendees • Location • Agenda and how the decision gate is to be conducted • Evidence to be evaluated • Actions • Method of closing the review Decision gate approval must involve the necessary disciplines and stakeholders and must be based on hard evidence of compliance. One of the underlying principles
Page 7.2 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

for the agile development and extreme programming movements is to substantially reduce (but not eliminate) the frequency and elaborate (and they would claim proforma) content of decision gates for software development. Balancing the formality and frequency of decision gates is seen as a critical success factor for all systems engineering process areas. On large or lengthy projects, decisions and their rationale are maintained using an information management process. 7.1.2 Making Difficult Decisions Making good decisions requires adequate information, experience, and good judgment. The techniques discussed in the following paragraphs are found in the literature, and have proven to be effective aids in making good decisions. In some cases, a technique may use mathematics to produce a result useful in the decisionmaking process, such as the hydrographical models used to assess the environmental restrictions in the Øresund Strait. People make decisions based on intuition and judgment; these techniques are aides to decision-making.4 Decision analysis is a method of identifying the best option from a set of alternatives, under uncertainty, using the possible outcomes of each alternative and their probabilities of occurrence to calculate the expected value of the outcome. Decision analysis has been a subject of interest for centuries,5, 6, 7 and can be applied to a widerange of problems and problem domains. Skinner 8 states, “Real world decisions often involve a high degree of ambiguity, conflicting goals due to multiple objectives, complex trade-offs, more than one decision maker, or several sequential decisions. It is these types of situations where decision analysis is most valuable. By carefully decomposing the problem into smaller more manageable problems and by focusing on what is truly important, we can develop clear objectives and defensible courses of action.” Skinner also lists ten principles of good decision making: 1. Use a value creation lens for developing and evaluating opportunities. 2. Clearly establish objectives and trade-offs. 3. Discover and frame the real problem. 4. Understand the business situation. 5. Develop creative and unique alternatives. 6. Identify experts and gather meaningful and reliable information. 7. Embrace uncertainty as the catalyst of future performance. 8. Avoid “analysis paralysis” situations. 9. Use systemic thinking to connect current to future situations. 10. Use dialog to foster learning and clarity of action.

Page 7.3 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Advocates of Lean Manufacturing would add one more suggestion to this list; delay commitment until the last responsible moment. Lean software development delays freezing all design decisions as long as possible, because it is easier to change a decision that is not made.9 Decision trees are a graphical and quantitative method for thinking through a decision. The first step is to create a decision “tree” diagram that represents the situation in question. Starting on the left with the initial decision point and proceeding to the right, the decision diagram must accurately represent each point where a decision is to be made and all the possible consequences of that decision. Figure 7-2 illustrates a situation where management needs to decide on whether or not to bid on a contract. The team estimates that their company has a 60% chance of winning. If they propose a unit price of $30, the company will earn $4.25 M, where M is 106. They further estimate that there is a 10% chance that the unit cost will be $28, which would result in an increase in income to $6 M. There is a 40% chance that the unit cost could be as high as $38, and the project will lose about $3 M. The unit costs and probabilities of each chance outcome are based on the best judgment of the team. The expected value of winning the contract is the sum of the expected value for each branch at the chance node times the probability for each branch. So Contract Win Expected Value = 10% * $6.05 M + 50% * $4.25 M – 40% * $2.95M or $1.55M The expected value of making the bid is 60% * $1.55 – 40% * 0.25 or $0.83 M
Cost is $38 0.400 $1,550,00 Win Contract 0.600 Cost is $30 0.500 ($2,950,000); P = 0.240

$4,250,000; P = 0.30

Make Bid

$830,00

Cost is $28 0.100

$6,050,000; P = 0.060

Simmstar’s Bid

Make Bid:

Lose Contract 0.400

($250,000); P = 0.400

Don’t Bid

$0

Figure 7-2 Decision Tree for a “Bid – No Bid” Decision10 This technique can be extended to include multiple decision points and multiple outcomes as long as every possible outcome has a value and a probability of occurrence associated with it.

Page 7.4 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Additional decision analysis techniques include: a. Sensitivity analysis, which looks at the relationships between the outcomes and their probabilities to find how “sensitive” a decision point is to the relative numerical values. b. Value of information methods, whereby expending some effort on data analysis and modeling can improve the optimum expected value. c. Multi-attribute Utility Analysis, which is a method that develops equivalencies between dissimilar units of measure. There are many tools available to support the decision management area. The INCOSE website maintains suggestions from the Tools Working Group. 7.1.3 Trade Study and Sensitivity Analysis Trade study describes a process for comparing the appropriateness of different technical solutions. The characteristics of each option are traded against each other. Once a best alternative has been identified, the stakeholders in the decision will want to know how sensitive the recommended selection is to differently evaluated criteria or to different estimates of the alternatives’ characteristics — perhaps a different best alternative would result. Therefore, a good trade study includes sensitivity analysis. A recent study reported that the following activities can be found in most trade study processes: 11 1. 2. 3. 4. 5. 6. 7. 8. 9. Frame the problem context, scope, constraints. Establish communications with stakeholders. Define evaluation criteria and weights where appropriate. Define alternatives and select candidates for study. Define measures of merit and evaluate selected candidates. Analyse the results and select best alternative. Review results with stakeholders and re-evaluate. Investigate the consequences of implementation. Use scenario planning to test assumptions about the future.

The utility or value of each feature of an alternative is determined or estimated, and often a weight is defined that assigns a relative importance of each feature across all alternatives. The weighted value of utility is simply the product of the utility and the weight for each feature, and the weighted total is the sum of the weighted utility values summed over all the features of an alternative. The selected alternative nominally is the one with the best weighted total. Involvement of the stakeholders in this process gives them confidence in the eventual choice and imparts useful insights to the whole team.
Page 7.5 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

A sensitivity analysis involves varying each utility and each weight and re-computing the weighted total for each alternative to ascertain what would change if the values of the utilities or weights were different. The significance of the change is best determined through conversations with stakeholders and subject matter experts. All evaluations and decisions are reviewed to address the concerns and opinions of stakeholders. A final evaluation of the consequences of implementing the selected alternative may help identify unintended consequences of an otherwise “best” solution. The highest score does not always win. Trade studies support decisions in all phases of system development, from conceptualization to deployment. Requirements can be traded against constraints; architecture features can be traded against dictated equipment or interface requirements; alternative functional or performance choices can be traded to determine an optimal configuration. In the case of the Øresund Bridge, trade studies helped determine many of the final elements of the bridge configuration, e.g. length of main span.

7.2 Requirements Management
There is near unanimous agreement that successful projects depend on meeting the needs and requirements of the stakeholder/customer. When the requirements are for a complex system, or for a system that may take many years to realize, a formal requirements management process is justified. Requirements management concerns the collection, analysis, and validation of requirements with all the communications and negotiations inherent in working with people. A great deal of literature exists on how to write and manage requirements. This overview touches on four major elements of this process area; elicit and capture requirements, generate a concept of operations, define system capabilities and performance objectives, and define non-functional requirements. 7.2.1 Elicit and Capture Requirements Within the context of ISO/IEC 15288, requirements are specifically mentioned in two of the technical processes, and are drivers for many of the system life cycle processes. Depending on the system development model, requirements capture may be done nominally once near the beginning of the development cycle, or as for agile methods, be a continuous activity. The reason for eliciting requirements is the same, understand the needs of the stakeholders well enough to support the architecture design process.

Page 7.6 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

One of the biggest challenges in this activity is the identification of the set of stakeholders from whom requirements should be elicited. Customers and eventual end-users are relatively easy to identify, but regulatory agencies, and other interested parties that may reap the consequences of the system-of-interest should also be sought out and heard. In sustainable development this includes finding representation for future generations. Figure 7-3 illustrates the range of potential stakeholders.

Figure 7-3 Requirements elicitation captures the needs of stakeholders, operators and users across systems boundaries12 Requirements elicitation is an iterative activity and benefits from continuous communication and validation with stakeholders. Techniques for requirements elicitation include interviews, focus groups, the Delphi technique, and soft systems methodology. Tools for capturing and managing requirements are many and varied. The INCOSE Tools Database Working Group evaluates the relative merits of different products and maintains a database that is available from the INCOSE website. 7.2.2 Systems Modeling Language (SysML) SysML is used to model complex systems and is an extension of the family of UMLbased standards that are intended to provide standard representations with well defined semantics that can support model and data interchange. SysML has been developed as part of a joint initiative between the Object Management Group and INCOSE.13, 14, 15 SysML includes diagrams that can be used to specify system requirements, behaviour, structure, and parametric relationships. The modelling elements represented in the diagram facilitate integration among the various diagrams and views. The SysML diagram types in Figure 7-4 are summarized below.

Page 7.7 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

Edited by Foxit Reader INCOSE Systems Engineering Handbook v. 3 Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.
SysML Diagram

Structure Diagram

Parametric Diagram

Requirement Diagram

Behavior Diagram

Block Definition Diagram*

Internal Block Diagram*

Activity Diagram

Timing Diagram

Use Case Diagram

Sequence Diagram

State Machine Diagram

Figure 7-4 SysML Diagram Types The system structure is represented as block definition diagrams and internal block diagrams. A block definition diagram describes the system hierarchy and system/ component classifications. The internal block diagram describes the internal structure of a system in terms of its parts, ports, and connectors. The behavior diagrams include the use case diagram, activity diagram, sequence diagram, state machine diagram, and timing diagram. A use-case diagram provides a high-level description of the system functionality. The activity diagram represents the flow of data and control between activities. A sequence diagram represents the interaction between collaborating parts of a system. The state machine diagram describes the state transitions and actions that a system or its parts perform in response to events. The timing diagram represents parameters, functions or states as a function of time. The requirements diagram captures requirements hierarchies, and the derivation, satisfaction, and verification relationships. It provides a bridge between requirements and system design models. The parametric diagram represents constraints on system parameter values such as performance, reliability, and mass properties to support engineering analysis. SysML includes an allocation relationship to represent allocation of functions to components, allocation of logical to physical components, and other types of allocations. 7.2.3 Concept of Operations Scenarios and what-if thinking are essential tools for planners who must cope with the uncertainty of the future. Scenario thinking can be traced back to the writings of early philosophers such as Plato and Seneca.16 As a strategic planning tool, scenario techniques have been employed by military strategists throughout history. Building scenarios serves as a methodology for planning and decision-making in complex and uncertain environments. The exercise makes people think in a creative way,
Page 7.8 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

observations emerge which reduce the chances of overlooking important factors, and the act of creating the scenarios enhances communications within and between organizations. Creation or upgrade of a system shares the same uncertainty regarding future use and emergent properties of the system. The Stakeholder Requirements Definition Process suggests capturing the understanding of stakeholder needs in a series of concept documents, each focused on a life cycle stage, see chapter 4.2. The goal of a concept document is to capture an implementation-free understanding of stakeholders’ needs by defining what is needed, without addressing how to satisfy the need. It captures behavioral characteristics required of the system in the context of other systems with which it interfaces, and captures the manner in which people will interact with the system for which the system must provide capabilities. If the system is for a military customer, there may be several required operational views of the system driven by architectural frameworks. These are defined, for example, in the United States Department of Defense Architecture Framework (DODAF) and in the Ministry of Defense (UK) Architecture Framework (MODAF). One objective is to ensure that operational needs are clearly understood and the rationale for performance requirements is incorporated into the design decision database. Other objectives are: a. To provide traceability between operational needs and the captured source requirements. b. To establish a basis for requirements to support the system over its life, such as personnel requirements, support requirements, etc. c. To establish a basis for test planning, system-level test requirements, and any requirements for environmental simulators. d. To generate operational analysis models to test the validity of external interfaces between the system and its environment, including interactions with external systems. e. To provide the basis for computation of system capacity, behavior under/ overload, and mission-effectiveness calculations. f. To validate requirements at all levels and to discover implicit requirements overlooked from other sources. Since a concept of operations describes system behavior, a starting point for building up the concept is to begin by identifying outputs generated by external systems (modified as appropriate by passing through the natural system environment) which act as stimuli to the system-of-interest, causing it to take specified actions and produce outputs, which in turn are absorbed by external systems. These single threads of behavior eventually cover every aspect of operational performance,
Page 7.9 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

including logistical modes of operation, operation under designated conditions, and behavior required when experiencing mutual interference with multi-object systems. Aggregation of these single threads of behavior represents a dynamic statement of what the system is required to do. Scenario building is an essentially human activity that may involve interviews with operators of current/similar systems, potential end users, and meetings of an Interface Working Group. The results of this exercise can be captured in many graphical forms using modeling tools and simulations. 7.2.4 Define systems capabilities and performance objectives The concepts of production, deployment, operations, and support serve as an excellent foundation from which the systems engineer can discern the required capabilities of the system-of-interest and the relevant performance objectives of the system. Together with identified system constraints, these will drive the architecture design activities. Typical constraints on the system may include: • Cost and schedule • Mandated use of Commercial Off-The-Shelf (COTS) equipment • Operational environment and use of pre-existing facilities and system elements • Operational interfaces with other systems or organizations As a result of this activity, a number of performance requirements will be identified. These may include areas such as power, propulsion, communications, data processing, environmental, and human interaction and intervention. In the Maglev Train, the desire to cover large distances in a brief time established train speed parameters, and the need to carry people suggested safety and maximum noise tolerances. It is advisable to place the assumptions, constraints, and analyses associated with derived requirements in the decision and/or requirements database(s). The concept of operations will also help identify adverse consequences of derived requirements: • Is unnecessary risk being introduced? • Is the technology producible? • Are sufficient resources available to move forward? • Are trade studies needed to determine appropriate ranges of performance? Large systems may justify the development of a high-level system simulation evolved from the system architecture. The simulation should contain sufficient functional elements that the interactions can be properly assessed. The purpose of the simulation is to establish measurable parameters for the functional requirements. This provides the necessary guidance to the designers on the size and capability required of their
Page 7.10 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

equipment. In addition, these parameters will be used as an integral part of the verification process in establishing the capability of the equipment (and the system) to satisfy user needs. When time permits, use of an interdisciplinary team to audit the requirements may help ensure the clarity, completeness and consistency of the set. Such a team can also assess that the requirements are verifiable. Unfortunately, it is possible to write reasonable-sounding requirements which in fact cannot be met. In the 1980s, a government/industry team created requirements for a weather satellite program, with eight satellites to be built and launched, one every three years. The specifications were – and still are – so tight that the last satellite scheduled to be launched in 2008 must have a waiver, since it cannot meet the original specifications. If there is uncertainty associated with a requirement, it should be identified as needing further attention, and even proposed for monitoring as part of the project risk management. Resolution of uncertainty should be assigned as a responsibility to an individual, and progress and eventual resolution recorded in the decision database. 7.2.5 Technical Performance Measures Technical Performance Measures (TPM) express the objective performance requirements, are evaluated at decision gate reviews, and may be used to assess the risk position of the project. TPM provide visibility into important project technical parameter status to enable effective management enhancing the likelihood of achieving the technical objectives of the project. Limit the number of TPM being monitored to critical issues. Collecting too many measures without knowing how they can be used wastes time and resources, and, even worse, the really useful values may become lost in the ocean of data. Without TPM, a project manager could fall into the trap of relying on cost and schedule status alone, with perhaps the verbal assurances of technical staff to assess project progress. This can lead to a product developed on schedule and within cost that does not meet all key requirements. Values are established to provide limits that give early indications if a TPM is out of tolerance, as illustrated in Figure 7-5.

Page 7.11 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Specified “Not to Exceed ” Value
100% 90 Action Team to Bring Back into Spec Planned Value Profile X X X X X X X X X Demonstrated Variance Predicted Variance Current Estimate X Achievement to Date

80 70

X

Demonstrated Values

Estimated Value

Allocated Value

Calculated Value

Measured Value

Proposal

Gate

Gate

Test

Delivery
© CSM, Used with permission

Figure 7-5 TPM Monitoring Periodic recording of the status of each TPM provides the continuing verification of the degree of anticipated and actual achievement of technical parameters. Measured values that fall outside an established tolerance band will alert management to take corrective action. 7.2.6 Define other non-functional requirements The concept documents will also suggest requirements that are not directly related to the primary capability provided by the system-of-interest. Many of these are discussed further in chapter 9.2, such as availability, supportability, security, and training. The Øresund Bridge case illustrated the avoidance of negative environmental impact by establishing constraints on the construction practices. Addressing non-functional requirements from the earliest stages is a good way to ensure that they are not forgotten and that they are satisfied.

7.3 Risk and Opportunity Management
Most projects are executed in an environment of uncertainty. Uncertainty influences the ability of the project team to achieve the project objectives. Uncertainty includes events that could harm the project (threats) and those that could help the project (opportunities). Well-established techniques exist for managing threats. There is some debate whether the same techniques are applicable to recognizing opportunities. In an optimal situation, opportunities are maximised at the same time as threats are minimised, resulting in the best chance to meet project objectives.17 The Øresund Bridge case illustrates this; the man-made Peberholm Island was created from the materials dredged from the Strait to meet environmental requirements and is now a sanctuary for a rare species of tern.
Page 7.12 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

7.3.1 Concepts Definitions: Risks are events that if they occur can jeopardize the successful completion of the project. Risks should be identified and assessed for probability of occurrence and impact on the project.18 “Traditionally, risk has been defined as the likelihood of an event occurring coupled with a negative consequence of the event occurring. In other words, a risk is a potential problem — something to be avoided if possible, or its likelihood and/or consequences reduced if not.” 19 As a corollary, opportunity is “the potential for the realization of wanted, positive consequences of an event.”20 Fundamentals: the measurement of risk has two components as illustrated in Figure 7-6: • The likelihood that an event will occur. • The undesirable consequence of the event if it does occur.
High

High Risk

Medium Risk
Consequence

Low Risk
Low Low Likelihood High

Figure 7-6 Level of risk depends upon both likelihood and consequences The likelihood that an undesirable event will occur often is expressed as a probability. The consequence of the event is expressed in terms that depend on the nature of the event (e.g. lost investment, inadequate performance). The combination of low likelihood and low undesirable consequences gives low risk, while high risk is produced by high likelihood and highly undesirable consequences. By changing the adjective from undesirable to desirable the noun changes from risk to opportunity, but the diagram remains the same. As suggested by the shading, most projects experience a comparatively small number of high risk or high opportunity events.
Page 7.13 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Risk pervades the life cycle of systems. The system may be intended for technical accomplishments near the limits of the state of the art, creating technical risk. System development may be rushed to deploy the system as soon as possible to meet an imminent threat, leading to schedule risk. All systems are funding-limited so that cost risk is present. Risk can be introduced by external constraints or can develop from within the project, since technical risk can create schedule risk, which in turn can create cost risk. There is no alternative to the presence of risk in system development. The only way to remove risk is to set technical goals very low, to stretch the schedule, and to supply unlimited funds. None of these events happen in the real world. No realistic project can be planned without risk. The challenge is to define the system and the project which best meet overall requirements, which allow for risk, and which achieve the highest chances of project success. Figure 7-7 illustrates the major interactions between the four risk categories; technical, cost, schedule and programmatic. The arrow names indicate typical risk relationships; others certainly are possibe.
Technical Risk
C Co m p pr

nd

s

e es

em

d

Mission Changes

Fu

s se

s

T Te h ch

d d Sc

ite

bl

ic nic

ro

m

h he

Li

lP

d du

l al

ca

Te

Programmatic Risk g ud ets
De m an

l le

o Pro

s

ch

ni

e ble s ms

Im

s po

e

dB

d

Sc

he

du

le

s

Cost Risk

Schedule Slips

Schedule Risk

Figure 7-7 Typical Relationship among the Risk Categories Technical risk is the possibility that a technical requirement of the system may not be achieved in the system life cycle. Technical risk exists if the system may fail to achieve performance requirements; to meet operability, producibility, testability, integration requirements; or to meet environmental protection requirements. A potential failure to meet any requirement which can be expressed in technical terms is a source of technical risk. Cost risk is the possibility that available budget will be exceeded. Cost risk exists if the project must devote more resources than planned to achieve technical requirements;
Page 7.14 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

if the project must add resources to support slipped schedules due to any reason; if changes must be made to the number of items to be produced; or, if changes occur in the enterprise or national economy. Cost risk can be predicted at the total project level or for a system element. The collective effects of element-level cost risks can produce cost risk for the total project. Schedule risk is the possibility that the project will fail to meet scheduled milestones. Schedule risk exists if there is inadequate allowance for acquisition delays. Schedule risk exists if difficulty is experienced in achieving scheduled technical accomplishments, such as the development of software. Schedule risk can be incurred at the total project level for milestones such as deployment of the first system element. The cascading effects of element-level schedule risks can produce schedule risk for the total project. Programmatic risk is produced by events which are beyond the control of the project manager. These events often are produced by decisions made by personnel at higher levels of authority. Programmatic risks can be produced by reductions in project priority, by delays in receiving authorization to proceed with a project, by reduced or delayed funding, by changes in enterprise or national objectives, etc. Programmatic risk can be a source of risk in any of the other three risk categories. The Risk Management process activities are Risk Identification, Risk Assessment, Risk Handling, Risk Tracking and Control, and Risk Mitigation. 7.3.2 Risk Identification The purpose of risk identification is to identify risks and evaluate their relative severity. The basis for this evaluation may be qualitative or quantitative. All stakeholders and project personnel should feel welcome to contribute to risk identification. The objective is to set priorities and focus attention on areas of risk with the greatest consequences to the success of the project. If a project is unprecedented, brainstorming using SWOT (Strength-WeaknessOpportunity-Threat) or Delphi techniques may be appropriate. But most projects represent a new combination of existing systems or system elements or represent the insertion of incremental advances in technology. This means that key insights can be gained concerning a current project’s risk by examining the successes, failures, problems, and solutions of similar prior projects. The experience and knowledge gained, or lessons learned, can be applied to identify potential risk in a new project and to develop a strategy for risk management. The first step is to determine the information needs in this phase of risk management. This could vary from assessing the risk in development of a custom computer chip to identifying the risks associated with a major system development. The second step is to define the basic characteristics of the new system. This is necessary to identify
Page 7.15 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

past projects that are similar in technology, function, design, etc. Then, based on the availability of data, analogous systems or subsystems are selected and data gathered. Often the data collection process and initial assessment lead to a further definition of the system for the purposes of comparison. After this has been accomplished, the last step in the process is the analysis and normalization of the historic data. Comparisons to prior systems may not be exact or the data may need to be adjusted to be used as a basis for estimating the future. The desired output is insight into cost, schedule, and technical risks of a project based on observations of similar past projects. 7.3.3 Risk Assessment Uncertainty is characterized by a distribution of outcomes based on likelihood of occurrence and severity of consequences. Risk involves both the probability and consequences of the possible outcomes. In its most general form, risk assessment should capture the spectrum of outcomes relative to the desired project technical performance, cost, and schedule requirements. Risk generally needs to be assessed subjectively because adequate statistical data are rarely available. Expert Interviews: Efficient acquisition of expert judgments is extremely important to the overall accuracy of the risk management effort. The expert interview technique consists of identifying the appropriate experts, questioning them about the risks in their area of expertise, and quantifying these subjective judgments. One result is the formulation of a range of uncertainty or a probability density function (with respect to cost, schedule, or performance) for use in any of several risk analysis tools. Since expert interviews result in a collection of subjective judgments, the only real “error” can be in the methodology for collecting the data. If it can be shown that the techniques for collecting the data are not adequate, then the entire risk assessment can become questionable. For this reason, the methodology used to collect the data must be thoroughly documented and defensible. Experience and skill are required to encourage the expert to divulge information in the right format. Typical problems encountered include identification of the wrong expert, obtaining poor quality information, unwillingness of the expert to share information, changing opinions, getting biased viewpoints, obtaining only one perspective, and conflicting judgements. When conducted properly, the expert interviews provide very reliable qualitative information. However, the transformation of that qualitative information into quantitative distributions or other measures depends on the skill of the analyst. Models: Risk is often expressed only in qualitative terms or by a single value. However, it is very important to quantify risk in some methodical way to assure a good allocation of resources for risk reduction. Ideally, risk would be characterized by using cumulative probability curves with the probability of failure and the consequences expressed quantitatively in measurable terms, but given the inherent lack of data and limited analysis, this is usually impractical. It is very important to properly quantify risk because an invalid assessment could lead to an improper
Page 7.16 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

conclusion with misapplication of resources. Expected Value Model: A somewhat subjective, relative rating of risk is developed, where risk is expressed as: Expected consequence = Probability of failure (Pf )* Consequences of failure (Cf). For illustration purposes, consider a proposal to develop a new light-weight and compact power supply with an operating life of 8,000 hours. The consequences of failing to meet at least 6,000 hours are assessed to be critical, so the consequence of failure is assigned a value of 0.8. Given the present state of technology, cost and schedule, the probability of failing to achieve an operating life of 6,000 hours is judged to be relatively low and is estimated as 30% (0.3). Applying the equation to the above example yields Risk = 0.3*0.8 = 0.24 This would suggest a relatively low risk situation. Intuitively, the described scenario represents a low/moderate risk (subjective judgment); therefore this approach appears to yield a valid relative ranking of risk. 7.3.4 Risk Handling Risk handling approaches need to be established for the moderate and high-risk items identified in the risk assessment effort. These activities are formalized in the Risk Management Project Plan, produced within the Risk Management Process, chapter 5.6. There are basically four (4) approaches to handle risk: • accept the risk and do no more; • mitigate the risk by expending budget and other resources to reduce likelihood and/or severity; • transfer the risk by agreement with other party that it is in their scope to mitigate; or, • deal with a risk that has occurred. 7.3.5 Risk Tracking and Control Project management uses metrics to simplify and illuminate the risk management process. Each risk category has certain indicators, which may be used to monitor project status for signs of risk. Tracking the progress of key system technical parameters can be used as an indicator of technical risk. The typical format in tracking technical performance is a graph of a planned value of a key parameter plotted against calendar time. A second contour showing actual value achieved is included in the same graph. Cost and schedule risk are monitored using the products of the Cost/Schedule Control System or some equivalent technique.
Page 7.17 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Normally cost and schedule variances are used, along with a comparison of tasks planned to tasks accomplished. 7.3.6 Risk Mitigation Risk mitigation activities conform to the risk handling options. There are some steps that can be taken to avoid unnecessary risks. Requirements scrubbing – Requirements that significantly complicate the system can be scrutinized to ensure that they deliver value equivalent to their investment. Find alternative solutions that deliver the same or comparable capability. Selection of most promising options – In most situations several options are available, and a trade study can include project risk as a criterion when selecting the most promising alternative. Staffing and team building – Projects accomplish work through people. Attention to training, teamwork, and employee morale can help avoid risks introduced by human errors. For high-risk technical tasks, risk avoidance is insufficient and can be supplemented by the following approaches: • Early procurement • Initiation of parallel developments • Implementation of extensive analysis and testing • Contingency planning The high-risk technical tasks generally imply high schedule and cost risks. Cost and schedule are impacted adversely if technical difficulties arise and the tasks are not achieved as planned. Schedule risk is controlled by early procurement of long-lead items and provisions for parallel-path developments. However, these activities also result in increased early costs. Testing and analysis can provide useful data in support of key decision points. Finally, contingency planning involves weighing alternative risk mitigation options. In China, the authorities built the short Maglev train line in Shanghai as a proof-ofconcept. In spite of the high investment, this represented lower risk to the project than attempting a longer line with an unproven technology. This results collected from this project are inspiring others to consider Maglev alternatives for greater distances. A number of references exist on the topic of risk management. 21, 22, 23, 24, 25

Page 7.18 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

1 Literature sampling included a – k a) Armstrong, J. E. and A. P. Sage. Introduction to Systems Engineering, John Wiley & Sons, 2000. b) Aslaksen, E. W. The Changing Nature of Engineering. McGraw Hill, 1996. c) Blanchard, B. Logistics Engineering and Management, 4 ed. Prentice Hall, 1992. d) Chase, W. P., Management of System Engineering. John Wiley & Sons, 1974. e) Chestnut, H., Systems Engineering Methods. New York: Wiley, 1967. f) Forsberg, K., et. al., Visualizing Project Management, 3 ed. John Wiley & Sons, 2005. g) Hall, A. D. A Methodology for Systems Engineering. Princeton, NJ: Van Nostrand, 1962. h) Kossiakof, A and W. Sweet. Systems Engineering Principles and Practice. John Wiley & Sons, 2003. i) Martin, J. N. Systems Engineering Guidebook, CRC Press, 1996. j) Sage, A. P. Methodology for Large-scale Systems. McGraw Hill, 1977. k) Stevens, R. et. al. Systems Engineering: coping with complexity. Prentice Hall Europe, 1998. 2 AIAA and INCOSE, Systems Engineering Primer, 1997, www.incose.org/ProductsPubs/products/ seprimer.aspx 3 Used with permission from United Media 4 Teale, M., et. al., Management Decision-making. Prentice Hall, 2003. 5 Bayes, the Reverend Thomas (1702 – 1761). “Essay Toward Solving a Problem in the Doctrine of Chances.” Philosophical Transactions of the Royal Society of London, 1763. 6 Raiffa, Howard, Decision Analysis: Introductory Lectures on Choices Under Uncertainty., AddisonWesley, New York, 1968. 7 Schlaiffer, Robert, Analysis of Decisions Under Uncertainty, McGraw-Hill Book Company, New York, 1969. 8 Skinner, David C., Introduction to Decision Analysis, Second Edition, Probabilistic Publishing, Gainsville, FL 2001. p 34, 88. 9 Poppendieck. Mary, “Morphing the Mold”, Software Development, Jul 07, 2003. 10 Skinner, p. 34. 11 Emes, Michael, “Strategic Multi-stakeholder Trade Studies,” Proceedings of EuSEC, Edinburgh, 18-20.sep 2006. 12 Arnold, Stuart and Harold Lawson, “Viewing Systems from a Business Management Perspective: The ISO/IEC 15288 Standard,” Journal of Systems Engineering, 7:3, 2003. 13 Friedenthal, Sanford, Burkhart, Extending UML from Software to Systems, Proceedings Thirteenth Annual International Symposium INCOSE. Arlington, VA, USA, June 30- July 1, 2003. 14 Friedenthal, Sanford, and Kobryn, “Extending UML to Support a Systems Modeling Language”, INCOSE Symposium, Toulouse, France June 2004 15 OMG Systems Engineering Domain Special Interest Group (SE DSIG) Website, http://syseng.omg. org 16 Heijden, K. vd, et. al., The Sixth Sense, John Wiley & Sons, 2002; p. 121. 17 Project Management Institute, 2000. A Guide to the PMBOK. Upper Darby, USA: p. 176. 18 Widerman, R. Max. Comparative Glossary of Common Project Management Terms v3.1, March 2002. 19 Conrow, E. H., Effective Risk Management, 2nd Edition, American Institute of Aeronautics and Astronautics, Inc., VA, 2003, p 435. 20 Ibid. p. 436. Page 7.19 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

21 AT&T Engineering Guides for Managing Risk: Design to Reduce Technical Risk; Design’s Impact on Logistics; Moving a Design into Production; Testing to Verify Design and Manufacturing Readiness, from the McGraw-Hill Professional Book Group (1-800-842-3075) 22 Barton, Thomas L., William G. Shenkir, and Paul L. Walker, Making Enterprise Risk Management Pay Off: How Leading Companies Implement Risk Management, Upper Saddle River, NJ: Financial Times/Prentice Hall PTR/Pearson Education Company, 2002 23 Michel, Robert Mark, and Dan Galai, Risk Management, NY: McGraw Hill, 2001 24 Shaw, T.E. and Lake, J. G., Ph.D., “Systems Engineering: The Critical Product Development Enabler,” APICS Conference, April 1993 25 Wideman, R. Max, Editor, Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities, Newtown Square, PA: Project Management Institute, 2004.

Page 7.20 of 20
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

8 Systems Engineering Support Activities
The topics in chapter 8 are covered in alphabetical order by topic title to avoid giving more weight to one topic over another. See Table 1-1 for an overview. The objective of this chapter is to present the most frequently recommended set of activities within the systems engineering effort. Depending on the nature of the project, its complexity, size, and duration, some or most of these activities will be included in the project execution. More information about each activity can be found in references to external sources and the IPAL.

8.1 Acquisition and Supply
The initiation of a project begins with user need. Once a need is perceived and resources are committed to establish a project it is possible to define the parameters of an acquisition and supply relationship. This relationship exists whenever an organization with a need does not have the ability to satisfy that need without assistance. Acquisition is also an alternative for optimising investment when a supplier can meet the need in a more economical or timely manner. The Acquisition and Supply Processes are the subject of chapters 6.7 and 6.8, respectively. The acquisition and supply processes are two sides of the same coin. Each process establishes the contractual context and constraints under which the other system life cycle processes are performed. The unique activities for the agreement processes are related to contracts and managing business relationships. An important contribution of the ISO/IEC 15288 is the recognition that systems engineers are relevant contributors in this domain.1 The Maglev train case is an example where the government representatives of China and Germany participated in the relationship. Contract negotiations are handled in various ways depending on the specific organization. In a process that is widely used, the contracts organization in industry (or the contracting officer in the government) is responsible for negotiating contracts, including the contract terms and conditions. Key parameters such as profit target and acceptable contract type (firm fixed price, cost plus fixed fee, cost plus award fee) are established by the business area manager or by enterprise management. Project managers rarely lead contract negotiations, however, the lead contract negotiator should only agree to any changes in scope, cost, or schedule with the project manager’s approval. The systems engineer is in a supporting role to the project manager during negotiations. The lead contract negotiator may need, within minutes or a few hours, an assessment of the impact of customer-proposed changes; for major changes, the team may need a few days. In preparation for contract negotiations, systems engineers often perform preliminary trade studies on a range of cost, schedule, and technical performance options that might be proposed by the customer during negotiations
Page 8.1 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

(or, for subcontract negotiations, changes that might be presented by the supplier). Of particular importance is the impact to project risk. What is needed is accuracy – not precision – so the team is prepared for anything reasonable that might arise. A team that is prepared will always have a more favorable outcome in negotiations, and the buyer will be pleased to work with a knowledgeable provider. A critical element to each party is the definition of acceptance criteria. These criteria protect both sides of the business relationship – the acquirer from being coerced into accepting a product with poor quality; and the supplier, from the vagaries of a fickle or indecisive buyer.

8.2 Architectural Design
Developing the system architecture is one of the most important responsibilities of the systems engineer. It is a creative process, and there is no unique solution to satisfying user requirements. The system architecture is critical because it provides the framework for system development. The Architectural Design Process is the topic of chapter 4.4. In his book Wasson states, “System, product, or service architectures depict the summation of a system’s entities and capabilities levels of abstraction that support all phases of deployment, operations, and support.” 2 In 1987 John Zachman first formally enunciated the opinion that in the modern world we should no longer talk about multiple architectures; that instead we need to talk about multiple views of a single broad-reaching architecture.3,4 Consider developing architectural alternatives that are significantly different in their approach to meeting stakeholder requirements, as illustrated in Figure 8-1.
Alternative Architecture Concept Example for Intercontinental Telephone Communication

Land Line
*0 #
12 3 45 6 78 9

*0 #

12 3 45 6 78 9

Underground Cable Underwater Cable

Concept #1 Wireless Communication via Satellite

Concept #2 Wireline Communication

90493A

Figure 8-1 Example of Alternative Architectural Concepts

Page 8.2 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Creating an effective system architecture draws on the experience, intuition, and good judgment of the team to devise an appropriate solution. As Rechtin and Maier define it, systems architecting builds on four methodologies:5 • Normative (solution based) such as building codes and communication standards. • Rational (method based) such as systems analysis and engineering. • Participative (stakeholder based) such as concurrent engineering and brainstorming. • Heuristic (lessons learned) such as “Simplify. Simplify. Simplify.” Because systems architecting is a creative process, and because intuition and experience play such an important role, the systems engineer must pay attention to situations where past experience and intuition have been a handicap. The book, The Innovator’s Dilemma,6 by Clayton Christensen, clearly sets forth the benefit of making creative use of past experience. He uses the example of the computer hard disk drive industry in which experience had been a key factor to the growth of companies that dominated the hard disk market. Christensen then highlights the transition difficulties for companies making large disks and their inability to capture any market share when the industry moved to smaller size disks. According to Christensen no manufacturer made a successful transition from a 14-inch (35.6 cm) disk to the 8-inch (20.3 cm) disk; a whole new set of companies dominated that market. This was repeated as the sizes dropped from 8 to 5-¼ to 3-½ to 2-½ to 1.8 inches. This sequence started in 1980s and is continuing today with the flash drives. In each of these transitions, the established companies lost out, in part because their established user base was locked-in to the older architecture, and in part, because their entire enterprise from systems engineering to marketing to manufacturing to executive management was unable to see the new vision. 8.2.1 Interoperability Analysis Interoperability depends on the compatibility of components of a large and complex system (which may sometimes be called a system of systems or a family of systems) to work as a single entity. This feature is increasingly important as the size and complexity of systems continues to grow. Pushed by an inexorable trend toward electronic digital systems and pulled by the accelerating pace of digital technology invention, commercial firms and national enterprises span the world in increasing numbers. As their spans increases, these commercial and national enterprises want to make sure that their sunk investment in legacy components of the envisioned new system is protected and that new components added over time will work seamlessly with the legacy components to comprise a unified system. Standards have also grown in number and complexity over time, yet compliance with standards remains one of the keys to interoperability. The standards that correspond to the layers of the ISO-OSI Reference Model for peer-to-peer communication
Page 8.3 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

systems once fit on a single wall chart of modest size. Today it is no longer feasible to identify the number of standards that apply to the global communications network on a wall chart of any size. Interoperability will increase in importance as the world grows smaller due to expanding communications networks, and as nations continue to perceive the need to communicate seamlessly across international coalitions of commercial enterprises or national defense forces. The Øresund Bridge demonstrates the interoperability challenges faced when just two nations collaborate on a project; meshing of regulations on health and safety, and the resolution of two power supply systems for the railway. 8.2.2 Manufacturing and Producibility Analysis The capability to produce a system element is as essential as the ability to properly define and design it. If a designed product can not be manufactured, this causes design rework and program delays with concomitant cost overruns. For this reason, production engineering analysis and trade studies for each design alternative form an integral part of the Architectural Design process. One objective is to determine if existing proven processes are satisfactory since this could be the lowest risk and most cost-effective approach. The Maglev train contractor experienced a steep learning curve to produce an unprecedented system from scientific theory. Critical producibility requirements are identified during system analysis and design and included in the program risk analysis, if necessary. Long-lead-time items, material limitations, special processes, and manufacturing constraints are evaluated. When production engineering requirements create a constraint on the design, they are communicated and documented. Producibility analysis is a key task in developing low cost, quality products. Multidisciplinary teams work to simplify the design and stabilize the manufacturing process to reduce risk, manufacturing cost, lead time, and cycle time; and to minimize strategic or critical materials use. Design simplification considers ready assembly and disassembly for ease of maintenance and preservation of material for recycling. The selection of manufacturing methods and processes are included in early decisions. Manufacturing analyses draw upon the Concept of Production, Concept of Deployment, and Concept of Maintenance. Manufacturing test considerations are shared with the engineering team and are taken into account in Built-In-Test and Automated Test Equipment. IKEA is often used as an example of supply chain excellence. IKEA has orchestrated a value creating chain that begins with motivating customers to perform the final phases of furniture assembly in exchange for lower prices and a fun shopping experience. They achieve this through designs that support low cost production and transportability – the bookcase that comes in a flat package and goes home on the roof of a car.
Page 8.4 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

8.3 Configuration Management
The purpose of Configuration Management (CM) is to establish and maintain control of requirements, documentation, and artifacts produced throughout the system’s life cycle. The Configuration Management Process is the topic of chapter 5.7. Change is inevitable, as indicated in Figure 8-2, and managing the impact of change on a project is the work of CM. Systems engineers ensure that the change is necessary, and that the most cost-effective recommendation has been proposed. It is important also to ask: “What is the impact of not making the change?” especially as the system matures, since changes made later in the life cycle have an increasing risk of hidden impacts which can adversely affect system cost, schedule, and technical performance.

New Requirements Changed Requirements

Required for Final Delivery

Original Requests

Original Requirements

Deleted Requirements

Changes in the Environment

Figure 8-2 Requirements changes are inevitable CM is the practice of applying technical and administrative direction, surveillance, and services to: • Identify and document the characteristics of system elements such that they are unique and accessible in some form; assign a unique identifier to each version of each system element; • Establish controls to allow changes in those characteristics; ensure consistent product versions; • Record, track, and report status pertaining to change requests or problems with a product; maintain comprehensive traceability of all transactions. The initial planning efforts for CM are defined in the Configuration Management Plan that establishes the scope of items that are covered by the plan, the resources and personnel skill level required, defines the tasks to be performed, identifies CM tools and processes, as well as methodology, standards and procedures that will be used on the project. Configuration control maintains integrity by facilitating approved changes and preventing the incorporation of unapproved changes into the items under configuration control. Such activities as check-in and check-out of source code,
Page 8.5 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

versions of system elements, and deviations of manufactured items, are part of the CM. Independent configuration audits assess the evolution of a product to ensure compliance to specifications, policies, and contractual agreements. Formal audits may be performed in support of decision gate review. A request to change the current configuration of a system is typically made using an engineering change proposal (ECP). An ECP may originate in a number of ways. The customer may request an ECP to address a change in requirements or a change in scope; an unexpected breakthrough in technology may result in the supplier of a system element proposing an ECP; or a supplier may identify a need for changes in the system under development, and an ECP may originate to address those changes. Circumstances like these that will potentially change the scope or the requirements are appropriate reasons to propose an ECP and to conduct an analysis to understand the effect of the change on existing plans, costs, and schedules. The ECP must be approved before the change is put into effect. It is never appropriate to propose an ECP to correct cost or schedule variances absent of change in scope. A minor change that falls within the current project scope usually does not require an ECP but should be approved and result in the generation of an engineering notice (EN). The most desirable outcomes of an ECP cycle are (1) that system functionality is altered to meet a changing requirement; or (2) that new technology or a new product extends the capabilities of the system beyond those initially required in ways that the customer desires, (3) that the costs of development, or of utilization, or of support are reduced; or (4) that the reliability and availability of the system are improved. Outcomes (3) and (4) reduce life cycle costs, and potentially save more money than is invested to fund the proposed change. Evolving system requirements are a reality that must be addressed over the life of a system development effort, and throughout the utilization and support stages of the system. ECPs and ENs help ensure that a system evolves in ways that allow it to continue to satisfy its operational requirements and its objectives and that any modification is known to all relevant personnel. The camera system illustrated in Figure 2-2 is an example of a product family that depends on accurate identification of system elements and characteristics to support the mix & match consumer market.

8.4 Information Management
The purpose of Information Management (IM) is to maintain an archive of information produced throughout the system’s life cycle. The Information Management Process is the topic of chapter 5.8. The initial planning efforts for IM are defined in the Information Management Plan that establishes the scope of project information that is maintained, the resources and personnel skill level required, defines the tasks to be performed, identifies IM tools and processes, as well as methodology, standards and procedures that will be used
Page 8.6 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

on the project. Typical information includes source documents from stakeholders, contracts, project planning documents, test documentation, engineering analysis reports, and the files maintained by CM. Today IM is most often concerned with the integration of databases such as the decision database – with results from decision gate reviews and other decisions taken on the project; requirements management tools databases; computer-based training and electronic interactive user manuals; websites and share information spaces accessed over the internet, such as (for example) INCOSE CONNECT. The standard for the exchange of product model data (STEP - ISO 10303) will provide a neutral computer-interpretable representation of product data throughout the life cycle. ISO 10303-239 (Product Life Cycle Support) is an international standard that specifies an information model that defines what information can be exchanged and represented to support a product through life.7 INCOSE is a co-sponsor of ISO 10303233 (AP233) - Systems Engineering Data Exchange. Figure 8-3 shows how AP233 would be used to exchange data between a SysML and other Systems Engineering application and then to applications in the larger life cycle of systems potentially using related ISO STEP data exchange capabilities.

Figure 8-3 AP233 facilitates data exchange With effective IM, information is readily accessible to authorized project and enterprise personnel. Challenges related to maintaining databases, security of data, sharing data across multiple platforms and organizations, and transitioning when technology is updated are all handled by IM. With all the emphasis on knowledge management, organizational learning and information as competitive advantage, these activities are gaining increased attention.

8.5 Investment Management
The purpose of Investment Management is to balance the use of financial assets within the enterprise. The Investment Management Process is the topic of chapter 6.3. 8.5.1 Define the Business Case Enterprise management generally demands that there will be some beneficial return for the effort expended in pursuing a project. The business case establishes the
Page 8.7 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

scope of required resources (people and money) and schedule, and sets reasonable expectations. An important element of each design gate is a realistic review of the business case as the project matures. The result is re-verification or perhaps restatement of the business case. The Iridium case described in chapter 3.2 illustrates the dangers of failing to keep a realistic perspective. Despite the technological triumph of implementing the world’s first Maglev train line, the exorbitant initial cost and the slow return on investment are causing the authorities to question plans to build another line. The business case may be validated in a variety of ways. For large projects, creation of a sophisticated engineering model, or even prototypes of key system elements, help prove that the objectives of the business case can be met, and that the system will work as envisioned prior to committing large amounts of resources to full-scale engineering and manufacturing development. For very complex systems, such a demonstration can be conducted at perhaps twenty percent of development cost. For smaller projects, when the total investment is modest, proof-of-concept models may be constructed during the Concept Stage to prove the validity of the business case assumptions. 8.5.2 Cost-Effectiveness Analysis In economics, the term cost-effectiveness applies to the comparison of the relative spending (costs) and outcomes (effects) associated with two or more courses of action. System cost-effectiveness analysis is helpful for deriving critical system performance and design requirements, and supports decision-making. Some examples of critical cost/effectiveness analyses are: 1. Studies of the desirable performance characteristics of commercial aircraft to increase an airline’s market share at lowest overall cost over its route structure (more passengers, better fuel consumption) 2. Studies of the desired characteristics of a communications satellite to serve specified markets most economically (placement, coverage) 3. Urban studies of the most cost/effective improvements to a city’s transportation infrastructure (buses, trains, motorways, and mass transit routes and departure schedules). Military and government acquisitions are under the scrutiny of auditing offices to demonstrate that the money spent has delivered the expected benefits.8 A recent concept, Cost as an Independent Variable builds on cost-effectiveness studies to determine an objective cost for the system acquisition. Once the cost is agreed, it becomes a constraint on future decisions regarding project execution.9

Page 8.8 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

8.5.3 Life Cycle Cost Analysis As discussed in chapter 2, decisions made during the early stages of a project inevitably have an impact on future expenditures. New systems are designed, developed, manufactured, and tested over the span of many years, as in the case of a new automobile, or nearly two decades in the case of a submarine. Over such lengths of time, decisions made at the outset may have substantial, long-term effects that are frequently difficult to analyze. Life cycle cost (LCC) analysis is a method of economic evaluation which takes into account all relevant costs of a system over a given period of time adjusting for differences in the timing of those costs. 10 For products purchased off the shelf, the major factors are the cost of acquisition, operation, maintenance, and disposal. Otherwise, it may be necessary to include the costs associated with each of the six life cycle stages. A life cycle cost analysis results in a timetable of expenses so that an organization can cover its costs. If all costs can not be covered, it may not be possible to produce the system. In some literature, LCC is equated to total-cost-of-ownership. LCC analysis helps the project manager understand the total cost impact of a decision; to compare between decision alternatives; and to support trade studies for decisions made throughout the system life cycle. LCC normally includes the following costs, represented in Figure 8-4. Accuracy in the estimates will improve as the system evolves and the data used in the calculation is less uncertain. 1. Research and Development costs 2. Investment (Production/Deployment/Installation) costs 3. Utilization and Support costs 4. Disposal costs
LIFE CYCLE COST UTILIZATION COST
COST

INVESTMENT COST ACQUISITION COST R & D COST PROJECT R & D COST

Concept Utilization & Support Phase Phase Development Phase Production & Deployment Phase

Figure 8-4 Life Cycle Cost Elements (not to scale)
Page 8.9 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Examples of the justification for LCC analysis A typical example of a decision with a long-term effect concerns the choice of system elements and parts for a new system. Often, the desire to minimize the initial investment by selecting less expensive parts carries the consequence of a higher probability of failures during the operational life of the system and the corresponding higher maintenance costs. Therac-25 is an example where the decision to save time and money on software unit testing resulted in undetected design errors that emerged later during operation. A third example relates to the need for logistics support. Maintenance costs during the operational stage can be reduced by including in the system built-in test equipment that identifies problems, locates their source, and recommends a corrective course of action. Diagnostic testing elements of this type that combine sensors with automated checklists and expert systems logic are expensive to develop, but in the long run decrease maintenance costs and increase availability. A relatively small change in mean-time-to-repair or mean-time-between-failures can result in large cost savings during the Operations Stage. Advantages of LCC analysis LCC analysis has three important benefits – All costs associated with a system become visible: upstream; locked in costs, such as R&D; downstream; customer service.11 – Supports an analysis of enterprise interrelationships. Reinforces the importance of locked in costs, such as R&D; low R&D expenditures may lead to high customer service costs in the future. – Project managers can develop accurate revenue predictions. Methods / Techniques 1. Wide-band Delphi techniques – estimations from multiple technical and domain experts (estimations only as good as the experts) 2. Analogy - estimating by comparing the proposed project with one or more completed projects that are judged to be similar, with corrections added for known differences (for early estimations) 3. Price-To-Win - focuses on providing an estimate, and associated solution, at or below the price judged necessary to win the contract. 4. Algorithmic (parametric) - uses mathematical algorithms to produce cost estimates as a function of cost driver variables, based on historical data; often supported by commercial tools/models. 5. Design-To-Cost or Cost-As-An-Independent-Variable – based on a design solution that stays within a predetermined set of resources.

Page 8.10 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

8.6 Project Planning
The purpose of Project Planning is to estimate the budget and schedule for a project against which to monitor the progress. This process is the topic of chapter 5.2. As illustrated in Figure 5-1, systems engineers and project managers collaborate in project planning. Systems Engineers perform technical management activities consistent with project objectives. Technical management activities include planning, scheduling, reviewing, and auditing the Systems Engineering process as defined in the Systems Engineering Plan (SEP), and the Systems Engineering Master Schedule (SEMS). The SEP is the top-level plan for managing the Systems Engineering effort. The SEP defines how the project will be organized, structured, and conducted and how the total engineering process will be controlled to provide a system that meets stakeholder requirements. A well-written SEP provides guidance to a project and helps the organization avoid unnecessary discussions about how to perform Systems Engineering. Enterprises generally maintain a template of the SEP suitable for tailoring and reuse. Project-specific appendices are often used to capture detailed and dynamic information such as a schedule of milestones and decision gate reviews, and the methodology to be used in resolving problems uncovered in reviews. Effective project control requires that there be a SEP which the systems engineer keeps current and uses on a daily basis to manage the team’s actions. The SEMS is an essential part of the SEP and a tool for project control. It identifies the critical path of technical activities in the project. Verification activities may also receive special attention in the SEMS. In addition, the schedule of tasks and dependencies helps justify requests for personnel and resources needed throughout the development lifecycle. The SEP and SEMS are supported by a Work Breakdown Structure (WBS) that defines a project task hierarchy. A description of the enterprise procedures for starting work on a part of the WBS may be defined in the SEP. Under some circumstances, the SEP may address Design to Cost and Value Engineering practices to provide insight into system/ cost effectiveness. For example, “Can the project be engineered to have significantly more value with minimal additional cost?” If so, does the customer have the resources for even the modest cost increase for the improvement? The intent is to assure the customer that no obvious cost effective alternatives have been overlooked.

8.7 Quality Management
The purpose of Quality Management is to outline the policies and procedures necessary to improve and control the various processes within the enterprise that ultimately lead to improved business performance. The Investment Management Process is the topic of chapter 6.3.
Page 8.11 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

8.7.1 Process Compliance Reviews Enterprises that set internal policies and procedures conduct periodic process compliance reviews to assess the effectiveness or their processes. Such reviews are conducted on a recurring basis and may be combined with other assessments (such as ISO 9000), to reduce the perceived burden. The review should address defects in the examined process at the time of the review, the improvement process, tailoring of the process, and tailoring of the improvement process (if applicable). Enterprise management prioritizes and approves changes based on requested or recommended areas for improvement in the standard processes. Sometime, it is sufficient to provide additional tailoring guidelines. Results of the review are recorded and maintained. Occasional benchmark comparisons with other organizations can be useful. Reference processes, practices and other capabilities can be accessed through either direct contact or an intermediary’s compilations of benchmarked processes, practices and other capabilities. This section is not complete without a caution. Leaders in management research advise organizations also to reassess the utility of process management programs and apply them with discrimination.12 “In the appropriate setting, process management activities can help companies improve efficiency, but the risk is that you misapply these programs, in particular in areas where people are supposed to be innovative. Brand new technologies to produce products that don’t exist are difficult to measure. This kind of innovation may be crowded out when you focus too much on processes you can measure.”13 8.7.2 Quality Assurance The primary objective of quality assurance (QA) is to produce an end result that meets or exceeds stakeholder expectations. Using a quality system program, manufacturers (for example) establish requirements for each type or family of product to achieve products that are safe and effective. To meet this objective they establish methods and procedures to design, produce, distribute, service, and document devices that meet the quality system requirements. Quality management is the topic of chapter 6.6 and is closely related to the verification and validation processes. QA is generally associated with activities such as failure testing, statistical control, and total quality control. Many organizations use statistical process control as a means to achieve Six Sigma levels of quality. Traditional statistical process controls use randomly sampling to testing a fraction of the output for variances within critical tolerances. When these are found, the manufacturing processes are corrected before more bad parts can be produced. Quality experts14,15 have determined that if quality cannot be measured, it cannot be systematically improved. Assessment provides the feedback needed to monitor performance and make mid-course corrections. It provides data for diagnosing
Page 8.12 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

Edited by Foxit Reader INCOSE Systems Engineering Handbook v. 3 Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

difficulties and pinpointing improvement opportunities. A widely used paradigm for QA management is the Plan-Do-Check-Act approach, also known as the Shewhart cycle.16 Quality pioneer W. Edwards Deming stressed that meeting user needs represents the defining criterion for quality and that all members of an organization need to participate actively in “constant and continuous” quality improvement—to commit to the idea that “good enough isn’t.”17 His advice marked a shift from inspecting for quality after production to building concern for quality into enterprise processes. As an example, in 1981, Ford launched a quality campaign – see Figure 8-5 – which went beyond getting good workers and supporting them with high-quality training, facilities, equipment, and raw materials. By characterizing quality as a “job,” everyone in the organization is motivated to concern themselves with quality and its improvement—for every product and customer.18

Figure 8-5 Banner from Ford quality campaign Total Quality Control deals with understanding what the stakeholder/customer really wants. If the original needs statement does not reflect the relevant quality requirements, then quality can be neither inspected nor manufactured into the product. For instance, the Øresund Bridge consortium included not only the bridge material and dimensions but operating, environmental, safety, reliability and maintainability requirements. Product certification is the process of certifying that a certain product has passed performance or quality assurance tests or qualification requirements stipulated in regulations such as a building code or nationally accredited test standards, or that it complies with a set of regulations governing quality or minimum performance requirements. Today medical device manufacturers are advised to use good judgment when developing their quality system and apply those sections of the Food and Drug Administration Quality System Regulation that are applicable to their specific products and operations. The regulation, 21-CFR-820.5 is continuously updated since its release in 1996. It ought not to be possible to repeat the errors of the Therac-25 project.

8.8 Resource Management
The purpose of Resource Management is to maintain and manage the people, hardware, and support tools required by the portfolio of enterprise projects. The Resource Management Process is the topic of chapter 6.5. Resource management is the efficient and effective deployment of an enterprise’s resources when and where they are needed. Such resources may include inventory, human skills, production resources, or information technology. An optimised goal
Page 8.13 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

is to achieve 100% utilization of every resource, but this is unlikely when providing some minimum level of service while minimizing cost. Resource management relies heavily on forecasts into the future of the demand and supply of various resources. Project managers face their resource challenges competing for scarce talent in the larger enterprise pool. They must balance access to the experts they need for special studies with stability in the project team with its tacit knowledge and project memory. Today’s projects depend on teamwork and optimally multi-disciplinary teams. Such teams are able to resolve project issues quickly through direct communication between team members. Such intra-team communication shortens the decision-making cycle and is more likely to result in improved decisions because the multi-disciplinary perspectives are captured early in the process. However, studies have shown that group decisions are often “riskier” resulting in the potential for greater innovation. In a multi-disciplinary team, each member comes from a discipline with its own perspective. They are responsible for representing that viewpoint, while at the same time establishing the necessary relationships with the other members. However, team results are condemned to mediocrity unless each member confronts the team with challenging ideas while focusing on the final result. Using concurrent development, see Figure 8-6, it may be possible to finish the work faster and thus return valuable skills back to the personnel pool, having achieved a successful delivery.
TRADITIONAL DEVELOPMENT
1 2 3 4 5 6 7 8 9

CONCURRENT DEVELOPMENT
1 2/3 3/4/5/6 5/8 7/9

Figure 8-6 Shorter delivery time with concurrent development vs. traditional As early as 1974, Chase had identified the importance of communications and that “system designs are dependent upon the effective integration of multidisciplinary efforts.”19 He recommended that the organization of a system project should provide opportunity for all disciplinary specialists to work together continuously on a face-toface basis and, most importantly, to acquire the systems viewpoint and understanding of the role that their specific knowledge can provide in deriving a particular system design.20 Chase advocates identifying the lines of communication among tasks in terms of interdependencies and mutual constraints to reveal that different stages of the life cycle call for different tasks and different personnel skills. Properly used, this allows management to acquire and properly utilize the proper combination of specialist
Page 8.14 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

and generalist skills. A project avoids “bureaucratization” of the design approach by streamlining the organization and integrating the various specialist backgrounds into common system-oriented task groups with loyalties directed toward the systems design effort. Modern projects use the concepts of integrated product and process teams to establish a project organization.21

8.9 Validation
System validation confirms that the system, as built (or as it will be built), satisfies the stakeholders’ stated needs. Validation ensures the requirements and the system implementation provide the right solution to the customer’s problem. In other words, “you built the right thing.” Validation is the topic of chapter 4.9. Validation determines that a system does all the things it should and does not do what it should not do. End users and other stakeholders are usually involved in validation activities, but when warranted, an independent third party may be called in to perform validation. Validation may take place either in the operational environment or a simulated operational environment if conditions are hazardous. Both validation and verification activities often run concurrently and may use different portions of the same environment. Requirements validation is conducted as part of requirements elicitation to provide early assurance that the requirements are the “right” requirements for guiding the development process to a conclusion which satisfies the stakeholders. Requirements validation is often based on requirements analysis; exploration of requirements adequacy and completeness; assessment of prototypes, simulations, models, scenarios, and mock-ups; and by obtaining feedback from customers, users or other stakeholders. Much of the discussion regarding verification (below) also can be applied to validation. The objects of validation are the designs, prototypes, and final systems elements, as well as the documentation and training materials that describe the system and how to use it. Validation results are an important element of decision gate reviews.

8.10 Verification
System verification addresses whether the system, its elements, and its interfaces satisfy their requirements. Verification ensures the conformance to those requirements; in other words that “you built it right.” This is the topic of chapter 4.7. Verification encompasses the tasks, actions and activities performed to evaluate the progress and effectiveness of the evolving system solutions (people, products and process) and to measure compliance with requirements. The primary function
Page 8.15 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

of verification is to determine that system specifications, designs, processes and products are compliant with requirements. A continuous feedback of verification data helps to reduce risk and to surface problems early. The goal is to completely verify system capability to meet all requirements prior to production and operation stages. Problems uncovered at in these stages are very costly to correct, see Figure 2-3. Early discovery of deviations from requirements reduces overall project risk and helps the project deliver a successful, low cost system.22 Verification results are an important element of decision gate reviews. Verification analysis can be initiated once a design concept has been established. If a requirements traceability matrix is used, each requirement has a verification activity associated with it. A unique requirements identifier can be used for traceability to the test plans, test procedures, and test reports to provide a closed loop verification process from demonstrated capability back to the requirement. Basic verification activities are: Inspection: an examination of the item against applicable documentation to confirm compliance with requirements. Inspection is used to verify properties best determined by examination and observation (e.g., - paint color, weight, etc.). Analysis: use of analytical data or simulations under defined conditions to show theoretical compliance. Used where testing to realistic conditions cannot be achieved or is not cost-effective. Analysis (including simulation) may be used when such means establish that the appropriate requirement, specification, or derived requirement is met by the proposed solution. Demonstration: a qualitative exhibition of functional performance, usually accomplished with no or minimal instrumentation. Demonstration (a set of test activities with system stimuli selected by the system developer) may be used to show that system or subsystem response to stimuli is suitable, see Figure 8-7. Demonstration may be appropriate when requirements or specifications are given in statistical terms (e.g., mean time to repair, average power consumption, etc.). Test: an action by which the operability, supportability, or performance capability of an item is verified when subjected to controlled conditions that are real or simulated. These verifications often use special test equipment or instrumentation to obtain very accurate quantitative data for analysis. A fifth verification method, certification, refers to verification against legal or industrial standards by an outside authority without direction to that authority as to how the requirements are to be verified. For example, this method is used for electronic devices; CE certification in Europe, and UL certification in the US and Canada.

Page 8.16 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Figure 8-7 A test platform for analyzing battery performance at high loads23 The design of the verification activity involves choosing the most cost-effective mix of simulations and physical testing, and integrating test results to avoid unnecessary redundancy. Complete simulation of the system (both performance and design) has become common-place in major system development, and has resulted in reduced development time and cost. There are four basic test categories. They are: Development Test: Conducted on new items to demonstrate proof of concept or feasibility. Qualification Test: Tests are conducted to prove the design on the first article produced, has a predetermined margin above expected operating conditions, for instance by using elevated environmental conditions for hardware. Acceptance Test: Conducted prior to transition such that the customer can decide that the system is ready to change ownership status from supplier to acquirer. Operational Test: Conducted to verify that the item meets its specification requirements when subjected to the actual operational environment. Human engineering engineers develop task descriptions, operational sequence diagrams, and evaluate the human-machine interface to establish the required interactions with the hardware and software. Verification analysis checks that tests have been established using realistic scenarios to demonstrate human reaction times that satisfy operational requirements. Maintainability demonstrations should include a sufficient number of tests and problem areas to provide a high confidence level of meeting maintainability parameters, such as Mean-Time-To-Repair. Production line tests are recommended for items that are new or have not been previously applied to this application. The tests demonstrate producibility and repeatability.

1 Arnold, Stuart and Harold Lawson, “Viewing Systems from a Business Management Perspective: The ISO/IEC 15288 Standard,” Journal of Systems Engineering, 7:3, 2003. 2 Wasson, Charles S., System Analysis, Design, and Development, John Wiley and Sons, NY, NY, 2006. p. 412. 3 Zachman, John A., “A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26, no. 3, 1987; IBM Publication G321-5298 4 The Zachman Institute for Framework Advancement (ZIFA) can be found at http://www.zifa.com/. Page 8.17 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

5 Rechtin, Eberhardt and Mark W. Maier, The Art of Systems Architecting, CRC Press, Boca Raton, FL. Second Edition, 2000. p. 3. 6 Christensen, Clayton M., The Innovator’s Dilemma, HarperCollins Publishers, NY, NY. 2000. 7 http://www.plcs-resources.org/ 8 http://www.washingtonwatchdog.org/documents/gao/05/GAO-05-966.html 9 Defense Acquisition Deskbook, Version 3.1, 30 September 1999. 10 Fabrycky, W. J. and B. S. Blanchard, Life-Cycle Cost and Economic Analysis, Prentice Hall, 1991. 11 Life cycle cost analysis. (2006, May 11). In Wikipedia, The Free Encyclopedia. Retrieved May 22, 2006, from http://en.wikipedia.org/w/index.php?title=Life_cycle_cost_analysis&oldid=52726603 12 Womack, J. P., Lean Thinking: Where Have We Been and Where Are We Going?, Lean Supplement, Sp 2002, Downloaded May 23, 2006, from http://www.sme.org/gmn/mag/2002/02sem172/ 02sem172.html 13 Brenner, M. J., TQM, ISO 9000, Six Sigma: Do Process Management Programs Discourage Innovation?, Downloaded May 23, 2006 from http://knowledge.wharton.upenn.edu/index.cfm?fa=pr intArticle&ID=1321 14 Crosby, Philip B., Quality is Free, New York: New American Library, 1979 15 Juran, J. M., ed., Quality Control Handbook, Third Edition. New York: McGraw-Hill, 1974 16 Shewhart, Walter Andrew. Statistical Method from the Viewpoint of Quality Control. NY: Dover, 1939 17 Deming, W. E., Out of the Crisis, M.I.T. Center for Advanced Engineering Study, Cambridge, MA, 1986 18 Scholtes, Peter R., The Team Handbook, How to Use Teams to Improve Quality, Joiner Associates, Inc., 1988 19 Chase, Wilton P., Management of Systems Engineering. John Wiley & Sons, Inc. 1974.p. 14. 20 Ibid. p. 22. 21 Martin, J. N., Systems Engineering Guidebook: a process for developing systems and products. CRC Press. 2000. 22 Systems Verification, Validation and Testing Methodology Guidelines, SysTest, Contract: G1RD-CT2002-00683, http://www.incose.org/secoe/0105.htm 23 Picture downloaded May 22, 2006, from http://www.jk-labs.com/ProdDev.html.

Page 8.18 of 18
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

9 Specialty Engineering Activities
The topics in this chapter are covered in alphabetical order by topic title to avoid giving more weight to one topic over another. See Table 1-1 for an overview. The objective of this chapter is to give enough information to systems engineers to appreciate the significance of the engineering specialty area, even if they are not an expert in the subject. It is recommended that subject matter experts are consulted and assigned as appropriate to conduct specialty engineering analysis. More information about each specialty area can be found in references to external sources and the IPAL. With a few exceptions, the forms of analysis are similar to those associated with systems engineering. Most analysis methods are based on the construction and exploration of models that address specialized engineering areas, such as electro-magnetic compatibility, reliability, safety, and security. Not every kind of analysis and associated model will be applicable to every application domain. Figure 9-1 contains a generic Context Diagram for Specialty Engineering Activities.
Controls
Legal, Regulatory Project Constraints

Inputs
-Requirements -CONOPS

Activities
Specialty Engineering Analysis

Outputs
- Analysis Results -Risk, technical status

Enablers
Results from prior projects Standards, tools, and technologies

Figure 9-1 Context Diagram for Specialty Engineering Figure 9-1 GenericGeneric Context Diagram for Specialty Engineering Analysis Activities

9.1 Design for Acquisition Logistics – Integrated Logistics Support
The Operation and Maintenance Processes are defined in chapters 4.10 and 4.11, respectively. The sustainment of these processes during the Utilization and Support Stages is dependent on actions set in motion during the earlier stages. These activities are known under various titles, such as Integrated Logistics Support (ILS), Supply Chain Management, Product Support, Customer Services, and similar names. The full scope of ILS includes Acquisition Logistics – activities influencing the design of a system and its readiness for utilization and support; and, Operational Logistics – activities that ensure that the right materiel and resources, in the right quantity and quality, are available at the right place at the right time throughout the Utilization and Support Stages. Operational logistics also receives attention under the heading of supply chain management. This handbook uses the term ILS, and this section focuses on Acquisition Logistics. Strategies and tactical plans for ILS are established as part of the Enterprise
Page 9.1 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

Edited by Foxit Reader INCOSE Systems Engineering Handbook v. 3 Copyright(C) by Foxit Software Company,2005-2006 For Evaluation Only.

Processes, and will drive the basic considerations to be applied during the Acquisition Logistics activities. Many different analyses are used to consider whether it is more cost effective to influence the initial design of the system or to plan for spare parts and repairs during utilization. When initial acquisition costs are fixed, this can have a downstream impact on the funding that will be needed in future years. 9.1.1 “-ilities” influencing the system design

Acquisition Logistics focus on design requirements criteria, applicable to all system elements, and comprise (but is not limited to) the following list of engineering specializations: Affordability (Life Cycle Cost); Cost/System Effectiveness; Disposability (Recycling / Retirement); Maintainability; Packaging, Handling, Storage and Transportation (PHS&T); Producibility (Manufacturability); Reconfigurability (Flexibility / Standardization); Reliability; Security; Supportability (Serviceability); Survivability; and, Vulnerability – sometimes referred to as the “-ilities”. Figure 9-2 illustrates the relationship between ILS analysis activities.
Design/Logistics Requirements Supportability Parameters for Tradeoff Analysis Design • • • • Maintainability Maintenance Engineering Human Factors Safety Publications Operations & Maintenance Task Analysis

Specifications & Studies

Operations & Maintenance Requirements

Item R&M Characteristics Failure Modes & Effects Analysis Criticality & Maintainability Analysis

PHS&T Engineering Characteristics • Support Equipment

• Reliability & Maintainability Engineering - Packaging • Publications - Handling - Storage • Provisioning - Transportation • Supply Support • Cataloging • Facilities Engineering

Unit & Automated Test Programs

Support Equipment & Training Material Description

Facility Description

Skill Evaluation • Human Factors • Training

Support Item Identification & Application Data

Figure 9-2 Acquisition Logistics Activities The Availability, Reliability and Maintainability of a system are major drivers in the use of support resources and the related in-service costs. The probability that the system, when used under stated conditions, will operate satisfactorily is often expressed as Availability, which in turn, is dependent on the design for Maintainability and Reliability as well as the support arrangements during the Utilization and Support Stages. However, the term Availability in itself is imprecise as it may, or may not include logistics and administrative delay time, corrective and preventive maintenance. Therefore, we categorize Availability into: Inherent, Achieved, or Operational Availability. Reliability is concerned with the probability of the systemof-interest working when it should. Maintainability is concerned with keeping the system working and the ease of putting things right once they have gone wrong.1
Page 9.2 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

A summarizing denomination for Availability, Reliability, Maintainability and Supportability, may also be known as Dependability. The Dependability of a system describes its ability to fulfill the required performance under given conditions, taking degradation of performance due to failure and maintenance into consideration. Under certain conditions, it may be necessary to introduce redundancy into the design of a system to enhance the system’s reliability by providing two or more functional paths or physical objects in areas that are critical to successfully achieve specified Availability under given conditions. Likewise, it is important to eliminate single points of failure during the design of a system. In the discussion of the Øresund Bridge case, the survivability of the bridge in the event of ship collisions, and analysis of the design to ensure that traffic flow is not interrupted by accidents are two examples of ILS-related trade studies that were conducted. Another important factor to consider during the design of a system is the Packaging, Handling, Storage and Transportation (PHS&T), which includes all special provisions, materials and containers, and how the system or the parts thereof shall be handled, distributed and stored. In addition to the system itself, PHS&T also covers spares and consumables. Packaging can occasionally be more expensive than the product itself. Packaging requirements often have conflicting user objectives. A merchant wants the package to be so tough that a shoplifter cannot steal parts from inside the package while it is on the store shelf. The consumer wants the package to be easy to open when they get it home. Experience as a consumer suggests that the merchant won; many packages are almost impossible to open without using tools. Handling can be a source of failure. A warehouse worker can – and sometimes does – drive a folk-lift through a package. Airline baggage handlers are known to throw boxes onto carts, even though they are marked “fragile.” The storage environment can impose significant constraints on packaging and the system itself. Humidity, dust, and temperature are typical environmental concerns. In addition, warehousing places constraints on size and density of objects. Transportation is often overlooked when designing a system. Use of freight trains or cargo planes imposes limits on height, width, length and weight. For some systems, these constraints may force building multiple system elements that are not assembled until delivered to the operational site. For example after completing a new post office building in a major USA city at a cost of $140 million, the city engineers found that post office trucks would not fit into the enclosed loading dock. Similarly, food trucks that normally service Denver Airport’s restaurants are too high to fit under the elevated walkways that cross over their access roads.

Page 9.3 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Acquisition Logistics / ILS is important and relevant to systems engineers. As consumers themselves, systems engineers have experienced the frustration of unreliable systems. Those who have maintained systems at some point in their careers know that failure to acknowledge that humans maintain systems can cause significant problems in an operational environment. When availability gets too bad, systems are sometimes simply shut down in frustration, which can cause significant rework at considerable cost. The huge variety of Acquisition Logistics analyses are best carried out by subject matter experts, because they are familiar with the mathematics that underlie the techniques, with the tools that are available to support these analyses, and with the factors that influence the outcome of these analyses. 9.1.2 “-ilities” analysis methods

Within the fields of Reliability, Maintainability and Supportability Engineering there are several analyses that are performed iteratively and recursively as they are codependent on results of other analyses. This section briefly addresses some of the most useful and common analyses techniques. Failure Modes Effects and Criticality Analysis (FMECA) should be performed early enough to influence equipment design. The aim is to minimize maintenance requirements and thereby cost. FMECA indicates that potential failures may occur that either: cannot be removed through re-design but can be avoided through preventive maintenance; or have a non-critical impact and therefore can be allowed to occur, with subsequent rectification through corrective maintenance. FMECA is a means of recording and determining what functions the equipment is required to perform, and • How these functions could fail • Possible causes of the failures • Effects the failures would have on the equipment or system • The criticality of the failures Level of Repair Analysis is the process of evaluating system elements to first determine (in most cases from an economic point of view, only) if the element or system should be discarded or repaired. If repairing the item is feasible, establish where the repair should take place; e.g. at home, locally, or at the factory. This is expressed as an organizational level. This analysis is conducted throughout the system life cycle. The handling of a system element may change based on experiences from prior decisions. Logistic Support Analysis (LSA) / Supportability Analysis is a structured method of analyzing the support implications of system elements as they are being developed, with the aim of identifying features of the design that could result in excessive expense during the operational life of the system. Once identified, these items can be
Page 9.4 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

the subject of trade-offs to revise the design in order to reduce later costs. Once the design is more fully defined, during the late activities of the Development stage, the LSA can identify all the logistic resources necessary to support the equipment and the impact on the existing support infrastructure. LSA is only cost effective where it is likely to generate benefit in terms of a more supportable design or better defined support requirements and hence reduced life cycle cost. Reliability Centered Maintenance Analysis (RCM) can be performed to assess the most cost efficient preventive maintenance program for the system. RCM is best initiated very early in the Development Stage and evolves throughout the Production Stage. As such it can also successfully be introduced for systems already in operation, as it can be accomplished using a decision tree, leading the analyst through a logical sequence of the nature and frequency of applicable preventive maintenance tasks. Survivability Analysis is performed when items must perform critical functions in a hostile operational environment. Threats to be considered include conventional, electronic, nuclear, biological, chemical, and other weapons, and terrorism or sabotage, erratic human behavior, and harsh environmental conditions, such as ocean salinity. Critical survivability characteristics are identified assessed, and analyzed to evaluate their impact on system performance and effectiveness.2 A system is said to be survivable if it can fulfill its purpose in a timely manner, even in the presence of attacks or failures. Because of the severe consequences of failure, enterprises increasingly focus on system survivability as a key risk topic. The Spitfire (see Figure 9-3) was designed with an elliptical wing, giving greater speed and maneuverability (perhaps the most critical -ility of all for a warplane). This was at a price: 13000 man-hours per airframe. Willy Messerschmitt had optimized for speed and manufacturability: only 4000 man-hours; but the Bf 109 was no faster than the Spitfire, and was consistently out-turned by it. The elliptical wing had been considered, but rejected it as too difficult to manufacture. 3

Figure 9-3 The Spitfire: A perfect balance of -ilities? System Security Analysis identifies and evaluates system vulnerabilities to known or postulated security threats, and recommends means to eliminate the vulnerabilities or to at least reduce the susceptibility to compromise, damage, or destruction to an acceptable level of risk.
Page 9.5 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

9.2 Electromagnetic Compatibility Analysis
Electromagnetic compatibility (EMC) analysis is performed on electric or electronic items to ensure that they can perform in their intended electromagnetic environments. Analysis also ensures that items that are intentional radiators of radio frequency energy comply with commercial, governmental, and relevant international policies for radio frequency spectrum management and do not interfere with other signals – Electromagnetic interference (EMI). Even cable or speaker wire routing for home devices, such as a television, must consider EMI/EMC to achieve maximum performance and ensure safety of the users.

9.3 Environmental Impact Analysis
Europe, the USA and many other nations recognize regulations that control and restrict the environmental impact that a system may inflict on the biosphere. The ISO 14000 series, Environmental Management4 standards are an excellent resource for analysis and assessment methods for the protection of the environment. Failure to comply with environmental protection laws carries penalties and may result in the system not being approved for development. The issue is discussed in several references. 5, 6 The focus of environmental impact analysis is on potential deleterious effects of a proposed system’s development, construction, use, and disposal. All countries that have legally expressed their concern for the environment restrict the use of hazardous chemicals and components (e.g. mercury, lead, cadmium, chromium 6, and radioactive materials) with a potential to cause human disease or to threaten endangered species through loss of habitat or impaired reproduction. Concern extends over the full life cycle of the system to be developed, as is made evident by the European Union’s resolution to adopt within 2006 a legal restriction that system developers and their component suppliers retain lifetime liability for decommissioning systems that they build and sell. The Øresund Bridge is an example of how early analysis of potential environmental impacts ensures that measures are taken in the design and construction to protect the environment with positive results. Two key elements of the success of this initiative were the continual monitoring of the environmental status and the integration of the environmental concern into the requirements from the Owner. Disposal analysis is a significant analysis area within Environmental Impact Analysis. Traditional landfills for non-hazardous solid wastes have become less available within the large city areas and the disposal often involves transporting the refuse to distant landfills at considerable expense. The use of incineration for disposal is often vigorously opposed by local communities and citizen committees, and poses the problem of ash disposal; the ash from incinerators is sometimes classified as hazardous waste. Local communities and governments around the world have been formulating significant new policies to deal with the disposal of non-hazardous and hazardous wastes.

Page 9.6 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

One goal of the architecture design is to maximize the economic value of the systemelements residue and minimize the generation of waste materials destined for disposal. Because of the potential liability that accompanies the disposal of hazardous and radioactive materials the use of these materials is carefully reviewed and alternatives used where and whenever possible. The basic tenet for dealing with hazardous waste is the “womb-to-tomb” control and responsibility for preventing unauthorized release of the material to the environment. This may include designing for reuse, recycling, or transformation (e.g. composing, bio-degradation). In accordance with United States and European Union laws, system developers and component manufacturers must analyze the potential impacts of the systems that they construct, and must submit the results of that analysis to government authorities for review and approval to build the system. Failure to conduct and submit the environmental impact analysis can result in severe penalties for the system developer, and may result in an inability to build or to deploy the system. It is best when performing environmental impact analysis to employ subject matter experts who are experienced in conducting such assessments and submitting them for governmental review.

9.4 Human Factors
The Human Engineering or Human Systems Engineering effort affects every portion of the system that has a human-machine interface. It is essential to integrate human system factors into the design of items. The objective is to achieve a balance between system performance and cost by ensuring that the system design is compatible with the capabilities and limitations of the people who will operate, maintain, transport, supply, and control the system. It is essential from both ethical and liability perspectives that a concern for human operators, maintainers, and administrators is reflected in the design of systems. In situations where it is not possible to eliminate all risks by design, remediation steps can be identified and taught to enable people to reduce the risk of temporary or permanent injuries. Human Performance and Human Engineering Design Requirements During requirements analysis, requirements from a variety of sources and disciplines are analyzed to resolve conflicts. The human factors engineer is primarily responsible for two types of requirements; human performance requirements and human engineering design requirements. Human performance requirements include times and accuracies for tasks assigned to humans. The human factors engineer ensures that the proposed requirements are in fact achievable by the intended operators and users. The human engineer may in some cases, define the human performance requirements based on external requirements, specifications of other system elements, or the capabilities and limitations of the prospective operators and users. Human performance requirements are frequently derived from or at least bounded by other performance requirements within the system. The accuracy, response time, and
Page 9.7 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

other attributes of the operator tasks will affect similar attributes at the system level. The implementation of the requirements needs to be verified, and additional design decisions need to be made as the design progresses. The human engineering design requirements concern specific aspects of the hardware and software that are necessary to fit the operators and assist them in their assigned tasks. These requirements define what must be designed and constructed to permit the operators and users to interact with one another and the rest of the system. Such requirements commonly address topics that make the work area more effective (use of colors, button and knob design and layout, etc.). It is generally good practice to minimize characteristics that require extensive cognitive, physical, or sensory skills; require the performance of unnecessarily complex tasks; require tasks that result in frequent or critical errors. Ergonomics is the name of the engineering discipline concerned with the elimination of aspects of a system design that could cause temporary or permanent injury to people who operate, maintain, or otherwise use the system. This may include identification of steps people can take to reduce the risk of injury when operating, maintaining, or otherwise using the system after it is deployed. It is also a matter of ethics that systems do not present undue risks to the people who will use them. The ergonomics engineering process begins during the Concept Stage of the system life cycle and continues throughout the life of the system. Figure 9-4 identifies a three-step process to reduce the risk that a system will require costly rework in order to be authorized to deploy, or fail to be allowed to deploy at all; (1) identify the key design considerations and address them in step 3, during development of the system, (2) build the right team, and (3) manage the human factors engineering process.
START

Step 2

Form Vendor Partnerships

STOP

Get Approved Capital Budget

Form the “Right” Team

Simulate and Test Conceptual Designs And New Equipment

Train Employees and Supervisors

Establish Development And Communication Protocols

Identify Key Design Considerations1

Measure the Impact of New Designs

Step 1

Conduct Users Interviews

Record Their Comments

Step 3

Develop Better Engineering Solutions

NOTE Key design considerations may include system-user demographics; workspace considerations; workflows; equipment weights; powered equipment configurations; component materials, environmental exposures; special tools; and remedial human behaviors.
1

Figure 9-4 Ergonomics Engineering Minimizes Risks to System Stakeholders7
Page 9.8 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

The Occupational Safety and Health Agency has a website8 that features eight eTools that address ergonomics for a number of industries and occupations, including baggage handling, beverage delivery, computer workstations, grocery warehousing, health care, poultry processing and sewing. The design shown in Figure 9-5 may meet simple requirements for a teapot, but no human would want to use it. The author discusses many examples of implemented systems from calculator keypads with keys in a non-intuitive location to department store door handles where there is no indication where to push to open the door. The consistent issue in these instances is a lack of human factor considerations in the design. In many cases, styling and appearance are allowed to override good engineering, such as the car dash board design in which the identically shaped handles for brake release and hood release are placed side-by-side under the dash with no easily distinguished marking on either handle. Rental car drivers beware!

Figure 9-5 Unique Teapot Shown on Book Cover9

9.5 Mass Properties Engineering Analysis
Mass Properties Engineering10 (MPE) is done to assure that the system or system element has the appropriate mass properties to meet the requirements. The mass properties include weight, the location of center of gravity, inertia about the center of gravity, and product of the inertia about an axis. Typically, the initial sizing of the physical system is derived from other requirements,
Page 9.9 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

such as minimum payload, maximum operating weight, or human factors restrictions. Mass properties estimates are done at all stages of the system life cycle, based on the information that is available at the time, which may range from parametric equations to a three-dimensional product model, to actual inventories of the product in service. A risk assessment is done using techniques such as uncertainty analysis or Monte Carlo simulations to verify that the predicted mass properties of the system will meet the requirements, and that the system will operate with in its design limits. Validation is usually done at the end of the Production Stage to assure all parties that the delivered system meets the requirements, and then several times during the Utilization Stage to assure safety of the system, component or human operator. For a multi-billion dollar project such as oil platform or warship the MPE level of effort is significant. One trap in MPE is that design mangers may believe that their 3-D modeling tools can be used to estimate the mass properties of the system or system element. This is problematic because: (1) not all parts are modeled on the same schedule, (2) most parts are modeled neat, that is without such items as manufacturing tolerances, paint, insulation, fittings etc. which can add from 10 to 100% to the system weight. For example, the liquid in piping and tanks can weigh more than the structural tank or metallic piping that contain it. MPE usually includes a reasonableness check of all estimates by using an alternative method. The simplest method is to justify the change between the current estimate and any prior estimates for the same system, or the same system element on another project. Another approach is to use a simpler estimating method to repeat the estimate then justify any difference.

9.6 Modeling, Simulation, and Prototyping
Modeling, simulation, and prototyping used during architecture design can significantly reduce the risk of failure in the finished system. These techniques enable the development of complex and costly enabling systems, such as a flight simulator or a high-volume production line, which allow validation of the system’s concepts, or supports training of personnel in ways that would otherwise be cost prohibitive. Systems engineers use modeling and simulation on large complex projects to manage the risk of failure to meet system mission and performance requirements. This form of analysis is best conducted by subject matter experts who develop and validate the models, conduct the simulations, and analyze the results. 9.6.1 Modeling and Simulation

Modeling and simulation are an effective and usually efficient way to address technical risk on a project, especially a large project, because they represent a cost-effective means to find and fix problems before development is concluded and production begins. Modeling helps generate data in the domain of the analyst or reviewer, not available from existing sources, in a manner that is affordable and timely to support
Page 9.10 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

decision-making. The objective of modeling is to obtain information about the system before significant resources are committed to its design, development, construction, testing, or operation. Consequently, development, validation, and operation of the model must consume time and resources not exceeding the value of the information obtained through its use. A model is a mapping of the system-of-interest onto a simpler representation which approximates the behavior of the system-of-interest in selected areas. Models may be used to represent the system under development, the environment in which the system operates, or interactions with enabling systems and interfacing systems. Models can be used within most Systems Life Cycle Processes, such as the following. • Requirements Analysis: determine and assess impacts of candidate requirements • Architectural Design: evaluate candidate options • Verification: simulate the system’s environment and evaluate test data • Operations: simulate operations in advance of execution for planning and validation The result of modeling is to predict characteristics (performance, reliability, operations, and cost, etc.) across the spectrum of system attributes throughout its life cycle. The predictions are used to guide decisions about the system’s design, construction, and operation, or to verify its acceptability. Standard tools for all types of modeling are now available commercially for a wide range of system characteristics. 9.6.2 Types of Models

Models fall into one of two general categories – representations and simulations. Representations employ some logical or mathematical rule to convert a set of inputs to corresponding outputs with the same form of dependence as in the represented system, but do not mimic the structure of the system. Validity depends on showing, through analysis or empirical data, that the representation tracks the actual system in the region of concern. Simulations, on the other hand, mimic the detailed structure of the simulated system. They are composed of representations of system elements, connected in the same manner as in the actual system. The validity of a simulation depends on validity of the representations in it and the faithfulness of its architecture to the actual system. Usually the simulation is run through scenarios in the time domain to simulate the behavior of the real system. An example might be the simulation of a fluid control system made up of representations of the piping, pump, control valve, sensors, control circuit, and the fluid running through the system. The type of model selected depends on the particular characteristics of the system which are of interest. Generally, it focuses on some subset of the total system characteristics such as timing, process behavior, or various performance measures.
Page 9.11 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Representations and simulations may be made up of one or several of the following types: Physical, Graphical, Mathematical (deterministic), and Statistical. Physical models exist as tangible, real-world objects which are identical or similar in the relevant attributes to the actual system. The physical properties of the model are used to represent the corresponding properties of the actual system. Examples of physical models include: wind tunnel, testbed, and breadboard/brassboard. Graphical models are a mapping of the relevant attributes of the actual system onto a graphical entity with analogous attributes. The geometric or topological properties of the graphical entity are used to represent geometric properties, logical relationships, or process features of the actual system. Examples of graphical models include: functional flow block diagrams, N2 diagrams, logic trees, blueprints, schematics, and maps. Mathematical (deterministic) models use closed mathematical expressions or numerical methods to convert input data to outputs with the same functional dependence as the actual system. Mathematical equations in closed or open form are constructed to represent the system. The equations are solved using appropriate analytical or numerical methods to obtain a set of formulae or tabular data defining the predicted behavior of the system. Examples of mathematical models include: operational or production throughput analysis; thermal analysis; vibration analysis; load analysis; stress analysis; eigen value calculations; and linear programming. Statistical models are used to generate a probability distribution function for expected outcomes, given the input parameters and data. Statistical models are appropriate whenever truly random phenomena are involved as with reliability estimates, whenever there is uncertainty regarding the inputs such that the input is represented by a probability distribution, or whenever the collective effect of a large number of events may be approximated by a statistical distribution. Examples of statistical models include: Monte Carlo; logistical support; discrete and continuous models. A simulation can used to quickly examine a range of sizes and parameters, not just a “Point Design.” This will insure that the “best” solution is obtained – the system is the proper size throughout, with no choke points. Exercise the simulation using scenarios extracted from the concept of operations with inputs based on system requirements. Monte Carlo runs may be made to get averages and probability distributions. In addition to examining nominal conditions, non-nominal runs should also be made to establish system reactions or breakage when exposed to extraordinary (out-of-spec) conditions. 9.6.3 Prototyping

Prototyping is a technique that can significantly enhance the likelihood of providing a system that will meet the user’s need. In addition, a prototype can facilitate both the awareness and understanding of user needs and stakeholder requirements. This section will discuss briefly two types of prototyping; rapid and traditional.
Page 9.12 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Rapid prototyping is probably the easiest and one of the fastest ways to get user performance data and evaluate alternate concepts. A rapid prototype is a particular type of simulation quickly assembled from a menu of existing physical, graphical, or mathematical elements. Examples include tools such as laser lithography or computer simulation shells. They are frequently used to investigate form and fit, human-system interface, operations, or producibility considerations. Rapid prototypes are widely used, and are very useful, but, except in rare cases they are not “prototypes.” Traditional prototyping is a tool that can reduce risk or uncertainty. A partial prototype is used to verify critical elements of the system-of-interest. A full prototype is a complete representation of the system. It must be complete and accurate in the aspects of concern. Objective and quantitative data on performance times and error rates can be obtained from these higher fidelity interactive prototypes. The original use of a prototype was as the first of a kind from which all others were replicated. However, prototypes are not “the first draft” of production entities. Prototypes are intended to enhance learning and should be set aside when this purpose is achieved. Once the prototype is functioning, changes will often be made to improve performance, or reduce production costs. Thus, the production entity may require different behavior. The Maglev train system may be considered a prototype (in this case, proof-of-concept) for longer distance systems that will exhibit some but not all of the characteristics of the short line. Scientists and engineers are in a much better position to evaluate modifications that will be needed to create the next system.

9.7 Safety & Health Hazard Analysis
Safety and health hazards are hazards to the well-being of human operators, maintainers, administrators, or other users of a system. They are a major concern11 wherever hazardous materials are employed, such as the chemical industries, building enterprises, medical and radiological equipment supply concerns, energy production, and aviation and space. A systems engineer in one of the cited industries or any number of other industries that deal with hazardous materials, processes or human activities must be aware that subject matter experts are available to perform the analyses that can identify these hazards and their attendant risks, and can help identify means to eliminate or at least mitigate the risks to acceptable levels. Safety risks are associated with such processes as complex machinery used in a manufacturing plant, or high-temperature metals in a steel plant, or coal mining, or maintenance of deep sea platforms (among others); or with activities such as flying, or space travel or deep sea fishing (among others). While a safety decision tree can be a useful starting place to analyze processes and activities as well as physical components of systems, it is likely that the means to eliminate or reduce process and activity risks will be different. Construction of safety cages can protect people in a complex manufacturing work cell; “kill” buttons can be installed; and barriers can be constructed to make sure a person cannot fall (for example) into molten steel; specialized training
Page 9.13 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

and back-up safety equipment can available to (for example) divers that maintain off-shore oil rigs. The Therac-25 case illustrates the cost in human life that may result when adequate measures are not taken to build safety measures into potentially dangerous equipment. The specially designed windows for the Maglev train dampen the noise level that would otherwise present a hazard to passengers. When the hazards are caused by materials used within the system, it is crucially important to isolate the materials by some safe means as they are used in the system, and to plan for their eventual substitution by non-hazardous materials as material science advances. See Figure 9-6 for examples of protective clothing.

Figure 9-6 Protective clothing for Hazmat Level A and bird flu Many governments have regulations that mandate that all hazards to human safety and health be reduced as far as is possible, and that all safety and health hazards that can not be eliminated are mitigated by other than system means to reach acceptable levels of risk. This means avoiding wherever possible the use of hazardous materials, containing hazardous material that cannot be eliminated, and addressing the hazards associated with process and human activities that are required to support and maintain the system in its operational environment. It also means planning for the safe handling and disposal of hazardous materials, and including such effort in the life cycle cost models and cost forecasts for the system being developed.

9.8 Sustainment Engineering Analysis
Sustainment engineering helps ensure that a system continues to satisfy its objective over its intended lifetime. In that timeframe, system expectations will expand, the environments in which the system is operated will change, technology will evolve, and elements of the system may become unsupportable and need to be replaced. The desktop computing environment is a case in point. Today it is nearly impossible to find cables to support parallel port printers since the introduction of the Universal Serial Bus (USB).

Page 9.14 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Sustainment Engineering is an integrated effort designed to address industry needs regarding aging systems, and a need to maintain those systems in operation. A sustainment program may include re-engineering electronic and mechanical components to cope with parts obsolescence, the development of automated test equipment, and extending the life of aging systems through technology insertion enhancements, and proactive maintenance. These changes will have significant impact on ILS analyses.

9.9 Training Needs Analysis
Training needs analyses support the development of products and processes for training users and maintainers of a system. Training analysis includes the development of personnel capabilities and proficiencies to accomplish tasks at any point in the system life cycle to the level they are tasked. These analyses address initial and follow-on training necessary to execute required tasks associated with system use and maintenance. An effective training analysis begins with a thorough understanding of the concept documents and the requirements for the system-of-interest. A specific list of functions or tasks can be identified from these sources, and can be represented as learning objectives for operators, maintainers, administrators and other users of the system. The learning objectives then determine the design and development of the training modules and their means of delivery. Important considerations in the design of training include who, what, under what conditions and how well each user must be trained and what training will meet the objectives. Each of the required skills identified must be transformed into a positive learning experience and mapped onto an appropriate delivery mechanism. The formal classroom environment is rapidly being replaced with or augmented by simulators, computer-based-training, internet-based distance delivery, and in-systems electronic support, to name a few. Updates to training content use feedback from trainees after they have some experience to improve training effectiveness.

1 Blanchard, Ben and Wolter Fabrycky, Systems Engineering and Analysis, 3rd ed., Prentice Hall, 1998. Ch. 12-13 include complete discussions of the metrics and calculations for Availability, Reliability and Maintainability. 2 For discussion of Survivable Systems Analysis Methods see http://www.cert.org/archive/html/ analysis-method.html 3 Alexander, Ian, Systems Engineering: -ilities for Victory, Downloaded from http://easyweb.easynet. co.uk/iany/consultancy/systems•engineering/ilities•for•victory.htm 4 The ISO 14000 family of International Standards, www.iso.ch/iso/en/prods-services/otherpubs/ iso14000/index.html 5 Botkin, Daniel B. and Edward A. Keller, Environmental Science: Earth as a Living Planet, 2nd edition, New York: John Wiley Sons, 1998. Page 9.15 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

6 Mary Edwards, an Assistant Professor at the University of Wisconsin, Madison, developed a guide that includes a chapter on environmental impact analysis. It can be found at http://www.lic.wisc. edu/shapingdane/facilitation/all•resources/impacts/analysis•environmental.htm 7 Copyright© 2004 by Marsh Inc., www.marshriskconsulting.com/st/PDEv•C•371•SC•228135•NR•30 6•PI•233074.htm. 8 The OSHA web site can be found at www.osha.gov/SLTC/ergonomics/ 9 Norman, Donald A., The Design of Everyday Things, Doubleday, New York, NY 1988 10 See Recommended Practices from the Society of Allied Weight Engineers at www.sawe.org. 11 US Department of Labor, Job Hazard Analysis, Washington, DC: OSHA 3071, 2002 (available online at http://www.osha.gov/Publications/osha3071.pdf).

Page 9.16 of 16
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

10 Tailoring Overview
10.1 Introduction
Standards and handbooks are written to address generic practices that may, or may not, apply to a given organization or system-of-interest. Most are accompanied by a recommendation to adapt the processes and activities to the situation at hand. This adaptation is called tailoring. Throughout this handbook, advice has appeared about the formal use of these processes. Formality is highly dependent on the sophistication of the system, the organizations and the work to be accomplished. Tailoring scales the rigorous application of these processes to an appropriate level based on need and the system life cycle stage. For example, tighter assessment and control cycles are typical of earlier stages of the system life cycle. The principle behind tailoring is to establish an acceptable amount of process overhead committed to activities not otherwise directly related to the creation of the system. Oppressive overhead, with no visible value-added contributions, is demoralizing, and may result in a system that costs more than it is worth. Insufficient process results in uncoordinated human effort and thrashing 1 – which also adds cost. This chapter describes the process of tailoring this handbook to meet your needs.

10.2 Tailoring Process
Figure 10-1 is a notional graph for balancing formal process against the risk of cost and schedule overruns. As discussed in Chapter 2, insufficient systems engineering effort is generally accompanied by high risk. McConnell1 describes the improvements in efficiency realized by adding process. But as the graph illustrates, too much formal process also introduces high risk.

Page 10.1 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

or re c

ta mo

unt of

to

am

pr od u

co s

t ing rm rfo f pe to C os

ct/ s

S al m for

E

ys te

m

inte g

rity

Degree of formal systems engineering process used on the project

Figure 10-1 Tailoring requires balance between risk and process2 If too many or unnecessary processes are performed, increased cost and schedule impacts will occur with little or no added value to the integrity of the system. Tailoring processes is dynamic over the system life cycle depending on risk and the situational environment and should be continually monitored and adjusted as needed. Figure 10-2 is the Context Diagram for the Tailoring Process described in this chapter.
Controls
- Agreements - Enterprise Risk Strategy

Activities Inputs
-Enterprise environment -Organization environment -Supplier environment - Identify baseline tailoring criteria - Determine process relevance: to project cost, schedule, and risks to system integrity - Determine quality level of needed documentation - Determine extent of review, coordination, and decision methods

ro ce ss

tailoring

to t

h

ss ce pro e

P

Outputs
-Baseline tailored processes -Tailoring sensitivity

Enablers
- Organizational learning - Organizational maturity

Figure 10-2 Tailoring Process Context Diagram 10.2.1 Inputs to the Tailoring Process Tailoring is driven by the environment of the system life cycle stages. These environments determine the criteria for process tailoring:

Figure 10-2 Tailoring Process Context Diagram

Page 10.2 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

Formal systems engineering process followed

Risk of Schedule and Cost Overruns

No or adhoc systems engineering applied

d d c che o s Cost/ e ule k riis

C C t t/ P e ec roj Pr r ro

e ue sd sd

g gr

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Enterprise environment As indicated in chapter 6, the enterprise environment provides the context for most processes. Enterprise processes establish standards, policies, processes, goals, and objectives that are based on market environment and opportunities, governmental and other external laws and regulations, and enterprise strategies in response to these factors. The enterprise context includes the industry domain. Organization environment The work of an enterprise is conducted through organizations that execute strategy through programs and projects. Factors that influence tailoring at the organizational level include: • Stakeholders and customers – number of stakeholders, quality of working relationships • Project budget, schedule, and requirements • Risk tolerance • Complexity and precedence of the system Supplier environment Today’s systems are more often an integration of many systems and system elements to create an operational environment. This demands that cooperation transcends the boundaries of any one organization or enterprise. Harmony between multiple suppliers is often best maintained by agreeing to follow a set of consistent processes and standards. In such environments, consensus on a set of practices is helpful but adds complexity to the tailoring process. 10.2.2 Tailoring Process Activities Tailoring process activities should be conducted at least once for each stage of the system life cycle. Identify tailoring criteria for each stage – This activity establishes the criteria for including or excluding any process in the formal conduct of a given stage. Some essential processes, such as configuration management, build cumulatively throughout the system life cycle and may determine a set of permanent activities. Other processes, such as project planning, have a more limited range of applicability. Determine process relevance to cost, schedule, and risks – This activity analyzes the various environments, including their decision processes, relationships, and sensitivity to risks. The results define the appropriate tailoring of the review, decision and coordination methods for each process activity in each stage. Determine process relevance to system integrity – This activity analyzes the system features, intended environment, criticality of product/system use, reliability, and availability. It defines the appropriate tailoring of the process activities such as verification, qualification, level of analysis needed, and review and decision gate criteria.
Page 10.3 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Determine quality of documentation needed – This activity analyzes the support environment, system evolution, criticality of system functions, and internal and external interfaces. It defines the extent of detail needed in documentation for the project. Determine the extent of review, coordination and decision methods – This activity analyzes the project issues such as stakeholder diversity, extent of their involvement, nature of working relationships, (e.g. single, unified, or conflicting customer needs). These factors influence tailoring of formal reviews, coordination and decision methods, and communications to fit the situation. 10.2.3 Control of the Tailoring Process Elaboration of the control activities shown in Figure 10-2 are expanded upon in the following paragraphs. • Agreements – Agreements between enterprises create constraints on tailoring. • Stakeholder/Customer policy/legal – Issues of compliance to stakeholder, customer, and Enterprise policies, objectives, and legal requirements will sometime control the extent of tailoring. Certain documents and procedures may be mandatory in some situations. • Enterprise issues – The Enterprise environment controls the processes used in the development, determines who needs to approve certain products, defines what form and content the product takes, and what information can (or cannot) be shared between entities, both internal and external. • Contracting Requirements – Methods of procurement or intellectual property will influence the extent of tailoring of the agreement process activities. Tolerance for formal processes is influenced by the contracting method – fixed price, cost plus fixed fee, time and material. • Life cycle process/model used – The Life Cycle process/model used determines the extent and nature of System Engineering process application, such as the number of reviews, development iterations, or decision points. Enterprise Risk Strategy Each participating enterprise will bring their tolerance for risk to the tailoring process. Risk adverse enterprises may need more detailed information than what the system requires, in order to build confidence in the processes. In such instances, tailoring may introduce extra activities that are removed as the level of trust builds between parties.

Page 10.4 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

10.2.4 Enablers of the Tailoring Process The following paragraphs elaborate on the enablers shown in Figure 10-2. • Organizational learning – A key enabler in the tailoring process is experience with similar systems or familiarity between the participating parties. Beginning with less formal process structure for well-understood systems and established teams may yield significant cost savings without jeopardizing performance or quality. • Organizational maturity – Established and well documented processes that are used frequently among parties can contribute to successful outcomes. In such instances, it may be more disruptive and add cost to remove such a process. Consideration of the maturity of the participating parties, both individually and as a whole is an important enabler for tailoring. 10.2.5 Outputs from the Tailoring Process The following paragraphs elaborate on the output shown in Figure 10-2. • Baseline of tailored processes – At the end of the tailoring process a set of formal processes and activities are identified. This plan includes, but is not limited to, a documented set of tailored processes, identification of the system documentation required, the identified reviews, decision methods and criteria, and the analysis approach to be used. • Tailoring sensitivity – The tailoring plan, processes, documentation and analyses are sensitive to change and increased knowledge from experience. By identifying the assumptions and criteria for tailoring, the tailoring process can be conducted throughout the life cycle to optimize the use of formal processes.

10.3 Traps in Tailoring
The following discussion reveals traps in the tailoring process. 1) Reuse of a tailored baseline from another system without repeating the tailoring process It is fallacious to assume that previously tailored baselines are appropriate for all systems. Prior successes are not a guarantee of future success. There is something unique in each system. 2) Using all processes and activities, “just to be safe” The trap is that the each process carries an overhead cost. If this approach is taken, the quality of the system may actually degrade because of application of an inappropriate process. It can not be called tailoring if there is not a clear justification for the inclusion of every process in the plan.
Page 10.5 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

3) Using a pre-established tailored baseline Enterprise shortcuts to create templates of baselines that can be taken off the shelf and applied to work based on arbitrary categorizations such as high, medium, and low risk systems can be counter-productive. They carry the same hazards as traps #1 and #2 above. Tailoring is important because the emphasis is placed on the system and only processes that support attainment of the objective in terms of quality and performance should be retained. 4) Failure to include relevant stakeholders The tailoring process itself can become a unifying activity that establishes shard visions and understanding of the objectives. Suppliers, or other organizations, that are identified and not included in the process may feel disenfranchised with the result that they feel a lower level of commitment to the process baseline. When new parties are added, they should be familiarized with the baseline and asked to make constructive contributions.

1 McConnell, Steven (1998). “The Power of Process,” IEEE Computer, www.stevemcconnell.com/ articles/art09.htm 2 Adapted from a presentation given by Ken Salter, at the Jet Propulsion Laboratory in Pasadena CA. (2003)

Page 10.6 of 6
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

Appendix A

System Life Cycle Process N-squared chart per ISO/IEC 15288

Page Appendx-1 of 14

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

n-squared chart illustrating input-output dependencies between the System Life Cycle Processes 1 x x x x x x x x x x x x x 2 x x x x x x x 3 x x x x x x x x x 4 x x x x x x x 5 x x x x x x x 6 x x x x x x x x 7 x x x x x x x 8 x x x x x x x x 9 x x x x x x x 10 x x x x x x 11 x x x x x 12 x x x x x x x x x x x x x x x x 13 x x x x x x x x x 14 x x x x x x x x x 15 x x x x x x x x 16 x x x x x x x x 17 x x x x 18 x x x x 19 x x x x x x x x x x 20 x x x x x x x x x x 21 x x x x x x x x x x x x x x x x x x x 22 x x x x x x x x x x x x x x x x x x x x x x 23 x x x x x x x x

INCOSE Systems Engineering Handbook v. 3

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Cross reference between the numbers on the diagonal to the process name 1. stakeholder requirements definition 2. requirements analysis 3. architectural design 4. implementation 5. integration 6. verification 7. transition 8. validation 9. operation 10. maintenance 11. disposal 12. project planning 13. project assessment 14. project control 15. decision-making 16. risk management 17. configuration management 18. information management 19. enterprise management 20. investment management 21. system life cycle processes management 22. resource management 23. quality management How to read this N-squared chart: The outputs from lower-numbered processes that are input to higher-numbered processes are indicated by an x in the top diagonal. For an example, the shaded x at the intersection (1,8) reflects the passing of the validation criteria for stakeholder requirements into the Validation Process. The outputs from higher-numbered processes that are input to lower-numbered processes are indicated by an x in the lower diagonal. For example, the shaded x at the intersection of (21, 3) reflects that the Project processes and procedures identified by the SLC Processes Management Process influences the Architectural Design Process. Absence of an x in an intersection does not preclude tailoring to create a relationship between any two processes.
Page Appendx-2 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Appendix B: Acronym List
AIAA AP cm CM CMP COTS CSEP DOD DODAF DoE DOE ECP EMC EMI EN FMECA h IEC IEEE IID ILS IM IMP INCOSE IPAL ISO IT IV&V km LCC LSA m MIT MN American Institute of Aeronautics and Astronautics [USA] Application Protocol centimeter Configuration Management Configuration Management Plan Commercial Off-The-Shelf Certified Systems Engineering Professional Department of Defense Department of Defense Architecture Framework [USA] Department of Energy Design of Experiments Engineering Change Proposal Electromagnetic Compatibility Electromagnetic Interference Engineering Notice Failure Modes, Effects and Criticality Analysis hour International Engineering Consortium Institute of Electrical and Electronics Engineers Incremental & Iterative Development Integrated Logistics Support Information Management Information Management Plan International Council On System Engineering INCOSE Process Asset Library International Organization for Standardization Information Technology Integration, Verification and Validation kilometer Life Cycle Cost Logistic Support Analysis meter Massachusetts Institute of Technology Mega Newton
Page Appendx-3 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

MODAF MOE MOP MPE NASA OMG OSI PHS&T PLCS QA QMP R&D R&M RCM RMP ROI RVTM SE SEMP SEMS SEP SLC STEP SWOT SysML TP TPM TQM UML URL USA USB V&V WBS

Ministry of Defence Architecture Framework [UK] Measure of Effectiveness Measures of Performance Mass Properties Engineering National Aeronautics & Space Administration [USA] Object Management Group Open Systems Interconnection (for communication protocols) Packaging, Handling, Storage & Transportation Product Life Cycle Support Quality Assurance Quality Management Plan Research and Development Reliability and Maintainability Reliability Centered Maintenance Risk Management Plan Return on Investment Requirements Verification Traceability Matrix Systems Engineering; Systems Engineer System Engineering Management Plan, see SEP System Engineering Master Schedule Systems Engineering Plan System Life Cycle STandard for the Exchange of Product model data Strength-Weakness-Opportunity-Threat Systems Modeling Language Technical Product Technical Performance Measure Total Quality Management Unified Modeling Language Uniform Recourse Locator United States of America Universal Serial Bus Verification and Validation Work Breakdown Structure

Page Appendx-4 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Appendix C: Terms and definitions
The term and definitions in italic font style are from ISO/IEC 15288: 2002(E) – Systems engineering – System life cycle processes. Words not included in this glossary carry meanings consistent with dictionary definitions. acquirer the stakeholder that acquires or procures a product or service from a supplier a set of actions that consume time and resources and whose performance is necessary to achieve, or contribute to, the realization of one or more outcomes Technical and management activities conducted to ensure supportability implications are considered early and throughout the acquisition process to minimize support costs and to provide the user with the resources to sustain the system in the field. Project execution methods can be described on a continuum from “adaptive” to “predictive.” Agile methods exist on the “adaptive” side of this continuum, which is not the same as saying that agile methods are “unplanned” or “undisciplined.” the mutual acknowledgement of terms and conditions under which a working relationship is conducted a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures An expression of a system, product, function or process’ ability to achieve a specific objective under stated conditions. Commercial items that require no unique acquirer modifications or maintenance over the life cycle of the product to meet the needs of the procuring agency A characteristic of a system element, or project artifact, describing their maturity or perfomance. This version of the handbook provides a high level view of the process-of-interest. The diagram summarizes the process activities, and their inputs and outputs from/to external actors; some inputs are categorized as controls and enablers. A control governs the accomplishments of the process; an enabler is the means by which the process is performed.
Page Appendx-5 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

activity

Acquisition Logistics

Agile

agreement

baseline

Capability Commercial Off-TheShelf (COTS) Configuration

Context diagram

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Decision gate

A decision gate is an approval event (often associated with a review meeting). Entry and exit criteria established for each decision gate; continuation beyond the decision gate is contingent on the agreement of decision-makers. Detailed characteristics of the system-of interest that typically are identified during elicitation of stakeholder requirements, requirements analysis, trade studies or validation The boundary conditions, externally or internally imposed, for the system-of-interest within which the organization must remain when executing the processes during the concept and development stage a system that complements a system-of-interest during its life cycle stages but does not necessarily contribute directly to its function during operation The surroundings (natural or man-made) in which the system-of-interest is utilized and supported; or in which the system is being developed, produced or retired. the physical means or equipment for facilitating the performance of an action, e.g. buildings, instruments, tools The event in which any part of an item does not perform as required by its specification. The failure may occur at a value in excess of the minimum required in the specification, i.e., past design limits or beyond the margin of safety. that part of an organization with responsibility to acquire and to supply products and/or services according to agreements The systematic application of relevant information about human abilities, characteristics, behavior, motivation, and performance. It includes principles and applications in the areas of human related engineering, anthropometrics, ergonomics, job performance skills and aids, and human performance evaluation. The operational and support requirements a program must address (e.g., availability, maintainability, vulnerability, reliability, supportability, etc.). The total cost to the organization of acquisition and ownership of a system over its entire life. It includes all costs associated with the system and its use in the concept, development, production, utilization, support and retirement stages.

Derived Requirements

Design Constraints

enabling system

Environment

facility

Failure

enterprise

Human Factors

“-ilities”

Life Cycle Cost (LCC)

Page Appendx-6 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

life cycle model

a framework of processes and activities concerned with the life cycle, which also acts as a common reference for communication and understanding A metric used to quantify the performance of a system, product or process in terms that describe a measure to what degree the real objective is achieved. This graphical representation can be used to define the internal operational relationships or external interfaces of the system-of-interest. an individual who, or an organization that, contributes to the functionality of a system and draws on knowledge, skills and procedures to contribute the function a group of people and facilities with an arrangement of responsibilities, authorities and relationships [ISO 9000:2000] A quantitative measure characterizing a physical or functional attribute relating to the execution of a process, function, activity or task; Performance attributes include quantity (how many or how much), quality (how well), timeliness (how responsive, how frequent), and readiness (when, under which circumstances). set of interrelated or interacting activities which transforms inputs into outputs [ISO 9000:2000] an endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements A naïve realization of an idea or technology to demonstrate its feasibility A statement that identifies a system, product or process’ characteristic or constraint, which is unambiguous, can be verified, and is deemed necessary for stakeholder acceptability. an asset that is utilized or consumed during the execution of a process Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle a period within the life cycle of a system that relates to the state of the system description or the system itself

Measure of Effectiveness

N-squared diagrams

operator

organization

Performance

process

project

Proof-of-concept

Requirement

resource

Specialty engineering

stage

Page Appendx-7 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

stakeholder

a party having a right, share or claim in a system or in its possession of characteristics that meet that party’s needs and expectations an organization or an individual that enters into an agreement with the acquirer for the supply of a product or service a combination of interacting elements organized to achieve one or more stated purposes Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.[INCOSE] Systems Engineering effort integrates multiple disciplines and specialty groups into a set of activities that proceed from concept to production to operation. Systems Engineering considers both the business and the technical needs of all stakeholders with the goal of providing a quality system that meets their needs. Structured information describing how the system engineering effort, in form of tailored processes and activities, for one or more life cycle stages, will be managed and conducted in the organization for the actual project.

supplier system

Systems Engineering

Systems Engineering Effort

Systems Engineering Plan

system element system-of-interest system life cycle

a member of a set of elements that constitutes a system the system whose life cycle is under consideration the evolution with time of a system-of-interest from conception through to retirement
System of systems applies to a system-of-interest whose system elements are themselves systems; typically these entail large scale inter-disciplinary problems with multiple, heterogeneous, distributed systems.

System of systems

Page Appendx-8 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Tailoring

The manner in which any selected issue is addressed in a particular project. The organization may seek to minimize the time and efforts it takes to satisfy an identified need consistent with common sense, sound business management practice, applicable laws and regulations, and the time sensitive nature of the requirement itself. Tailoring may be applied to various aspects of the project, including project documentation, processes and activities performed in each life cycle stage, the time and scope of reviews, analysis, and decision-making consistent with all applicable statutory requirements. decision-making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders individual who or group that benefits from a system during its utilization confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled [ISO 9000: 2000] confirmation, through the provision of objective evidence, that specified requirements have been fulfilled [ISO 9000: 2000]

trade-off

user

validation

verification

Page Appendx-9 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

Page Appendx-10 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

Appendix D: Comment Form
Reviewed document: Name of submitter (first name & last name): Date Submitted: Contact info (email address): Type of submission (individual/group): Group name and number of contributors (if applicable) Insert Document Title John Doe III 21-Aug-2010 john.doe@anywhere.com group INCOSE XYZ WG

(See SAMPLE FORM on following two pages ➦)

Submit comments to TBD Working Group chair. Current WG chair will be listed at: http://www.incose.org/techcomm.html If this fails, comments may be sent to: info@incose.org (the INCOSE main office), which can relay to the appropriate WG, if so requested in the comment cover page.

Page Appendx-11 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

Please read examples carefully before providing your comments (and delete the examples provided). Specific Reference (e.g., Paragraph, Line, Figure, Table Issue, comment and rationale (rationale must make comment clearly evident and supportable) Proposed Changed/New Text – MANDATORY ENTRY – (must be substantial to increase the odds of acceptance) (delete third paragraph) Importance Rating (R=Required, I = Important, T=Think About for future version

INCOSE-TP-2003-002-03 June 2006

Commenter’s Name

Comment Sequence Number

Category (TH, TL, E, G)

Section Number (e.g. 3.4.2.1, no alpha)

John Doe 1 III Paragraph three Is the inclusion of the spiral model in the incremental life cycle stray text? The spiral model is more often associated with the evolutionary model (6.3.3) Find a different term for reviewing requirements to assure goodness: this is not requirements validation. Call the activity review, or ? Each technical requirement statement should be reviewed to ensure that it exhibits the following quality attributes:

E

6.3.2

Page Appendx-12 of 14

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

John Doe 2 III first line

TH

A5.2.e

R

INCOSE Systems Engineering Handbook v. 3

Please read examples carefully before providing your comments (and delete the examples provided). R

INCOSE-TP-2003-002-03 June 2006

John Doe 4 III

TH

A.5.5

Page Appendx-13 of 14

Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.

This section wants validation to be completed before integration. Usually validation is completed after integration. If this is written as intended, then more amplification is needed to clarify why validation should precede integration. These sound like they are notes for A.5.8; the validation notes section, and belong in that section. This section should address some notes tied directly to integration. (See the SAE TBD WG or INCOSE’s Jane Smith for some further thoughts on integration.)

This section wants validation to be completed before integration. Usually validation is completed after integration. If this is written as intended, then more amplification is needed to clarify why validation should precede integration. These sound like they are notes for A.5.8; the validation notes section, and belong in that section. This section should address some notes tied directly to integration. (See the SAE TBD WG or INCOSE’s Jane Smith for some further thoughts on integration.)

INCOSE Systems Engineering Handbook v. 3

INCOSE-TP-2003-002-03 June 2006

INCOSE Systems Engineering Handbook v. 3

THIS PAGE INTENTIONALLY LEFT BLANK

Page Appendx-14 of 14
Copyright © 2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover.