プロのソフトウェア開発者は、意味のあるサイズのソフトウェア開発プロジェクトの開始時に、ソフトウェア要件の収集プロセスを実行する必要があります。 そのプロジェクトフェーズの最終製品は、一般にソフトウェア要件仕様（SRS）と呼ばれるドキュメントです。 これは通常、最初のプロジェクトのマイルストーンまたは成果物です。 この文書の重要性を過小評価することはできません。 その最も重要な機能は、クライアントのビジネスニーズと要件を書面で記録し、残りのソフトウェア開発プロセスの基盤となることです。 これらの要件がコンパイルされると、ドキュメントは、ソフトウェアが何を達成する必要があるかについてのクライアントと開発者の両方の理解の記録になります。 通常、クライアントはSRSを確認して署名し、完全なソフトウェア設計および開発フェーズを開始します。 関連する高レベルの手順を実行することにより、SRSドキュメントを作成できます。
ステップ1
組織に標準のソフトウェア要件仕様ドキュメントテンプレートがない場合は、今すぐ作成してください（テンプレートへのリンクについては「参考文献」を参照してください）。
今日のビデオ
ステップ2
対象分野の専門家/クライアントと会って、要件を収集します。
ステップ3
ソフトウェアの機能を定義します。
ステップ4
主要なサブプロセスのユースケースを作成します。 たとえば、注文入力システムを設計している場合、ユースケースは、新しい注文の作成、既存の注文の変更、および顧客注文の検索で構成されます。
ステップ5
ユーザーインターフェイスを定義します。
ステップ6
ハードウェアインターフェイスや他のソフトウェアシステムインターフェイスなど、他のインターフェイスを定義します。
ステップ7
プロセスフローを定義します。
ステップ8
特定のビジネスルールを決定します。
ステップ9
パフォーマンス仕様を定義します。
ステップ10
プロセスフローを説明したり、主要な要件を詳しく説明したりするために必要な図を作成します。
ステップ11
SRSドキュメントをコンパイルし、必要なすべての関係者にレビューまたは署名してもらいます。
必要なもの
ワードプロセッシングアプリケーション
MicrosoftVisioなどの作図ソフトウェア
ヒント
標準のドキュメントテンプレートを作成します。 トレーサビリティマトリックスを含めます。 要件とそれらの要件のソースとの間のリンクを含めます。 定義されたビジネスオペレーションルールを明確にリストします。 ルールとプロセスが正確で明確な言葉で定義されていることを確認してください。
警告
SRSには、機能要件のみが含まれています。 ソフトウェアの設計や実装の詳細を含めるべきではありません。
