基本情報の要件定義を機能要件・非機能要件と具体例で理解する

基本情報の要件定義は、業務で実現したいこと、システムにさせたい処理、守るべき品質や制約を分けると理解しやすくなります。「何を作るか」を決めるだけでなく、対象の範囲をそろえ、関係者が同じ条件で完成を判断できるようにする工程です。

この記事では、備品貸出システムを学習用の例にして、業務要件・機能要件・非機能要件の違いを整理します。要求分析から設計へのつながり、曖昧な希望を確認できる文へ直す方法、分類に迷う選択肢の読み方まで説明します。例に出す組織や数値条件は説明用に設定したもので、実在する導入事例や試験の公式基準ではありません。

基本情報の要件定義を分類する

要件定義は範囲と合意をそろえる

要件定義の出発点は、関係者の希望をすべて機能一覧に並べることではありません。まず、何の業務を改善するのか、誰が利用するのか、今回どこまでをシステム化するのかをそろえます。範囲が違ったまま「貸出を便利にする」と合意しても、担当者は返却管理まで含むと考え、開発側は申込みだけと考えるかもしれません。

IPAの基本情報技術者試験シラバスVer.9.2では、要件定義の目的や、業務・機能・非機能の要件、利害関係者による確認が扱われています。学習では用語の暗記に加え、どの視点の条件を決めている文章なのかを判断できることが大切です。

たとえば「カメラ、三脚、プロジェクターの学内貸出を対象とし、購入申請と修理費の精算は対象外」と決めれば、同じ「備品管理」でも境界が見えます。対象外を示すのは手抜きのためではなく、今回の成果に含むものと別途扱うものを関係者で共有するためです。

要件は文書に書くだけで完了ではありません。現場で実行できるか、目的に合っているか、関係者どうしで矛盾していないかを確かめ、必要な人の合意を得ます。承認者の名前だけを見るより、何の内容について誰が判断するのかを考えましょう。

要求分析と要件定義と設計の違い

要求分析では、利用者の発言の背景にある課題や必要性を調べます。「貸出表をアプリにしたい」という発言に対して、紙だから困るのか、記入漏れが多いのか、同じ備品への申込みが重なるのかを確認する段階です。最初の発言をそのまま実装仕様にすると、本当の困り事を残してしまいます。

要件定義では、分析した内容をもとに、業務やシステムに求める条件を具体化して合意します。たとえば「貸出可能な備品を検索できる」「貸出中の備品には新しい貸出を確定できない」と整理します。設計では、それらを実現する画面、データ、処理の構成などを具体的に組み立てます。

段階	備品貸出の例	答える疑問
要求分析	重複貸出が起きる場面と原因を調べる	何が困り事で、なぜ解決が必要か
要件定義	同じ備品を同時に二人へ貸し出さないと決める	何を満たせば目的に合うか
設計	貸出確定時の状態確認と更新の仕組みを決める	どのような構造で実現するか

この区別は、開発中に使う書類名を一対一で決めるためのものではありません。要求分析の結果を受けて要件を見直したり、設計上の制約が分かって再度調整したりすることもあります。実際の工程名や作成する資料の粒度は、組織や開発方法によって異なります。

「要求は希望、要件は合意済みの条件」と考えると学習の助けになります。ただし、両語に普遍的で厳密な訳し分けがあるとは限りません。IPAの要件定義の解説も用語上の注意を示しています。問題文に定義があれば、その文脈を優先して読みます。

業務要件は仕事のルールを決める

業務要件は、仕事として何を実現する必要があるかを示します。備品貸出なら「利用できるのは在籍する学生と教職員」「貸出期間は原則7日以内」「返却時は窓口担当者が破損の有無を確認する」といった条件です。画面の機能がなくても成立する、業務の対象やルールに注目します。

ここでは、システムで行う処理と、人が行う作業をまとめて捉えます。返却時の外観点検を人が担当するなら、点検そのものを自動化する必要はありません。一方、「担当者が点検済みの結果を登録する」は、業務を支えるシステムの機能へつながります。

現状のやり方を調べることと、今後もそのまま続けると決めることは別です。現在は電話で申込みを受けていても、将来の業務ではWeb申込みを受け付けるかもしれません。「現状」と「変更後」を区別し、変更後に誰が何を行うのかを明らかにします。

目標と業務ルールも分けると整理できます。「問い合わせを減らしたい」は目指す成果ですが、それだけでは仕事の流れが決まりません。「利用者は来室前に貸出可能な備品を確認する」「窓口は確定した申込みをもとに現物を渡す」とつなぐと、業務の姿が具体的になります。

機能要件はシステムの処理を決める

機能要件は、システムが提供する働きを示します。検索、登録、変更、承認、通知、集計など、「誰の操作やどんな出来事を受けて、何を処理し、何を返すか」で考えると具体化できます。画面に見えるボタンだけが機能ではなく、夜間の集計や他システムへのデータ連携も対象になります。

