ITパスポート 2014年 春期 問26

ソフトウェアライフサイクルの要件定義で確認するもの【ITパスポート 解説】

正解の理由

解法ステップ

1. 問題文で扱っている工程をはっきりさせる
   • 今回は「要件定義」の段階で何を確認するかを問われている。
2. 要件定義の目的を思い出す（利用者の要求を明確化し、業務の妥当性を確認する）
   • 要件定義は業務にとって正しい要件かを検証する工程。
3. 選択肢を「業務的確認」「設計・実装の実現可能性」「要件間の整合性」などで分類する
   • 業務的妥当性 → 要件定義（正解）
   • 設計・実装の実現可能性 → 開発・設計段階で確認
4. 最も工程の目的に合致する選択肢を選ぶ
   • ここでは業務要件の妥当性（ウ）。

選択肢別の誤答解説

• ア: システム要件とソフトウェア要件の一貫性と追跡可能性
  • 「追跡可能性（traceability）」は要件の管理や品質保証の観点で重要ですが、これは要件が定義された後に、設計やテストに正しく引き継がれているかを確認する作業に関係します。要件定義段階では一貫性を意識しますが、詳細なトレーサビリティの確認は設計・開発フェーズで行われることが一般的です。よって主題とはズレます。
• イ: ソフトウェア要件に関するソフトウェア設計の実現可能性
  • これは「設計（design）」側の評価です。設計が要件を満たせるかどうか、技術的に実装可能かは開発フェーズや設計レビューで詳しく検討します。要件定義ではまだ設計レベルの詳細は確定していません。
• エ: 割り振られた要件を満たすソフトウェア品目の実現可能性
  • これは各要件をどのソフトウェアコンポーネント（品目）に割り当てるか、そしてその各コンポーネントが実現できるかを確認する作業で、実装や構成設計に近い内容です。したがって開発段階の活動に該当します。

よくある誤解

1. 「要件定義＝技術的実現可否の検討」
   • 要件定義の主目的は業務ニーズの正当性確認です。技術的な可否は概略レベルで確認することはありますが、詳細な検討は設計・開発段階で行います。
2. 「業務要件とシステム要件は同じ」
   • 業務要件は業務の目的やルール（何を達成したいか）。システム要件はその業務を支えるシステムの性能や機能（どう実現するか）です。混同しないことが重要です。
3. 「追跡可能性は不要」
   • トレーサビリティは重要ですが、主に要件管理や品質保証に関する活動で確認されます。要件定義の「妥当性確認」とは役割が異なります。

補足コラム

• 要件の階層について簡単に整理します。
  • 業務要件（business requirements）：業務・利用者の目的、期待される効果。要件定義で主に扱う。
  • システム要件（system requirements）：業務要件を満たすためのシステム全体の要件（性能・運用など）。
  • ソフトウェア要件（software requirements）：システムを構成するソフトウェアに求められる具体的な機能や振る舞い。
• 要件定義の成果物例：要件定義書（利用者要求や業務フロー、受入基準など）。受入基準（acceptance criteria）は後のテストで合否を判断する基準になるので、要件定義で明確にしておくことが大切です。
• 開発の流れをざっくり示すと、企画（何をやるか）→ 要件定義（何が必要か、業務の妥当性）→ 設計・開発（どう作るか、実現可能性の検討）→ 運用（実際に使う）の順です。

FAQ