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

概要と動機

システムズエンジニアリングとは、複雑なシステム全体を端から端まで設計し、そのすべての部品が協調して本物のニーズを満たすようにする規律です。部品にはソフトウェアよりはるかに多くのものが含まれます。現代的なシステムは通常、ソフトウェア、ハードウェア、人、データ、プロセスを組み合わせ、乱雑な現実世界で動かなければなりません。システムズエンジニアリングは、システムの全寿命にわたって、これらすべてを整合させ続けます。

これはソフトウェアアーキテクチャとは異なります。ソフトウェアアーキテクチャ(3.1章)は、ソフトウェアのコンポーネントがどう構造化され、互いにどう話すかを決めます。システムズエンジニアリングは、一段上に位置します。システム全体が何をしなければならないか、ソフトウェアとハードウェアと人間のオペレーターが仕事をどう分担するか、そして完成したものが動くことをどう証明するかを問います。その専門的な拠り所は、国際システムズエンジニアリング協議会であるINCOSEで、その中核の標準は、システムの寿命のためのプロセスを定義するISO/IEC/IEEE 15288です。

これが大きな企業と政府のプログラムにとって重要なのは、そのシステムが大きく、長寿命で、安全が重要またはミッションが重要だからです。防衛のプラットフォーム、航空交通のシステム、衛星群は、特注のハードウェア、サードパーティの部品、組み込みとクラウドのソフトウェア、人間のオペレーターを混ぜ合わせ、単一のチームが全体を頭に収めることはできません。また、しばしばシステムのシステムを築きます。それぞれ単独で有用な多くの独立したシステムが、より大きな能力を提供するために協調しなければなりません。

本章は、ソフトウェア要求(2.8章)、アーキテクチャの基礎(3.1章)、ソフトウェアのモデルと手法(2.12章)、相互運用性とオープン標準(3.8章)、プロジェクト管理(10.6章)につながります。

主要原則

部品ではなく、全体を設計する。 システムは全体として成功または失敗するので、一つのサブシステムを孤立して最適化することは、全体を悪化させえます。
ライフサイクルに従う。 システムは最初のコンセプトから最終的な退役まで寿命を持ちます。構築だけでなく、そのすべてのために計画します。
あらゆる要求をトレースする。 すべてのニーズは、要求、設計要素、テストに対応づけられるべきです。トレースできなければ、証明できません。
インターフェースを意図して管理する。 ほとんどの失敗は部品の間の境界で起こるので、インターフェースには明示的なオーナーシップと管理が値します。
検証と妥当性確認を別々に行う。 正しく作ること(検証)と正しいものを作ること(妥当性確認)は別の問いで、両方の答えが必要です。
創発的な振る舞いを予期する。 部品を組み合わせると、どの単一の部品も示さない振る舞いが生まれます。その一部は要点であり、一部は厄介な驚きです。
ハードウェアとソフトウェアを共同設計する。 両方が特注のとき、一方の決定が他方を制約するので、一緒に計画します。

推奨事項

システムのライフサイクル全体を管理する

システムには全体の寿命があるものとして扱い、各段階を計画します。一般的なライフサイクルは次のように進みます。コンセプト(ニーズを理解し選択肢を探る)、要求(システムが何をしなければならないかを正確に述べる)、設計(アーキテクチャと部品を決める)、統合(部品を一緒にする)、検証と妥当性確認(動くこととそれが正しいシステムであることを証明する)、運用(それを動かし保守する)、退役(データと廃棄を含め、安全に廃止する)。ISO/IEC/IEEE 15288が、そのためのプロセスの枠組みを与えます。段階は硬直したウォーターフォールである必要はありません。反復し、プロトタイプを作り、増分を届けられます。要点は、早期の計画がしばしば無視する高価な後の段階を含め、あらゆる段階を意識的に扱うことです。

ステークホルダーのニーズを捉え、トレーサビリティを伴って要求を割り当てる

システムを気にかける人々から始めます。ユーザー、オペレーター、所有者、規制当局、公衆。彼らのニーズを平易な言葉で集め、それから具体的でテスト可能な、設計された要求に変えます(2.8章を参照)。次に要求の割り当てが来ます。各システムレベルの要求を特定のサブシステムに割り当て、どの部品がそれを満たす責任を負うかがわかるようにします。トレーサビリティマトリクス、つまり各ニーズを、その要求、それを満たす設計要素、それを検証するテストにリンクする、生きた記録を保ちます。それにより、いつでも、すべてのニーズがカバーされ、すべての部品に存在理由があることを証明できます。

