システムエンジニアリング

システム エンジニアリングは、エンジニアリングとエンジニアリング管理の学際的な分野であり、ライフサイクル全体にわたって複雑なシステムを設計、統合、管理する方法に焦点を当てています。システム エンジニアリングは、その中核として、システム思考の原則を利用してこの知識体系を整理します。このような取り組みの個々の成果であるエンジニアリング システムは、相乗効果を発揮して集合的に有用な機能を実行するコンポーネントの組み合わせとして定義できます。

要件エンジニアリング、信頼性、ロジスティクス、さまざまなチームの調整、テストと評価、保守性、およびシステムの設計、開発、実装、最終的な廃止を成功させるために必要な他の多くの分野(別名「スキル」)などの問題は、大規模または複雑なプロジェクトを扱う場合にはさらに困難になります。システム エンジニアリングは、このようなプロジェクトにおける作業プロセス、最適化方法、およびリスク管理ツールを扱います。これは、産業工学、生産システム工学、プロセス システム工学、機械工学、製造工学、生産工学、制御工学、ソフトウェア工学、電気工学、サイバネティクス、航空宇宙工学、組織研究、土木工学、プロジェクト管理などの技術的かつ人間中心の分野と重複しています。システム エンジニアリングは、プロジェクトまたはシステムのすべての可能性のある側面が考慮され、全体に統合されることを保証します。

システム エンジニアリング プロセスは、製造プロセスとはまったく異なる発見プロセスです。製造プロセスは、最小限のコストと時間で高品質の出力を実現する反復的なアクティビティに重点を置いています。システム エンジニアリング プロセスは、解決する必要がある実際の問題を発見し、発生する可能性が最も高い、または最も影響が大きい障害を特定することから始める必要があります。システム エンジニアリングには、これらの問題に対する解決策を見つけることが含まれます。

システムエンジニアリングという用語は、1940年代のベル電話研究所にまで遡ることができます。 ^[1]複雑なエンジニアリングプロジェクトでは、システム全体の特性と各部分の特性の合計が大きく異なる可能性があるため、システム全体の特性を識別して操作する必要性から、さまざまな業界、特に米国軍のシステムを開発する業界がこの分野を適用するようになりました。^{[2] [3]}

システムを改善するために設計の進化に頼ることができなくなり、既存のツールが増大する需要を満たすのに十分でなくなったとき、複雑さに直接対処する新しい方法が開発され始めました。^[4]システムエンジニアリングの継続的な進化は、新しい方法とモデリング技術の開発と特定で構成されています。これらの方法は、エンジニアリングシステムが複雑化するにつれて、設計と開発管理をよりよく理解するのに役立ちます。USL 、UML、QFD、IDEFなど、システムエンジニアリングのコンテキストでよく使用される一般的なツールは、この時代に開発されました。

1990年、システムエンジニアリングの専門団体である全米システムエンジニアリング評議会（NCOSE）が、米国の多くの企業や組織の代表者によって設立されました。NCOSEは、システムエンジニアリングの実践と教育の改善の必要性に対応するために設立されました。米国外のシステムエンジニアの関与が高まった結果、1995年に組織の名前が国際システムエンジニアリング評議会（INCOSE）に変更されました。 ^[5]いくつかの国の学校では、システムエンジニアリングの大学院プログラムが提供されており、現役のエンジニア向けの継続教育オプションも用意されています。^[6]

システム エンジニアリングは、アプローチのみを意味し、最近ではエンジニアリングの分野を意味します。システム エンジニアリングの教育の目的は、さまざまなアプローチを単純に形式化し、そうすることで、他のエンジニアリング分野で見られるものと同様の新しい方法と研究の機会を特定することです。アプローチとして、システム エンジニアリングは全体的かつ学際的な性質を持っています。

エンジニアリングの従来の範囲には、物理​​システムの構想、設計、開発、生産、運用が含まれます。システム エンジニアリングは、本来の意味で、この範囲に含まれます。この意味での「システム エンジニアリング」とは、エンジニアリングの概念の構築を指します。

「システムエンジニア」という用語の使用は、時間の経過とともに進化し、「システム」とエンジニアリングプロセスのより広範で総合的な概念を包含するようになりました。この定義の進化は継続的な論争の対象となっており、^[13]この用語は、より狭い範囲とより広い範囲の両方に適用され続けています。

