--- title: "ソフトウェア要件定義書とは？SRSの構成とISO/IEC/IEEE 29148の記載項目を解説" url: "https://www.issoh.co.jp/column/details/18678/" published: 2026-10-21 updated: 2026-10-21 categories: ["Webシステム"] publisher: "株式会社一創" --- # ソフトウェア要件定義書とは？SRSの構成とISO/IEC/IEEE 29148の記載項目を解説 ソフトウェア要件定義書は、開発するソフトウェアが何をどの水準で満たせば合格かを、テストで確かめられる文の集まりとして書いた文書です。英語ではSoftware Requirements Specification、略してSRSと呼ばれ、国際規格ISO/IEC/IEEE 29148:2018と、それを翻訳したJIS X 0166:2021に章立てと記載内容の指針があります。この記事では、29148が定める4種類の要件仕様書の中でSRSがどこに位置するか、SRSの章ごとに書く項目、要件文の書き方と属性の付け方を整理しました。あわせて、業務要件定義書やシステム要件定義書との書き分けと、規格どおりのSRSを作るべき案件の見極めまで扱います。 ## まとめ：ソフトウェア要件定義書は29148の章立てを型に検証できる文で書く ソフトウェア要件定義書（SRS）は、システム要件のうちソフトウェアが受け持つ部分を、序論・要件・検証の3つの章に分けて書く文書です。かつて定番だったIEEE 830-1998はすでに置き換えられており、2026年10月時点で参照すべきはISO/IEC/IEEE 29148:2018と、内容が同一のJIS X 0166:2021です。 書き方の要は2つ。要件を「shall」を使った1文1要件で書くこと、そして要件ごとに識別子・出典・検証方法を持たせることです。この2つがあれば、要件定義書がそのまま受入テストの基準表になります。 ただし、全章立てを規格どおりに埋める必要がある案件は限られます。請負契約で受入基準が検収に直結する案件、複数の開発会社にソフトウェアを分けて発注する案件、保守を別会社へ引き継ぐ案件では正式なSRSを作ることが必要です。SaaSの設定が中心の導入や、バックログで要件を回すアジャイル開発なら、要件文の型と属性だけを借りた簡略版で足ります。 ## ソフトウェア要件定義書の位置づけとISO/IEC/IEEE 29148が定める4つの仕様書 ### BRS・StRS・SyRS・SRSの4文書と日本の要件定義書との対応関係 29148は要件を書く文書を1つに限っていません。[日本規格協会が公開しているJIS X 0166:2021のプレビュー](https://webdesk.jsa.or.jp/preview/pre%5Fjis%5Fx%5F00166%5F000%5F000%5F2021%5Fj%5Fed10%5Fch.pdf)の目次を見ると、9.3から9.6にかけて4種類の仕様書の内容が順に規定されています。 | 規格上の文書 | JISの節 | 国内で近い文書 | | -------------- | ----- | ----------- | | BRS ビジネス要件仕様 | 9.3 | 企画書・業務要件定義書 | | StRS 利害関係者要件仕様 | 9.4 | 要求定義書 | | SyRS システム要件仕様 | 9.5 | システム要件定義書 | | SRS ソフトウェア要件仕様 | 9.6 | ソフトウェア要件定義書 | 右端の列は規格の定めではなく、国内の受託開発で通じる呼び方に対応づけたものです。業務の目的や新しい業務の姿はBRSとStRSの領分で、国内では[業務要件定義書の8つの記載項目](https://www.issoh.co.jp/column/details/16307/)として書かれることが多い内容です。SRSは4文書の最下流にあたり、上の3文書で決まったことをソフトウェアの振る舞いに落とします。 ### IEEE 830から29148とJIS X 0166へ移った規格の版と改訂予定 SRSの書き方を調べると、今もIEEE 830のテンプレートが多く見つかります。[IEEE SAのIEEE 830-1998のページ](https://standards.ieee.org/ieee/830/1222/)では状態がSuperseded Standardとなっており、「Superseded by ISO/IEC/IEEE 29148:2011」と明記されています。29148:2011はIEEE 830に加え、IEEE 1233とIEEE 1362も統合した規格です。 現行版は2018年11月発行の第2版です。[ISOの29148:2018のページ](https://www.iso.org/standard/72089.html)によると、全92ページで価格はCHF 227。2024年に見直しを経て現行版として確認されていますが、次版のDIS 29148が開発中で、数か月以内に置き換わる見込みと表示されています（2026年10月21日時点）。国内ではJIS X 0166が2014年に制定され、2021年9月21日の改正で29148:2018と一致する内容になりました。 ### 共通フレーム2013のソフトウェア要件定義プロセスで作られる文書 国内の工程名で言えば、ソフトウェア要件定義書は共通フレーム2013の「2.4.2 ソフトウェア要件定義プロセス」の成果物です。[IPAの共通フレーム2013第3部ガイダンス抜粋](https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000062659.pdf)は、2.4.2で利用者集団からのヒアリングを勧め、外部インタフェースの例として電文・ファイル・データベースと、画面・帳票を挙げています。 業務要件・システム要件・ソフトウェア要件の3層がどう分かれるかは、[システム要件定義と3層の要件の違い](https://www.issoh.co.jp/column/details/18676/)で詳しく扱いました。ここで押さえるのは1点だけで、ソフトウェア要件定義書は2.4のソフトウェア実装プロセスに置かれた、開発側が主に書く文書だということです。 ## 29148準拠のソフトウェア要件定義書の章立てと各章に書く記載項目 29148本文は有償のため、ここでは要件管理ツールReqViewの開発元が[29148:2018に基づくSRSの作例](https://www.reqview.com/doc/iso-iec-ieee-29148-srs-example/)として公開している文書の章立てを使って説明します。大きくは序論・要件・検証・補足情報・参考文献の5章です。 ### 序論の章で書く目的・範囲・製品の位置づけと9種類のインタフェース 第1章の序論は、1.1目的から1.9略語まで9つの節で構成されます。読み手が最初に確かめるのは1.2範囲で、ソフトウェアがやることと、やらないことの境界をここに書きます。 分量が増えるのは1.3製品の位置づけです。システム・ユーザー・ハードウェア・ソフトウェア・通信の5つのインタフェースに、メモリ制約、運用、設置先への適合、サービスとのインタフェースを加えた9項目が並びます。1.6制約と1.7前提と依存も、発注側が読み飛ばしやすい節です。「利用者はChromeかFirefoxの最新版を使う」といった前提がここに書かれていれば、後から対応ブラウザで揉めることはありません。 ### 要件の章に並ぶ機能・使用性・性能・論理DBなど8つの節の書き分け 第2章の要件は、次の8節に分かれます。 1. 外部インタフェース 2. 機能 3. 使用性要件 4. 性能要件 5. 論理データベース要件 6. 設計制約 7. 標準への準拠 8. ソフトウェアシステム属性 作例では、性能要件に「起動後10秒以内に文書を表示する」「1万オブジェクト・添付100ファイル・合計100MBまでの文書を開ける」と数値が入っています。論理データベース要件には「永続データを暗号化する」、ソフトウェアシステム属性には「プロジェクトのデータをインターネットへ送信しない」という要件が置かれた構成です。機能以外の要件をどの節に置くかで迷ったら、機能要件と非機能要件の区別に立ち返ります。セキュリティや可搬性のような品質の性質は、8番目のソフトウェアシステム属性にまとめるのが29148の作例の書き方です。 ### 検証の章を空欄にしない理由と要件ごとの受入テストへの接続方法 第3章の検証は、要件ごとにどう確かめるかを書く章です。国内の要件定義書では省かれやすい章ですが、ここが空だと「要件を満たしたか」の判定が検収の場での話し合いになります。作例では検証テストを別文書に切り出し、その文書を参照する形を取っています。 実務では、要件IDとテストケースIDを対応表でつなぐのが確実です。要件から設計・実装・テストまでを追えるようにする手順は[要件とテストを紐付けるトレーサビリティの実装手順](https://www.issoh.co.jp/tech/details/16816/)で解説しています。第4章の補足情報と第5章の参考文献には、上流のSyRSやStRSなど、要件の出どころになった文書を挙げます。 ## ソフトウェア要件を検証できる1文で書く記述ルールと要件属性の付け方 ### shallとshouldで義務と目標を分ける要件文の型と曖昧語の言い換え 29148に沿ったSRSでは、要件を「主語＋shall＋振る舞い」の1文で書きます。ReqViewの作例でも「The application shall allow users to create a new empty document.」のように、1文に1つの振る舞いだけを置いています。満たさなければ不合格になる義務を示すのはshall、達成を目指す目標を示すのはshouldです。作例の性能要件のうち起動時間と応答時間がshouldなのは、目標値として扱っているためです。 日本語で書くときは「〜すること」を義務、「〜を目標とする」を目標に割り当て、文末で区別します。「速やかに」「使いやすい」「必要に応じて」は検証できない語です。「検索結果を2秒以内に表示すること」「初回利用者が説明書なしで3操作以内に登録を終えられること」のように、計る対象と閾値を入れて書き直します。 ### ID・出典・根拠・優先度・検証方法など要件ごとに持たせる属性 要件文だけでは、なぜその要件があるのか、誰に聞けばよいのかが分かりません。[ReqViewの29148テンプレート](https://www.reqview.com/doc/iso-iec-ieee-29148-templates/)は、規格の要件プロセスを支える属性として次を定義しています。 - 識別子（Id）と見出し（Heading） - 担当者（Owner）と優先度（Priority） - 出典（Source）と根拠（Rationale） - 難易度（Difficulty）と状態（Status） - 検証方法（Verification Method） 実務で最低限必要なのは、識別子・出典・根拠・検証方法の4つです。検証方法はテスト・デモンストレーション・インスペクション・分析の4種から選びます。根拠が書かれていない要件は、予算が足りなくなったときに削ってよいかを判断できません。 ### 個々の要件と要件の集合に求められる品質特性とレビュー時の確認観点 JIS X 0166の目次で5.2「要件（要求事項）の基本」に充てられているのは11ページから19ページまで。ここでは良い要件の特性を、個々の要件と要件の集合の2段で整理しています。個々の要件には、必要であること、曖昧でないこと、単一であること、実現可能であること、検証可能であることなどが求められます。集合としては、抜けがなく、互いに矛盾しないことが条件です。 レビューで最も見つけやすいのは「単一」の違反です。「CSVとPDFで出力できること」は2つの要件なので、片方だけ実装された場合に合否を付けられません。要件文に「および」「または」が出てきたら分割を疑う、という1つの規則だけで、レビューの指摘の多くは拾えます。 ## 業務要件定義書・システム要件定義書と書き分けるときの判断基準 ### 同じ性能の条件をシステム要件とソフトウェア要件のどちらに書くかの線引き 「画面応答3秒以内」という要件は、システム要件定義書にもソフトウェア要件定義書にも出てきます。違いは、その数値を誰が満たすかです。サーバーの台数やネットワークを含めた全体で満たす値はシステム要件、プログラムの処理だけで満たす値はソフトウェア要件に書きます。 共通フレーム2013の4.3.2.3は、ソフトウェア要件がシステム要件を正確に反映しているかを検証の対象にしています。したがってSRSの性能要件に出典として書くのは、元になったシステム要件のIDです。数値を書き写すだけで出典を付けないと、システム要件が変わったときにSRS側が取り残されます。 ### 発注者がソフトウェア要件定義書で必ずレビューする箇所と任せる箇所 SRSは開発側が書く文書ですが、発注側が読まずに承認してよい文書ではありません。発注側が必ず読むのは、1.2範囲と1.6制約と1.7前提、そして第3章の検証です。どれも契約の範囲と検収の基準に直結します。 一方で、2.2機能の内部の分け方や2.5論理データベースの細部は、開発側に任せてかまいません。発注側が確かめるのは、業務要件と要求定義で決めた内容がSRSのどの要件IDに引き継がれたかだけです。要求と要件の責任の分け方は[要求定義と要件定義の責任範囲と契約の分界点](https://www.issoh.co.jp/column/details/16305/)で、受入検査から検収までの流れは[検収と受入検査の違い](https://www.issoh.co.jp/column/details/17274/)で整理しています。 ## 29148準拠のSRSを作るべき案件と簡略版で足りる案件の見極め ### 請負契約・複数ベンダー・保守移管の案件でSRSを正式に作る条件 29148の章立てどおりにSRSを作るべき案件は、3つの条件のどれかに当てはまるものです。1つ目は、請負契約で受入基準が検収と支払いに直結する案件。2つ目は、1つのシステムを複数の開発会社にソフトウェア単位で分けて発注する案件で、各社の境界は1.3のインタフェースの節でしか固定できません。3つ目は、稼働後の保守を別の会社へ引き継ぐ予定がある案件です。 この3つに当てはまる案件で、社内に要件文の型や属性の運用経験がない場合は、要件定義の段階から第三者を入れる判断が合理的です。当社の[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)では、発注側の立場で開発会社のソフトウェア要件定義書をレビューし、検証の章と受入基準の対応づけまで支援しています。 ### SaaS設定中心やアジャイル開発でSRSの全章立てを採用しない場面 逆に、全章立てを埋めるのが過剰な案件もはっきりしています。SaaSやパッケージの設定が中心で、作り込むソフトウェアが帳票数本や連携バッチ程度の案件では、1.3の9項目の大半が「該当なし」になります。この場合は要件一覧表に識別子・要件文・出典・検証方法の4列を持たせれば十分です。 スプリントごとに要件を見直すアジャイル開発でも、SRSを最初に書き切る進め方は採りません。要件はプロダクトバックログで管理し、shallの文型と受入条件だけを各項目に借ります。進め方は[アジャイル開発での要件定義の5ステップ](https://www.issoh.co.jp/column/details/16313/)を参照してください。日本式の章立てで要件定義書全体を組みたい場合は、[要件定義書の章立てサンプルと書き方](https://www.issoh.co.jp/column/details/12849/)のほうが手早く使えます。 ## よくある質問 ソフトウェア要件定義書について、作成やレビューの場面で出ることの多い質問を5つ取り上げます。 ### ソフトウェア要件定義書とソフトウェア要件仕様書は違うものですか？ 呼び方の違いで、指している文書は同じです。英語のSoftware Requirements Specificationを「要件仕様書」と訳すか「要件定義書」と呼ぶかの差で、JIS X 0166:2021では「ソフトウェア要件（要求事項）仕様」と表記されています。国内の受託開発の現場では、共通フレーム2013の工程名に合わせて「ソフトウェア要件定義書」と呼ぶことが多く、契約書や見積書ではこちらの表記がよく使われます。社内でどちらに統一するかを先に決めておけば十分です。 ### IEEE 830のテンプレートを今も使ってよいですか？ 社内の書式として使い続けること自体は禁じられていませんが、規格としては置き換え済みです。IEEE SAのページでIEEE 830-1998はSuperseded Standardとされ、後継はISO/IEC/IEEE 29148です。29148:2011はIEEE 830に加えてIEEE 1233とIEEE 1362も統合しており、SRSだけでなく上流のStRSやSyRSとの関係まで1つの規格で説明できます。新しく書式を作るなら、29148:2018の章立てを基準にするほうが後の監査や引き継ぎで説明しやすくなります。 ### ソフトウェア要件定義書は誰が作成しますか？ 共通フレーム2013では、ソフトウェア要件定義はソフトウェア実装プロセスの中の工程で、主に開発会社が作成します。発注側は業務要件と要求を示し、開発会社がそれをソフトウェアの要件に書き下す分担です。ただし範囲・制約・前提と検証の章は契約と検収に直結するため、発注側も必ず読んで承認します。発注側だけでSRSを書き切ろうとすると、技術的に実現できるかの評価が抜け落ちます。 ### ソフトウェア要件定義書に非機能要件はどこまで書きますか？ ソフトウェアの処理だけで満たせる非機能要件の記載先は、SRSの要件の章です。29148の作例の章立てでは、使用性要件・性能要件・論理データベース要件・ソフトウェアシステム属性が該当し、セキュリティや可搬性は最後のシステム属性にまとめます。サーバー構成や稼働率のようにハードウェアや運用を含めて満たす値はシステム要件定義書の側に書き、SRSにはその要件IDを出典として残します。 ### ソフトウェア要件定義書の分量はどれくらいが目安ですか？ 分量はページ数ではなく要件の数で見積もるほうが実態に合います。1要件を1文で書き、識別子・出典・根拠・検証方法を付けると、1要件あたり表の1行から数行に収まります。29148:2018の本文自体が92ページあるため、規格の解説まで書き写すと膨らみますが、SRSに必要なのは章立ての型と要件の一覧だけです。各章に「該当なし」と書いた節が多いなら、全章立てを使う案件ではないと判断できます。 ## 関連記事 - [要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説](https://www.issoh.co.jp/column/details/12848/)：ソフトウェア要件定義書を含む要件定義全体の目的と進め方を確認できます。 - [仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説](https://www.issoh.co.jp/column/details/13200/)：要件定義書と設計書・仕様書の役割の違いを整理しています。 - [機能要件とは？非機能要件との違いと定義する5つの事項・書き方](https://www.issoh.co.jp/column/details/3715/)：SRSの要件の章で機能と非機能を書き分ける前提知識です。 - [非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説](https://www.issoh.co.jp/tech/details/17610/)：性能要件を検証できる数値に落とす手順を実装目線で解説しています。 --- 出典: [ソフトウェア要件定義書とは？SRSの構成とISO/IEC/IEEE 29148の記載項目を解説]()（株式会社一創）