私は自分のプロジェクトを規律し、最初からビジョン/スコープの文書を作成することに力を注いでいます。これには、ユースケース図が含まれています。ユースケースをリストアップするだけで、顧客が求めているすべての要件を完全に理解することができ、対話が開かれました。
ユースケースをどの程度詳細に記述すべきか疑問に思っています。Web アプリケーションを作成していて、ユーザーがログインしてレポートを表示する場合、レポートのすべての列をユース ケースの説明に記載する必要がありますか?
そうでない場合、いつそれらの詳細を文書化しますか?
私が働いているユースケースは、ユーザーの視点から見たアプリケーションの説明です。そのレベルでは、非常に詳細です。したがって、レポートの例では、ユース ケースは、レポートのレイアウト、表示されるデータ、表示される順序などを記述します。ユースケースでは、そのデータがどのように取得されたのか、どこから来たのかはわかりません。
別の見方としては、ユースケースをテスターに渡すことを考えてみてください。ドキュメント内のあらゆるものをテスト (ブラック ボックス テスト) し、欠陥として登録できます。したがって、特定のデータが特定の条件下で表示されることになっている場合は、そのケースをユースケースで指定して、テストできるようにする必要があります。
全体像を完成させるために作成する必要があるその他のドキュメントは、SAD (ソフトウェア アーキテクチャ ドキュメント) および NFR (非機能要件) と呼ばれるものです。SAD は、ソフトウェア設計の観点から、ソリューションのプログラミング方法、使用するテクノロジ、および必要なアルゴリズムを記述します。NFR には、ソフトウェアまたはハードウェアの停止からの復旧、応答時間などが含まれます。
ユースケース図の利点は、それらが単純で、エンドユーザーが読んで理解できることです。
レポートに表示される列は、設計または要件仕様 (機能の詳細、アジャイル用語) の一部であり、ユース ケース図には属しません。
ユースケース図を乱雑にするものはすべて別の場所に属します
どこ？それが一貫した場所であり、どこにあるかを知っている限り、それは問題ではありません;-)
ユースケース図がどのように見えるか、そして偽りの詳細を入れる余地がない理由を人々に思い出させるため(出典: agilemodeling.com )
どの列を含める必要があるかがわかっている場合は、はい、それらをドキュメントに入れます。最初に少し考える必要がある場合は、それを実行して文書化してください。プログラマーが後で考えたり質問したりする必要がなくなり、プロセス全体がより効率的になります。
ただし、開発が開始されたときにシステム全体がどのように機能するかについて十分にわかっていないために、まだどの列を含めるべきか本当にわからない場合は、気にせずに「特定の列 TBD」と言ってください。 ."
前もってすべてを知ることはできませんが、知っていることを確実に文書化してください。
UML 表記を使用してユースケース図を作成すると、要件をすばやく理解して指定するのに役立ちます。通常、状況をすばやく理解するために、ソフトウェア エンジニアのチームの前でユースケース図を描くことができます。
実際には、ユースケースは書面形式である必要があります。3つのフォーマットがあります。
レポートの場合、レポートの形式と仕様を SRS ドキュメントに添付して、それに応じてテストを実行できるようにする必要があります。
詳細については... 「UMLとパターンの適用: Craig Larmanによるオブジェクト指向分析と設計および反復開発の紹介」を参照してください。
ユースケースの説明は次の範囲である必要があります。
