SRSの要件の説明-ユースケース？
IEEE標準にアクセスできず、ネット上の情報が矛盾しています。ユースケースを使用してSRSでユーザー要件をキャプチャできますか？または、個別の要件ではなくシナリオに似ているため、ユースケースを個別に保持する必要がありますか？
簡単な要約
答えは「はい」です。UMLユースケースを使用してSRSの要件を記述できますが、標準が古くなっているため、元のSRSをその目的に合わせてカスタマイズする必要があります。
IEEE 830-1998
SRS標準の最新の公開バージョン IEEE 830-1998 は1998年のものであることを覚えておくことが重要です。この標準は、最新のソフトウェアエンジニアリングには適切に適用されません。現状のままではなく、独自のSRSを定義するための基礎として使用できます。
その理由の1つは、1998年に要件が通常、必要な関数として記述されたことです。主なパラダイムは手続き型プログラミングでした。多くの場合、要件は自然言語で記述されていました。今日、私たちはオブジェクト指向プログラミングとそれをサポートするためのさまざまなテクニック/ツールを使用しています。
ベストプラクティスは、これまでもそうであったように、明確な要件を記述することです。そのため、UMLは完全に実行可能な表記法です。唯一の提案は、グラフィカルな図を決定する前に、テキストの使用例も考慮することです。ユースケースには、誤解の可能性を排除するのに役立つはるかに多くの情報がテキストで含まれています。
標準へのアクセス
標準のコピーを購入する必要なく、その 概要 を読むことができます。ウィキペディアで無料で入手できます。一部のソフトウェアエンジニアは、独自のカスタムSRSの基礎としてIEEE 830-1998を使用しています。それはその年齢の問題に対処することができる方法です。
ユースケースを使用したカスタマイズされたSRSの例
トピックに関する論文 （フォローするのに十分な解決策）
UMLユースケースは、SRSに関するIEEE規格（1994年のUMLおよび10年前の1984年のSRS）のずっと後に作成されました。そのため、SRSのif-and-whereユースケースに答える信頼できるソースはありません。
SRSドキュメントのIEEE標準は、ほとんどの場合、ドキュメントをどのように作成するかを示しています。したがって、SRSのどこかにユースケースを配置したい場合は、ドキュメントの「特定の要件」の部分にあります。ユースケースは特定のシナリオであり、特定の要件として扱う必要があります。
ただし、最初のステップとして、要件ドキュメントからクライアントまたはレシーバーに何を要求するかを尋ねます。彼らは本当にUMLユースケースや何か他のものを持ちたいのですか？要件を引き出す方法はたくさんありますが、一部のクライアントはそれを望んでいる可能性があります。 Soren Lauesen 著の本「ソフトウェア要件-スタイルとテクニック」を参照してください。