ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
[Think IT] 第2回：ユースケース図を学ぼう！ (3/3)
【伝わる！モデリング】はじめようUML！ 第2回：ユースケース図を学ぼう！ 著者：株式会社テクノロジックアート 照井 康真 公開日：2008/04/08（火） ユースケースの操作手順 「ユースケース」と言っても、それはユースケース図の中の楕円だけを表すのではありません。システムを実現するまでの過程では、それぞれのユースケースの詳細な操作方法を分析する必要があります。各ユースケースの詳細な操作方法は、「ユースケース記述」の中でイベントフローとして表されることが一般的です。 ユースケース記述には、ユースケース名、概要、主アクター、支援アクター、事前条件、事後条件（保障）、トリガー、基本フロー、代替フロー、例外フローなどの項目について日本語で記述します。これらのユースケース記述のテンプレート（様式）は、UML の範囲ではありませんので、プロジェクトによって異なります。 上記の項目は、一般的なユー
＠IT：連載：【改訂版】初歩のUML
ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
