SWE.1 ソフトウェア要件分析

プロセスID SWE.1

プロセス名 ソフトウェア要件分析

プロセス目的 ソフトウェア要件分析プロセスの目的は、システム要件のうちソフトウェア関連部分をソ フトウェア要件の集合に変換することである。

プロセス成果 このプロセスを適切に実装した場合の成果は、以下のとおりである。

1) システムのソフトウェアエレメントおよびそれらのインタフェースに割り当てるべきソフト ウェア要件が定義されている。

2) ソフトウェア要件が正確性および検証可能性によって分類され、分析されている。

3) ソフトウェア要件の運用環境への影響が分析されている。

4) ソフトウェア要件を実装する優先順位が定義されている。

5) ソフトウェア要件が必要に応じて更新されている。

6) 一貫性および双方向トレーサビリティが、システム要件とソフトウェア要件との間で 確立されている。一貫性および双方向トレーサビリティが、システムアーキテクチャ 設計とソフトウェア要件との間で確立されている。

7) ソフトウェア要件が、コスト、スケジュール、および技術的な影響に対して評価され ている。

8) ソフトウェア要件が合意され、影響を受けるすべての関係者へ伝達されている。

基本プラクティス SWE.1.BP1: ソフトウェア要件の仕様化 システム要件、システムアーキテクチャ、なら びにシステム要件およびアーキテクチャへの変更を使用し、ソフトウェアに必要となる機 能および性能を識別する。ソフトウェアの機能要件および非機能要件を、ソフトウェア 要件仕様に明記する。[成果 1, 5, 7]

備考 1: 機能および性能に影響を及ぼすアプリケーションパラメーターは、システム要件の一 部である。

備考2: ソフトウェア開発のみの場合、システム要件およびシステムアーキテクチャは与えられ た運用環境のことを指す（備考 5 も参照のこと）。この場合、利害関係者要件は、ソフト ウェアに必要となる機能および性能を識別するベースとして、ならびにソフトウェアの機能およ び性能に影響を及ぼすアプリケーションパラメーターを識別するベースとして使用すべきであ る。

SWE.1.BP2: ソフトウェア要件の構造化 ソフトウェア要件を、ソフトウェア要件仕様 の中で以下の例の様に構造化する。

 プロジェクトにおける関連内容に基づくグループ化

 プロジェクトにおける論理的順序に基づく並び替え

 プロジェクトに関連する基準に基づく分類

 利害関係者のニーズに基づく優先順位付け [成果 2, 4]

備考3: 一般的に優先順位付けには、計画したリリースにソフトウェア項目を割り当てること が含まれる。SPL.2 .BP1 を参照のこと。

SWE.1.BP3: ソフトウェア要件の分析 明記したソフトウェア要件を、その相互関係を 含めて分析し、正確性、技術的実現可能性、および検証可能性を保証し、リスク の識別に役立てる。コストおよびスケジュールへの影響、ならびに技術的な影響を分 析する。[成果 2, 7]

備考 4: コストおよびスケジュールへの影響分析は、プロジェクトの見積りの修正に役立つ。

MAN.3 .BP5 を参照のこと。

SWE.1.BP4: 運用環境における影響の分析 ソフトウェア要件がシステムエレメントの インタフェースおよび運用環境に及ぼす影響を分析する。[成果 3, 7]

備考5: 運用環境は、実行するソフトウェアを内に含むシステムとして定義される（例：ハー

ドウェア、オペレーティングシステム等）。

SWE.1.BP5: 検証基準の作成 各ソフトウェア要件に対して、その要件の検証にお ける定性的および定量的な手段を定義した検証基準を作成する。[成果 2, 7]

備考 6: 検証基準は、要件が合意した制約内で検証できることを実証する。一般的に検 証基準は、ソフトウェア要件への遵守を実証すべく、ソフトウェアテストケースの作成または他 の検証手段のインプットとして使用する。

備考7: テストで取り扱うことのできない検証は、SUP.2で実施する。

SWE.1.BP6: 双方向トレーサビリティの確立 システム要件とソフトウェア要件との間 の双方向トレーサビリティを確立する。システムアーキテクチャとソフトウェア要件との間 の双方向トレーサビリティを確立する。[成果 6]

備考8備考8: これらの取り組みは、プロジェクトおよび組織のニーズを網羅するように組み 合わせることで、重複を防ぐべきである。

備考9: 双方向トレーサビリティは、網羅性、一貫性、および影響分析に役立つ。

SWE.1.BP7: 一貫性の確保 システム要件とソフトウェア要件との間の一貫性を確

保する。システムアーキテクチャとソフトウェア要件との間の一貫性を確保する。[成果 6]

備考 910: 一貫性は、双方向トレーサビリティによって裏付けられ、レビュー記録によって実

証できる。

備考1011: ソフトウェア開発のみの場合、システム要件およびシステムアーキテクチャは与え

られた運用環境のことを指す（備考 2 も参照のこと）。この場合、一貫性および双方向 トレーサビリティは、利害関係者要件とソフトウェア要件との間で確保しなければならない。

SWE.1.BP8: 合意したソフトウェア要件の伝達 合意したソフトウェア要件、およびソ フトウェア要件の更新をすべての関係者へ伝達する。[成果 8]

アウトプット 作業成果物

13-04 情報伝達記録 → [成果8]

13-19 レビュー記録 → [成果6]

13-21 変更制御記録 → [成果5,7]

13-22 トレーサビリティ記録 → [成果1,6]

15-01 分析報告書 → [成果2,3,4,7]

17-08 インタフェース要件仕様書 → [成果1,3]

17-11 ソフトウェア要件仕様書 → [成果1]

17-50 検証基準 → [成果2]