私の現在の雇用主では、通常、従来の機能要件仕様を作成してから完全な技術設計を実行するという昔ながらのアプローチを採用しています。アプリが大きい場合は、アプリを小さなチャンクに分割し、一度に1つのチャンクを攻撃しますが、同じ基本パターンに従います。
このテクニックは何年にもわたって私に役立ってきました。ユースケースモデリングでは、ほぼ同じ情報を収集する必要があるようですが、編成が異なるだけです。
だから私の質問はこれです：ソフトウェア開発へのユースケース主導のアプローチに従うことの具体的な利点は何ですか？
あまり正式なユースケースアプローチは使用していませんが、ユースケースとあまり正式ではないユーザーストーリーは、ユーザーの観点から製品を想像するのに役立つことがわかりました。結局、私たちのほとんどは、私たち自身ではないユーザー向けのソフトウェアを作成します。ユースケースを策定することで、内部ビューから離れて、構築しているシステムの外部ビューに集中することができます。
それに加えて、アジャイルワークフローのために作業するためのパッケージ済みの生産ユニットを入手できます。1つのユースケースを実装できる場合、システムが果たす機能が1つあります。
私は、クラシックなデザインの事前要件の収集を行った経験があまりないことを認めます。この質問に対してより良い答えを与えることができる他の人々がいると確信しています
間違って行われた場合、利点はありません。このアプローチでは、ユースケースの写真をたくさん描き、UML（役に立たないモデリング言語）を使用して、なんとかして設計を行ったふりをします。
正しく行われると、ユースケースは、次の点で、従来の機能仕様を具体化する方法についての優れた高レベルの考え方です。
この場合、ユーザーは正確に何を達成しようとしていますか。
ソフトウェアはこれをどのようにサポートする必要がありますか。
ソフトウェアはこれをどのようにサポートする必要がありますか。
良いユースケースは、機能仕様への入力について利害関係者に質問する単なる方法だと思います。
あなたは正しいです-それは同じですが、よりセクシーな名前を持っています。1980年代に私はSSADM認定を取得し（当時のBBCの雇用主のようないくつかの大規模なNGOに必要）、そのプロセスを私がすでに知っているオブジェクト指向デザインの概念にかなり簡単にマッピングできることに驚きました。