use-case - ユースケースと機能要件に違いはありますか?

Question

人それぞれ意見が違うみたいなので気になります。SRS ドキュメントを作成するとき、ユース ケースと機能要件の両方が必要ですか、それとも機能要件はユース ケースを拡張するため、1 つだけが必要ですか?

Answer 1

... ユースケースと機能要件の両方が必要ですか、それとも 1 つだけが必要ですか ...

違いは、これらの手法の主要な作成者をよく読んだ場合のアプローチのみです。

ユース ケース アプローチは、重要な要件を収集するためのより効率的な手段と見なされますが、機能要件アプローチは、冗長性、重複、および不要な機能を除外できる完全な仕様を保証します。

ユース ケース アプローチでは、最初に外部アクター (ユーザー、プロセス、エージェントなど) とそれらがシステムとどのようにやり取りするかを考慮に入れますが、機能要件はソリューションの角度から問題にアプローチします (この機能を使用して問題を解決するにはどうすればよいか)。問題？）

ユースケースは、アクター、ユーザー、メソッド、ドメイン知識、独自のテクニックなどをキャプチャします。ユースケースは、完全なパッケージ化されたソリューションにつながる可能性があります。機能的アプローチは、製品カテゴリ、製品バリエーション、市場の差別化を捉えます。機能的アプローチは、機能が開発され、以前のリリースに重ねられる、細かく調整されたリリース戦略の開発に役立ちます。

別の言い方をすれば、ユースケースはよりユーザー指向の仕様であり、機能的アプローチは開発者の仕様であるということです。言語とコミュニケーションの観点から、ユース ケース アプローチは、エンド ユーザーの言語イディオムにすでにキャストされているドキュメントを理解しやすくすることにつながると言われています。一方、機能的アプローチは、システムを完全で統合された全体にするものです。

最新の SRS では、完全で有用なシステムには両方の視点が不可欠です。理想的には、一方を他方にマッピングする必要があります。プロセスをどこから始めても、両方のアプローチの利点を軽視することはできません。

Answer 2

両方を使用する必要がある場合 (システムが大規模または複雑なため)、機能仕様をユースケースよりも高いレベルに保ちます。機能仕様 (BFD やその他の表記法など) を定義すると、目的のビューに応じて、プロセス モデル、ストーリー マッピング、レベル化された DFD、またはユースケースを下位レベルに追加できます。DFD とエンティティ モデルは相互にクロスチェックします。