ユースケース: 要件と設計の間の理想的な橋渡し?

技術的な詳細や際限のない機能に惑わされることなく、製品が行う必要のあるすべてを説明しようとしているところを想像してみてください。 リスト。これは、Ivar Jacobson が 1980 年代にユースケースを紹介したときに解決しようとした問題です。彼は、システムが内部でどのように機能するかを心配するのではなく、システムと対話する人々やシステムに対してシステムが何を行うかに焦点を当て、システムを外部から、あたかも「ブラック ボックス」であるかのように説明しました。これにより、開発者は要件をより明確かつ一貫して把握できるようになり、今日私たちが頼りにしている使用事例への道が開かれました。

このビデオでは、ウィリアム・ハドソンが、 ユーザーエクスペリエンス Syntagm Ltd のストラテジスト兼創設者がユースケースを紹介し、Ivar Jacobson が要件を実装に橋渡しするためにユースケースをどのように作成したかについて説明します。

Ivar が使用したユースケースを表す元の用語はスウェーデン語でした。 ユースケース、直訳すると「使用例」となります。しかし、これは英語としてはぎこちない表現だったので、彼はそれを「use case」と短縮しました。ソフトウェア開発コミュニティは彼のアプローチを急速に採用し、 それはシステムを指定するための支配的な方法となりました。 アジャイル 人気になった 2000 年代の変わり目あたり (上部のグラフでわかるように)。

図と説明: ユースケースの 2 つの部分

ユースケースは 2 つの部分に分かれています。

• ユースケース図: アクターとそれらが関連付けられているユースケースの概要。

• 使用事例 物語: 各ユースケースにおけるアクターとシステム間の対話の説明。

このビデオでは、William が 2 つの部分を示し、図がどのようにして統一モデリング言語 (UML) の一部になったかを説明しています。

ユースケース図

ビデオで示されているユースケースの基本概念を以下に示します。注意してください。 俳優 他のシステムを含む、システムと対話するあらゆるものです。俳優が撮る 役割。残念なことに、従来のソフトウェア開発では、 役割はユーザー中心ではない。それらは、それを実行する人々のニーズや行動についてはほとんど教えてくれません。対話型システムでは、顧客、マネージャー、ユーザーなどの情報のない役割が表示されます。しかし、あなたはそれを解決するためにここにいます!

図は、システムの動作の全体的な概要を提供するのに非常に役立ちます。ただし、それらに含まれるのは、 時間や順序の要素はありません、これは欠点になる可能性があります。一般的に行われているのは、 図の上の方に、より一般的な使用例を配置します。。これは、ビデオで見たサンプルの場合です。

役割はユーザーのニーズについてほとんど教えてくれませんが、重要な場合があります。上の例では、1 人が 2 つの異なる役割を果たしている場合もあれば、異なる人が役割を担当している場合もあります。飛行機に搭乗する際には、これは重要な違いです。

ユースケースの説明

ユースケースの説明に標準的な形式はありませんが、Jacobson は次の要素を指定しています。

• 名前: ユースケースを説明する名前。

• 俳優: システムと対話するエンティティ (ユーザーまたは他のシステム)。

• ゴール: 俳優がこのインタラクションを通じて達成しようとしていること。

• 前提条件: ユースケースを開始する前に満たす必要がある条件。

• 基本的な流れ: アクターとシステム間の典型的な対話シーケンス。

• 代替フロー: 基本的なフローのバリエーション。例外やその他の可能性をカバーします。

• 事後条件: ユースケースが完了した後のシステムの状態。

簡単な例を次に示します。

• 名前： オンラインで座席を予約する

• 俳優: 乗客;予約プラットフォーム

• ゴール： 既存のフライト予約で座席を選択して予約します。

• 基本的な流れ：

  • 乗客は予約プラットフォームにログインし、予約を開始します。

  • システムにはフライトの詳細と利用可能な座席が表示されます。

  • 乗客は好みの座席を選択します。

  • システムは座席割り当てを使用して予約を更新します。

  • システムは予約の更新を確認します。

• 代替フロー: 選択された座席は利用できません – システムは乗客に通知し、別の座席を選択するよう求めます。

プログラマーではない場合、事前条件と事後条件は怖く聞こえるかもしれません。しかし、それらはただの物です ユースケースが成功するには、これが true でなければなりません (前提条件) そして ユースケースが完了すると (事後条件)、これは true になる必要があります。。これらは次のような用途に役立ちます。 ユーザー中心のデザイン インタラクションの前後にユーザーに条件を表示する必要がある場合があるため、ユーザー エクスペリエンスが向上します。上の例の事前条件と事後条件を考えてみましょう。

前提条件

• 乗客は指定されたフライトで 1 つ以上の座席を予約する必要があります。

• フライトはオンライン座席予約を受け付けている必要があります。

• 予約可能な座席が空いている必要があります。

事後条件

上記の例は簡略化されていますが、 基本的なフローの説明と代替フローの説明は実際には長くなる可能性があります。また、顧客が購入した座席を別の人物である場合に予約できるかどうかという問題もあります。このような質問に対するアジャイル アプローチでは、最後の瞬間まで問題が解決されます。 「ジャストインタイム設計」 しかし、それが初期の設計決定であれば、多大な労力と混乱が避けられるでしょう。

使用ストーリーの詳細をプロセスの段階に一致させる

ユースケースを含むすべての使用事例に関する最後のポイントは、プロセスのどの段階にいるかによって、適切な詳細レベルが異なるということです。設計の初期段階での使用ストーリー 詳細なやり取りは含めないでください、インターフェイス コンポーネントを含むものなど。したがって、「サンドラがポップアップ カレンダーから旅行の出発日を選択する」ではなく、「サンドラが旅行の出発日を指定する」と書く必要があります。実装の詳細に入るのが早すぎる可能性があります。 「時期尚早なデザイン」 実装の詳細は後の段階で必要になりますが、 あまりにも早すぎると気が散って制限されてしまいます。また、作業を提供する場合は、 プロトタイプ、インタラクションの詳細を散文で説明するよりも効果的であることがよくわかります。

テイクアウェイ

ユースケースは、設計者と開発者がシステムが何をすべきかを把握し始める上で重要なステップとなりました。 システムを記述できるようにした 行動 構造化された方法でたとえそれらが必ずしも研究に基づいたものではなかったとしても、 ユーザーのニーズ または行動。

これで、両方のユースケースをどのように表現できるかがわかりました。 視覚的に、図で、 そして 文章的に、物語的に。物語では通常、すべてが期待どおりに機能する「晴れた日」の流れが説明されますが、 しかし、例外、決定、エッジケースなどの代替フローも同様に把握することが重要です。。

ユースケースから得たもう 1 つの教訓: 適切な詳細レベルは、プロセスのどこにいるかによって異なります。あまりにも早く詳細を設定しすぎると、選択肢が制限され、「時期尚早な設計」につながる可能性があります。使用に関するストーリーを適切な詳細レベルに保ち、 あなたは柔軟かつ創造的であり続けるでしょう 構造を提供しながら。

ヒーロー画像：© インタラクションデザイン 財団、CC BY-SA 4.0