ユースケースとユーザーストーリーを使用した機能要件の取得

Table of Contents hide

1 機能要件を取得するためのどのような手法ですか？

2 ユーザーストーリーを使用した機能要件の取得

3 ユーザーストーリーテンプレート

4 ユースケースで機能要件を特定する方法は？

5 実際のユーザーとユースケースアクター

6 システムのユースケースを特定して機能要件を取得する方法

7 参考文献

新しい製品、サービス、プロセス、またはシステムを定義する最初のステップは、要件、つまり特定の機能要件または非機能要件を定義することです。

機能要件は、製品またはサービスが顧客のニーズをどのように満たすかを説明します。これには、ユーザーが製品またはサービスをどのように操作するかを文書化するユースケースの機能が含まれます。
非機能要件とは、パフォーマンス、使いやすさ、耐久性、セキュリティ、財務（価格とコスト）など、ユーザーにはわからないことがある運用および製品の属性です。

この図を編集–機能要件と非機能要件

機能要件は、製品が顧客のために行う必要があることと考えることができますが、非機能要件は、製品またはサービスが満たすように設計する必要がある制約と考えることができます。

機能要件は、システムの意図された動作をキャプチャします。この動作は、システムが実行する必要のあるサービス、タスク、または機能として表現される場合があります。ソフトウェア開発業界では、ユースケースアプローチが機能要件を把握するための広範な慣行になりました。これは、それらが生まれたオブジェクト指向およびUMLコミュニティに特に当てはまりますが、それらの適用性はオブジェクト指向システムに限定されません。

機能要件を取得するためのどのような手法ですか？

機能要件は通常、ユースケースまたはユーザーシナリオの形式で取得されます。これらの用語は同じ意味で使用されることもありますが、実際にはわずかに異なる意味を持っています。

ユースケース は、システムと、ユーザーのニーズを満たすためにシステムが実行しなければならないことに焦点を当てています。
一方、ユーザーストーリーは、ユーザーの視点から製品の機能を示し、ユーザーの役割と達成したい特定の目標を指定します。

ユーザーストーリーを使用した機能要件の取得

ユーザーストーリーは、製品の要件の「誰が」、「何を」、「なぜ」をすばやく把握するための軽量な方法です。簡単に言えば、ユーザーストーリーは、ユーザーが望むニーズを表現するアイデアです。ユーザーストーリーは短く、各要素には通常10語または15語未満が含まれます。ユーザーストーリーは、プロジェクトパスに沿ったステップを特定するのに役立つ「やること」リストです。これらは、プロセスと結果の製品が要件を満たしていることを確認するのに役立ちます。

ユーザーストーリーテンプレート

ユーザーストーリーは、要件の重要な要素のみをキャプチャします。

誰のためですか？
システムに何を期待しますか？
なぜそれが重要なのですか（オプション？）？

開業医の70％が使用するユーザーストーリーの簡単な形式は次のとおりです。

役割 –ユーザーは、システムと対話する実際の人間である必要があります。

できるだけ具体的に
開発チームはユーザーではありません

アクション –システムの動作はアクションとして記述されるべきです。

通常、ユーザーストーリーごとに一意です
「システム」は暗示され、ストーリーには書かれていません
受動態ではなく能動態（「通知を受けることができます」）

メリット –メリットは、機能しない、またはシステムの外部にある実際の結果である必要があります。

多くのストーリーが同じ利益ステートメントを共有する場合があります。
メリットは、ストーリー内のユーザーだけでなく、他のユーザーや顧客にも役立つ可能性があります。

ユースケースで機能要件を特定する方法は？

システムの機能要件を完全に理解するには、システムが誰のためのものであるか、つまり誰がシステムを使用するかを知る必要があります。

この質問への答えは次のとおりです。ユースケース分析のアクター

ユースケースまたはユーザーストーリーは、システムが実行する必要のあるサービス、タスク、または機能として動作を表現できる機能要件をキャプチャします。ユースケースは、開発中のシステムの機能要件を定義するのに役立つ、ユーザーとシステムサービス間の相互作用を定義します。言い換えれば、顧客のニーズとウォンツを満たすために製品またはサービスが何をする必要があるかということです。

ユースケースは、製品またはサービスの特定のユーザーである「アクター」または「誰」から始まります。

アクターは、システムとの対話において役割を果たす人または外部システムです。アクターのインスタンスは、個人または外部システムにすることができます。ただし、各アクターは、システムの一意で重要なパースペクティブ、つまりアクターの各インスタンス（実際の人/ユーザー）に共通のパースペクティブを提供します。

実際のユーザーとユースケースアクター

システムの目的を完全に理解するには、システムの目的、つまり誰がシステムを使用するかを知る必要があります。さまざまなユーザータイプは、アクター（ロール）として表されます。

ロールと個々のユーザーの違いは、ロールが実際のユーザーではなく、特定のクラスのユーザーを表すことです。異なるユーザーが同じ役割を果たすことができます。その場合、各ユーザーはアクターのインスタンスを構成します。

アクターとアクターのインスタンスのこの違いを以下に示します。

下の図は、メアリーとジョンが自動販売機の顧客である場合を示しています。自動販売機を使用する場合、それぞれは、システムの特定の機能（この場合は購入食品の印刷）にアクセスできることを期待する顧客と呼ばれるアクターのインスタンスによって表されます。

この自動販売機のイラストを編集する

逆に、同じユーザーが複数の役割を演じることができます（つまり、同じ人が異なる役割を演じることができます）。

たとえば、ComputerSocietyの委員であるDr.Gatesです。彼は、ユーザーアカウントの追加や削除など、メンバーシップ管理システムの管理を担当しています。これを行うとき、彼は管理者（アクター）と呼ばれる役割を果たします。ただし、同じDr.GatesがComputerSocietyのメンバーである可能性もあります。この場合、彼は「メンバー」（俳優）と呼ばれる役割も果たします。

システムのユースケースを特定して機能要件を取得する方法

ユースケースは、利害関係者に次のタイプの質問をすることで特定できます（アクターの観点から回答する必要があります）。

この役割のユーザーは何を達成しようとしていますか？
この役割を果たすために、ユーザーは何ができる必要がありますか？
この役割のユーザーの主なタスクは何ですか？
この役割のユーザーは、調査、作成、または変更するためにどのような情報を必要としますか？
この役割のユーザーは、システムから何を通知する必要がありますか？
この役割のユーザーは、システムに何を通知する必要がありますか？

ご了承ください：

ユースケースは、特定のビジネス目標を達成するために実行するために必要な相互作用とタスクを定義するため、機能要件とシステム要件を検出して表す手段としてよく使用されます。ただし、これらは通常、システムのパフォーマンスや品質などの非機能要件を定義するための適切な方法ではありません。