ソフトウェア要件定義書の書き方 (テンプレート付き)

学生の頃、19 世紀に書かれた小説を読んでいて、日本語で書かれているのにいまいち意味がわからないと思ったことはありませんか？オフィスで、技術志向の AI 開発者やウェブに詳しい SEO アナリストと共同作業をするときにも、同じようなことを思うかもしれません。同僚の使う言葉を変換してくれる翻訳機があれば便利なのですが、そうはいきません...

組織内では、たとえ使用する専門言語が違っても、対極にある部門が協力し合うことが不可欠な場合があります。部門横断チームで仕事をしたことがある人なら、全員が共通認識を持つことがいかに難しいかわかるはずです。

ソフトウェア要件仕様書を作成することで、プロジェクトマネージャー、プロダクトマネージャー、ビジネスアナリストは、大局的なコンセプトを、開発プロセスにおいてチームメンバー全員が実行できるように、アクションアイテムに分割できるようになります。

ソフトウェア要件仕様書 (SRS) とは？

ソフトウェア要件仕様書 (SRS) は、将来のプロジェクトに関する要件、期待事項、設計、基準をまとめた文書です。これには、プロジェクトの目標を決定する大局的なビジネス要件、エンドユーザーの要件やニーズ、技術的な観点における製品の機能性などが含まれます。つまり、SRS はソフトウェア製品がどのように機能すべきか、また開発チームがどのようにそれを実現すべきかを詳細に記載したものなのです。

アプリに関するいいアイデアを思いついたとします。このアプリの機能や見た目のイメージはできていますが、開発者に口頭で説明するだけでは、期待通りのものを作ってもらえるとは思えません。そんな時こそ、SRS の出番です。

SRS を使うメリット

新製品を開発する際に、開発者が方向性を明確に理解していなければ、思い描いたとおりのソフトウェアに仕上げるまでに予想以上の時間とコストがかかってしまうことがあります。

SRS を作成することで、アイデアを紙に書き出し、明確な要件リストを設定できます。この文書は、製品の信頼できる唯一の情報源となり、マーケティングからメンテナンスまで、すべてのチームが共通の認識を持てるようになります。

ソフトウェア要件仕様書は柔軟で調節可能な生きた文書であるため、製品開発プロセスに関わるすべての関係者間のコミュニケーションポイントとしても機能します。どのようなソフトウェア開発プロジェクトにおいても、製品のイテレーションは必ず発生しますが、SRS に変更点を記載することで、すべての関係者がその変更点を文書で確認できるようになります。これによって、製品要件に関する混乱が軽減されます。

SRS 文書に記載する内容

基本的な SRS 文書のアウトラインは、導入、システムおよび機能要件、外部インターフェイス要件、非機能要件の 4 部分から構成されます。

1. 導入

SRS の導入部は、その名の通り、プロジェクト全体を俯瞰するものです。導入を書く際には、製品の目的、対象となるオーディエンス、オーディエンスがどのようにそれを使用するかを説明します。また、導入部には以下の内容を記載しましょう。

• 製品のスコープ: スコープは、製品の全体的なビジネス目標に関連するものでなければなりません。これは、複数のチームや請負業者が文書にアクセスする場合に特に重要となります。製品に期待されるメリット、目的、目標などを記載しましょう。

• 製品の価値: 対象となるオーディエンスが、その製品にどのような価値を見出すか考えてみましょう。検討する内容は、製品が重要な理由、対象となるオーディエンスにどのように役立つのか、どのような機能を果たすのか、あるいはどのような問題を解決するのか、などです。

• 対象となるオーディエンス: 理想的なユーザー像を書き出しましょう。これによって、製品のデザインや使い心地、マーケティングの方法が決まります。

• 使用目的: 製品がどのように使われるかを考えてみましょう。製品が提供する機能と、ユーザーの役割に応じて想定される使い方をすべて書き出してください。また、ユースケースを記載して、あなたのビジョンを説明してもよいでしょう。

• 定義と略語: どの業界やビジネスにも、独自の略語や専門用語があるものです。SRS で使用する用語の定義をまとめ、すべての関係者が内容を理解できるようにしましょう。

• 目次: 詳しく書かれた SRS の文書は、とても長くなる可能性があります。参加者全員が探しているものを正確に見つけられるように、目次をつけましょう。

導入部はわかりやすく、簡潔に書きましょう。導入部は、SRS の残り部分へのガイドとなります。誰が読んでも同じように解釈できる内容にしましょう。

2. システム要件と機能要件

導入部を書き終えたら、具体的な内容に進みます。機能要件は、システムが意図したとおりに動作するように、システムの特徴や機能を分割したものです。

導入部でまとめた内容を参考に、要件がユーザーの基本的なニーズを満たしているかどうかを確認しながら、詳細を詰めていきます。製品によって、記載すべき機能要件は何千通りもあります。ここでは、その中でも特に一般的なものをご紹介します。

• If-then 動作

• データ処理ロジック

• システムワークフロー

• トランザクション処理

• 管理機能

• 規制やコンプライアンスに関するニーズ

• パフォーマンス要件

• 各画面で行われる操作の詳細

もし、これが大変だと感じたら、要件を一つずつ確認するとよいでしょう。SRS 文書に詳しい情報を盛り込めれば、後々トラブルシューティングに時間を割く必要が少なくなります。

3. 外部インターフェイス要件

外部インターフェイス要件とは、システムが外部コンポーネントと適切に通信できるようにする機能要件の一種です。これには以下が含まれます。

• ユーザーインターフェイス: コンテンツの表示、アプリケーションのナビゲーション、ユーザー補助など、アプリケーションの使いやすさの要となる部分。

• ハードウェアインターフェイス: システムのソフトウェアとハードウェアをつなぐ各インターフェイスの特性。サポートされているデバイスの種類や通信プロトコルなど。