インターフェースを明示的に管理する

インターフェースは部品が出会う場所であり、システムが最もよく壊れる場所です。インターフェースは、物理的なコネクタ、ネットワークプロトコル、データ形式、人間の手順でありえます。それぞれについて、インターフェース管理文書(ICD)、つまり二つの部品がどう接続し情報を交換するかの正確な合意された仕様を書きます。すべてのインターフェースに、それぞれの側で明確な所有者を与えます。一回限りのコネクタではなく、共有された公開仕様に頼ることは統合をはるかに容易にし、それが3.8章の相互運用性の論拠です。できる所では、インターフェースを早く固定してください。後の変更は、それに触れるすべての部品に波及するからです。

統合し、それから検証し妥当性を確認する

システム統合は、サブシステムを動く全体に組み合わせます。通常は一度にではなく段階的に行い、問題がまだ小さいうちに見つけます。統合の後に検証と妥当性確認(V&V)が来ます。二つの別個のチェックです。検証は問います。システムを正しく作ったか、つまり規定された要求を満たしているか。検査、解析、実演、テストを通じて検証します。妥当性確認は問います。正しいシステムを作ったか、つまりステークホルダーの本物のニーズを実際の使用で満たしているか。システムは、検証に合格しても(仕様を満たしている)、妥当性確認に失敗しうる(仕様が間違っていた)。両方を早期に計画し、そもそも検証できるように要求とインターフェースを書きます。

モデルベースシステムズエンジニアリングを採用する

従来のシステムズエンジニアリングは、同期がずれていく文書の山を生みました。モデルベースシステムズエンジニアリング(MBSE)は、その山を、ビューとレポートが生成される、システムの単一の共有された形式モデルに置き換えます。一般的なモデリング言語はSysML(システムモデリング言語)で、システムの要求、構造、振る舞い、制約を記述するグラフィカルな言語です。すべてが一つの接続されたモデルに存在するので、変更はあらゆる所を更新し、トレーサビリティは手作業の追跡ではなくクエリになります。MBSEは、2.12章のモデリングの考え方につながります。段階的に採用し、共有モデルが最も速く見返りをもたらす、最もリスクの高い部分から始めてください。

創発的な振る舞いにシステム思考を適用する

システム思考を実践します。部品を一つずつではなく、全体と部品の間の関係について推論する。これが創発的な振る舞い、つまり部品が組み合わさったときにのみ現れ、どの単一の部品も示さない性質を予期する方法です。良い創発はしばしばシステムの目的です(ドローンの群れが、どの単一のドローンにもできない領域をカバーする)。悪い創発は驚きの失敗です(二つの安全なサブシステムが相互作用して危険な状態を作る)。モデル化したことのないシステムから、創発をテストで取り除くことはできないので、運用の前にそれを見つけるために、シミュレーションと構造化されたハザード分析を使います。

ハードウェアとソフトウェアを共同設計する

システムが特注のハードウェアを含むとき、ハードウェア/ソフトウェア共同設計と呼ばれる実践で、ハードウェアとソフトウェアを一緒に設計します。決定は互いを拘束します。ハードウェアは、ソフトウェアが収まらなければならないタイミング、メモリ、電力の限度を設定し、ソフトウェアのニーズは、ハードウェアが提供しなければならないものを形づくります。ハードウェアの長いリードタイムも、スケジュールを駆動します。どの機能がハードウェアにあり、どれがソフトウェアにあるかを早期に決め、制約が現れるにつれてその分割を見直します。

トレードオフ: 長所と短所

アプローチ	長所	短所 / コスト
完全なシステムズエンジニアリングの厳密さ	後の驚きが少ない、強いトレーサビリティ、より安全で監査可能	高い前もってのコスト、遅い開始、重いプロセス
軽量 / ソフトウェアのみのアプローチ	小さなスコープでは速く、安く、柔軟	大きな複数分野のシステムで破綻する。インターフェースと創発を見逃す
モデルベース(MBSE)	信頼できる唯一の情報源、容易なトレーサビリティ、一貫したビュー	ツールと研修のコスト、文化の変化、学習曲線
文書ベースのシステムズエンジニアリング	馴染みがある、ツールのコストが低い、共有しやすい	文書の同期がずれる。トレーサビリティは手作業でエラーが起きやすい

