ソフトウェア要求仕様書（SRS）の書き方

• 関係者間のコミュニケーション
  顧客、ユーザー、開発チーム、テストチームが、作るシステムについて共通の理解を持てるようにします。
• 開発の土台を作る
  設計、実装、テストなど、後続の工程の基準になります。
• 変更管理の基準を作る
  進行中に生じた要求の変更を追跡し、管理する根拠になります。
• 検証と妥当性確認の基準を作る
  開発したシステムがユーザーの要求を満たすか、検証（Verification）と妥当性確認（Validation）を行う基準になります。

1. 序論（Introduction）
   • 目的（Purpose）
     。SRS自体の目的と、想定読者を説明します。
   • 範囲（Scope）
     。ソフトウェアの名称、目標、主な機能を簡潔に示し、システムが対象とする作業と対象外の作業を明確にします。
   • 用語、頭字語、略語（Definitions, Acronyms, and Abbreviations）
     。文書で使う専門用語や略語を定義します。
   • 参考資料（References）
     。プロジェクト計画書や関連規格など、作成時に参照した文書を列挙します。
   • 概要（Overview）
     。残りの構成と、各章の内容を簡潔に案内します。
2. 全体の説明（Overall Description）
   • 製品の位置づけ（Product Perspective）
     。単独の製品なのか、大きなシステムの一部なのかなど、関連システムや既存システムとの関係を説明します。
   • 製品の機能（Product Functions）
     。システムが実行すべき主な機能をまとめます。詳しい機能要件は次の章で扱います。
   • ユーザー特性（User Characteristics）
     。主な利用者グループと、それぞれの知識、経験、技術的な背景を記述します。
   • 制約（Constraints）
     。特定のハードウェアやソフトウェアの使用、開発言語、予算、スケジュール、セキュリティ規則など、開発や成果物に影響する制約を示します。
   • 前提と依存関係（Assumptions and Dependencies）
     。SRSが前提とする事柄や、プロジェクトの成否に影響する外部要因を記述します。
3. 詳細な要求（Specific Requirements）

   SRSの中心となる部分です。システムが満たすべき要求をすべて具体的に記述します。通常は、機能要件、非機能要件、インターフェース要件などに分けます。詳しくは後述します。
4. 付録（Appendices）と索引（Index）

   （任意）

   データモデルや詳細なユースケース仕様など、本文に入れにくい情報や、用語の索引を掲載できます。

• 「システムは〜しなければならない（The system shall...）」「ユーザーは〜できる（The user can...）」などの形で書きます。
• 個々の機能は明確で、解釈が分かれず、検証できるように書きます。

• 「ユーザーはIDとパスワードを使ってログインできなければならない。」
• 「システムは書名、著者、出版社のキーワードで書籍を検索する機能を提供しなければならない。」
• 「管理者は新規アカウントを作成し、既存のユーザー情報を変更または削除できなければならない。」
• 「商品を注文したとき、システムは在庫を確認し、在庫不足をユーザーに通知しなければならない。」

• ユーザーの視点から必要な機能を特定します。ユースケース分析が役立ちます。
• 機能ごとに、入力、処理、出力、例外時の動作を具体的に記述します。
• 「FR-001 ユーザーのログイン」のように固有の識別子を付け、追跡と管理をしやすくします。

• 性能（Performance）
  「通常の条件では、システムはユーザーの要求に2秒以内に応答しなければならない。」
  「システムは1,000人の同時利用を支えられなければならない。」
• 使いやすさ（Usability）
  「初めてのユーザーも10分以内に基本機能を習得できる、直感的なUIを提供しなければならない。」
  「すべての機能にキーボードだけでアクセスできなければならない。」
• 信頼性（Reliability）
  「システムは年間99.9%の可用性を保証しなければならない。年間の停止時間は8.76時間以内とする。」
  「障害時には5分以内に自動で復旧しなければならない。」
• セキュリティ（Security）
  「すべてのユーザーのパスワードを暗号化して保存しなければならない。」
  「システムはSQLインジェクションとXSS攻撃から保護されなければならない。」
• 保守性（Maintainability）
  「コードは社内のコーディング標準に従い、主要なモジュールにはコメントを付けなければならない。」
  「決済モジュールを追加しても既存の決済システムに影響を与えてはならない。」
• 移植性（Portability）
  「システムはWindowsとLinuxの両方で動作しなければならない。」

• 明確さ（Clear）と一義性（Unambiguous）
  各要求は1つの意味に解釈できるようにします。主観的な表現や曖昧な用語は避けます。
  • 悪い例。「システムは使いやすくなければならない。」これでは曖昧です。
  • よい例。「主要機能に3回以内のクリックでアクセスできなければならない。」これなら具体的です。
• 完全性（Complete）
  必要な機能、性能、制約などを漏れなく記述します。「後日決定（To Be Determined、TBD）」は最小限にします。
• 一貫性（Consistent）
  要求同士が矛盾したり衝突したりしないようにします。用語や表現も統一します。
• 正確さ（Correct）
  すべての要求が、顧客やユーザーが実際に求めていることを正確に反映する必要があります。
• 検証可能性（Verifiable / Testable）
  テストや分析によって、満たしているかを確かめられるように記述します。測定できない要求は避けます。
• 追跡可能性（Traceable）
  要求に固有の識別子を付け、設計文書、コード、テストケースに関連づけて変更履歴を追跡できるようにします。
• 変更しやすさ（Modifiable）
  要求が変わることを前提に、変更時に修正と管理をしやすい構造にします。
• 優先順位（Prioritized）
  要求の重要度は一律ではありません。MoSCoW（Must have、Should have、Could have、Won't have）などで優先順位を明記すると、限られたリソースで効率的に開発を計画できます。

次回は、形式的・非形式的な分析や、インタビュー、ワークショップなど、要求分析の手法を詳しく見ていきます。

• IEEE 830-1998 - IEEE Recommended Practice for Software Requirements Specifications↗（英語のIEEE SRS指針。有料の場合は要約や解説も探してください）
• Software requirements specification - Wikipedia↗（英語のSRSの解説）
• How to Write a Software Requirements Specification (SRS Document) - Perforce↗（英語の詳しい作成ガイド）