• ソフトウェアインターフェイス: データベース、ライブラリ、オペレーティングシステムなど、製品とその他のソフトウェアコンポーネント間をつなぐもの。

• 通信インターフェイス: メールや埋め込みフォームなど、製品が使用する通信機能に関する要件。

組み込みシステムは、外部インターフェイス要件に左右されます。画面レイアウト、ボタン機能、製品が他のシステムにどのように影響されるかなど説明を盛り込みましょう。

4. 非機能要件 (NRF)

SRS の最後のセクションでは、非機能要件を詳しく説明します。機能要件がシステムに何をすべきかを示すのに対し、非機能要件 (NFR) は、システムがこれらの機能をどのように実装するかを決定します。たとえば、機能要件は、顧客が製品を注文したときに納品書を印刷するようにシステムに指示するものです。一方 NFR は、標準サイズである A6 の白い紙に、納品書が印刷されるように指定します。

NFR を満たしていなくてもシステムは動作しますが、ユーザーや関係者の信頼を損なう可能性があります。NFR は機能要件を管理するものであり、製品の価格や使いやすさなどの特徴も含まれます。

特に一般的な NFR の種類は、以下のように性質や状態を表す言葉によって分類され定義されます。英語で -ity で終わる単語ばかりなので、"itys" と呼ばれます。

• セキュリティ: ソフトウェアがユーザーから収集する機密情報を確実に保護するために必要なもの。

• キャパシティ: 製品の現在および将来のストレージニーズ (需要の増加に対するシステムの拡張計画を含む)。

• 互換性: オペレーティングシステムとそのバージョンのサポートなど、ソフトウェアに最低限必要なハードウェア。

• 信頼性と可用性: ユーザーがどのくらいの頻度でソフトウェアを使用することを想定しているか、また、通常の使用状況下で致命的な故障が発生するまでの期間はどの程度か。

• 拡張性: システムが期待通りの性能を発揮できるワークロードの上限。

• 保守性: 機能追加やバグ修正をスムーズに行うために、アプリケーションで継続的インテグレーションをどのように活用すべきか。

• ユーザビリティ: 製品の使いやすさ。

その他の一般的な非機能要件には、性能要件、規制要件、環境要件などがあります。

ソフトウェア要件仕様書のテンプレート

開発したいソフトウェアを思いついたら、次に Asana のテンプレートを使って、SRS を作成しましょう。この SRS テンプレートには、理想的な SRS 文書に欠かせない 4 つの重要な構成要素がすべてそろっています。これを活用することで、開発する製品に関する貴重なインサイトをチームに提供できます。要件を詳細、明確、かつ簡潔に書くことで、すべての関係者が同じビジョンを思い描けるようになります。

SRS 文書の作成におけるベストプラクティス

SRS の目的は、各部門の各チームが明確な目標に向かって仕事に取り組めるようにすることです。しかし、SRS がその目的を果たせるように、やらなければいけないことがいくつかあります。ここでは、ベストプラクティスをご紹介します。

視覚的データで SRS を充実させる

ダイアグラム、図式、モデルなどの視覚的データを含めると、チームメンバーがプロセスをより理解しやすくなります。特に、これはソフトウェアの主な機能や操作性を説明する場合に役に立ちます。

プロジェクトのブレーンストーミングで試せるテクニックのひとつに、アイデア、機能、シナリオを整理して、それらのつながりを描くマインドマップがあります。マインドマップを作成することで、ランダムに出てくる考えをまとめ、アイデアを整理することができます。この視覚的データはそれほど詳細である必要はありません。というのも、それが SRS の役目だからです。その代わり、ソフトウェアが持つ主要な機能と、その機能が互いにどのように関連しているかに焦点を当てましょう。

明確かつ簡潔にまとめる

製品を開発する際に、開発者が迷うことは避けたいものです。チームメンバーが勝手に考えて不明な点を埋めるような余地を残さないようにしましょう。ソフトウェアの要件を説明するときは、できるだけ詳細に記述し、次のようなことは避けてください。

• 「一般的に」や「およそ」などの曖昧な言葉を使用すること

• 「オンライン / オフライン」など、「および」と「または」のどちらでも解釈される可能性のある「/」を使用して複数の言葉をつなぐこと

• 複雑な境界値を使用すること

• 二重否定、三重否定を使用すること

正式にピアレビューを行うと、SRS 文書のあいまいな部分を正確に把握できるようになります。参加者全員に確認してもらい、要件に対する理解度を比較し、必要な変更を加えましょう。

エンドユーザーを知る

SRS に実地調査とユーザーインタビューの内容を追加し、エンドユーザーの要件、期待、ニーズを明確に理解しましょう。これにより、エンドユーザーがそのソフトウェアで行う操作をイメージしやすくなります。起こりうるすべての状況や傾向を考慮し、SRS に盛り込みましょう。開発者は、SRS に記載された内容をそのまま実装することになります。

柔軟に対応するためにマージンを含める

SRS は生きた文書です。つまり、イテレーションごとに新しい機能を追加したり、修正を加えたりすることになります。そのため、結果が期待にそぐわない場合に備えて、要件に柔軟性を持たせておきましょう。また、誤解を避けるために、文書に加えられた変更の記録も残しておくと安心です。こうすることで、参加者は各要件の原文をたどり、誰が、いつ、何のために変更したかを把握できます。

ソフトウェア要件仕様書を活用して、ビジョンを明確にする

SRS の作成は簡単な作業ではありませんが、トラブルシューティングやチームメンバー間の議論を解決するのも大変なことです。包括的なソフトウェア要件仕様書に力を注ぐことで、チームや関係者が胸を張れるようなすばらしい製品を生み出すことができるのです。