欲しいことを確かめられる条件にする
- 利用者が通常の業務と例外を説明し、要求の漏れを確認する
- 処理内容である機能要件と、性能等の非機能要件を区別する
- 曖昧な要求を測定条件と受入基準へ具体化し、利用部門と開発側で合意する
点線のことばを押すと、意味と使い方を調べられます。
表示・保存
このページの目次 3節・復習と3問
- 1説明を読む
- 2復習する
- 3問題を解く
- 4次へ進む
1現場の要求を調べる
業務要件定義は、経営・システム戦略と利用者のニーズを踏まえ、仕事として実現すべきことを明確にする活動です。「便利にしたい」だけでは作る側と使う側で解釈が分かれます。
受付担当へ聞き取り、実際の作業を観察し、現行業務の順序・例外・困り事を分析します。予約票から氏名、日時、人数などのデータを洗い出し、誰が作成・更新・参照するか整理します。不要な重複や曖昧な項目も見つけます。
- 1聞く・見る
電話受付の流れを確認
- 2整理
氏名・日時・人数を洗出し
- 3定義
受付で必要な仕事を明記
矢印は作業を進める順序です。
ハルとビットで、使い方を確かめよう
便利にして、だけでは足りない？
どの仕事をどうできるようにするか、具体例を一緒に示そう。
2機能と非機能を具体化する
機能要件はシステムが何をするかの条件です。「予約を登録できる」「満席なら受付を止める」が例です。非機能要件は性能、使いやすさ、信頼性、安全性など、機能をどのような品質や制約で実現するかの条件です。
「速い」より「指定した同時利用人数とデータ量で検索結果を3秒以内に表示する」の方が確認できます。3秒は架空の合意条件です。機能以外の条件を不要と考えず、業務停止の影響などから利用者も検討に加わります。
3合意が後の受入れを支える
調査内容を分析して業務要件を定義し、関係する利用部門と開発側が内容・優先順位・受入基準を確認して合意します。受入基準は納入物を受け入れてよいと判断する条件です。変更時も費用や納期への影響を確認して合意を更新します。
業務要件が曖昧だと、設計のやり直しや「何を試せば受け入れられるか分からない」という問題につながります。ただし構想段階の投資判断の誤りや、明確な仕様に反するコーディングミスとは原因を分けて考えます。
- 1業務要件
満席の予約を防ぐ
- 2基準
満席時は登録不可
- 3確認
満席の入力で試験
矢印は作業を進める順序です。
ハルとビットで、使い方を確かめよう
完成してから条件を決めてもいい？
先に合意すれば、作る側も受け入れる側も同じ基準を使えるよ。
復習
このレッスンを振り返ろう
問題で確かめる
学んだことを問題で確かめよう
過去問を参考にした独自問題1問、入門の確認問題2問で、この範囲の考え方を使います。答えを選んだら、正解の理由とほかの選択肢の違いも確かめましょう。
ヒントを見る
実際の業務を最もよく知る人から、何を聞き取るべきか考える。
出題準拠オリジナル · シラバス 6.5
3問中0問の答えと解説を確認しました。選んだ答えの理由も確かめてから、次へ進みましょう。
出典・参考資料を確認する
学習範囲：IPA シラバス Ver.6.5 ↗ 項目23。身近な例・会話・図解・確認問題は当サイトのオリジナルです。
学習範囲と参考資料
シラバスは学習範囲の根拠です。説明は参考資料を基に当サイトが作成しています。身近な事例・会話・図の数値は学習用の架空例です。2026年9月10日確認。