「備品を検索できる」だけでは、使う側と作る側で想像が分かれます。「利用者は備品の種類と利用希望日を指定し、その期間に貸出可能な備品の名称と受取場所を一覧で確認できる」と書けば、入力条件と出力内容がつながります。必要な条件は、業務で何を判断したいかから決めます。

登録では正常に進む場合だけでなく、入力が足りない場合、存在しない備品を指定した場合、権限がない場合も考えます。たとえば「返却予定日が受取日より前なら、貸出を登録せず、修正が必要な項目を示す」は、入力の検査と処理結果を表した機能要件です。

ただし、この段階でボタンの色やデータベースの索引まで一律に決める必要はありません。業務上、指定様式の帳票が必要ならその出力条件は要件になり得ますが、実現の細部は設計で検討できます。「画面について書いてあるからすべて設計」と機械的に判断しないようにしましょう。

選択肢の中に「在庫数を表示する」と「在庫一覧を短時間で表示する」が並ぶときは、前者は提供する働き、後者はその品質を問う表現です。同じ画面についての説明でも、文の中心が何を定めているかが異なります。

非機能要件は品質と制約を決める

非機能要件は、機能を提供するうえで必要な品質や制約などを定めます。応答の速さ、使える時間帯、障害時の復旧、運用方法、移行、安全性といった観点です。検索機能が存在していても、必要な時間に使えず業務が止まるなら、利用者の目的は満たせません。

確認の観点を増やす参考になるのが、IPAの非機能要求グレードです。IPAの要件定義資料にある非機能要求の分類では、システム基盤を中心に六つの大項目が示されています。次の例文は、その観点を備品貸出に当てはめて作成した学習用の例です。

観点	この例で確認したい条件
可用性	貸出窓口が開いている時間に使えるか
性能・拡張性	申込みが集中しても必要な速さで処理できるか
運用・保守性	障害を誰が把握し、どの手順で対応するか
移行性	従来の貸出中データをいつ、どう引き継ぐか
セキュリティ	権限のない人が他人の貸出情報を見られないか
システム環境・エコロジー	設置場所や電力などの条件を満たせるか

六分類は、あらゆる品質条件を完全に言い表す唯一の分類ではありません。特に、非機能要求グレードはシステム基盤を主な対象にしています。操作の分かりやすさなども含めて、このシステムで不足する観点がないかを別に確認する必要があります。

また、「速いほどよい」「絶対に止まらない」とだけ書くと、必要な水準と費用を比較できません。貸出時間外は停止してもよいのか、停止時は紙で代行できるのかなど、業務の影響から条件を決めます。すべての項目を最も厳しくすることが、そのままよい要件定義になるわけではありません。

セキュリティは文の目的で見分ける

分類で迷いやすいのが、セキュリティを実現するための機能です。「安全にする」は安全性に関する要求ですが、実現するにはログイン、アクセス制御、記録の保存などの具体的な働きが必要になります。そのため、同じ対策を機能の側から説明する場合と、非機能の側から説明する場合があります。

たとえば「担当者だけが利用者全員の貸出一覧を閲覧できる」は、閲覧権限を制限する安全性の条件です。一方、「管理者は担当者の権限を追加・解除できる」は、権限管理というシステムの働きを説明しています。単語に「認証」「権限」があるだけで分類を即決するより、何を確定する文章かを読み取ります。

基本情報の選択肢を読むときも、問題が「機能として何を提供するか」を聞いているのか、「安全性や運用条件として何を決めるか」を聞いているのかをそろえましょう。分類の境界が重なることを知っていれば、単語だけの丸暗記に頼らず、選択肢全体から判断できます。

基本情報の要件定義を具体化する

曖昧な要求を確認できる文に直す

具体的な要件は、読んだ人が同じ条件で確認できる必要があります。「使いやすくする」「すぐ表示する」「適切に管理する」は方向性として理解できても、何を満たしたらよいかが分かれます。最初から数値を足すのではなく、対象の利用者と作業場面を特定するところから始めます。

学習用には「誰が」「どの条件で」「何をする」「どんな結果になる」「何で確認する」の五つを補うと整理しやすくなります。すべての文章を同じ書式にする必要はありませんが、抜けた要素を見つけるための問いとして使えます。確認方法は実行によるテストに限らず、文書の確認や手順の実演なども考えられます。

曖昧な記述	具体化した学習用の例
備品を簡単に探せる	利用者は種類と希望日で検索し、貸出可能な備品の名称と受取場所を確認できる
間違った日付を防ぐ	返却予定日が受取日より前なら登録せず、その日付項目に修正を促す
記録をきちんと残す	担当者による貸出確定と取消しについて、実行者と実行日時と対象備品を記録する

