ITパスポート 2013年 秋期 問43

システム開発における設計手順 +【ITパスポート 解説】

正解の理由

• 業務要件（business requirements）：組織が達成したい目的や業務の流れ、守るべきルール。何を実現したいかの高いレベルの要求。
• システム要件定義（system requirements）：業務要件を実現するためにシステム全体が満たすべき性能・連携・運用などの条件。ハード・ネットワーク・既存システムとの接続なども含むことが多い。
• ソフトウェア要件定義（software requirements）：個々のソフトウェアやモジュールが満たすべき機能や画面仕様、API仕様などの詳細な技術仕様。

解法ステップ

1. 問題文で出てくる各語句を「レベル（粒度）の高いもの→低いもの」で分類する。
   • 業務要件＝最も上位（ビジネス目的）。
   • システム要件＝中間（システム全体の条件）。
   • ソフトウェア要件＝最下位（個別ソフトの詳細）。
2. 上位から下位へ「何を→どのような仕組みで→具体的にどう作るか」の順に並べる。
3. 選択肢の並びと照合する。上位から順に並んでいるものが正答。

選択肢別の誤答解説

• ア: 正しい。業務（目的）→システム（仕組み）→ソフト（実装）の順で、論理的に具体化している。
• イ: 業務→ソフト→システム。この順だと、個別ソフトの詳細を先に決めてからシステム全体の連携や制約を考えることになり、既存システムとの接続やハード性能などで破綻する可能性が高い。順序として不適切。
• ウ: システム→業務→ソフト。システム要件を先に定めてから業務要件を見ると、本来必要な業務の目的が反映されないまま技術的制約に引きずられる恐れがある。まず業務を理解するのが基本。
• エ: システム→ソフト→業務。もっとも逆の順で、業務の目的が最後になるため、目的に合わない設計になりやすい。現実的ではない。

よくある誤解

1. 「システム＝ソフトウェア」と混同する誤解
   • システムはソフトウェアだけでなく、ハード（サーバ・ネットワーク）、運用体制、既存システムとの接続も含みます。ソフトはその一部です。
2. 「要件定義は順番どおりにやらないとダメ」と考える誤解
   • 実務では反復（何度も見直す）が必要です。ただし概念的な流れは業務→システム→ソフトの階層を意識します。
3. 「小さなプロジェクトでは順序を気にしなくてよい」と思う誤解
   • 規模が小さくても、目的（業務）を最初に確認しないと、作ってから要りませんと言われるリスクがあります。

補足コラム

• 要件の階層化は「上位要求を下位要求に分解していく作業」です。これを要件のトレーサビリティ（追跡可能性）と言い、上位の業務要件がどのソフトウェア要件にどう反映されているかを対応付けておくと後で変更管理が楽になります。
• 開発モデルとの関係：伝統的なV字モデルでは要件定義→設計→実装→検証と進み、要件の階層化が明確です。アジャイル開発でも短い反復の中で「業務理解→システム範囲→実装単位」を小さく回していきます。順序の概念は変わりませんが、繰り返し行う点が異なります。
• 例（オンライン注文システム）
  • 業務要件：注文処理時間を半分にする、在庫と連動させる。
  • システム要件：同時1000ユーザ対応、既存在庫DBとAPIで連携、稼働時間99.9%等。
  • ソフト要件：注文APIの入力項目、UIの画面遷移、エラーハンドリング仕様など。

FAQ