従来のシステムエンジニアリングは、古典的な意味でのエンジニアリングの一分野、つまり宇宙船や航空機などの物理システムにのみ適用されるものとして考えられていました。最近では、システムエンジニアリングは、特に人間がシステムの不可欠な構成要素と見なされるようになったときに、より広い意味を持つようになりました。たとえば、ピーター・チェックランドは、「エンジニアリング」は「一般的な意味で解釈できます。会議や政治的合意をエンジニアリングすることができます」と述べて、システムエンジニアリングのより広い意味を捉えています。^{[14] : 10}

システムエンジニアリングのより広い範囲に合わせて、システムエンジニアリング知識体系（SEBoK）^[15]では3つのタイプのシステムエンジニアリングを定義しています。

• 製品システム エンジニアリング (PSE) は、ハードウェアとソフトウェアで構成される物理システムの設計に重点を置いた従来のシステム エンジニアリングです。
• エンタープライズ システム エンジニアリング (ESE) は、エンタープライズ、つまり組織または組織の組み合わせをシステムとして捉える考え方です。
• サービスシステムエンジニアリング（SSE）は、サービスシステムのエンジニアリングに関係しています。チェックランドは、サービスシステムを、別のシステムにサービスを提供するシステムと定義しています。^[14]ほとんどの土木インフラシステムはサービスシステムです。

システム エンジニアリングは、開発サイクルの早い段階で顧客のニーズと必要な機能を分析して引​​き出し、要件を文書化し、その後、システム ライフサイクルという完全な問題を考慮しながら設計の統合とシステムの検証を進めることに重点を置いています。これには、関係するすべての利害関係者を完全に理解することが含まれます。Oliver らは、システム エンジニアリング プロセスは次のように分解できると主張しています。

• システムエンジニアリングの技術プロセス
• システムエンジニアリング管理プロセス

オリバーのモデルでは、管理プロセスの目標はライフサイクルにおける技術的取り組みを整理することであり、技術プロセスには利用可能な情報の評価、有効性尺度の定義、動作モデルの作成、構造モデルの作成、トレードオフ分析の実行、および順次ビルド＆テスト計画の作成が含まれます。^[16]

業界では用途に応じていくつかのモデルが使用されていますが、それらはすべて、上記のさまざまな段階の関係を特定し、フィードバックを組み込むことを目的としています。そのようなモデルの例としては、ウォーターフォールモデルやVEEモデル（Vモデルとも呼ばれる）などがあります。^[17]

システム開発には、さまざまな技術分野からの貢献が求められることが多い。^[18]システムエンジニアリングは、開発作業のシステム（全体論的）視点を提供することで、すべての技術的貢献者を統一されたチーム作業にまとめ、構想から生産、運用、場合によっては終了や廃棄まで進む構造化された開発プロセスを形成するのに役立つ。取得においては、全体論的統合分野が貢献を組み合わせ、コスト、スケジュール、パフォーマンスのトレードオフのバランスを取りながら、アイテムのライフサイクル全体にわたって許容できるリスクレベルを維持する。^[19]

この考え方は教育プログラムでもよく取り入れられており、システム工学のコースでは他の工学部の教員が教えており、学際的な環境を作り出すのに役立っています。^{[20] [21]}

システム エンジニアリングの必要性は、システムとプロジェクトの複雑さが増すにつれて高まり、コンポーネントの摩擦の可能性が飛躍的に増加し、設計の信頼性が低下しました。この文脈で言えば、複雑さにはエンジニアリング システムだけでなく、人間によるデータの論理的編成も含まれます。同時に、システムは、サイズの増大、および設計に関係するデータ、変数、またはフィールドの数の増加により、より複雑になる可能性があります。国際宇宙ステーションは、そのようなシステムの例です。

よりスマートな制御アルゴリズムの開発、マイクロプロセッサの設計、環境システムの分析もシステムエンジニアリングの範疇に含まれる。システムエンジニアリングは、システムの複雑さをよりよく理解し管理するためのツールや方法の使用を推奨する。これらのツールの例をいくつか挙げると、次のとおりである。^[22]

• システムアーキテクチャ
• システムモデル、モデリング、シミュレーション
• 数学的最適化
• システムダイナミクス
• システム分析
• 統計分析
• 信頼性工学
• 意思決定

