メインコンテンツにスキップ
自媒科技企業向けAI・開発から導入まで
日本語JA
プロジェクト相談
プロジェクト相談

企業AIプロジェクトWiki · 要件とビジネスシナリオ

機能要件

別名Functional requirement · 機能要求 · 機能仕様 · システム機能要件

定義

機能要件とは、指定したシステム階層に配分され、明示条件下でシステムが何を受領、検証、変換、保存、検索、計算、判断、制御、表示、送信、記録、阻止または復旧すべきかを、境界外から観測または検証できる結果とともに規定する規範的記述である。必要、原子的、一義的、実現・検証可能で、双方向追跡できる必要がある。

機能要件はシステムが何をするかを規定し、機能名の一覧ではない

承認、検索、知識 Q&A、帳票出力は能力名にすぎない。要件には、どのシステム階層が、どのトリガー、権限、データ状態、モードで、どの入力に対して何を行い、どの出力・状態を生じさせ、失敗時に何を保持するかが必要である。

機能要件はシステム、サブシステム、ソフトウェア、サービス、部品の各階層に置ける。上位の「申請を受けて処理する」を、本人確認、証拠検証、ルール判断、状態更新、通知へ分解できるが、階層を示し、下位項を上流理由へ結ぶ。

機能は何を行うか、性能は所定負荷・環境でどれほど速く、正確に、大規模に、安定して行うかを示す。併記しても、振る舞い義務と量的判定の双方を識別できるようにする。

機能要件が通常規定する振る舞い

機能はボタンを押した時だけ発生するものではありません。システムはイベントを受け、資料を検証し、状態を変え、外部サービスを呼び、通知を作り、失敗時には業務対象を保持または復元します。振る舞いを分けると、仕事が最初から最後まで閉じるかを確認できます。

入力受領と検証

フォーム、ファイル、事象、メッセージを受け、形式、必須性、来歴、署名、権限、状態を確認する。無効入力の拒否も機能である。

変換、計算、派生

版管理されたルールで正規化、集約、分類、計算、派生し、丸め、空値、時間、単位、ルール競合を扱う。

保存、検索、記録

業務情報を作成、読取、更新、保管、削除し、対象、条件、版、関連、履歴、変更不可記録を規定する。

判断とルール実行

適格性、経路、阻止、審査依頼、許可された推奨を扱い、結論、説明、実行副作用と決定権を分ける。

状態とモード制御

条件成立時の許容遷移、不正遷移の阻止、正常、縮退、保守、停止、復旧モードを規定する。

表示、通知、相互作用

対象役割への表示、説明、確認、訂正、通知と、出所、受信者、トリガー、確認、重複動作を定める。画面配置は通常設計である。

インターフェースと編成

外部呼出し・応答、多段処理の意味、順序、冪等、時間切れ、再試行、補償、部分成功を規定する。詳細プロトコルはインターフェース仕様で管理できる。

権限、保護、監査動作

本人確認、認可、職務分離、秘匿化、同意記録、監査事象など、セキュリティ・プライバシー目標を実行する機能を定める。

例外、縮退、復旧

証拠不足、依存障害、重複、競合、時間切れを検知し、拒否、状態保持、警報、人的引継ぎ、補償、再試行、復旧を定める。

実行可能な一件の機能要件に記録する事項

「調達申請を支援する」は機能名にすぎず、きっかけの後に何を行い、どの結果が正しいかを示しません。実行可能な要件は、主体、事前状態、入力、処理、出力、失敗結果を示し、適用ルールと権限へ結びます。

安定 ID と担当階層

サービス、システム、サブシステム、ソフトウェア、部品のどれが義務を負うかを示す。

規範主体と一つの動作

対象システムと規範語を用い、一件一義務とする。「対応する」「能力を提供する」を明確な動詞の代わりにしない。

トリガーと要求者

事象、定時処理、外部メッセージ、有権役割を示し、誰でも起動できない場合の権限を明記する。

事前条件、状態、モード

業務対象・依存の状態、既存データ、時間窓、正常・縮退モードを定め、未充足時の振る舞いも覆う。

入力、来歴、有効性

必須入力、権威情報、形式、版、権限、検証境界を示し、利用者申告、システム事実、外部参考を分ける。

処理規則と順序

承認済みルール、必要順序、原子性、優先を参照し、具体方式を強制する場合は設計制約の理由を残す。