中心的なトレードオフは、厳密さと速度です。完全なシステムズエンジニアリングは、労力をコンセプト、要求、インターフェースの仕事に前倒しにします。その労力は、大きく、長寿命で、安全が重要なシステムでは何倍にもなって元が取れます。運用で見つかった欠陥は、要求で見つかった同じ欠陥の何千倍ものコストがかかりえるからです。小さく短命でソフトウェアのみの製品では、その厳密さは過剰です。プロセスの重さを、システムの規模、寿命、リスクに合わせてください。失敗モードは、30年動き、現実世界のリスクを負うシステムに、使い捨てのプロジェクトの習慣を適用することです。

チームで議論すべき問い

仕様が求めたとおりに作りながら、それでも間違ったシステムを出荷したのはどこで、何がそれを捉えたでしょうか。 検証(正しく作ったか)と妥当性確認(正しいものを作ったか)は異なる問いに答え、システムは、仕様そのものが間違っていたために、すべての検証テストに合格しながら妥当性確認に失敗しえます。大きなプログラムでは、二つが「テスト」に潰され、修正が要求の変更の何千倍もかかる遅い時期まで、誰も本物のオペレーターのニーズに対して妥当性確認しません。納品されたシステムが要求を満たしながら実際のニーズを逃した過去の例を持ち込み、どんな妥当性確認の活動(本物のオペレーターによるシミュレーション、現場での早期のプロトタイプ)が、それをもっと早く表面化させたかを問ってください。両方のチェックを最初から計画し、そもそも検証できるように要求とインターフェースを書きます。その区別が、乏しいレビューの労力をどこに使うかを決めます。
システムが運用に入る後ではなく前に、悪い創発的な振る舞いをどう探しますか。 安全なサブシステムを組み合わせると、どの単一の部品も示さない危険な状態を作りえて、モデル化したことのないシステムから創発をテストで取り除くことはできません。安全が重要またはミッションが重要なプログラムでは、驚きの相互作用は、誰かを傷つけたりミッションを失敗させたりするものなので、実際の運用の前に見つけなければなりません。全体をモデル化する方法(シミュレーション、構造化されたハザード分析、相互作用を捉えるSysMLモデル)を持ち込み、サブシステムをまたぐ振る舞いのどれを実際に探索し、どれを想定で片付けたかを問ってください。良い創発はしばしばシステムの目的で、それに向けて設計する価値があり、悪い創発は、それに対してエンジニアリングしなければならない失敗です。唯一の統合戦略が、部品を配線して何が起こるかを見ることなら、本番で創発を発見する計画です。
リードタイムの長いハードウェアの決定はいつ固定されなければならず、その期限はソフトウェアのスケジュールをどう駆動しますか。 システムが特注のハードウェアを含むとき、両者は共同設計されなければなりません。チップはソフトウェアが収まるタイミング、メモリ、電力の上限を設定し、ハードウェアのリードタイムはしばしばスケジュール全体を支配します。ソフトウェアを分離可能として扱うチームは局所的に最適化し、それから統合でハードウェアの制約に衝突し、何か月も失います。ハードウェアのリードタイムと、ハードウェア/ソフトウェアの機能分割が決まらなければならない日付を持ち込み、盲目的に固定するのではなく、制約が現れるにつれてその分割を見直してください。どの機能がシリコンにあり、どれがソフトウェアにあるかを早く決めるほど、高価な逆転に直面することが減ります。両者の間のインターフェースには、インターフェース管理文書と、それぞれの側の所有者が値します。そこでの後の変更は、それに触れるすべてに波及するからです。
一つのステークホルダーのニーズを、要求、設計要素、それを証明するテストまで端から端までトレースでき、そのリンクを生かしておくのは誰ですか。トレーサビリティは、いつでも、すべてのニーズがカバーされ、すべての部品に存在理由があることを示せるようにするものですが、大きなプログラムでは、誰も所有しなくなった瞬間にマトリクスは腐ります。相反する引力は本物です。エンジニアはトレーサビリティを官僚的なオーバーヘッドとして体験し、手で保守されるマトリクスは設計が変わるより速く古くなります。現在のプログラムから本物の糸を一本持ち込み、部屋で端から端までたどってみてください。名前のあるステークホルダーのニーズから、割り当てられた要求、それを満たすサブシステムと設計要素、検証テストまで。そして連鎖がどこで切れるかを記録します。誰がマトリクスを所有し、トレーサビリティが手作業の追跡ではなくクエリになるモデルに置くべきかを決めてください。企業や政府のプログラムでは、マトリクスは規制当局や調達当局が求める監査の成果物でもあるので、切れた連鎖はエンジニアリングを遅くするだけでなく、認証や支払いを止めえます。
モデルベースのアプローチは、そのツールと文化のコストに見合いますか。それとも、高価な死蔵品になりますか。 文書ベースのシステムズエンジニアリングは馴染みがあり、ツールのコストが安いですが、文書の同期がずれ、トレーサビリティは手作業でエラーが起きやすい。MBSEはその山を、ツール、研修、本物の文化の変化を代償に、接続された一つのモデルに置き換えます。どちらの極端も高価です。大きな複数分野のプログラムでMBSEを飛ばせば統合の驚きで払い、モデルを最新に保つ規律なしに採用すれば、モデルがないより悪い死蔵品に腐ります。ツールの成熟度、チームの誰が実際にSysMLモデルを作成し保守できるか、共有モデルが最も速く見返りをもたらす、パイロットにできるリスクの高い一つのサブシステムについて、誠実な読みを持ち込んでください。組織全体に一度に義務づけるのではなく、段階的に決めます。多くの供給者を持つ大きな企業や政府のプログラムでは、共有モデルが、そうでなければ古い文書を交換する契約者の間で、要求、インターフェース、テストを一貫して保つ唯一の現実的な方法かを量ってください。
ライフサイクル計画は運用と退役に真剣に資金を出していますか。それとも、静かに稼働開始で止まっていますか。 長寿命のシステムの総コストを支配する段階、何十年も動かすことと安全に廃止することは、出荷する圧力が常にあるため、早期の計画が日常的に無視するものです。相反する考慮は、お金と注意がこれらの後の段階が最も遠く感じられるまさにそのときに最も乏しいため、運用、保守、データ移行、廃棄が、高価でリスクの高い慌ただしさになるまで先送りされることです。現在のライフサイクル計画を持ち込み、運用と退役に所有者、予算、終了基準が名指しされているか、それとも稼働開始をゴールとして扱っているかを確認してください。寿命の終わりにデータとハードウェアがどうなるか、その間の何年もの保守を誰が払うかを問ってください。20年か30年動いて、それから公衆の精査のもとで退役しなければならない企業や政府のシステムでは、計画されていない廃止は、規制、環境、記録の保持の義務に違反しうるので、退役は最初のコンセプトレビューから計画と予算に属します。