工学システムへの学際的アプローチは、システム コンポーネントの動作やコンポーネント間の相互作用が必ずしもすぐに明確に定義または理解されるとは限らないため、本質的に複雑です。このようなシステムとサブシステム、およびそれらの相互作用を定義して特徴付けることは、システム エンジニアリングの目標の 1 つです。そうすることで、ユーザー、オペレーター、マーケティング組織からの非公式な要件と技術仕様の間に存在するギャップがうまく埋められます。

^[23]

システム工学の原則（全体論、創発的行動、境界など）は、システム思考があらゆるレベルで採用されていれば、複雑なシステムであろうとなかろうと、あらゆるシステムに適用できます。^[24]防衛・航空宇宙産業以外にも、多くの情報技術系企業、ソフトウェア開発会社、電子・通信分野の産業では、チームの一員としてシステムエンジニアを必要としています。^[25]

INCOSE Systems Engineering Center of Excellence (SECOE) の分析によると、システムエンジニアリングに費やされる最適な労力は、プロジェクト全体の労力の約 15～20% です。^[26]同時に、システムエンジニアリングは本質的にコスト削減などの利点をもたらすことが研究で示されています。^[26]しかし、最近まで、さまざまな業界を網羅したより大規模な定量調査は行われていませんでした。システムエンジニアリングの有効性を判断し、その利点を定量化するための研究が進行中です。^{[27] [28]}

システム工学では、システムとその相互作用に関する仮定や理論を検証するためにモデリングとシミュレーションの使用を推奨しています。 ^{[29] [30]}

安全工学では、起こりうる故障を早期に検出できる手法が設計プロセスに組み込まれています。同時に、プロジェクトの開始時に下した決定の結果が明確に理解されていない場合、システムの寿命の後半に多大な影響を及ぼす可能性があり、これらの問題を検討して重要な決定を下すのは現代のシステム エンジニアの仕事です。今日の決定が、システムが最初に考案されてから数年または数十年後に稼働するときにまだ有効であることを保証する手法はありません。ただし、システム エンジニアリングのプロセスをサポートする手法はあります。例としては、ソフト システム方法論、ジェイ ライト フォレスターのシステム ダイナミクス法、統一モデリング言語(UML) などがあり、これらはすべて現在、エンジニアリングの意思決定プロセスをサポートするために調査、評価、開発されています。

システム工学の教育は、通常の工学コースの延長として見られることが多く、^[31]工学部の学生は伝統的な工学分野（航空宇宙工学、土木工学、電気工学、機械工学、製造工学、産業工学、化学工学など）の基礎的な背景に加えて、システムエンジニアとして効果的な実践的な現実世界での経験が必要であるという業界の姿勢を反映しています。 システム工学を明確に扱う大学の学部プログラムの数は増えていますが、まだ一般的ではなく、そのような内容を含む学位は、ほとんどの場合、産業工学のBSとして提示されています。 通常、プログラム（単独または学際的な研究と組み合わせて）は、学術的および専門的なトラックの両方で大学院レベルから提供され、 MS / MEngまたはPh.D. / EngDの学位が授与されます。

INCOSEは、スティーブンス工科大学のシステム工学研究センターと共同で、適切に認定された機関の世界中の学術プログラムのディレクトリを定期的に更新しています。^[6] 2017年現在、システム工学の学部および大学院プログラム400以上を提供する北米の140以上の大学が掲載されています。この分野が独自のサブ分野として広く組織的に認知されるようになったのはごく最近のことで、同じ出版物の2009年版では、そのような学校とプログラムの数はそれぞれわずか80と165と報告されています。

システム エンジニアリングの教育は、システム中心またはドメイン中心として捉えることができます。

• システム中心のプログラムでは、システム エンジニアリングを別の分野として扱い、ほとんどのコースではシステム エンジニアリングの原則と実践に重点を置いて教えられます。
• ドメイン中心のプログラムでは、エンジニアリングの別の主要分野と組み合わせて実践できるオプションとしてシステム エンジニアリングが提供されます。

これら2つのパターンは、コアエンジニアに求められる深みをもって学際的なプロジェクトを監督できるシステムエンジニアを育成することを目指しています。^[32]

システムエンジニアリングツールとは、プロジェクトや製品に対してシステムエンジニアリングを実行するのに役立つ戦略、手順、およびテクニックです。これらのツールの目的は、データベース管理、グラフィカルブラウジング、シミュレーション、推論、ドキュメント作成、ニュートラルインポート/エクスポートなど多岐にわたります。^[33]

システム エンジニアリングの分野では、 システムの定義は数多くあります。以下に、権威ある定義をいくつか示します。

