ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
SYS.2で求められることとは？
SYS.2（システム要件分析）の目的は、ステークホルダー要求事項と整合性の取れた、構造化・分析済みのシステム要件事項の集合を確立することです。
SYS.1で合意されたステークホルダー要求事項を、システムというブラックボックスに対する具体的な機能要件・非機能要件へと落とし込み、実現可能性や動作環境への影響まで検証したうえで、後工程（SYS.3のアーキテクチャ設計）に渡せる状態に仕上げることがゴールです。
SYS.2で得られる成果
- システム要件事項が仕様化されている
- システム要件事項が構造化・優先順位付けされている
- システム要件事項が正確性および技術的実現可能性の観点で分析されている
- システム要件事項が動作環境に及ぼす影響が分析されている
- システム要件事項とステークホルダー要求事項との間で、一貫性および双方向のトレーサビリティが確立されている
- システム要件事項が合意され、全ての関係者に伝達されている
これらの成果は、そのままBP1～BP6の各基本プラクティスに対応しています。
SYS.2で作成される主な成果物
- 要求事項：仕様化したシステム要件事項そのもの
- 要求事項の属性：構造化・優先順位付けを支えるメタ情報
- システム要求の分析結果：正確性・実現可能性分析、BP4の動作環境への影響分析の記録
- 一貫性のあるエビデンス：確立した双方向トレーサビリティの裏付け
- コミュニケーションエビデンス：関係者に合意事項を伝達した記録
SYS.2の基本プラクティス（Basic Practice）
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SYS.2 システム要件分析 には合計6つの基本プラクティス（BP1～BP6）が存在します。
SYS.2（システム要件分析）の目的は、ステークホルダー要求事項と整合性の取れた、構造化・分析済みのシステム要件事項の集合を確立することである。
SYS.2.BP1
BP1では、システム要件事項の仕様化が求められています。
SYS.1で合意されたステークホルダー要求事項をインプットとし、システムに求められる機能要件・非機能要件を識別したうえで、定義済みの特性に従って文書化する必要があります。
ここで言う「定義済みの特性」とは、たとえばISO/IEC/IEEE 29148やISO 26262-8、INCOSEの要求事項作成ガイドなどの規格が示す特性のことで、具体的には「検証可能であること（要求事項の文中に検証基準が内在していること）」「一意に理解できること（曖昧さがないこと）」「設計や実装の記述を含まないこと」「他の要求事項と矛盾しないこと」などが挙げられます。
単に要求を書き写すのではなく、こうした品質基準に沿って要件化することがBP1のポイントです。
SYS.2.BP2
BP2では、システム要件事項の構造化が求められています。
BP1で識別したシステム要件事項を、機能別のグルーピングや製品バリアントごとの整理など、適切な観点で構造化し、優先順位付けを行う必要があります。
優先順位付けは、プロジェクトやステークホルダーのニーズに応じて、たとえばリリーススコープ（どのリリースにどの要件を含めるか）の定義といった形で行われることがあります。
SYS.2.BP3
BP3では、システム要件事項の分析が求められています。
仕様化されたシステム要件事項について、要件同士の相互依存関係も含めて分析し、正確性および技術的な実現可能性を確認するとともに、プロジェクトマネジメントにおける見積り作業を支援する必要があります。
技術的な実現可能性は、既存のプラットフォームや製品ラインをベースに評価する方法や、プロトタイプ・デモンストレーターを作成して評価する方法などが挙げられます。なお、プロジェクトの実現可能性評価はMAN.3.BP3、プロジェクト見積りはMAN.3.BP5と関連します。
SYS.2.BP4
BP4では、システムコンテキストへの影響分析が求められています。
システム要件事項が、当該システムを取り巻く関連するシステムコンテキスト（周辺システムや外部環境の要素）にどのような影響を及ぼすかを分析する必要があります。
自システム単体の要件を満たすだけでなく、接続先のシステムや外部環境側にどのような影響・制約が生じるかまで見通しておくことが、後工程での手戻りを防ぐうえで重要になります。
SYS.2.BP5
BP5では、一貫性の確保および双方向トレーサビリティの確立が求められています。
システム要件事項とステークホルダー要求事項との間で、一貫性を確保するとともに、双方向のトレーサビリティ（上位から下位、下位から上位の両方向に追跡できる状態）を確立する必要があります。
双方向トレーサビリティは、一貫性の担保だけでなく、変更依頼が発生した際の影響分析や、ステークホルダー要求事項に対する網羅性の証明にも役立ちます。ただし、トレースリンクが存在すること自体は、内容として整合性が取れていることを意味しない点に注意が必要です。
また、プロセス要求事項のように、システム要件事項側にトレースされない非機能のステークホルダー要求事項も存在し得ますが、そうした要求事項も検証の対象からは外れません。
SYS.2.BP6
BP6では、合意されたシステム要件事項およびシステムコンテキストへの影響の伝達が求められています。
合意済みのシステム要件事項と、BP4で分析したシステムコンテキストへの影響分析の結果を、影響を受ける全ての関係者に伝達する必要があります。
要件そのものだけでなく、その要件が周辺環境にもたらす影響までをセットで共有することで、関係者全員が同じ前提のもとで後続の設計・検証作業を進められるようになります。
コメント