セクター別の視点

スタートアップ。 小さなチームは正式なシステムズエンジニアリングのプログラムを運営できず、試みるべきでもありませんが、ファームウェア、アプリ、クラウドを三つの別のプロジェクトではなく、一つのシステムとして扱うことはできます。部品がどう話すかを固定する短いインターフェース文書を一つ書き、各顧客のニーズをそれを満たす部品にリンクする単純な表を保ち、重いプロセスは省きます。最も乏しい資源はエンジニアリングの注意なので、境界での間違った想定が現場で製品を静かに壊す所にだけ、トレーサビリティの労力を使います。

小規模事業者。 専任のシステムズエンジニアはおらず予算も厳しいので、自分で設計し検証しなければならない特注の統合ではなく、公開された標準と買ったサブシステムに頼ってください。永遠に所有しなければならない特注のコネクタなしに部品がはまるよう、明確なインターフェース仕様を公開するベンダーを好みます。作るか買うかの選択を、製品の寿命にわたって現実的に管理し検証できるインターフェースを軸に枠づけ、残りは買います。

大企業。 規模では、問題は多くのチームと供給者にわたる一貫性です。ISO/IEC/IEEE 15288に沿った共有のライフサイクルプロセス、すべての供給者の境界のインターフェース管理文書と名前のある所有者、そして一つのコンポーネントの変更がプログラム全体の慌ただしさを引き起こさないよう、端から端までのトレーサビリティ。共有モデルが、契約者にわたって要求、インターフェース、テストを整合させる所で、MBSEに投資します。検証と妥当性確認が別個であり、すべての要求が責任ある部品に割り当てられるよう、プロセスを統治します。