一つの文に何種類もの条件を詰め込むと、一部だけ満たしたときの扱いが曖昧になります。「速く検索できて、安全で、返却も便利」と書くより、検索の機能、応答時間、閲覧権限、返却の手順に分けましょう。それぞれに確認方法を結び付けられるので、未確定の箇所も見つけやすくなります。

ここで使う例文は、実務向けの完全な要件定義書ではありません。日付の基準、休館日の扱い、端末環境などは実際の業務に合わせて追加する必要があります。文章を長くすることより、読み手が異なる結果を想像する余地を減らすことを意識してください。

備品貸出を一つの例で具体化する

まず、利用者の声として「窓口に行ったら備品がなく、手続をやり直した」を考えます。要求分析では、利用状況を事前に確認できないのか、貸出が二重に確定するのか、故障品も貸出可能として数えているのかを調べます。同じ困り事でも、原因によって必要な対策が変わります。

業務要件としては「利用者は受取前に貸出の確定状況を確認できる」「窓口は貸出確定済みの備品だけを渡す」「故障中の備品は貸出対象に含めない」と決められます。現物を渡す人の判断と、データ上の状態をそろえるためのルールです。

機能要件にすると「担当者は備品を貸出可能・貸出中・故障中に分類して登録できる」「利用者への検索結果には貸出可能な備品だけを示す」「確定後は対象の備品を貸出中として扱う」と具体化できます。状態名はこの例の設定であり、どのシステムでも同じ三種類にすべきという意味ではありません。

さらに、二人がほぼ同時に同じ備品を申し込む場面を考えます。両者の検索画面に「貸出可能」と表示されていても、両方の貸出を確定してよいことにはなりません。「同一の備品について貸出確定は一件とし、後から確定しようとした利用者には確定できなかったことを示す」と、競合時の結果まで定めます。

具体的な仕組みとして、データの更新をどう制御するかは設計で検討します。要件の段階では、利用者から見た結果や業務上守る条件を明確にしておくことが中心です。正常な一人の操作だけで終えず、同時操作、取消し、故障が見つかったときも確認すると、分類が実際の動きに結び付きます。

性能は測定条件まで決める

「検索を2秒以内で終える」という数値だけでは、まだ確認条件が十分ではありません。利用者が一人のときか、何人も使うときか、備品が何件あるか、どの時点から計り始めるかによって結果が変わるためです。数値と一緒に、測定する場面をそろえる必要があります。

ここでは仮に、「備品データ1万件、同時利用者50人の条件で、指定した検索を200回実行し、検索操作の開始から結果一覧の表示完了までが2秒以内のものを190回以上とする」と設定します。合否を決めるなら、使用端末、ネットワーク、検索条件の組合せなども事前にそろえます。これらは説明用の条件で、一般的な推奨値ではありません。

この条件で、2秒以内が192回なら回数の基準を満たし、188回なら満たしません。平均が2秒以内であることとは別の判定です。多くの検索が速くても、一部だけ非常に遅い場合がありますし、平均だけを記録していては「190回以上」を確かめられません。求める指標と確認する記録を対応させます。

「同時利用者50人」と「検索を200回」も同じ意味ではありません。前者は測定時の負荷条件、後者は判定に使う測定回数です。どの利用者がいつ操作するかをそろえなければ、再測定で条件が変わってしまいます。基本情報の学習でも、負荷の条件と達成すべき性能を区別すると文章を読みやすくなります。

可用性でも同様です。「稼働率を高くする」だけでなく、対象時間、計画停止の扱い、障害時に何を復旧とみなすかを決めます。指標だけを先に覚えるのではなく、業務がどの程度の停止まで受け入れられるのかと結び付けるのがポイントです。

矛盾と未確定事項を残さず扱う

要件を個別に読むと正しく見えても、組み合わせると矛盾する場合があります。たとえば「すべての申込みに担当者の承認を必要とする」と「利用者は申込み直後に必ず貸出確定を確認できる」は、担当者が不在でも即時確定するのかという問題を含みます。条件を分けずに両方を採用すると、設計側で勝手な解釈が必要になります。

この場合は「申込み受付」と「貸出確定」を分け、受付直後は受付済み、担当者が承認した後は確定済みと表示する案を関係者で検討できます。即時確定が業務上不可欠なら、承認を省く対象を決める案もあります。どちらを選ぶかは、業務の目的や責任に照らして合意します。

優先順位も、「全部必要」の一言で終えず、満たさない場合の影響から決めます。開館時間中の貸出が止まる問題と、集計表の見た目が整わない問題では影響が異なります。新しい希望が出たときは、追加する内容だけでなく、既存の要件、確認方法、運用への影響を見ます。

