当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
資格の勉強や現場の会話で「ソフトウェア要件定義」という言葉が出てきて、システム要件定義と何が違うのか分からなくなっていませんか。
結論から言うと、ソフトウェア要件定義は、システムの中のソフトウェアの部分に絞って「何をするか」を細かく決める工程です。
この記事では、同じ機能を工程ごとに書き分けた例を使って、決める内容の細かさの違いをつかんでいきます。
ソフトウェア要件定義とは？システムの中の「ソフトの部分」を決める工程
ソフトウェア要件定義は、システム全体の要件のうち、ソフトウェアが受け持つ部分について、機能や入出力、守るべき条件を決める工程です。開発側が技術の言葉で書くのが特徴です。
システムは、サーバーや端末などのハードウェアと、その上で動くソフトウェア、さらに人の作業が組み合わさってできています。
ソフトウェア要件定義とは、そのうちソフトウェアに任せる部分について「何をするか」を決める工程のことです。
ソフト要件定義、ソフトウエア要件定義と書かれることもありますが、指している中身は同じです。
ここで決めた内容は、次のソフトウェア方式設計やソフトウェア詳細設計の土台になります。
要件定義という言葉そのものから確かめたい方は、要件定義とは？意味をわかりやすく解説を先に読んでおくとスムーズです。
要件定義の段階は3つに分かれている
『要件定義って一回で終わるものでは？』と思う方も多いはずです。
実は、IPAの「共通フレーム2013」では、要件定義と名の付く工程が段階的に並んでいます。
| 工程 | 決める人の中心 | 書く言葉 |
|---|---|---|
| 要件定義プロセス | 利用者・発注側 | 業務の言葉（誰が、いつ、何を） |
| システム要件定義 | 開発側（発注側と合意） | システムの言葉（機能、性能、外部とのつながり） |
| ソフトウェア要件定義 | 開発側 | ソフトウェアの言葉（処理、データ、入出力、条件） |
共通フレーム2013は、ソフトウェアのライフサイクルで使う用語と作業の区切りをそろえるための枠組みです。
発注側と開発側で「要件定義」の意味がずれないよう、共通の物差しとして使われています。
システム要件定義とソフトウェア要件定義はどう違う？
システム要件定義はシステム全体として何ができるかを決め、ソフトウェア要件定義はその中でソフトウェアが何をするかを決めます。間にシステム方式設計が入り、どこをハードウェア、どこをソフトウェアに任せるかが分けられます。
共通フレーム2013の工程を並べると、ソフトウェア要件定義は次の位置にあります。
- 企画プロセス
- 要件定義プロセス
- システム要件定義
- システム方式設計
- ソフトウェア要件定義
- ソフトウェア方式設計
- ソフトウェア詳細設計
- 実装とテスト
ポイントは、システム要件定義とソフトウェア要件定義の間に、システム方式設計が挟まっていることです。
システム方式設計で、システム全体をハードウェア、ソフトウェア、人の作業に分けて、全体の構成を決めます。
その分け方が決まってはじめて、ソフトウェアに任せる部分の要件を細かく書けるんです。
システム要件定義の書き方はシステム要件定義とはで、工程全体の位置づけは要件定義プロセスとは（開発工程の中の位置づけ）で詳しく扱っています。
ハードウェアの要件定義との分担
システム方式設計で分けられたハードウェアの部分は、別にハードウェアの要件として決めていきます。
例えば、端末の画面の大きさ、サーバーの台数や置き場所、ネットワークのつなぎ方などです。
| 分ける先 | 決める内容の例 |
|---|---|
| ソフトウェア | 入力の受け付け、データの登録と検索、通知の送信、権限の判定 |
| ハードウェア | 端末の種類、サーバーの構成、ネットワークの経路、予備の機器 |
| 人の作業 | 端末の電源を入れる、紙で受け付けた分を入力する |
サーバーやネットワークなどの基盤の要件は、インフラ・基盤の要件定義で詳しく紹介しています。
同じ機能で並べると分かる「粒度の違い」
同じ要望でも、工程が進むほど主語が「人」から「システム」、そして「ソフトウェアの処理」へと変わります。書き方の細かさを並べて見ると、違いがすっと入ってきます。
言葉の説明だけだと、どうしてもピンと来にくいですよね。
ここでは架空の題材として「会社の受付に端末を置き、来客が自分で受付をすると担当者に知らせが届く仕組み」を作る場合で並べてみます。
| 工程 | 書き方の例（来客受付の場合） |
|---|---|
| 要件定義プロセス | 来客は受付で待たずに自分で受付を済ませ、担当者はすぐに来客に気づける |
| システム要件定義 | 受付端末で来客の会社名と担当者名を入力でき、担当者に到着の知らせを送る |
| ソフトウェア要件定義 | 担当者名を入力途中から候補表示し、確定すると来客記録を登録して、担当者あてに通知を送る |
ソフトウェア要件定義になると、「候補表示」「来客記録の登録」「通知の送信」のように処理の単位まで分かれていますよね。
もう一段細かく、ソフトウェア要件定義の中身を書き出すと次のようになります。
| 項目 | ソフトウェア要件の記入例（例） |
|---|---|
| 入力 | 来客の会社名、氏名、担当者名、人数を受け付ける |
| 処理 | 担当者名は社員の一覧と照らし合わせ、一致しない時は受付の代表あてに切り替える |
| 出力 | 担当者あてに来客の到着を知らせ、来客記録を一覧画面に表示する |
| データ | 来客記録は受付日時と担当者をひも付けて保存する |
| 外部とのつながり | 社員の一覧は人事のデータから毎朝取り込む |
| 守るべき条件 | 来客の個人情報は、担当者と受付の管理者だけが見られる |
『ここまで細かいと、もう設計なのでは？』と感じた方もいるかもしれません。
違いは、「何をするか」を決めているか、「どう作るか」を決めているかです。
画面の部品の配置や、プログラムをどう分けるかはソフトウェア方式設計や詳細設計の役目になります。
品質の条件も、工程ごとに細かくなる
粒度が変わるのは、機能だけではありません。速さや守り方といった品質の条件も、工程が進むほど具体的になります。
| 工程 | 品質の条件の書き方（来客受付の場合・例） |
|---|---|
| 要件定義プロセス | 来客を受付で待たせない |
| システム要件定義 | 受付の確定から担当者への知らせまでを、待たせない速さで行う |
| ソフトウェア要件定義 | 通知の送信に失敗した時は再送し、それでも届かない時は受付の代表に切り替える |
ソフトウェア要件定義では、うまくいかなかった時の動きまで書いているのが分かりますよね。
会話にすると、こんなやり取りがよく出てきます。
「担当者が会議中で通知に気づかなかったら、どうしますか？」と開発側が聞きます。
「一定の時間がたっても反応がなければ、受付の代表に知らせてほしいです」と発注側が答えて、はじめてソフトウェアの処理として書ける形になります。
こうした例外の動きは、システム要件定義の段階では書かれていないことも多いです。ソフトウェア要件定義で気づいたら、発注側に確かめてから書き足しておきましょう。
ソフトウェア開発の要件定義で決めることと、確かめ方
ソフトウェア要件は、テストで合否を判断できる書き方にしておくことが大事です。あいまいな言葉が残っていないかを、書き終えた後に見直してみてください。
ソフトウェア開発の要件定義で決めることは、主に次のとおりです。
- 機能（どんな処理をするか、どんな時にエラーにするか）
- 入出力（何を受け取り、何を返すか、画面や帳票に何を出すか）
- データ（何を保存し、どの項目でつなぐか）
- 外部とのつながり（他のシステムや機器と何をやり取りするか）
- 品質の条件（応答の速さ、扱える件数、権限、記録を残す範囲）
良い要件になっているか確かめるチェック
要求工学の国際規格ISO/IEC/IEEE 29148では、良い要件の性質として次のようなものがよく挙げられます。
- 必要な要件だけが書かれているか確かめる
- 読む人によって解釈が分かれないか見直す
- テストで合否を判断できる書き方にする
- 実現できる内容になっているか開発側で確かめる
- 他の要件と矛盾していないか照らし合わせる
- 1つの文で1つのことだけを言う
- どの上位の要件から来たのかをたどれるようにする
例えば「担当者をすぐに呼び出せる」は、読む人によって「すぐ」の受け取り方が変わります。
「受付を確定したら、担当者あてに到着の知らせを送る」と書けば、テストで確かめられる形になります。
システム要件をそのまま写して、ソフトウェア要件とした気になってしまう。主語がシステム全体のままだと、ソフトウェアの担当範囲があいまいになります。どの処理をソフトウェアが受け持つのかまで書き分けておきましょう。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
よくある相談に答えます
資格の勉強をしている方や、開発の現場に入ったばかりの方から寄せられがちな相談を、要点だけまとめて答えます。
ソフトウェア要件定義、方式設計、詳細設計はそれぞれ何をするの？
ITパスポートなどの勉強中に、この3つの違いで手が止まる方は多いです。
ひとことで言うと、要件定義は「何をするか」、方式設計は「どんな部品に分けるか」、詳細設計は「部品の中をどう作るか」を決めます。
来客受付の例なら、要件定義で「担当者に通知を送る」と決めます。
方式設計で「受付の部品、通知の部品、記録の部品」に分け、詳細設計で通知の部品の中の手順を決める、という流れです。
要求定義、要求分析、要件定義、要件分析は何が違う？
似た言葉が多くて混乱しますよね。
要求は利用者の「こうしたい」、要件はその中からシステムで実現すると合意したこと、という区別で考えると分かりやすくなります。
要求を集めて整理するのが要求定義や要求分析で、それを実現する内容に絞り込むのが要件定義や要件分析です。呼び方は会社によって揺れるので、現場の使い方に合わせてください。
文系出身でも、要件定義の仕事で力を活かせる？
『プログラムの知識がないと、要件定義は無理かな…』と心配する方もいます。
要件定義では、相手の話を聞く力や、業務を理解する力、文章で正確に書く力が大きく役立ちます。
ただ、ソフトウェア要件定義は技術の言葉で書く工程なので、ITの基礎知識も少しずつ身につけておくと安心です！
よくある質問
ソフトウェア要件定義とは、ひとことで言うと何ですか？
システムの中でソフトウェアが受け持つ部分について、機能や入出力、データ、守るべき条件を決める工程です。どう作るかではなく、何をするかを技術の言葉で決めます。
システム要件定義とソフトウェア要件定義の違いは何ですか？
システム要件定義はシステム全体として何ができるかを決め、ソフトウェア要件定義はその中でソフトウェアが何をするかを決めます。間にあるシステム方式設計で、ハードウェアとソフトウェアの分担が決まります。
ソフトウェア要件定義は誰が書きますか？
開発側が中心になって書くことが多いです。ただ、業務の判断が必要な箇所は発注側に確かめながら進めます。
小さな開発でもソフトウェア要件定義は分けて行いますか？
小さな開発では、システム要件定義とまとめて1つの文書にすることもあります。分けるかどうかより、ソフトウェアが受け持つ処理が書き分けられているかを大事にしてください。
ハードウェアの要件定義は、ソフトウェア要件定義と同じ担当者が行いますか？
案件によって変わります。サーバーやネットワークの部分はインフラエンジニアが担当し、ソフトウェアの担当者と方式設計の段階ですり合わせることが多いです。端末の操作性など両方にまたがる要件は、どちらで書くかを最初に決めておくと漏れを防げます。
まとめ
- ソフトウェア要件定義は、ソフトウェアが受け持つ部分の「何をするか」を決める工程
- システム要件定義の後、システム方式設計でハードウェアとの分担が決まってから行う
- 工程が進むほど、主語が人からシステム、ソフトウェアの処理へと細かくなる
- 入力、処理、出力、データ、外部とのつながり、守るべき条件を書き出す
- テストで合否を判断できる書き方になっているかを見直す
コメント