• ANSI / EIA -632-1999：「最終製品と特定の目的を達成するための製品の集合体。」^[34]
• DAUシステムエンジニアリングの基礎：「明示されたニーズや目的を満たす機能を提供する、人、製品、プロセスの統合された複合体。」^[35]
• IEEE Std 1220-1998：「関連性があり、その動作が顧客/運用上のニーズを満たし、製品のライフサイクルの持続性を提供する要素とプロセスの集合または配置。」^[36]
• INCOSEシステムエンジニアリングハンドブック：「現実世界で事前に定義された動作を示し、個別にはその動作を示さない異種の部分と、コンポーネントおよび/またはサブシステムの統合された構成で構成される均質なエンティティ。」^[37]
• INCOSE: 「システムとは、さまざまな要素が集まって構成または集合体となり、その要素だけでは得られない結果を生み出すものです。要素またはパーツには、人、ハードウェア、ソフトウェア、設備、ポリシー、文書など、システムレベルの結果を生み出すために必要なすべてのものが含まれます。結果には、システムレベルの品質、プロパティ、特性、機能、動作、パフォーマンスが含まれます。パーツが個別に提供する価値を超えて、システム全体によって付加される価値は、主にパーツ間の関係、つまりパーツがどのように相互接続されているかによって生み出されます。」^[38]
• ISO/IEC 15288:2008：「1つ以上の目的を達成するために編成された相互作用する要素の組み合わせ。」^[39]
• NASAシステムエンジニアリングハンドブック：「（1）ニーズを満たす能力を生み出すために一緒に機能する要素の組み合わせ。要素には、この目的のために必要なすべてのハードウェア、ソフトウェア、機器、施設、人員、プロセス、および手順が含まれます。（2）システムを構成する最終製品（運用機能を実行する）とイネーブリング製品（運用最終製品にライフサイクルサポートサービスを提供する）」^[40]

システムエンジニアリングプロセスには、製品を定義するために必要なすべての創造的、手動的、技術的な活動が含まれており、システム定義を製品の製造と展開に十分な詳細なシステム設計仕様に変換するために実行する必要があります。システムの設計と開発は、それぞれ異なる定義を持つ4つの段階に分けることができます。^[41]

• タスク定義（情報定義）
• 概念段階（基本的な定義）
• 設計段階（形成的定義）
• 実装段階（製造定義）

ツールは、その用途に応じて、システムエンジニアリングプロセスのさまざまな段階で使用されます。^[23]

モデルはシステム工学において重要かつ多様な役割を果たします。モデルは次のようないくつかの方法で定義できます。^[42]

• 現実世界に関する特定の質問に答えるために設計された現実の抽象化
• 現実世界のプロセスまたは構造の模倣、類似物、または表現。
• 意思決定者を支援するための概念的、数学的、または物理的なツール。

これらの定義は、システム設計の検証に使用される物理工学モデルだけでなく、機能フローブロック図などの概略モデルやトレード研究プロセスで使用される数学的（定量的）モデルも含むほど広範囲にわたります。このセクションでは、最後のモデルに焦点を当てます。^[42]

トレード研究で数学モデルや図表を使用する主な理由は、既知または推定可能な一連の量からシステムの有効性、パフォーマンスまたは技術的属性、およびコストの推定値を提供することです。通常、これらすべての結果変数を提供するには、個別のモデルのコレクションが必要です。数学モデルの中心となるのは、入力と出力の間の意味のある定量的関係のセットです。これらの関係は、構成量を合計して合計値を取得するのと同じくらい単純なものから、重力場における宇宙船の軌道を記述する一連の微分方程式のように複雑なものまであります。理想的には、関係は相関関係だけでなく因果関係も表します。^[42]さらに、システムエンジニアリング活動を成功させる鍵は、これらのモデルを効率的かつ効果的に管理し、システムをシミュレートする方法でもあります。しかし、さまざまな領域では、システムエンジニアリングのモデリングとシミュレーションの問題が繰り返し発生することが多く、新しい進歩は、「モデリングとシミュレーションに基づくシステムエンジニアリング」というタイトルで、異なる科学コミュニティとエンジニアリングコミュニティの間で方法を相互に刺激することを目指しています。^{[43] [ページが必要]}

当初、システムエンジニアの主な目的が複雑な問題を理解することである場合、システムの機能要件とデータ要件を伝えるためにシステムのグラフィック表現が使用されます。^[44]一般的なグラフィック表現には次のものがあります。