政府。 調達規則、透明性、公的な説明責任があらゆる選択を形づくります。契約でシステムズエンジニアリングのプロセス、トレーサビリティ、V&Vの証拠を指定し、供給者に、監査できるインターフェース管理文書とライフサイクルの成果物の納品を求め、安全とミッションの妥当性確認は、実際の切り替えの前に、本物のオペレーターを伴う独立したレビューのために取っておきます。運用と退役を明示的に計画し資金を出します。公共のプログラムは、安全な廃止と記録の保持を含む、ライフサイクル全体に説明責任を負うからです。

事例

スタートアップ。 接続されたセンサーを作る4人のハードウェアスタートアップは、正式なシステムズエンジニアリングのプログラムを負担できませんが、それでも製品を三つの別のプロジェクトではなく、ファームウェア、モバイルアプリ、クラウドバックエンドの一つのシステムとして扱います。デバイス、アプリ、サーバーがどう話すか(メッセージ形式、単位、エラーコード)を固定する短いインターフェース文書を一つ書き、各顧客のニーズをそれを満たす部品にリンクする単純な表を保ちます。より安いセンサーチップがファームウェアの変更を強いるとき、その共有のインターフェースがすぐに、アプリとバックエンドが何を調整しなければならないかを示すので、部品の入れ替えが現場で製品を静かに壊すことはありません。

大企業。 世界的な自動車メーカーが、新しい電気自動車のプラットフォームを築きます。ソフトウェア(バッテリー管理、運転支援、インフォテインメント)、ハードウェア(モーター、センサー、チップ)、人的要因のシステムに加え、それぞれがサブシステムを納める多くの供給者。会社はシステムズエンジニアリングのプログラムを運営します。ステークホルダーのニーズが割り当てられた要求に流れ、すべての供給者のインターフェースにはインターフェース管理文書があり、SysMLモデルが要求を設計とテストに結びつけます。バッテリーセルの供給者が部品を変更するとき、トレーサビリティのモデルが、どの要求、インターフェース、テストが影響を受けるかを正確に示すので、変更はプログラム全体の慌ただしさを引き起こす代わりに封じ込められます。

政府。 国の航空航法当局が、レーダー、管制官の作業端末、通信、ソフトウェアにまたがり、24時間稼働する、安全が重要なシステムのシステムである航空交通管理システムをモダナイズします。プログラムは、ライフサイクル全体にわたってISO/IEC/IEEE 15288に従います。検証は各サブシステムが仕様を満たすことを証明し、本物の管制官を伴うシミュレーションによる妥当性確認は、実際の航空機が依存する前に、統合されたシステムが安全な運用を支えることを証明します。厳格なV&Vにより、当局は、各ステップでフォールバックを備えて段階的に切り替えられます。ここでは、テストされていない創発的な失敗は、公共の安全に関わる事象だからです。

ビジネスケース: 動機、ROI、TCO

動機は、欠陥が見つかるのが遅いほど、指数関数的に高価になることです。要求の段階で捉えられた要求の誤りは、直すのにほぼコストがかかりません。運用で捉えられた同じ誤りは何千倍ものコストがかかりえ、安全が重要なシステムでは、命、リコール、失敗したミッションのコストがかかりえます。システムズエンジニアリングは、欠陥の発見を安い早期の段階に移します。

投資収益(ROI、費やしたコストに対して得られた価値)については、見返りは避けられた手戻り、少ない統合の失敗、超過せずにスケジュールと予算に収まるプログラムです。大きなプログラムについての業界の研究は、強いシステムズエンジニアリングの労力が、より小さな超過と相関することを繰り返し見出しています。総所有コスト(TCO、システムを作り、動かし、退役させる生涯のコスト全体)については、システムズエンジニアリングは、長期のコストを支配するが場当たり的なプロジェクトが無視する、運用と退役の段階を考慮します。保守性、インターフェース、廃棄を最初から設計することは、システムが運用に費やす数十年のコストを下げます。プロジェクト管理(10.6章)を参照してください。

アンチパターンと落とし穴

反復のない大きな事前設計。 ライフサイクルを硬直した一方通行のウォーターフォールとして扱い、すべてを築いた後でようやく要求が間違っていたと知ること。
トレーサビリティのない要求。 誰も設計やテストにリンクしない要求の山で、カバレッジを証明することも、どの部品も正当化することもできないこと。
インターフェースの無視。 サブシステムがただはまると想定し、それから誰も所有しなかった境界の不一致に、統合で何か月も失うこと。
妥当性確認のない検証。 システムが仕様を満たすことを証明しながら、仕様が本物のニーズに合っているかを確かめず、間違ったシステムを出荷すること。
ソフトウェアを別物として扱う。 ソフトウェアチームが、ハードウェアの制約、タイミング、人間のオペレーターを無視して局所的に最適化すること。
死蔵品としてのMBSE。 モデルを一度築き、同期がずれて腐らせ、モデルがないより悪くすること。
退役計画の省略。 廃止、データ移行、廃棄の計画がなく、寿命の終わりが高価でリスクの高い慌ただしさになること。

