SRSとは何ですか？
SRS-ソフトウェア要件仕様 -システムの動作方法、実行する機能、耐える負荷の種類などに関する情報を含むソフトウェアの特別なドキュメント。
なぜ必要なのですか？
すべてが非常に簡単です。 TK（自転車）を使用し、SRS（車）を使用します。 アナロジーが明確であることを願っていますか？ :)
SRS構造
以下は、生の形式の英語の構造です。 記事の少し後、各項目をより詳細に検討します
- はじめに
- 目的
- 文書の規則
- 対象読者と読書の提案
- プロジェクト範囲
- 参照資料
- 全体的な説明
- 製品の視点
- 製品の特徴
- ユーザークラスと特性
- 動作環境
- 設計と実装の制約
- ユーザードキュメント
- 仮定と依存関係
- システム機能
- システム機能X（ このようなブロックがいくつかある場合があります ）
- 説明と優先度
- 刺激/応答シーケンス
- 機能要件
- システム機能X（ このようなブロックがいくつかある場合があります ）
- 外部インターフェースの要件
- ユーザーインターフェース
- ソフトウェアインターフェース
- ハードウェアインターフェース
- 通信インターフェース
- 非機能要件
- 性能要件
- 安全要件
- ソフトウェア品質の属性
- セキュリティ要件
- その他の要件
- 付録A：用語集
- 付録B：分析モデル
- 付録C：問題リスト
それで、構造を整理しました。次に、セクションとそれらに書き込む必要があるものに進みましょう。
すべてのSRSセクションの基本要件
- 簡潔に、はっきりと。 非常に簡潔かつ明確にすべてを説明します。 可能な限り。
- あいまいな説明なし。 SRSを読む人は、何が書かれているかを正確に理解する必要があります。 マーフィーの法則：誤解される可能性がある場合、誤解されます。 これを避ける
- シンプルさと「読みやすさ」。 難解すぎるターンは使用しないでください。 美しさはシンプルです:)
- DFDダイアグラム 。 記述されたソフトウェアの入り口に何があるのか、出口に何があるのかわからない場合、仕様を完全にすることはできません。 すべてを明確に描く必要があります。
- 詳細度。 これはヒューリスティックパラメーターです。 それは次のように定義できます：機能に関する情報を自由に述べることができ、書かれていることが私を当惑させない場合、要件が明確であり、二重理解の対象ではない場合、要件が機能の動作を十分に説明している場合、SRSの開発は完全であるとみなすことができます
SRS構造の各句の説明
はじめに\目的
このセクションでは、SRSで機能が説明されるアプリケーションまたは製品について説明します。
はじめに\ドキュメントの規則
ここでは、SRSにあるすべてのあいまいな技術用語または用語について説明します。 理解できない単語の説明には、別の理解できない単語を含めることはできません。 シンプルでわかりやすい言語で使用する用語をできるだけ詳細に説明するようにしてください。 このセクションを保存しないでください。不明瞭なものを書き留めるほど、後で設計しやすくなります。
はじめに\参照
このセクションでは、使用されている技術と事実の基礎を見つけることができる文献へのリンクを作成します。 TCP / IPで動作するアプリケーションを作成している場合、RFCを埋め込み、参照するドキュメントへのリンクを挿入できるなどと仮定します。 リンクとその説明は可能な限り完全でなければなりません。その場合（リンクは単純に停止しました）、この資料をグーグルで検索することができました。
全体的な説明\製品の機能
このセクションでは、機能の一部を高レベルで説明します。 詳細については、機能の各部分について、以下のセクションで説明します。 ここでは、システムの一般的な相互作用を示すDFD図を配置することをお勧めします。
全体的な説明\動作環境
このセクションの名前から明らかなように、製品が動作する環境について説明します。 OS、コンパイラのバージョン、データベース、サーバー、ソフトウェア、ハードウェア、および製品の動作に必要なその他のもの。
全体的な説明\設計と実装の制約
このセクションは下手です:)。 開発標準を課すことにより、開発者の思考の流れを制限します。 このような制限は、たとえば次のようなものです。
- プログラミング言語データベース
- コーディング標準
- データ交換標準
- 運用環境によって課せられた制限、たとえばFFとの互換性のみ
- プロジェクトのビジネスロジックによって課される可能性のある制約
全体的な説明\ユーザードキュメント
この製品のユーザーに必要なドキュメントについて説明します。 おそらく、これがHTMLエディターであれば、HTMLに関する本です。
システム機能\システム機能X
この機能をプロジェクトに呼び出し、一意の識別子を付けます。 たとえば、server.html.editor。 チケットのどこかに書かないように一意の識別子が与えられます-「しかし、HTMLを編集できるのはたわごと」
システム機能\システム機能X \説明と優先度
製品の機能について詳しく説明します。 彼女は何のためですか？ どうすればいいですか？ 彼女の実行の優先順位は何ですか？..このセクションから、cmsユーザーの読者には、この機能がシステムに存在する理由がすぐに明らかになるはずです。
システム機能\システム機能X \刺激/応答シーケンス
トリガートリガー機能。 いつ起動し、起動時にどのように動作しますか？ たとえば、ユーザーがメニューリンクをクリックするとHTMLエディターが表示されますHTMLエディターを開く
システム機能\システム機能X \機能要件
機能の詳細かつ詳細な説明。 仕組み、エラーへの対応方法、チェック対象、データの表示方法、保存方法と保存場所など、すべてを説明します。
外部インターフェースの要件
システムが外界と相互作用する方法の説明。 もちろんそうなれば。 どのAPI、これまたはそのデータを取得する方法など。 サブセクションは、要件の詳細を示すために使用されます。 どのソフトウェアインターフェイス、ハードウェアインターフェイス、通信インターフェイスなど。
非機能要件
機能要件ではありません。 セキュリティ要件など、ある種の機能として説明できない要件があります。
非機能要件\パフォーマンス要件
パフォーマンス要件。 これは機能ではありませんが、特定の制限があります。 プロジェクトデータベースが1秒あたり1000件のクエリに耐える必要があるとします。 これらの要件は、プロジェクトを最適化するための多大な作業につながります。
非機能要件\ソフトウェア品質属性
ここでは、コードの品質要件について説明します。 使用するテスト コードの品質を判断するために使用するメトリックは何ですか？ どのくらいのコードをテストでカバーする必要がありますか？
非機能要件\セキュリティ要件
安全要件。 これがサイト上の何かを変更できるHTMLエディターである場合は、次のようになります。HTMLエディターを介して、サーバー上にシェルを配置するなどはできません。
付録A：用語集
アプリケーション。 SRSでは、プロトコルなどの説明を挿入しようとすることがあります。 これは必要ありません。 ただし、ある種の概念を明確にする必要がある場合があります。 このセクションがあります。 そのような説明へのリンクを挿入します。 そのような辞書。
付録B：分析モデル
このセクションでは、SRSを記述するときに使用する図を定義します。 たとえば、DFD、相互作用と作業の一般的な図
付録C：問題リスト
このセクションは、非常に正式なSRSに使用されます。 TBD（To Be Done）のポイントを説明します-将来何をする必要があるかについて説明しますが、ここでは説明しません。
おわりに
SRSはオプションですが、中規模から大規模のプロジェクトに役立ちます。 SRSを使用すると、開発者としてのプロフェッショナルレベルがわかります。
PSせいぜいあなたにお願いします-多かれ少なかれハブの平均規模の最初の記事 構文の修正は大歓迎です（私は正しく記述しようとしますが、ロシア語の7年生の教育はマークを残しています）。