出力と終了状態

返却物、受信者、保存記録、通知、状態変化または変えてはならない状態を示す。

例外、代替、禁止副作用

不足、無権限、競合、重複、時間切れ、部分失敗と、発生させてはならない決定、支払、送信、開示を定める。

出所、理由、配分、追跡

上流の場面、要件、ルール、リスクと、下流の子機能、インターフェース、設計、実装、証拠を結び、派生理由を残す。

検証方法と判定

検査、分析、実演、試験の方法、環境、役割、初期状態、入力分類、期待結果、重大失敗を定め、性能要件を関連付ける。

シナリオと上流要件から機能要件を導出する

上流要件は関係者が必要とする結果を示し、機能要件はその結果を安定して出すシステム動作を示します。正常、例外、情報不足の場面を順にたどり、状態変更、外部連携、人的引継ぎを見つけます。画面案から機能を写すだけでは足りません。

  1. 上流成果と境界を確認する

    承認済みステークホルダー、利用者、システム要件、ルール、リスクから始め、現画面や供給製品から需要を逆造しない。

  2. 端から端の場面を歩く

    正常、例外、不足、取消、重複、依存障害、人的引継ぎ、復旧経路の役割、入力、判断、記録、終了状態を追う。

  3. 必要な論理機能を識別する

    画面やマイクロサービスを決める前に、受領、検証、変換、保存、検索、判断、表示、送信、制御、復旧を抽出する。

  4. 入出力と状態をモデル化する

    各機能の入力、制御、出力、遷移、前後条件、失敗形態、影響を示す。活動、順序、状態モデルは漏れを示すが自動的に承認要件にはならない。

  5. ルール、権限、データ制約を適用する

    業務ルール、本人性、データ分類、インターフェース契約を機能へ写し、機能統制と性能・品質・工学制約を分ける。

  6. 分解、派生、配分する

    設計・検証可能な子機能へ分け、集合の十分性を確認し、インターフェース、構造、失敗分析から生じた機能を根拠付き派生要件にする。

  7. 反例と境界で妥当性確認する

    業務、利用者、運用、開発、試験、保護、インターフェース担当が合法・不正状態、空値、重複、順序逆転、権限変更、依存障害を確認する。

  8. 基準化し双方向追跡を保つ

    要件、モデル、ルール、TBD の指定版を承認し、変更時に上流成果、隣接状態、インターフェース、データ、品質、試験、運用への影響を追う。

機能要件をどの粒度まで分解するか

大きすぎれば一つの失敗が工程全体へ広がり、小さすぎれば業務結果と文脈を失います。単独で配分、検証、変更でき、同時にどのシナリオ段階を支えるか説明できる単位が実用的です。

親に外部観測可能な成果を残す

親機能はなぜ必要で外部に何をもたらすかを保ち、内部呼出し一覧にしない。

子を個別配分・検証可能にする

担当要素、インターフェース、失敗処理、検証方法が異なる動作は子要件に分け、担当を明示する。

原子的は文脈なしを意味しない

一つの主要義務にも必要条件は残る。過剰分割は条件と結果を切り離し、単独で理解不能にする。

親子の十分性と必要性を確認する

子集合が親を満たし、各子が親、制約、派生理由へ遡ること。無出所の便利機能は範囲・保守リスクである。

機能分解と部品分解を分ける

論理機能を先に識別し、構造により人、ソフト、ハード、サービスへ配分する。一機能は複数部品にまたがり得る。

配分と検証が成立する地点で止める

一義、実現可能、配分可能、設計可能、有限検証可能で、インターフェースと失敗が十分理解できれば、固定階層数によらず止められる。

機能要件基準前の品質ゲート

