ASPICE解説は下記リンクよりアクセスください
プロセスアセスメントモデルはコチラから
※当該解説をより詳細に知りたい方はアセスメントモデルを参照ください
SYS.5で求められることとは？
SYS.5（システム検証）の目的は、システムがシステム要件事項と整合していることを確実に検証することです。
SYS.4で結合されたシステム全体を対象に、今度は「システムアーキテクチャ」ではなく「システム要件事項」そのものに立ち返って適合性を確認する工程です。熱特性や環境耐性、EMCといった、システム全体としての非機能要件の検証もここで扱われます。
SYS.5で得られる成果
- システム要件事項に基づき、システム検証のための検証手段が仕様化されている
- 検証手段が、回帰検証の基準を含めてリリーススコープに応じて選定されている
- 選択した検証手段を用いて統合システムが検証され、結果が記録されている
- 検証結果と検証手段との間で、一貫性と双方向のトレーサビリティが確立されている
- 検証結果が要約され、全ての関係者に伝達されている
SYS.5で作成される主な成果物
- 検証手段：仕様化したシステム検証の内容
- 検証手段の選択：選択した検証の計画
- ・検証手段データ／検証結果：検証実施記録・レポート
- 一貫性のエビデンス：確立した双方向トレーサビリティの裏付け
- コミュニケーションのエビデンス：関係者に結果を伝達した記録
SYS.5の基本プラクティス（Basic Practice）
基本プラクティスに関する詳細な記述はプロセスアセスメントモデルを参照ください。
SYS.5 システム検証 には合計5つの基本プラクティス（BP1～BP5）が存在します。
SYS.5（システム検証）の目的は、システムがシステム要件事項と整合していることを確実に検証することである。
なお、SYS.4「システム結合および結合検証」がシステムアーキテクチャに対する結合検証であったのに対し、SYS.5はより上位の「システム要件事項」に対して、完成した統合システムそのものを検証するプロセスである点が違いになります。
SYS.5.BP1
BP1では、システム検証のための検証手段の仕様化が求められています。
システム要件事項に記載された機能要件・非機能要件への適合を証明できるよう、検証手段を仕様化する必要があります。仕様化には、検証手法、合否判定基準、検証の開始・終了基準、検証手段の実施順序、必要な検証インフラ・環境構築の内容を含めます。
システム検証で扱う検証手段は、機能面の確認だけでなく、たとえば熱特性、環境耐性、堅牢性・耐久性、EMC（電磁両立性）といった、システム全体としての非機能特性の確認も対象になり得る点が特徴です。
SYS.5.BP2
BP2では、検証手段の選択が求められています。
BP1で仕様化した検証手段の中から、回帰検証の基準を含む選択基準に基づいて、実際に適用するものを選定し、文書化する必要があります。選定された検証手段は、リリーススコープに対して十分なカバレッジを持つものでなければなりません。
選択基準の例としては、要求事項の優先順位付け、システム要件事項への変更に起因するリグレッション検証の必要性、納入する製品リリースの用途（テストベンチ、テストコース、公道など）が挙げられます。
SYS.5.BP3
BP3では、統合されたシステムに対する検証の実施が求められています。
BP2で選択した検証手段を用いて、結合済みのシステム（統合システム）に対する検証を実施する必要があります。合否ステータスおよび対応する検証手段データを含む検証結果を記録します。
検証結果が期待結果から逸脱した場合の扱いについては、SUP.9（問題解決管理）を参照してください。
SYS.5.BP4
BP4では、一貫性の確保および双方向トレーサビリティの確立が求められています。
検証手段とシステム要件事項との間で一貫性を確保し、双方向のトレーサビリティを確立する必要があります。また、検証結果と検証手段との間にも双方向のトレーサビリティを確立します。
双方向トレーサビリティは、一貫性の担保に加え、変更依頼の影響分析や検証カバレッジの証明を支えます。ただし、トレースリンクが存在すること自体は、内容としての整合性を保証するものではない点に留意が必要です。
SYS.5.BP5
BP5では、結果の要約および伝達が求められています。
システム検証の結果を要約し、影響を受ける全ての関係者に伝達する必要があります。
テストケース実行結果から得られる必要な情報を要約して提供することで、他の関係者がその結果の持つ意味（後工程やリリース判断への影響）を判断できるようになります。
コメント