ユースケースドキュメントの詳細レベル [終了]

Question

私はプロジェクトを規律化し、開始時にビジョン/スコープの文書を作成することに熱心に取り組んでいます。これにはユースケース図が含まれています。ユースケースをリストアップするだけで、顧客が求めているすべての要件を完全に理解するのに非常に役立ち、対話が可能になりました。

ユースケースをどこまで詳しく書くべきか疑問に思っています。Web アプリケーションを作成していて、ユーザーがログインしてレポートを表示する場合、ユースケースの説明にレポートのすべての列をリストする必要がありますか?

そうでない場合、いつその詳細を文書化すればよいでしょうか?

Answer 1

ユースケース図の利点は、それらが単純であり、エンドユーザーがそれらを読んで理解できることです

レポートに表示する列は、設計または要件の仕様（アジャイル用語での機能の詳細）の一部であり、ユースケース図に属しません

ユースケース図を乱雑にするものはどこかに属します

どこ？一貫した場所であり、どこにあるかわかっている限り、問題ではありません;-）

ユースケース図がどのようなものかを人々に思い出させるために-そしてなぜ偽の詳細の余地がないのか-
_{（ソース： agilemodeling.com ）}

Answer 2

私が取り組んでいるユースケースは、ユーザーの観点からアプリケーションを説明したものです。そのレベルでは、非常に詳細です。したがって、レポートの例では、ユースケースはレポートのレイアウト、どのデータがどのような順序で表示されるかなどを記述します。ユースケースでは、データがどのように取得されるか、またはデータがどこから来たのかはわかりません。

別の見方としては、ユースケースをテスターに​​渡すことを考えることです。文書内のあらゆるものをテスト (ブラック ボックス テスト) し、欠陥として登録することができます。したがって、特定のデータを特定の条件下で表示する必要がある場合は、テストできるようにそのケースをユースケースで指定する必要があります。

全体像を完成させるために作成する必要があるその他のドキュメントは、SAD (ソフトウェア アーキテクチャ ドキュメント) および NFR (非機能要件) と呼ばれるものです。SAD は、ソフトウェア設計の観点から、ソリューションをどのようにプログラムするか、使用するテクノロジ、および必要なアルゴリズムを説明します。NFR には、ソフトウェアまたはハードウェアの停止からの回復、応答時間などが含まれます。

Answer 3

どの列を含めるべきかがわかっている場合は、はい、それらを文書に入れます。最初に少し考えなければならない場合は、そうして文書化します。プログラマーが後でそれについて考えたり質問したりする必要がなくなり、プロセス全体がより効率的になります。

ただし、開発の進行中にシステム全体がどのように再生されるかについて十分な知識がないため、どの列を含めるべきか本当に本当にわからない場合は、それについて心配し、「特定の列TBD」と言うだけです。

前もってすべてを知ることはできませんが、あなたが知っていることを確実に文書化してください。

Answer 4

ユースケースの説明は次の間にある必要があります：

• 低詳細：そのユーザー 理解し、考えます：＆quot; 方法 簡単です＆quot;
• 高詳細：未解決の可能性（詳細な説明 各ステップの後に発生します）

Answer 5

UML表記を使用してユースケース図を作成すると、＆amp;要件をすばやく指定します。通常、ユースケース図をソフトウェアエンジニアのチームの前に描いて、状況をすばやく理解できます。

実際には、ユースケースは書面で作成する必要があります。 3つの形式があります。

1. 簡潔
2. カジュアル
3. 完全な服装

レポートの場合、レポート形式とテストをそれに応じて実行できるように、仕様をSRSドキュメントに添付する必要があります。

詳細については... ＆quot; UMLとパターンの適用：オブジェクト指向分析と設計の紹介、およびCraig Larmanによる反復開発＆quot;

を参照してください。