機能要件は直接実装とテストへ進むため、曖昧な言葉はすぐ担当者ごとの推測になります。正常経路だけでなく、無権限、重複要求、外部障害、有効結果なしの場合に業務状態が黙って変わらないことも確認します。

  1. 必要で上流根拠があるか

    各機能が承認成果、ルール、リスク、記録済み派生を支え、製品にあるからという理由ではない。

    上流要件、場面、ルール、派生理由を確認する。

  2. 主体、条件、振る舞い、結果が一つか

    誰がいつ何に対して何を行い、どの終了状態になるかの解釈が一致する。

    独立言い換え、反例、用語集で確認する。

  3. 正常、例外、禁止結果が完全か

    空、無効、重複、無権限、競合、時間切れ、依存障害、人的介入、復旧が明示される。

    場面・機能・状態網羅表を確認する。

  4. 階層と解決手段独立性が適切か

    正しい階層に配分され、根拠なく部品、製品、算法を固定しない。

    境界、構造判断、制約を確認する。

  5. ルール、データ、インターフェース、品質と整合するか

    判断、状態、用語、意味、権限、エラーが矛盾せず、必要な性能、保護、信頼性、利用品質へつながる。

    横断要件とインターフェースを審査する。

  6. 実現・検証可能か

    技術、データ、人、依存で実現でき、有限入力、初期状態、観測結果で適否を判定できる。

    実現性証拠と検証方法を確認する。

  7. 双方向追跡と変更影響が完全か

    上流動作に漏れなく対応し、下位機能に出所があり、変更から場面、インターフェース、状態、品質、試験、運用を追える。

    追跡、孤立項、影響報告を確認する。

調達申請サービスの機能要件構成例

以下の顧客と無関係な調達サービスで、「提出前に不足資料を見つける」を観察可能な動作へ分けます。画面表示だけでなく、ルール読込み、権限保護、下書き状態の保持、障害処理も含みます。IDと条件は記述方法の説明用です。

FR-101：提出準備を確認する

権限ある申請者が下書き提出を求めたとき、システムは要求時点の承認済み適用ルールで必須事実と証拠を確認し、充足、不足、ルール ID を返し、承認状態を変えないこと。

FR-102：無権限提出を拒否する

主体に組織代表権限がない、または申請状態が許可外なら、提出を拒否し、状態を保持し、主体、申請、方針版、理由、時刻を記録すること。

FR-103：不足を人へ引き継ぐ

証拠が読めない、権威ルール版が不明、資料が競合するとき、自動判断を止め、確認済み事実を保存し、指定審査キューへ送り、保留事項を説明すること。

FR-104：正式提出を作成する

FR-101 を満たし FR-102・103 が非該当の場合だけ、固有提出版を原子的に作り、下書きを提出済みにし、ルール・証拠版を記録して確認を一度送ること。

FR-105：重複要求を処理する

同じ申請版と冪等キーの再要求には初回結果を返し、二件目の提出、二重状態変更、重複通知を行わないこと。

FR-106：決定境界を保つ

完全性確認、資料要約、AI 説明は提出準備だけを支援し、調達承認、供給者選定、予算確保を行わないこと。これらは別の有権工程だけが行う。

設計、試験、受入、運用への接続

機能要件は、設計で担当部品が決まり、テストから証拠が戻り、運用で観察記録が残って初めてシステムへ入ります。受入後もこの関係を使い、障害時に要件から実装、ログ、外部依存、直近変更をたどれます。

要件とモデル

活動、状態、順序、ユースケース、データ流モデルで機能関係を示し、各要素を規範要件へ追跡し、モデル変更で影響審査を起動する。

要件と設計配分

どの人、プロセス、ソフト、ハード、外部サービスが機能を実現するか、インターフェースと取引境界を構造に記録する。

要件と検証網羅

各機能に方法と正常、境界、無効、無権限、重複、障害、復旧の網羅を持たせる。テストケースは証拠例で、要件の出所ではない。

要件と受入境界

受入基準は成果物、版、環境、業務標本の合否を選ぶ。内部子機能を顧客が全件受入しなくても、証拠は上位判定を支える。

要件と不具合・免除

失敗を要件 ID・版、環境、再現、重大度、処置、再試験へ結ぶ。延期は有権承認し、不具合現状に合わせた要件改稿を受入にしない。

要件と運用監視

重要機能の起動、成功、失敗、拒否、人的引継ぎ、副作用を、アクセスとプライバシーを守る証拠で観測できるようにする。

企業 AI は生成、ツール実行、人的権限を分けて機能要件化する

一回のAI回答の裏で、証拠検索、文章生成、業務状態を変えるツール呼出しが続く場合があります。各段階のリスクと失敗方法は違うため、「AIが処理する」と一文にまとめません。証拠の出所、助言だけの段階、権限や人の確認が必要な段階を分けます。

文脈組立てとアクセス过滤

主体、作業、対象を特定し、検索・モデル送信前に無権限データを除外し、実入力と版を記録する。プロンプトはサーバ側権限制御に代わらない。