• 機能フローブロック図(FFBD)
• モデルベース設計
• データフロー図(DFD)
• N2チャート
• IDEF0図
• ユースケース図
• シーケンス図
• ブロック図
• シグナルフローグラフ
• USL 関数マップと型マップ
• エンタープライズアーキテクチャフレームワーク

グラフィカルな表現は、機能、データ、またはインターフェースを通じて、システムのさまざまなサブシステムまたは部分を関連付けます。上記の方法のいずれかまたはそれぞれが、業界の要件に基づいて使用されます。たとえば、システム間のインターフェースが重要な場合は、N2 チャートが使用されることがあります。設計フェーズの一部は、システムの 構造モデルと動作モデルを作成することです。

要件が理解されると、今度はシステム エンジニアがそれらを改良し、他のエンジニアとともに仕事に最適なテクノロジを決定する責任があります。この時点でトレード スタディから始めて、システム エンジニアリングでは、最適なオプションを決定するために重み付けされた選択を使用することを推奨しています。決定マトリックス、または Pugh 法は、重要なすべての基準を考慮しながらこの選択を行う 1 つの方法です (別の方法はQFD )。トレード スタディは次に設計に情報を提供し、設計は (要件を変更せずに) システムのグラフィック表現に再び影響します。SE プロセスでは、この段階は実行可能なソリューションが見つかるまで実行される反復的なステップを表します。決定マトリックスは、統計分析、信頼性分析、システム ダイナミクス (フィードバック制御)、最適化手法などの手法を使用して作成されることがよくあります。

システムモデリング言語（SysML）は、システムエンジニアリングアプリケーションに使用されるモデリング言語であり、広範囲の複雑なシステムの仕様、分析、設計、検証、検証をサポートします。^[45]

ライフサイクルモデリング言語（LML）は、システムエンジニアリング用に設計されたオープンスタンダードのモデリング言語であり、概念、利用、サポート、廃止の各段階というライフサイクル全体をサポートします。^[46]

多くの関連分野は、システム エンジニアリングと密接に結びついていると考えられます。次の分野は、システム エンジニアリングを独自の存在として発展させることに貢献してきました。

認知システム工学（CSE）は、人間機械システムまたは社会技術システムの記述と分析に対する特定のアプローチです。^{[47] CSEの3つの主なテーマは、人間が複雑性に対処する方法、}人工物の使用によって作業が達成される方法、および人間機械システムと社会技術システムを共同認知システムとして記述できる方法です。 CSEは当初から認知工学とも呼ばれる科学分野として認められています。 特に、共同認知システム（JCS）の概念は、複雑な社会技術システムをさまざまな解像度で記述する方法を理解する方法として広く使用されるようになりました。 CSEの20年以上の経験は広範囲に渡って説明されています。^{[48] [49]}

システム エンジニアリングと同様に、防衛および航空宇宙産業で実践されている構成管理は、広範なシステム レベルの実践です。この分野はシステム エンジニアリングのタスクと類似しています。システム エンジニアリングは要件の開発、開発項目への割り当て、検証を扱い、構成管理は要件の取得、開発項目への追跡可能性、および開発項目の監査を扱い、システム エンジニアリングやテストおよび検証エンジニアリングが客観的なテストを通じて証明した目的の機能が達成されていることを確認します。

制御工学と、その制御システムの設計および実装は、ほぼすべての業界で広く使用されており、システム工学の大きなサブフィールドです。自動車のクルーズコントロールと弾道ミサイルの誘導システムは、2 つの例です。制御システム理論は、解空間の調査と制御プロセスの分析のための新しい方法の開発を含む、応用数学の活発な分野です。

産業工学は、人、お金、知識、情報、設備、エネルギー、材料、プロセスの統合システムの開発、改善、実装、評価に関わる工学の一分野です。産業工学は、工学分析と統合の原理と方法、数学、物理学、社会科学、および工学分析と設計の原理と方法を活用して、このようなシステムから得られる結果を指定、予測、評価します。

生産システム工学（PSE）は、生産システムの基本原理を明らかにし、それを分析、継続的な改善、設計に活用することを目的とした、エンジニアリングの新しい分野です。^[50]

