宇宙機開発の上流工程であるシステム設計フェーズでアウトプットされるドキュメントについて、JAXAの資料等から要点をまとめた。

システムズエンジニアリングのプロセスにおいて、システム設計プロセス群のプロセスとして、以下の４つが定義されている。 [1]

D1 ミッション要求定義
D2 システム要求分析
D3 機能設計
D4 物理設計

これらのアプトプットドキュメントが次のようになる。

D1 ⇒ ミッション要求書

D2 ⇒ システム要求書
D3 + D4 ⇒ システム仕様書

上にあるドキュメントが下のドキュメントのベースライン文書（基準文書）となる。
よって、上位ドキュメントと下位ドキュメント間の整合性がとられることが求められる。その確認手段であるトレーサビリティー管理についても付記しておく。

参考文書
[1] SEの基本的な考え方（初版）　BDB-06007B
[2] ミッション要求書作成ガイドライン BDB-09009A
[3] システム要求書・仕様書作成ガイドライン BDB-100002A
[4] 上野宗孝:ミッション創出に向けたシステムズエンジニアリング入門, 探査ミッション立案スクール (2017年8月）
[5] 上野　宗孝:宇宙科学ミッションの考え方について，CPS-ISAS 大学共同利用連携拠点キックオフWS（2015年8月）

こちらに上記1〜3を含む関連文書があります。
JAXA宇宙科学プログラム室 WG関連資料

ミッション要求書

ミッションを提案する者が、ミッションに関連するステークホルダ(顧客、ユーザ、スポンサー、経営層等を含む)とミッションの目的・意義、ミッション要求、ミッション成功基準等を共有することを目的として作成する文書 [2]
ミッション要求 [2]
- ミッションとして真に何を求めるかを記述する。そのためには、本質的な要求とそれを実現するための手段を切り分け、実現性のある本質的な要求のみを定義する
  - ミッション機器への要求
  - ミッション機器からシステムへの要求
ミッション成功基準（サクセスクライテリア） [2]
- ミッション目標に対する達成の度合いを計るための基準を記述する
- 成功基準はミッションの最終目標を複数の項目に分解し、分解した各々の項目について基準を設定する。基準は定量的なものが望ましいが、定性的な基準もある。
要件のプロパティ [4]
- ミッションステートメント：必要な目的と測定値を１つの文に記述します
- 要件は、ミッションの目的を達成するために何が必要かを表す正式なステートメントです
- 要件は、プロセス関連ではなく、製品関連でなければなりません
- 明確な要件が優れた設計の鍵
- 要件は階層的です：下位レベルのシステム要件は、上位レベルのミッション要件から取得する必要があります

システム要求書

システム要求書は、ミッション要求書及び与えられた制約条件をインプットとして、ミッション要求を満足するシステムの機能・性能要求を検討し纏めたもの [3]
- ミッション要求を満たすに必要な本質的な「手段」に対する要求 [5]
  - 「手段」の最上位要求と位置付ける
  - 必ず、ミッション要求に根拠付けできる要求とすること
  - できる限り技術を限定化しない。書き過ぎない、ただし必要な要求は網羅
  - 性能要求の定量化（最低限満たすべき「要求値」と、期待される「目標値」は区別し、明確に識別する）
  - 制約条件、前提条件、運用、データ活用コンセプトとの根拠付けも明確に
  - 技術レベルも考慮した、実現可能な要求とする
  - 最も注意すべきは、上位要求に対する traceability
与えられたミッション要求と制約条件だけでは検討が進められない場合は、前提条件(証拠や実証無しに仮定した条件)を設定して作業を進める [3]
- 制約条件 (constraints) [5]
  - ミッション、プロジェクトで考慮すべき制限
    - プログラム的制約:コスト、スケジュール、打ち上げ手段や国際競合など
    - 開発環境
    - 運用環境・要求
    - 法・規則・規定
    - 協力先プロジェクト、機器とのI/F、スケジュールなど
- 前提条件 (assumptions) [5]
  - プロジェクトを進める上で前提として考える条件で、プロジェクトで要識別
  - 前提条件はリスクとして識別・管理される（国際協力を前提とした場合、未知の宇宙環境などの仮設定など）
- リスク [5]
  - ミッション実現に必要な技術レベルと現状の差
  - 既存技術の宇宙環境への不適合性や適合性未確認
作成する際には、開発方針に基づいた要求になっていること、要求品質の高い記述になっていること等を考慮すること [3]
- ミッション要求をシステムに対する機能・性能要求に変換するトップダウン的アプローチ
- 物理的な実現解をイメージしながらシステム要求を設定するボトムアップ的アプローチ
- 物理的な実現解が複数ある場合にそれらに共通する必要十分な要求を設定したりする
ミッションの実現及び信頼性の確保のために、ミッションの目的や技術開発レベルによっては、サブシステム・機器レベルまで掘り下げて詳細化した要求を設定しなければならないこともあるため、その場合、これらも含めたシステム要求を設定しなければならない [3]
システム要求を満たす実現解が見つからない場合はミッションの意義・目標を損なわない範囲で前提条件、ミッション要求等の見直しが可能か検討する [3]
- 前提条件は状況の変化に応じて見直しが必要になることもあるため制約条件とは区別しリスク項目として管理することが望ましい
システム要求に求められる品質 [3]
システム要求分析(D2) [1]
- 定義された要求を分析し、技術的要求(システム要求書等)に変換することにより、システムへの機能・性能要求を明確にする
- 上述の作業において、与えられたミッション要求と制約条件だけでは検討が進められない場合は、前提条件(確証無しに仮定した条件)を設定して作業を進める
- 技術的要求に関して、顧客とともに妥当性を確認する
- 境界や成果物自体の明確化を図る
- システムライフサイクル全般にわたる成果物そのものと、外部環境や当該システムの運用を支援する外部システムとの関係について明らかにする
  - コンテキスト解析・ユースケース図等の方法は境界を明確化するための有用な手法である
- 潜在的なリスク要因、安全性、信頼性等について明確にする。前提条件は、潜在的なリスク要因となりえるので、制約条件と識別しておくことが重要である

システム仕様書

システム仕様書は、与えられた制約条件と自ら仮定した前提条件の下で定義されたシステム要求を基に予備設計を実施し、その結果を反映して実現可能かつ検証可能なシステムの開発仕様を定めたもの [3]
システムがシステム要求書に記載された機能・性能を満足するよう予備設計を実施し検証可能な開発仕様として纏める [3]
機能設計(D3) [1]
- 要求分析で明確となったシステムへの機能・性能要求を管理のできる、より下位の機能に分解する
- 機能分解の際、機能毎に上位のレベルから抜けなく分解し、順次詳細化することにより、トレーサビリティが保たれる
  - このような手法で生成されたブロック図は機能フローブロックダイアグラム、FFBD(Functional Flow Block Diagram)と呼ばれる
- 機能設計を行うにあたり、当初イメージした物理的なシステム構成にとらわれると、最適な設計解が得られないこともありうるので、要注意
物理設計(D4) [1]
- 機能設計で出力された機能ブロックの集合を実現可能な構成要素(ハードウェアやソフトウェア)に割り付ける
  - 複数の代替案(比較案)を定義し、設計条件(外部インタフェース要求、技術要求、物理的故障モード、ライフサイクルコスト、発展性、製作か購入か、製品の標準化、取りまとめる上での懸念事項、製作時に考慮すべき事項(作業内容、作業場所、作業場所に設置された機器類、雰囲気)に対して分析し、最良の設計結果を選定する
- 構成要素間及び上位のシステム等とのインタフェース仕様を明確化する
- 設計仕様書、図表、試験検証計画書、インタフェース仕様、技術リスク項目などを出力する
- 次の各項目を検証する
  - 定義された設計結果が、技術活動の制約内で実現できること
  - 出力された要求仕様とミッション要求定義との間にトレーサビリティがあること
  - 設計結果を設定する過程でなされた決定と前提条件が明確であること
- 必要な副成果物(試験装置等)の開発あるいは入手を計画する
- ミッション要求定義やシステム要求分析を経てアーキテクチャ設計を行うが、その際、トレーサビリティマトリックスを用いてトレーサビリティの確保に注意を払う。

トレーサビリティー管理

各システムの要求や仕様項目間の整合性をとり、変更の都度整合性を維持すること [3]
- 上位要求と下位要求・仕様間の整合性を可視化する
  - 要求・仕様項目間の関係をマップ形式、表形式等で示す
  - 本作業は要求品質向上の効果が期待できるものの作業負荷も高いため、以下に示す種類の要求について重点的に実施する場合もある
    - ミッション要求の達成に影響の大きい要求・仕様
    - 新規性の高い開発品目の要求・仕様
    - 新規性の高い運用コンセプトに基づく要求・仕様
- 各要求・仕様の設定理由を残す
  - 要求項目、仕様項目毎に設定理由(根拠)が分かるようにする
  - 関連する制約条件、前提条件も併せて残すことで、前提条件が変更になった際の影響を確認できるようにする