要件ドキュメントを効果的に作成 – 概要

すべてのUXデザインプロジェクトで最も重要な部分は、要件収集プロセスです。ここでは、要件収集の可能な方法の一部の概要を示します。

優れた設計は、すべてのビジネス要件、ユーザー要件、および機能要件を考慮に入れ、ユーザーのコメントやフィードバックに基づいて、新しい機能を通知し、新しい要件を生成することさえあります。作業する必要のない要件仕様がなければ、設計の多くは仮定と主観に委ねられます。要件は、プロジェクトを軌道に乗せ、設計の基礎を提供します。堅牢な設計は、設計プロセスのすべてのステップで常に要件に結びついています。

プロジェクトの要件を翻訳する方法はたくさんありますが、ユースケース、ユーザーストーリー、シナリオは、それらをキャプチャするために最も頻繁に使用される方法です。精巧なプロジェクトの中には、そのプロジェクトのすべての成果物の絶対的な基盤を形成する包括的なビジネス要件ドキュメント(BRD)がある場合があります。

それぞれが何であるか、そしてそれぞれがどのような文脈で使用されるかについて、もう少し深く掘り下げます...

ユースケースとは?

ユースケースは、インタラクション要件を引き出し、分析し、モデル化するための優れた方法です。また、インターフェイス、データ、プロセス、およびビジネスルールに関連する要件を生成するのにも役立ちます。ユースケースでは、ユーザーがシステムと対話する方法を説明する機能について説明します。それらはテキストとして書かれ、セクションに分割されています。ユースケースは、次のような形式に従います。

名前：ユースケースの名前

Description: Description of the Use Case

プライマリアクター:これが対象としている主なユーザー

前提条件：このユースケースを開始するには、すでに何が存在する必要がありますか

トリガー：このユースケースの始まり

基本フロー:イベントの理想的な流れ

代替フロー: 発生する可能性のあるその他のフロー

事後条件:実行されたフローの結果。

システム機能ごとに 1 つまたは複数のユースケースが存在する可能性があり、1 つのユースケースが関係を確立する別のユースケースを参照している場合があります。たとえば、ユースケース図やフローチャートを使用してそれらの関係を示すなど、それらを全体として分析することで、設計プロセスを開始するための有効な要件の強固な基盤が提供されます。

後: Matt TerskiMaster The Use Case Include Relationship

ユーザーストーリーとは?

ウォーターフォールからアジャイルへの移行を進めている多くの開発チームは、ユーザーストーリーの使用を好みます。ユースケースは高度に構造化されており、ステップを列挙していますが、ユーザーストーリーは必要性を示すことでステージを設定します。ユーザーストーリーは通常、短い文章や非公式の言葉で表現されています。例えば、「教師として、学習教材を学校のポータルにアップロードしたいのですが、そうすれば、生徒はそれにアクセスして作業することができます」。

後: Derek Huether認定ユーザーストーリーとは?

ユーザーストーリーは、高レベルの機能を収集し、優先順位を付けるためのアクティビティとして最適です。それらは本質的に骨格であり、より多くの詳細を組み込む必要があります。しかし、この最初のタスクをユーザーから学ぶことは、ユーザーのニーズをすべて特定し、優先順位を付けるための簡単な方法です。これらのユーザーストーリーは、ビジネス要件とユースケースに変化します。

シナリオとは

シナリオは、人とシステムとの相互作用の物語的な説明です。これらは通常、購入決定、テクノロジーや製品の使用、ライフスタイルの選択などで同様の行動パターンを示すユーザーのグループを表すユーザーペルソナにリンクされています。シナリオがユーザーのターゲット グループを中心に構築されている場合、機能要件やビジネス要件とは異なるユーザーのニーズに設計作業を集中させるのに役立ちます。シナリオは、どちらも非公式の非技術的な言語で書かれているため、ユーザーストーリーと似ています。通常、シナリオは長くなり、追加のコンテキスト情報が提供されます。シナリオが特徴とする詳細レベルはユースケースに匹敵しますが、シナリオにはユースケースのような正式な構造がありません。これにより、シナリオを関連する部分に解決するのが面倒になる可能性があります。ただし、ユース ケースとは異なり、シナリオは、技術的なバックグラウンドを持たないユーザーでも作成して理解できます。

After: Eric Schaffer  UI Design Newsletter , HFI

以下は、セールスマネージャーの日々の活動を説明する3つの方法すべての例です。

Scenario

John は、営業チームをより適切に管理したいと考えています。そのためには、チームの人々のリストを見る必要があります。彼は、営業担当者の名前や地理的な場所、または顧客で検索したいと考えています。彼は彼の捜索を通じてアダムを見つけます。彼は Adam の顧客と彼の販売記録を見たいと思っています。

User Story

セールスマネージャーとして、ログインしてチームメンバーのリストを検索したいと思います。チーム メンバーとそれに関連する販売記録を検索する検索オプションが欲しいです。

Use Case

名前	Sales Person Lookup
説明	これは、セールスマネージャーが自分のチームの特定の営業担当者に関する情報にアクセスするために実行するアクティビティを説明するユースケースです
プライマリーアクター	営業部長
Precondition	管理者権限でログインしている必要があります
Trigger	ユーザーがダッシュボードでアクセスした
Basic Flow	User	System
	ユーザーは米国地図で北東地域にアクセスします	NE USのページ上のシステムフィルター情報
	ユーザーがすべての営業担当者のリストにアクセスする	システムは完全な営業担当者リストを表示します
	ユーザーは、営業担当者のリストから Adam を選択します	アダムの情報と販売レコードが表示されます
Alternate Flow	User	System
	ユーザーは、検索文字列として「Adam」を使用する検索エンジンを利用します。	姓名に「Adam」が含まれるすべての営業担当者の検索結果リストが表示されます
	ユーザーが検索結果から「Adam」を選択します	アダムの情報と販売レコードが表示されます
事後条件	すべての条件が満たされると、ユーザーは調べた営業担当者の詳細が表示されます

要件を記述するためのこれらすべての手法は、要件を統合して効果的な方法で提示する方法であり、それらを設計に含める特定の方法を指示するものではありません。たとえば、このユースケースのルックアップリストは、UIでドロップダウンメニュー、リストボックス、またはグリッドとしてアドレス指定でき、デザイナーが決定できます。つまり、要件は、タスクを実行するためにユーザーが持つ必要がある一連の能力のみを求めます。

個人的には、ユースケースとシナリオを組み合わせてデザインするのが好きです。これには例外があり、クライアントからの口頭でのブリーフィングを受けなければならなかったことがありますが、彼らは専門知識を持っていないか、プロジェクトの精巧な要件を生成するための時間と興味を持っていません。そして、クライアントが常に詳細な要件を知っているとは限らない状況があります。デザイナーにとっては素晴らしいプロジェクトスタートではありませんが...そのようなクライアントを支援する最善の方法は、設計プロセスを通じてクライアントを導き、ブレーンストーミングを使用してアイデアを生成し、その過程でそれらのアイデアを具体的な要件に変換することです。