検索と証拠選択

クエリ、許可資料、版・鮮度过滤、重複除去、競合表示、引用を定め、権威証拠不足時の経路を持つ。

生成と構造化出力

許可内容、必須項目、出所、事実と助言の区別、解析失敗、承認・権限・状態・根拠の捏造禁止を定める。

ルールとモデルの責任分離

適格性、権限、状態遷移、強制停止は検証可能なルールやコードで実行し、モデルは抽出、要約、説明で正式決定権を代替しない。

不足、競合、拒否

証拠欠落・競合、知識期限外、攻撃、出力構造不正、高リスク時に停止、状態保持、制限説明、人的・非 AI 経路を実行する。

ツールと副作用

検索、下書き、送信、書込、削除、承認を別々に規定し、引数、最小権限、確認、冪等、時間切れ、取消、結果検証を持つ。

人的審査と引継ぎ

人的作業を作る条件、提示する原資料と根拠、訂正・上書き、決定の戻し方、無応答時の安全状態を定める。

監査、フィードバック、版変更

組合せ版、入力分類、証拠、ルール結果、ツール、人的決定、重大失敗を記録し、モデル・知識・提示変更後の回帰と再承認に使う。

表現は変わっても重要な統制まで揺らしてはいけない

複数の言い方を許す時は、構造、必須内容、禁止結果を定め、反復実行で変動を見ます。一方、権限が通るか、状態が変わったか、情報不足で停止したかは、毎回決定的で反復検証できる結果が必要です。

機能要件と隣接概念の違い

機能、画面、ユーザーストーリー、業務ルール、テストケースは同じ作業項目に並びますが、システム動作、利用理由、組織制約、証明方法という別の問いに答えます。分けておけば、業務理由を保ちながら現在の画面設計を要件そのものに固定せずに済みます。

概念機能要件との境界
機能・特性名帳票、検索、AI アシスタントは分類名であり、機能要件は条件、振る舞い、観測結果まで規定する。
システム要件完全基準は性能、インターフェース、データ、品質、運用、制約も含み、機能要件は振る舞い分類の一つである。
利用者要件利用者ニーズと能力から相互作用・利用品質を導く。機能を派生し得るが、全内部動作ではない。
ユーザーストーリー役割、目標、価値の短い対話・計画用叙述で、一話に複数の機能・品質要件が必要になり、正式追跡には代わらない。
ユースケース・業務シナリオ複数手順、役割、システムの経路を述べ、機能要件は指定階層が負う原子的規範義務を抽出する。
業務プロセス人、システム、判断を含む組織の端から端の順序を示し、機能要件は対象システムへ配分された動作だけを規定する。
ビジネスルール業務の定義、許可、義務、禁止、判断を定め、機能要件は権威ルールをシステムがどう適用・支援するかを示す。
非機能・性能要件機能をどれほど良く行うかや品質・制約を定める。結果を返すことと、所定負荷で何秒以内かは別判定である。
インターフェース要件境界双方の意味、プロトコル、時序、責任を定める。呼出し・応答は機能だが、完全契約はより広い。
アルゴリズムと設計どう実現するかを示す。方式を強制するなら標準、リスク、相互運用の根拠を制約または派生として残す。
受入基準とテストケース受入基準は成果物の合否、テストは入力、手順、期待を定め、機能要件を検証するが置き換えない。
バックログ項目・作業増分の分析、設計、開発、検証作業を予定する。機能要件は製品基準に属し、複数作業・リリースにまたがり得る。

出典と適用範囲

本項はシステム・ソフトウェア要件工学の機能要件を扱う。すなわち、境界を定めたシステム、サブシステム、ソフトウェア項目またはサービスが、所定のトリガー、事前条件、状態、モード下で実行すべき機能、振る舞い、変換と、生成、保持または禁止すべき観測可能な結果を規定する要件である。「システムが何をするか」に答えるが、機能名、製品訴求、ユーザーストーリー、ユースケース、業務プロセス、ビジネスルール、アルゴリズム、インターフェース・画面設計、性能・非機能要件、完全なシステム・ソフトウェア仕様、受入基準、テストケースとは異なる。データ、保護、エラー、インターフェース振る舞いの分類は組織で異なるため、案件が分類を定め、実内容、優先度、数値、適用性は有権者が承認する。