その他

この章で覚えておきたいこと

• 要件定義は、発注者側と開発側が業務要件、システム要件、非機能要求を確認可能な形で合意する工程です。
• 共通フレームは、企画、システム化構想、要件定義、開発、運用までの作業や役割を共通化する枠組みです。
• 見積りは、何を基準に規模を測るかで解き分けます。類推法は過去の類似事例、パラメトリック法は数式モデル、ボトムアップ法は作業積上げです。
• ファンクションポイント法とCOSMICは機能規模、LOCはコード行数、COCOMOとCoBRAは規模や要因から工数を推定するモデルとして整理します。

基本知識

要件定義

要件定義では、利用部門が実現したい業務要件を整理し、それをシステム要件へ落とし込みます。機能だけでなく、性能、信頼性、保守性、セキュリティなどの非機能要求もここで明確にします。

試験では、要件定義を開発者だけで決めるような選択肢が誤りになりやすいです。要件定義は、発注者側と開発側が認識を合わせ、後工程で検証できる形へまとめる工程として押さえます。

共通フレームと企画プロセス

共通フレームは、システムやソフトウェアのライフサイクルに関する作業、役割、成果物、用語をそろえるための枠組みです。特定の開発手法を指定するものではなく、発注者と受注者が同じ言葉で工程を確認するために使います。

企画プロセスでは、経営課題や業務課題を踏まえてシステム化の目的を定めます。システム化構想では、対象業務、期待効果、対象範囲、実現の方向性を整理します。その後に要件定義で、必要な機能や品質要求を具体化していきます。したがって、企画、構想、要件定義は上流での粒度が順に細かくなる関係です。

見積り手法の基本

類推法は、過去の類似プロジェクトを参考に概算する方法です。早い段階でも使いやすい一方で、似た案件の実績がないと精度が安定しません。

パラメトリック法は、規模や要因を変数として数式モデルに当てはめる方法です。過去データを使って工数や費用を推定するため、計算式ベースの見積りと読めば候補になります。

ボトムアップ法は、作業を細かく分解し、各作業の工数を積み上げる方法です。WBSのように作業内容が具体化しているほど使いやすく、上流の初期段階より詳細設計後のほうが適します。

機能規模と工数推定モデル

ファンクションポイント法は、利用者から見た機能量を基準に規模を測る方法です。外部入力、外部出力、外部照会、内部論理ファイル、外部インタフェースファイルなどを数えるため、コード行数に依存しません。

LOCは、ソースコードの行数を基に規模を見積もる方法です。実装言語や記述スタイルの影響を受けやすいので、利用者視点の機能量そのものではありません。

COCOMOは、ソフトウェア規模などを入力として工数を推定する代表的なパラメトリックモデルです。CoBRAは、規模に比例する基本工数に、プロジェクト特有のコスト要因を加味して見積もる考え方です。どちらも工数推定モデルですが、CoBRAは変動要因の調整を組み込む点で区別します。

COSMICは、データ移動を基準に機能規模を測る方法です。ファンクションポイント法と同じく機能規模の測定ですが、数える対象が利用者機能の件数というより、データの移動である点が判断軸になります。

この章のまとめ

• 要件定義は、発注者側と開発側の合意形成が中心です。未確定事項を放置せず、確認可能な要件へ落とし込むことが重要です。
• 共通フレームは、企画から運用までの作業と役割を共通化する枠組みです。企画プロセスで目的を定め、システム化構想で方向性を描き、要件定義で具体化します。
• 見積り問題は、過去事例なら類推法、数式モデルならパラメトリック法、作業積上げならボトムアップ法で切り分けます。
• ファンクションポイント法とCOSMICは機能規模、LOCはコード行数、COCOMOとCoBRAは工数推定モデルという整理が基本です。

一次試験過去問での出方

2018年度第18問では、CoBRA、LOC、標準タスク法、ファンクションポイント法の違いが問われました。利用者機能を数えるのか、コード行数を見るのか、標準タスクを使うのかという基準の違いを見抜く問題でした。

2021年度第19問では、共通フレームの企画プロセス、システム化構想、要件定義、システム適格性確認テストの位置づけが問われました。上流から下流へ進むにつれて、目的整理から具体的要件、さらに受入確認へ粒度が変わる流れを押さえることが重要でした。

2024年度第16問では、CoBRA、COCOMO、COSMIC、ファンクションポイント法、類推法の区別が問われました。工数推定モデルなのか、機能規模測定なのか、過去事例による概算法なのかを一つずつ切り分ける力が必要でした。