ソフトウェア要件仕様 (SRS) ドキュメントの書き方

プロのソフトウェア開発者は、意味のある規模のソフトウェア開発プロジェクトの開始時に、ソフトウェア要件収集プロセスを実行する必要があります。そのプロジェクト フェーズの最終成果物は、一般にソフトウェア要件仕様 (SRS) と呼ばれるドキュメントです。これは通常、プロジェクトの最初のマイルストーンまたは成果物です。このドキュメントの重要性を過小評価することはできません。その最も重要な機能は、クライアントのビジネス ニーズと要件を書面で記録し、残りのソフトウェア開発プロセスの基盤となることです。これらの要件がまとめられると、そのドキュメントは、クライアントと開発者の両方がソフトウェアが何を達成すべきかを理解していることの記録になります。通常、クライアントは SRS を確認して署名し、完全なソフトウェア設計および開発フェーズを開始します。関連する高レベルの手順を実行することで、SRS ドキュメントを作成できます。

ステップ 1

組織に標準のソフトウェア要件仕様ドキュメント テンプレートがない場合は、今すぐ作成してください (テンプレートへのリンクについては、「参考文献」を参照してください)。

ステップ 2

対象分野の専門家/クライアントと会い、要件を収集します。

ステップ 3

ソフトウェアの機能を定義します。

ステップ 4

主要なサブプロセスのユース ケースを作成します。たとえば、注文入力システムを設計している場合、ユース ケースは、新しい注文の作成、既存の注文の変更、および顧客の注文検索で構成されます。

ステップ 5

ユーザー インターフェイスを定義します。

ステップ 6

ハードウェア インターフェイスやその他のソフトウェア システム インターフェイスなど、その他のインターフェイスを定義します。

ステップ 7

プロセス フローを定義します。

ステップ 8

特定のビジネス ルールを決定します。

ステップ 9

パフォーマンス仕様を定義します。

ステップ 10

プロセス フローを説明したり、主要な要件を詳しく説明したりするために必要な図を作成します。

ステップ 11

SRS 文書を編集し、必要な関係者全員に確認または署名してもらいます。

ヒント

標準ドキュメント テンプレートを作成します。トレーサビリティ マトリックスを含めます。要件とそれらの要件のソースとの間のリンクを含めます。定義されたビジネス運用ルールを明確にリストします。ルールとプロセスが正確で明確な言葉で定義されていることを確認してください。

警告

SRS には機能要件のみが含まれます。ソフトウェアの設計や実装の詳細は含めないでください。