成熟度モデル

レベル1: 開始。 システムズエンジニアリングは場当たり的で反応的です。要求は散らばった文書にあり、インターフェースは統合で発見され、検証はたまたま行われるテストです。大きなプログラムは定期的に超過し、チームを遅れて驚かせます。

レベル2: 発展。 基本的な実践が主要なプログラムにあります。要求は捉えられベースライン化され、主要なインターフェースには管理文書があり、検証計画があります。実践はチーム間で一貫せず、共有の方法ではなく個人に依存します。

レベル3: 標準化。 システムズエンジニアリングは、ISO/IEC/IEEE 15288に沿った、文書化された組織全体の規律で、チーム間で徹底されています。ライフサイクル全体が計画され、トレーサビリティは端から端まで維持され、インターフェースは正式に管理され、検証と妥当性確認は別個で計画されます。MBSEは複雑なプログラムで使われます。

レベル4: 管理。 システムズエンジニアリングは、データで測定され制御されています。組織はベースラインに対して指標を追跡します。要求の変動性とトレーサビリティのカバレッジ、統合で見つかったインターフェースの欠陥、検証と妥当性確認の合格率、ライフサイクルの段階ごとの欠陥の漏れ(各段階から何件の欠陥が漏れて、後でより高いコストで捉えられるか)。レビューはこれらの数字でプログラムを舵取りし、閾値は事後の消火活動ではなく是正行動を引き起こします。

レベル5: オーケストレーション。 システムズエンジニアリングは、組織全体で継続的に改善され統合されています。生きたMBSEのモデルが信頼できる唯一の情報源で、トレーサビリティは自動化され、シミュレーションが構築の前に創発的な振る舞いを予測し、過去のプログラムからの指標が次に反映されます。ハードウェアとソフトウェアは当然のこととして共同設計され、プロセスはプログラム、供給者、リスクの変化に応じて適応します。

議論のためのアイデア

あなたの組織で、システムズエンジニアリングとソフトウェアアーキテクチャの境界線はどこにあり、その間の空間を誰が所有していますか。
最大のプログラムで、一つのステークホルダーのニーズを、それを検証するテストまで端から端までトレースできますか。できないなら、何が必要ですか。
最近の失敗のうち、インターフェースで起きたのはどれで、誰がそれを所有していましたか。
MBSEは見返りをもたらしますか。それとも、あなたの文化とツールでは高価な死蔵品になりますか。
ライフサイクル計画は運用と退役に真剣に取り組んでいますか。それとも静かに稼働開始で止まっていますか。

要点

システムズエンジニアリングは、システム全体(ソフトウェア、ハードウェア、人、プロセス)を端から端まで設計するもので、ソフトウェアアーキテクチャとは別物です。
コンセプトから要求、設計、統合、V&V、運用、退役まで、ライフサイクル全体を計画します。
あらゆるニーズを要求、設計要素、テストまでトレースし、各要求を責任ある部品に割り当てます。
境界こそシステムが壊れる場所なので、明確なオーナーシップと管理文書でインターフェースを明示的に管理します。
検証(正しく作った)と妥当性確認(正しいものを作った)は別のチェックで、両方が必要です。
一つの接続された信頼できる唯一の情報源のためにMBSEとSysMLを使い、創発的な振る舞いを予期するためにシステム思考を使います。
プロセスの重さを、システムの規模、寿命、リスクに合わせます。

参考文献とさらなる読み物

INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
Sanford Friedenthal, Alan Moore, and Rick Steiner, A Practical Guide to SysML: The Systems Modelling Language
NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management
Dennis M. Buede and William D. Miller, The Engineering Design of Systems: Models and Methods
Donella H. Meadows, Thinking in Systems: A Primer
Eberhardt Rechtin and Mark W. Maier, The Art of Systems Architecting
U.S. Department of Defence, Defence Acquisition Guidebook (systems engineering guidance)