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