ソフトウェア要件にラベルを付ける方法は？
SRSのソフトウェア要件にラベルを付けるための適切な戦略は何ですか？
通常、ヘッダーにはアウトライン番号が使用されますが、ドキュメントに新しい見出しが挿入されると、番号が付け直されます。私にとっては、各ソフトウェア要件に対してより安定した指定を目指すことは良い考えのようです。これにより、SRSが更新された場合でも、特定の要件を参照しやすくなります。
これに関するあなたの経験は何ですか？
1つの戦略：
- SRS IDを単なる数値と見なし、連続した順序の強い概念を暗示しないでください（社会保障番号は合理的な例です）。
- 番号をリサイクルしないでください。シーケンス内のIDが削除された場合は、「削除済み」、「非推奨」などのマークを付けます。私は、要件の進化の実行記録を得るために、削除されたアイテムに要件テキストを保持することを好みます。これを行うことを選択した場合は、削除されたテキスト（たとえば取り消し線フォント）を明らかにマークしてください。
- ＃2は、新しい要件の追加が「その場で」発生することは決してないことを意味します。むしろ、それらは常にドキュメントに追加されます。
- この戦略は、変更が蓄積するにつれて階層的に整理またはクラスター化することが困難になる可能性があるため、各SRS IDに、検索に意味のあるラベル（[GUI]、[DB]など）を付けます。
ドット付き10進数を使用して要件をクラスター化するなど、他の方法もあります。次に例を示します。
- 1.0 GUI
- 2.0 DB
- 3.0処理
ご想像のとおり、それぞれの要件はトップレベルの番号に応じて順序付けする必要があります：1.1の場合は1.2、GUIの場合は1.2、2.3の場合は2.4、DBの場合は2.4など。削除と追加の管理。
要件ドキュメントで実施する重要な点：IDが要件に使用されると、別の要件に再度使用することはできません。つまり、SRS 1234が使用されてから削除された場合、後で再表示することはできません。 （そうすることを許可することは、進化するプロジェクトの過程での要件のトレーサビリティに絶対的な混乱をもたらします。）
事実上、SRS組織/構造には欠陥があることに注意してください。開発環境とアプリケーションのニーズに合ったものを選択してください。 （たとえば、上記の戦略は、FDAや他の政府機関によって監視されているものなど、高度に制御された開発環境で適切に機能します。）
最後に、要件管理ツールの使用を検討してください。このすべてをあなたのためにしてくれる良いものがあります（$$$$へのオープンソース）。
最高の概念的思考は、要件はさまざまな方法で相互に関連する別個のアイテムであるため、データベースに格納する必要があるということです。要件を保存するためにワードプロセッサを使用するのは間違った方法であり、「要件はドキュメントである」という概念的な考え方を駆り立てるため、多くの問題が発生します。ワードプロセッサを使用する必要がある場合は、Wordを使用して連絡先を格納する場合と同じように、各要件を個別に保持します。
したがって、アウトライン番号を使用して要件を維持すると問題が発生します。数値を変更した場合に、相互参照テストとSRSおよび顧客の要件を試行することを想像してみてください。 「要件10.2.3.1」について話し合うことを想像してみてください。昨日、お客様に送信したドキュメントは「10.2.2.1」でした。
要件はラベルであり、ほとんど意味を伝えません。スコープまたはユニットを識別するために、1つまたはいくつかの短い2から5文字の接頭辞が付いている場合がありますが、数千になるまでに、暗黙の意味は制限されます。例えば車では、EM-FUEL-1234（エンジン管理、燃料制御システム、要件1234）を使用している場合があります。
要件は、プロジェクト間で再利用できる必要があります。
要件は、プロジェクトの範囲と期間全体で一意である必要があります。ガイドとして、明確にするために要件を変更することは同じ数ですが、大幅に変更するには、古いものを削除して置き換えます。バージョンスキーム（Append_1、_2など）を使用すると便利です。
Wordを使用してこのデータベースを格納する必要がある場合は、開始トークンと終了トークンを使用して要件を特定することをお勧めします。要件の番号付けに固有のフォントスタイルを使用すると、マクロを使用して（おそらくデータベースに）強調表示、検索、抽出が簡単になります。例かもしれない
＃Req 1234＃
ブラブラブラブラ
＃ReqEnd＃
＃Req 1234a＃
Bla bla bla bla bla and more bla
＃ReqEnd＃