業務要件定義 — 機能要件・非機能要件と合意
標準約 25 分4 用語過去問 17 題
この単元の目標
- 業務要件定義の目的と、要件を明確にしていく順番を説明できる。
- システムへの要件を機能要件と非機能要件に分けられる。
- 要件を誰と確認し、どう確定させるか (要件の合意) を説明できる。
用語総表（4 語）
用語
業務要件定義は、現状の業務を分析して見えた問題点を踏まえ、新しい業務のあるべき姿 (業務の手順、役割と権限、業務ルールなど) と、システム化する範囲を明確にする作業である。
ソフトウェアライフサイクル (システムの企画から開発・運用までの流れ) では、企画の次に来る要件定義プロセスで行う作業である。目的は、システム化する範囲とそこで要る機能を具体的にし、利害関係者 (システムを使う部門や発注する側など、そのシステムに関わる人や組織) と認識をそろえることにある。
たとえ引っ越しの前に、今の家で不便な点を書き出し、新しい家での暮らし方を家族で決めることに似ている。間取りの図面を描くのは、その後の段階である。
出題のポイント
- 出題要件は業務要件 → システム要件 → ソフトウェア要件の順に、業務に近い側から明確にしていく。
- 出題業務要件は業務上の目標とそれを達成する業務のやり方を表す。システムの性能や方式を表すシステム要件とは別の層の要件である。
- 出題システムが従う業務ルールは、業務要件の定義の段階で明らかにしておく。ここが不十分だと、ルールを取り違えたままシステムが作られる。
この用語の過去問 3 題 業務要件定義 →
機能要件は、業務要件をかなえるために、システムが何をするか (受け付けるデータ、行う処理、出す画面や帳票) を定めた要件である。
例えば、注文を登録する、月末に請求額を集計するといった処理の内容が機能要件に当たる。業務の中でシステムが受け持つ部分を、システムの働きとして書き表したものと言える。
たとえ自動販売機なら、お金を受け取る、商品を出す、お釣りを返すといった、機械がする仕事そのものに当たる。
出題のポイント
- 出題システムがどんなデータを受け付け、どんなデータを返すか、つまり入出力データの種類は、処理の中身を決める情報なので機能要件に入る。
- 出題業務を支えるためにシステムが持つ機能を決め、システム化の範囲を具体的に示すのは要件定義プロセスの仕事である。
この用語の過去問 3 題 機能要件 →
非機能要件は、機能そのもの以外にシステムが満たすべき条件 (性能・信頼性・セキュリティといった品質の水準や、技術面・運用面の条件) を定めた要件である。
例えば、画面が何秒で応答するか、1 年でどれだけ止まってよいか、データをどう守るかがここに入る。同じ機能でも、求める水準によって必要な機器や費用は変わる。
たとえ同じ自動販売機でも、ボタンを押して何秒で商品が出るか、故障せずに何年動き続けるか、どのくらいの間隔で点検するかといった、機械がする仕事そのもの以外の条件に当たる。
出題のポイント
- 出題非機能要件のうち性能の要件は処理の速さを表し、操作への応答時間や処理にかかる時間で示す。
- 出題1 年に止まってよい時間の上限や、障害から回復させる目標時間は、システムの働きではなく品質の条件なので非機能要件に入る。
- 出題応答時間の目標や運用する時間帯のような非機能要件の値も、機能と同じく要件定義の工程で決め、利用部門と取り決める。
この用語の過去問 3 題 非機能要件 →
要件の合意は、まとめた要件を利用部門などの利害関係者と確認し合い、その内容で進めることを双方が了承して確定させることである。
合意した内容は要件定義書などの文書に残し、後の工程はこれを拠り所に進める。合意がないまま開発に進むと、完成後に業務の実態と合わない点が見つかり、作り直しが生じやすい。
たとえ注文住宅で、施主と工務店が打ち合わせを重ねて仕様書を詰め、最後に施主が内容に納得して署名する場面に当たる。署名の後は、その仕様書どおりに工事が進む。
覚え方「合意」の「合」は合わせる。作る側と使う側が内容を合わせたうえで、使う側の責任者が承認して確定する。
出題のポイント
- 出題業務要件の合意で欠かせない相手は、新しいシステムを使う利用部門の責任者である。
- 出題開発者がシステム要件を定義する場合も、利用者はそのレビューに加わり、要件が自分たちのニーズに合っているかを確かめる。
- 出題合意した要件定義書は、どこまでを開発するかという対象範囲を決める文書になる。
この用語の過去問 3 題 要件の合意 →
要点
- 業務要件定義は現状分析をもとに業務のあるべき姿を定め、システム化する範囲と必要な機能を具体的にする作業である。
- 非機能要件の目標は数値で書けるものが多く、応答の速さや止まってよい時間などをはっきりさせておく。
- 要件は文書にまとめ、利用部門の責任者の承認を得て確定させる。
- 要件が曖昧なまま開発に進むと、後の工程での作り直しが増える。
この分野の過去問をすべて見る →