新しい要件手順でビジネスユースケースとユーザーストーリーを使用しますか？
実際、私が働いている会社には、ソフトウェアを開発するための手順や方法論はありません。開発されたソフトウェアは自社の管理者であり、クライアントアプリケーションの多くはデータ駆動型であり、必要に応じて一部のアウトソーシングを行っています。私のマネージャーは、SDLC（ソフトウェア開発ライフサイクル）の一連の手順を作成するタスクを私に与えてくれました。近い将来、SCRUMが実装されることを知っています。
私は要件フェーズへのさまざまなアプローチについて多くのことを読んで研究しましたが、会社に利益をもたらすと考えられる方法論を説明している非常に優れた本、Mastering the Requirements Processを見つけました（ソフトウェアは考えずに作成される場合があるため） Volere要件仕様テンプレートである主な問題またはプロセス）。
私は本を読み終えていません、そして私は手順の草案を引き渡さなければなりません、そして私はあまりにも物事でかなり混乱しています：
ユーザーストーリーまたはビジネスユースケースを使用して要件またはその両方を指定する場合、SCRUMはチームが理解して学習するのに時間がかかる可能性があることを考慮してください。 （違いについてはすでに多くの回答があるので、私は違いについて質問していません）。
アジャイルマニフェストのスクラム方法論には、要件が常に変化しているため、ドキュメントよりもソフトウェアを機能させるという原則があります。これはロジックです。この本には、どのようなプロジェクトでより正式なものが必要であるかを確立するいくつかの例があります。「Rabbit Projects」という名前の迅速でそれほど正式ではないプロジェクトの場合、著者は常にSRSのドキュメントに要件がある必要はないと述べました、それでは、利害関係者とソフトウェアチームは、文書化されていない場合に何をする必要があるかを明確に理解するにはどうすればよいでしょうか。
ユーザーストーリーまたはビジネスユースケース
ほとんどの人は、公式のスクラムガイドがユーザーストーリーにさえ言及しておらず、バックログアイテムにさえ言及していることを知って驚いています。これには、十分な理由があります。それらのフォームはプロジェクト固有のものです。ほとんどの場合、特に初心者にとっては、ユーザーストーリーは良い考えです。しかし、どのように組織するかを決めるのはチーム次第です。そのため、どちらを使用するかを指定することはできません。それは、チームとその環境によって異なります。チームに話しかけ、2、3のスプリントの合意を見つけてから、回顧展を使用して経験から学び、進め方を決定します。
ドキュメントなしで明確に理解
文書化されていない明確な理解は、主に頻繁な対面のコミュニケーションによって達成されます。その上、アジャイル宣言はドキュメンテーションに反対するものではなく、機能するソフトウェアがより重要であると主張しているだけです。繰り返しになりますが、チームと一緒になって、どのドキュメントがどれだけ役立つかを判断する必要があります。