ITパスポート 2017年 秋期 問19

ソフトウェアライフサイクルの主プロセス（要件定義での作業）【ITパスポート 解説】

正解の理由

解法ステップ

1. 問題文で「要件定義プロセス」とあるので、要件定義の目的を思い出す。
   • キーワード：何を作るかを決める、利用者と合意する、機能・性能を決める。
2. 各選択肢がどのライフサイクル工程に当たるかを当てはめる。
   • 企画、要件定義、開発、運用、保守のどれかを考える。
3. 要件定義の説明と合致する選択肢を選ぶ。
   • 合致するのはエ。

選択肢別の誤答解説

• ア: 「開発されたシステムが仕様に合っており、稼働環境で使えるか確認するテストを行う。」
  • これはテスト（検証）や受入試験に関する説明です。テストは主に開発フェーズ後半やリリース前に行う作業で、要件定義段階の作業ではありません。従って要件定義には該当しません。
• イ: 「外部委託の内容と条件を委託先に提示し、見積りを入手する。」
  • これは外部委託（outsourcing：業務を外部業者に任せること）や調達、契約に関する作業です。企画の段階での調整や調達活動に近く、要件定義そのものではありません。
• ウ: 「データの書式やデータベースの構造を詳細に決定する。」
  • これは詳細設計（詳細な設計作業）に当たります。要件定義では「どんな機能や性能が必要か」を決めますが、データベースのテーブル設計やデータ書式などの細かな設計は開発フェーズの設計工程で行います。
• エ: 「どのようなシステムを構築するかを、機能、性能、利用方法などの観点で、利用者側と開発者側で明確にする。」
  • これが要件定義の典型的な説明です。要件定義では利用者と合意を取り、機能要件（何をするか）と非機能要件（性能やセキュリティ、使い勝手など）をまとめます。したがって正しい選択です。

よくある誤解

1. 「要件定義で詳細設計まで決めるべきだ」
   • 誤りです。要件定義は「何を実現するか」を決める段階で、実装方法やデータベースの細かい構造は詳細設計（設計工程）で決めます。要件定義を細かくしすぎると変更対応が大変になります。
2. 「テストは開発が終わってから考えればよい」
   • 誤りです。受入テストで何を基準に合格とするか（受入基準）は要件定義段階で明確にしておく必要があります。要件が曖昧だとテスト基準も曖昧になります。

補足コラム

• 要件定義で作る主なドキュメント
  • 要件定義書：ユーザー要件（ユーザーが求めること）とシステム要件（システムが満たすべき条件）を整理した文書。
  • 機能要件の例：ユーザーが商品を検索できる、注文できる。
  • 非機能要件の例：応答時間は3秒以内、同時1000ユーザーまで耐えられる、24時間稼働など。
• 関係者（ステークホルダー）の巻き込みが重要
  • 要件定義は利用者（業務担当者）、経営側、開発側、運用担当など多くの人の合意が必要です。漏れや誤解を防ぐためにレビューやワークショップを行います。
• 要件の粒度（あらましの粗さ）
  • 初期段階は高レベル（ユーザー視点）の要件を固め、段階的に詳細化していきます（段階的詳細化が管理しやすい）。

FAQ