// シス担のミカタ
スコープ管理

機能要件 きのうようけん

要件定義非機能要件システム開発スコープ仕様書RFP
機能要件について教えて

簡単に言うとこんな感じ！

「このシステムで○○ができること」という、システムに”させたいこと”のリストだよ！「注文できる」「在庫を検索できる」「請求書を印刷できる」みたいな、動作・操作・処理を具体的に書き出したものが機能要件なんだ。

機能要件とは

機能要件（Functional Requirements）とは、システムやソフトウェアが「何をするか」を定義した要件のことです。ユーザーやビジネスの目的を達成するために、システムが提供しなければならない具体的な機能・動作・処理を明文化したものです。

たとえば「ユーザーがIDとパスワードでログインできる」「商品をカートに追加できる」「月次の売上レポートをCSVで出力できる」といった記述が、すべて機能要件にあたります。システム開発の出発点となる要件定義フェーズで洗い出し、発注側（お客様）と開発側（ベンダー）が合意する非常に重要なドキュメントです。

機能要件がしっかり定義されていないと、「頼んだはずの機能がない」「思っていた動きと違う」というトラブルが起きやすくなります。発注側の担当者が「何を作ってほしいか」を言葉にして伝えるための、設計図の言語版と考えるとわかりやすいでしょう。

機能要件の構造と書き方

機能要件は「誰が・何を・どうする」の形式で書くと、漏れや誤解が減ります。

要素説明例
主体（Actor）誰が操作するか一般ユーザー、管理者、外部システム
操作（Action）何をするか登録する、検索する、承認する
対象（Object）何に対して商品情報、注文データ、ユーザーアカウント
条件（Condition）どんな状況でログイン済みの場合、在庫が1以上の場合
結果（Result）どうなるか画面に一覧が表示される、メールが送信される

機能要件の書き方テンプレート

よく使われる書き方が「〜できること」形式です。

【機能ID】 F-001
【機能名】 商品検索
【概要】   ユーザーがキーワードで商品を検索できること
【詳細】   ・商品名・商品コード・カテゴリで絞り込みできること
           ・検索結果は最大100件まで表示すること
           ・在庫ゼロの商品はグレーアウト表示すること
【利用者】 一般ユーザー（ログイン前でも利用可能）

機能要件の分類（粒度の3段階）

要件は粒度（どれだけ細かいか）によって3段階に整理されます。

粒度名称例
粗い業務要件受注管理ができる
中間機能要件注文をステータス別に一覧表示できる
細かい仕様・設計ステータスは「受注済・出荷済・完了・キャンセル」の4種類

歴史と背景

  • 1960〜70年代: 大型コンピュータの時代。プログラマーが「何を作るか」を口頭で決めることが多く、認識齟齬によるトラブルが頻発した
  • 1970年代後半: ソフトウェア工学の発展とともに、要件定義という工程が体系化され始める。ウォーターフォールモデルの普及とともに文書化が標準化
  • 1984年: IEEE 830として「ソフトウェア要件仕様書（SRS）の推奨プラクティス」が制定。機能要件と非機能要件を分けて記述する方法が普及
  • 1990年代: オブジェクト指向開発の普及とともに、ユースケース（誰が・何をするか）という形式が機能要件の記述方法として広まる
  • 2000年代: アジャイル開発の台頭により、「ユーザーストーリー（User Story）」形式（「〜として、〜したい。なぜなら〜だから」）が機能要件の軽量な記述方法として普及
  • 現在: ウォーターフォールでもアジャイルでも、機能要件の洗い出しは開発成功の鍵として重視され続けている

機能要件 vs 非機能要件

機能要件と対になる概念が非機能要件です。「何をするか」が機能要件、「どのくらいうまくするか・どういう品質で動くか」が非機能要件です。

機能要件 と 非機能要件の比較 機能要件 Functional Requirements ✔ ログインできる ✔ 商品を検索できる ✔ 注文を確定できる ✔ 請求書を印刷できる ✔ 在庫数を更新できる 💡「何ができるか」を定義 ユーザーが直接体験する機能 非機能要件 Non-Functional Requirements ✔ 3秒以内に応答する（性能） ✔ 99.9%稼働する（可用性） ✔ 1000人同時接続できる（拡張性） ✔ 通信を暗号化する（セキュリティ） ✔ 直感的に操作できる（UX） 💡「どの品質で動くか」を定義 ユーザーが感じる体験の質 vs

よくある失敗として、機能要件ばかり詳しく決めて、非機能要件を曖昧にしてしまうことがあります。「動くけど遅すぎて使えない」「セキュリティが甘くて情報漏洩した」という問題は、非機能要件の定義不足が原因です。

アジャイル開発でのユーザーストーリー形式

アジャイル開発では、機能要件を次のようなユーザーストーリー形式で書くことが多いです。

As a （ユーザーの役割）,
I want to （やりたいこと）,
So that （なぜそれをしたいか・目的）.

例：
As a 購買担当者,
I want to 発注履歴をCSVで出力したい,
So that 月次の経費集計作業を効率化したい.

関連する規格・RFC

規格番号内容
IEEE 830-1998ソフトウェア要件仕様書（SRS）の推奨プラクティス。機能要件・非機能要件の記述方法を定義
ISO/IEC 25010ソフトウェア品質モデル（SQuaRE）。機能適合性・性能効率性など品質特性を体系化
ISO/IEC/IEEE 29148要件エンジニアリングのプロセスと原則を定義した国際規格（2018年版）

関連用語