インターフェース設計とその仕様は、システムの各部分が、必要に応じてシステムの他の部分や外部システムと接続し、相互運用できるようにすることに関係しています。インターフェース設計には、システム インターフェースが、予約済みの配線、プラグ スペース、コマンド コード、通信プロトコルのビットなどの機械的、電気的、論理的インターフェースを含む新しい機能を受け入れることができるようにすることも含まれます。これは拡張性として知られています。ヒューマン コンピューター インタラクション(HCI) またはヒューマン マシン インターフェース (HMI) は、インターフェース設計のもう 1 つの側面であり、現代のシステム エンジニアリングの重要な側面です。システム エンジニアリングの原則は、ローカル エリア ネットワークとワイド エリア ネットワークの通信プロトコルの設計に適用されます。

メカトロニクス工学は、システム工学と同様に、動的なシステムモデリングを使用して具体的な構造を表現する、学際的な工学分野です。その点では、システム工学とほとんど区別がつきませんが、大きな一般化や関係性ではなく、より細かい詳細に重点を置く点が異なります。そのため、両方の分野は、実践の方法論ではなく、プロジェクトの範囲によって区別されます。

オペレーションズリサーチはシステムエンジニアリングをサポートします。簡単に言えば、オペレーションズリサーチは複数の制約の下でのプロセスの最適化に関係しています。^{[51] [52]}

パフォーマンス エンジニアリングは、システムがその寿命全体にわたって顧客の期待に応えるパフォーマンスを保証する分野です。パフォーマンスは通常、特定の操作が実行される速度、または単位時間内にそのような操作をいくつか実行する能力として定義されます。実行待ちの操作が限られたシステム容量によって抑制されると、パフォーマンスが低下することがあります。たとえば、パケット交換ネットワークのパフォーマンスは、エンドツーエンドのパケット転送遅延、または 1 時間に交換されるパケット数によって特徴付けられます。高性能システムの設計では分析またはシミュレーション モデリングが使用されますが、高性能実装の提供には徹底したパフォーマンス テストが含まれます。パフォーマンス エンジニアリングは、そのツールとプロセスにおいて 統計、待ち行列理論、および確率論に大きく依存しています。

プログラム管理(またはプロジェクト管理) はシステム エンジニアリングと多くの類似点がありますが、システム エンジニアリングのエンジニアリングの起源よりも幅広い基盤を持っています。プロジェクト管理は、プログラム管理とシステム エンジニアリングの両方に密接に関連しています。どちらも、管理プロセスにおける学際的な懸念事項を評価するためのエンジニアリング サポート ツールとしてスケジューリングを含んでいます。特に、リソース、パフォーマンス機能、およびタスクの期間に対するリスクの直接的な関係、またはタスク間の依存関係とシステム ライフサイクル全体にわたる影響は、システム エンジニアリングの懸念事項です。

提案エンジニアリングとは、科学的および数学的原理を応用して、コスト効率の高い提案開発システムを設計、構築、運用することです。基本的に、提案エンジニアリングでは、「システム エンジニアリング プロセス」を使用して、コスト効率の高い提案を作成し、提案が成功する可能性を高めます。

信頼性工学は、システムがその寿命を通じて顧客の信頼性に対する期待を満たすことを保証する分野です (つまり、予想よりも頻繁に故障しない)。故障の予測に次いで、故障の予防も同様に重要です。信頼性工学は、システムのあらゆる側面に適用されます。信頼性工学は、保守性、可用性(信頼性またはRAMSと呼ばれることもあります)、および統合ロジスティクス サポートと密接に関連しています。信頼性工学は、故障モード影響解析(FMEA) やハザード フォールト ツリー解析などの安全工学、およびセキュリティ工学において常に重要な要素です。

リスク管理、つまりリスクを評価して対処する実践は、システムエンジニアリングの学際的な部分の 1 つです。開発、取得、または運用活動において、コスト、スケジュール、およびパフォーマンス機能とのトレードオフにリスクを含めると、システムライフサイクルにわたって、システムエンジニアリングの学際的な技術的アプローチを必要とする、ドメイン間のスケジュールと要件管理に対するトレーサビリティと評価の反復的な複雑な構成管理が必要になります。システムエンジニアリングでは、リスク管理が、全体的な取り組みに統合されたリスク管理の構造化されたプロセスを定義、調整、実装、および監視します。^[53]

安全工学の技術は、安全性に重大な障害が発生する可能性を最小限に抑えるために、専門外のエンジニアが複雑なシステムを設計する際に適用できます。「システム安全工学」機能は、新しい設計における「安全上の危険」を特定するのに役立ち、システムから設計できない (潜在的に) 危険な状態の影響を「緩和」する技術を支援する場合があります。

