6動作するSRS文書を書くためのステップ+テンプレート
ソフトウェア仕様文書は、開発者にとってのみ意味のある成果物と見なされることがあります。 しかし、SRS文書はさらに進んで、マーケティングの専門家、利害関係者、設計チーム、さらにはユーザーのためのガイドになることができます。
この記事では、ソフトウェアドキュメントが重要な理由と、SRSドキュメントを書く方法を説明し、すべてのチームスペシャリストにとって実用的なガイ
SRS文書とは何ですか？
SRS(software requirement specification)文書は、将来の製品の要件、期待、および標準を含むアーティファクトです。 これは、テキスト文書、スプレッドシート、スキーム、先例、および製品のビジョンを明確にする他の要素をカバーすることができます。 言い換えれば、SRS文書は、製品がどのように動作するべきか、および製品開発チームがそれをどのように実装すべきかの詳細な説明を提供します。
船を建造するように想像してみてください。 あなたはマストや帆のビジョンを持っており、それが波の中をどのように移動するかを想像することさえできます。 しかし、あなたは水の上に船を置くために厳しい詳細が必要です。
製品開発についても同様です。 すべての機能、デザイン要素、およびボタンを使用して、構築するアプリの明確なビジョンを持つことができます。 しかし、機能の口頭での説明では、開発者がアイデアを実装するのに十分ではありません。
結果が頭の中の絵と一致するようにするには、機能がどのように機能するかを正確に紙で説明する必要があります。 SRS文書は、そのような技術的詳細を記述するための優れた手段です。
.jpg)
誰がSRS文書を書いていますか？
SRS文書を作成することは、機能、タスク、および目標の一般的な説明を、技術的実装の詳細な計画に転送することを意味します。
SRSドキュメントは、通常、製品およびプロジェクトマネージャーまたはビジネスアナリストによって書かれており、クライアントと直接通信したり、ユーザー
一方、この文書。 優れたSRS文書は、ビジネス目標、指標、ユーザーの問題、ユーザーのペルソナなどもカバーしているため、技術的なものだけではありません。
3 SRS文書が重要な理由
したがって、SRS文書の全体的な価値は明らかです。 ソフトウェア要件仕様書が不可欠な理由は次のとおりです:
SRSはコミュニケーションポイント
生きている文書として、SRS文書はすべての専門家の間のコミュニケーションプラットフォームとして機能します: 開発者、マーケティングの専門家、および共同創設者。
srs文書で詳細を説明することにより、正式または非公式に、管理者は結果の期待について顧客に同意します。 一方、要件に変更が加えられた場合、クライアントおよび/または製品所有者は、文書内でそれらをチェックして検証することができます。 そして、開発者はこれらの期待に応える責任があります。
機能の最終説明
SRSは、以前にクライアントと議論した前提から来たソフトウェアの最終バージョンを文書化しています。 会議や電話、ユーザーテスト、インタビューの間に、製品バージョンは非常に頻繁に変更される可能性があります。 時には、製品マネージャーでさえ、既存の製品の反復に圧倒されることがあります。 SRSファイルは、これらすべての要件を1つの標準に統一し、製品要件に関する混乱を排除するのに役立ちます。
SRSは、製品開発者のための標準ガイドです
製品の要件を説明するだけでなく、SRSドキュメントは、クライアントが望む製品を構築するために従うべ
プロジェクトの組織によっては、開発者はプロジェクトの分析部分に関与することができます。 いずれの場合も、システムがどのように機能するかを結論づけ、要件を定義し、それに合わせてパラメータをコード化する必要があります。
同様に、QAの専門家は、製品のコンセプトの背後にあるすべての技術的側面を理解する必要があります。 したがって、SRSドキュメントは、QAテストの計画と実行のための標準として機能します。
最後に、設計者はsrsドキュメントを通じてプロジェクトの洞察を得て、設計をユースケースに一致させます。
6 良いSRS文書を書くための手順
機能要件と非機能要件は、SRS文書の大部分を占めています。 プロダクトマネージャーは、単にどこからともなく、これらの要件を取ることはありません。 それらは顧客との正確なコミュニケーションおよび詳細なユーザーおよび技術的な研究の結果である。 優れたSRSドキュメントを作成する主な手順は次のとおりです:
ステップ1. ステークホルダーとのコミュニケーション
ステークホルダーに製品からの期待について尋ねることによって、不確実性の最初の層を取り除きます。 確かに、そのようなインタビューは、要件のほんの少しの理解を与えます。 しかし、これはまだ研究のための素晴らしい出発点です。
Uptechでは、お互いに合っているかどうかを把握しようとするときに、事前販売とキックオフコールでまずクライアントと話します。 私達は彼/彼女の考えを理解するために顧客についてのわずかな細部を結晶化することを試みます。
しかし、単純なコミュニケーションは、製品のターゲットオーディエンスとその欲求とニーズについて十分な情報を提供しません。 だから我々はそれを明確にするために発見段階に進みます。
ステップ2. ディスカバリーステージ
ディスカバリーステージはSRSドキュメントを書く上で重要です。 この段階で、私達にプロダクトが解決するべきである問題、興味および必要性を探検する機会があります。 ここでの目標は、ユーザーの問題を特定し、それらに取り組むための可能な解決策の仮説を定義することです。 このようなアプローチでは、アプリをユーザーにとって価値のあるものにすることができます。
ユースケースとユーザーストーリー
すべてのユーザーデータは、ユースケースとユーザーストーリーとしてSRSドキュメントの一部になります。 これら二つのカテゴリーの違いは、製品開発コミュニティの間で広く議論されています。
簡単に言えば、ユーザーストーリーは、機能を使用している間にユーザーが得る結果と利益に焦点を当てています。 一方、ユースケースは関数自体をより詳細に記述します。
例えば、Yazaプロジェクトで複数のユーザーインタビューを行った後、アプリにはチャットが必要であると結論づけました。 そのような場合のユーザーストーリーは、「ユーザーとして、潜在的な家の所有者とチャットしたい。”
一方、このストーリーのユースケースは、この目標を達成するためのユーザーの各ステップを説明します–”ユーザーとして、私はチャットリストに連絡先を追加し、彼/彼女
ステップ3. 構造体を構築する
発見が完了したら、SRSのドキュメントを記述します。 まず、文書の簡単な構造が必要です。 SRSドキュメントの内容は大きく異なる場合がありますが、一般的なSRSドキュメント構造は次のようになります:
1. はじめに
イントロでは、ドキュメントの内容の概要を説明します。 次の質問に答えることになっています:
- 文書の内容の簡単な説明;
- この文書の意図された読者;
- あなたが開発しているソフトウェアのアイデア;
- 意図された読者。
1.1ビジネス目標
MVPの作成、マルチプラットフォームモバイルアプリの作成、webサイトの起動など、プロジェクトで達成したい目標のリストを設定します。
また、このセクションでは、あなたのビジネスの目標と成功の指標を反映する必要があります。 この部分を文書から除外する人もいるかもしれませんが、研究開発に直接影響を与えるため、これらのことを示すことが不可欠です。
1.3 使用目的
個人があなたの製品をどのように使用すると想像していますか？ このタイプの使用のために提供している機能は何ですか？ ユーザーがどのようなユーザー役割を果たしても、ユーザーが製品を使用できるすべての可能な方法を説明します。
1.4 スコープ
この部分は、あなたのアイデアを生き生きとさせるために実行する必要がある作業の範囲について説明します。
1.5 定義と頭字語
これは、ユーザーが完全に理解できるように、ドキュメントで使用している用語の定義をレイアウトします。
2. 全体的な説明
ここでは、アプリのアイデア、それがどこから来たのか、なぜそれがユーザーにとって興味深いのかを説明する部分です。
2.1 ユーザーニーズ
誰のために構築されたソフトウェアの一部は、誰にも役立ちません。 しかし、ターゲットオーディエンスが誰であるか、どこで働いているのか、そして彼らの痛みを正確に知っていれば、ユーザーに広く採用されているアプリを提供する可能性が高くなります。
3. システムの機能と要件
今度は、将来のソフトウェアの技術的要件の概要を説明します。 製品に含まれる機能と、これらの製品の品質を定義する標準を説明します。
3.1 機能要件
機能要件とは、ソフトウェアが正常に機能しないシステム仕様です。 ソフトウェア機能に与える定義は、それらがさらに実装される方法を決定します。
3.2非機能要件
機能要件はシステムの機能を定義しますが、非機能要件はシステムがこれらの機能をどのように実装するかを決定します。
3.3 Tech Stack
tech stackは、ソフトウェアやプロジェクトを作成して実行するために使用される技術的なソリューションのプールです。 他のすべての技術的詳細を定義しているので、SRS文書にそれを示すことが重要です。
.jpg)
ステップ4. 一般的な説明を作成する
製品の詳細を入力する前に、アプリの主な機能の一般的な概要を説明します。 アプリの目的、機能、ユーザーの問題をどのように解決するかを説明するだけです。
ステップ5。 機能要件と非機能要件の定義
SRSドキュメントのコアは、通常、製品の機能要件と非機能要件で構成されます。 このような仕様を使用すると、一般的な概要に詳細を追加して、アプリの技術的な詳細をチームに案内します。
機能要件と非機能要件の違いは、製品開発コミュニティのもう一つのこだわりです。 この記事では、このトピックに関する専門知識を共有しました。
ステップ6。 同じページのクライアント
承認が開発の待望の部分であることを確認してください。 しかし、クライアントの編集は、プロジェクトの特定の時点で完了した作業の全体量を無効にすることがあります。
圧力を避けるために、一度に文書のパッケージ全体を提出するのではなく、完成したSRS文書の小さな部分に同意することをお勧めします。 これは、特定の問題を迅速に修正するのに役立ち、面倒なことはありません。
偉大なSRSドキュメントを書く上での専門家のヒント
優れたSRSドキュメントを書くスキルを磨くには時間がかかります。 私たちは、私たちの経験からSRS文書を書く上で専門家のヒントのリストを引っ張ってきました。 ここでは、SRSドキュメントを効果的にするいくつかの洞察を示します:
Make It Simple
これはほとんど秘密ではありませんが、単純なものが世界を支配しています。 これはあなたが働いているあらゆるタイプの文書に確かに当てはまります。 あなたのSRSは、あなたのチーム全体のための将来の製品の統一された説明です。 これは、SRS文書の言語、構造、定式化ができるだけ簡潔でなければならないことを意味します。
ビジネス目標を含める
SRS文書は主にビジネス目標を含む技術特性に焦点を当てていますが、良い習慣です。 SRSドキュメントは、開発チームのための指示であり、製品に関連する技術者以外の専門家のための製品概要です。 さらに、メトリクスや目的などのビジネス要件を含めることで、SRSはチーム全体の統一された手段になります。
ユーザーデータの追加
ディスカバリーステージは、通常、ユーザーに関する最も価値のある情報を公開します。 この情報をSRSドキュメントに追加すると、設計および開発チームにとって役立つ論文になります。
Srsを生きた文書として扱う
SRS文書は、プロジェクトに必要なすべてのパッケージをコンパイルしたとしても、静的であってはなりません。 アジャイルエコシステムでは、プロジェクトは反復ごとに新しい機能を取得します。 そのようなすべての修正および修正は、SRS文書で伝達され、クライアントと合意されるべきです。
結論
SRS文書を書くには、深い研究、分析、努力が必要です。 しかし、ビジネスの特性、技術的な詳細、およびユーザーデータをカバーする包括的なSRSドキュメントは、クライアントとユーザーの両方の期待を満たす見事な製品
Uptechは、繁栄するスタートアップのための製品を構築する経験の五年を持っています。 私達はユーザーのニーズを探検し、srsを塵カバーされたペーパーの積み重ねよりもむしろ有効なプロジェクト管理の器械文書にする方法を知っている。
F.A.Q.
SRSとは何ですか？
SRSは、アプリケーションまたはソフトウェアの技術仕様および要件の詳細な説明をカバーする文書です。 SRSはまた、クライアントの期待に合わせて製品のアイデアを実装する方法について開発者に指示します。
SRS文書の目的は何ですか？
SRSドキュメントの目的は、製品の機能の技術的な説明を与え、技術的および非技術的な要件を提供し、実装に関する開発チームを導くことです。
誰がSRS文書を書いていますか？
チームの構成に応じて、SRS文書は通常、次のように書かれています:
- プロダクトマネージャー;
- プロジェクトマネージャー;
- ビジネスアナリスト;
- テクニカルエンジニア。