すぐに決められない事項は、決定済みのように書かず、誰が、何を調べ、いつまでに判断するかを示します。「返却期限は後で考える」のまま放置すると、検索、通知、遅延の扱いまで決まりません。未確定であることを明らかにし、影響する範囲を共有することも要件の管理です。

要求の変更への向き合い方を開発手法と結び付けたい場合は、基本情報のアジャイルとスクラムの解説で、進め方の違いも確認できます。ここでは手法の優劣より、変更後も必要な条件と関係者の認識をそろえることを押さえましょう。

要件から確認方法までつなげる

要件定義書は、完成した書類の厚さで評価するものではありません。背景、対象範囲、業務ルール、機能、非機能、確認の考え方、未確定事項がつながっていると、設計やテストへ引き継ぎやすくなります。IPAのユーザのための要件定義ガイド第2版の案内でも、業務部門の関与や成果物の整合性を確認する観点が示されています。

学習用には、一つの要求に番号を付け、どの要件と確認方法につながるかを書き出してみてください。たとえば「二重貸出をなくす」という目的から「貸出確定は同一備品で一件だけ」という要件につなぎ、「同じ備品を二人が同時に確定しようとしても確定は一件になる」という確認を対応させます。

このように関連を追える性質をトレーサビリティと呼びます。番号を付けるだけで十分なわけではなく、目的から要件、要件から設計や確認へたどれることが大切です。取消しに関する業務ルールが変わったときも、影響する機能や確認項目を探しやすくなります。

確認は、書いてあるとおりに動くかと、その条件が目的に適しているかの両方で考えます。「確定は一件だけ」は守れていても、窓口で別の人へ現物を渡せば、業務の問題は残ります。システムの動作確認と業務手順の確認をつなげ、利用者、窓口担当者、運用担当者がそれぞれの立場で見直します。

要件をテスト条件へ落とす考え方をさらに練習したい場合は、ブラックボックステストや境界値分析の解説も役立ちます。また、決めた条件を外部への依頼へつなぐ流れは、RFP・RFI・RFQと調達手順の解説で確認できます。

分類と工程を確認する練習問題

次の問題は理解を確かめるために作成したオリジナル問題で、IPAの過去問題ではありません。最初に答えを見る前に、文章のどの部分を根拠にしたかを一言で説明してみましょう。分類名だけでなく理由まで言えると、表現が変わっても判断しやすくなります。

問題：最も適切な分類を考えてください。ア「備品を借りられるのは在籍する学生と教職員とする」。イ「利用者は自分の貸出中の備品を一覧で表示できる」。ウ「窓口が開いている平日9時から17時は利用できるようにする」。エ「貸出状況を画面で確かめられない原因を、担当者への聞き取りで調べる」。オ「貸出状態を保存する表と、更新処理の構成を決める」。

アは業務要件です。利用資格という業務の対象を決めています。イは機能要件です。本人の貸出一覧を表示するという働きを決めています。ウは非機能要件です。提供する機能ではなく、利用できる時間の条件を定めています。エは要求分析に当たり、現状の課題や原因を調べています。オは設計に当たり、要件を実現する構造や処理方法を具体化しています。

書き換え問題：「返却を便利にする」を具体化してください。すぐに「返却ボタンを作る」と決めず、誰が何に困っているかを補ってみます。利用者が返却済みか確かめられない問題なのか、窓口が返却記録を残せない問題なのかで、必要な機能が違います。

一つの解答例は「担当者は受け取った備品の点検を終えた後、対象の貸出を返却済みに登録できる。利用者は自分の貸出一覧で返却済みと分かる」です。ここでは担当者と利用者の役割、登録の条件、表示する結果が含まれています。さらに、点検で故障が見つかった場合の状態や、間違えて登録した場合の修正権限を確認できます。

判定問題：検索の平均時間が1.8秒なら合格ですか。この記事の「200回中190回以上が2秒以内」という条件では、平均だけで合格と判断できません。2秒以内だった回数と測定条件の記録が必要です。数値があるだけで十分と思わず、要件と根拠の対応まで確認する練習になります。

基本情報の要件定義のまとめ

基本情報の要件定義は、業務要件で仕事の対象とルール、機能要件でシステムの働き、非機能要件で品質や制約を考えると整理できます。同じ対象について書かれた文章でも、何を決めているかによって分類が変わります。

要求分析は課題や必要性を調べ、要件定義は満たす条件と範囲をそろえ、設計は実現の構造を具体化します。曖昧な要求に出会ったら、利用者、場面、処理、結果、確認方法を補い、例外や矛盾がないかを見直してください。

次は、選択肢を読んで「業務・機能・非機能のどれか」「分析・定義・設計のどの段階か」を自分の言葉で説明してみましょう。理解を問題で確かめたい場合は、基本情報の過去問演習へ進み、誤った選択肢もどの条件を示しているか考えてみてください。