セキュリティ エンジニアリングは、制御システムの設計、信頼性、安全性、およびシステム エンジニアリングの実践コミュニティを統合する学際的な分野と見なすことができます。セキュリティ エンジニアリングには、システム ユーザー、システム ターゲット、その他 (人、オブジェクト、プロセス) の 認証などのサブ専門分野が含まれる場合があります。

ソフトウェア エンジニアリングは、その始まりから、現代​​のシステム エンジニアリングの実践の形成に貢献してきました。大規模なソフトウェア集約型システムの複雑さの処理に使用される手法は、システム エンジニアリングのツール、方法、プロセスの形成と再形成に大きな影響を与えてきました。

• マドハヴァン、グル（2024年）。『Wicked Problems: How to Engineering a Better World』。ニューヨーク：WW Norton & Company。ISBN：978-0-393-65146-1
• Blockley, D. Godfrey, P. 『Doing it Differently: Systems for Rethinking Infrastructure』、第 2 版、ICE Publications、ロンドン、2017 年。
• Buede, DM、Miller, WD 『システムのエンジニアリング設計：モデルと方法』、第 3 版、John Wiley and Sons、2016 年。
• Chestnut, H. ,システムエンジニアリング手法. Wiley, 1967.
• Gianni, D. et al. (eds.),モデリングおよびシミュレーションベースのシステムエンジニアリングハンドブック、CRC Press、2014年、CRC
• Goode, HH、Robert E. Machol 『システムエンジニアリング：大規模システムの設計入門』、McGraw-Hill、1957年。
• Hitchins, D. (1997) World Class Systems Engineering、hitchins.net より。
• Lienig, J.、Bruemmer, H.、「電子システム設計の基礎」、Springer、2017年ISBN 978-3-319-55839-4。 
• マラクーティ、B. (2013)。「複数の目的を持つオペレーションと生産システム」ジョン・ワイリー・アンド・サンズ。ISBN 978-1-118-58537-5 
• MITRE、MITRE システム エンジニアリング ガイド(pdf)
• NASA (2007)システムエンジニアリングハンドブック、NASA/SP-2007-6105 Rev1、2007年12月。
• NASA (2013) NASA システムエンジニアリングプロセスと要件 2016年12月27日アーカイブWayback Machine NPR 7123.1B、2013年4月 NASA 手順要件
• Oliver, DW, et al. 「モデルとオブジェクトによる複雑システムのエンジニアリング」McGraw-Hill、1997年。
• Parnell, GS、Driscoll, PJ、Henderson, DL (編)、『Decision Making in Systems Engineering and Management』、第 2 版、Hoboken、NJ: Wiley、2011 年。これは工学部の学部生向けの教科書です。
• Ramo, S.、St.Clair, RK 『システムアプローチ：科学と実践的常識の結合による複雑な問題への新たな解決策』、アナハイム、カリフォルニア州：KNI、Inc、1998 年。
• Sage, AP ,システムエンジニアリング。Wiley IEEE、1992年。ISBN 0-471-53639-3。 
• Sage, AP、Olson, SR、「システムエンジニアリングにおけるモデリングとシミュレーション」、2001 年。
• SEBOK.org、システム エンジニアリング知識体系 (SEBoK)
• シャーモン、D. システムコストエンジニアリング、Gower Publishing、2009
• Shishko、R.、他。 (2005) NASA システム エンジニアリング ハンドブック。 NASA 航空宇宙情報センター、2005 年。
• Stevens, R.、他「システムエンジニアリング：複雑性への対処」Prentice Hall、1998年。
• アメリカ空軍、SMC システム エンジニアリング入門およびハンドブック、2004 年
• 米国国防総省システム管理大学 (2001)システムエンジニアリングの基礎。国防調達大学出版局、2001 年
• 米国国防総省の国防総省調達契約へのシステムエンジニアリングの統合に関するガイド 2017年8月29日アーカイブ、Wayback Machine、2006年
• 米国国防総省 MIL-STD-499 システムエンジニアリング管理

• ICSEngホームページ
• INCOSEホームページ
• INCOSE UK ホームページ
• PPI SE ゴールドマインのホームページ
• システムエンジニアリング知識体系
• システムエンジニアリングツール
• AcqNotes DoD システム エンジニアリングの概要
• NDIA システムエンジニアリング部門