要求定義について

要件定義のプロセス

プロジェクトが始まる際に、ビジネス要求を技術要件に変換する方法や、要件の優先順位付けも行う。

要件定義の基本的な流れを理解するために、まずは要件定義のプロセス全体を掴んでいきましょう。

以下は要件定義の主要なステップです。

要求収集は、プロジェクトの初期段階で非常に重要な作業です。この段階では、ステークホルダー（顧客、ユーザー、ビジネスオーナーなど）から必要な情報を収集し、ビジネス要求を技術的要件に変換するための基盤を築きます。

ステークホルダーとのインタビュー：まず、プロジェクトに関わるすべての関係者と会い、彼らの期待、要求、目標を理解します。
質問リストの作成：どのような情報を収集するべきか、あらかじめ質問リストを作成しておくことが重要です。これには、システムが提供するべき機能、システムの制約、ユーザーのニーズなどが含まれます。
ユーザーストーリー：ユーザーがシステムをどのように使いたいかを示す「ユーザーストーリー」を使って、要求を整理します。例えば、「ユーザーとして、〇〇をしたい」といった形です。
ワークショップと観察：ユーザーが実際に作業している様子を観察したり、ワークショップを開いて意見を集めたりします。これにより、言葉にできない要求や隠れたニーズが見つかることがあります。

収集した要求を整理し、どの要求が本当に必要なのかを明確にします。この段階では、要件をカテゴリごとに分類したり、重複を削除したりします。

機能要件と非機能要件：
- 機能要件：システムが実行すべき具体的な機能。例えば、「ユーザーがログインできる」など。
- 非機能要件：システムのパフォーマンス、セキュリティ、可用性、拡張性など、システムの「質」に関する要件。
優先順位付け：収集した要件が全て重要なわけではありません。ステークホルダーとの議論を通じて、各要件に対して優先順位をつけます。これには次の方法を使います：
- MoSCoW法（Must have, Should have, Could have, Won't have）：要件を4つのカテゴリに分けて優先順位をつける。
- Kanoモデル：顧客がどれだけ満足するかに基づいて要件を分類します。基本的な要件（必須）、期待を超える要件（魅力的要件）など。

要件を文書化することは、プロジェクトの成功に向けて非常に重要なステップです。文書化は、要件を明確にし、関係者間で共有するためのものです。以下の要素が含まれます：

要件定義書：各要件がどのようにシステムで実現されるべきかを記述します。要件定義書には、機能要件、非機能要件、制約条件、用語の定義、システムの動作などが含まれます。
ユースケース：ユーザーがシステムをどのように利用するかのシナリオを詳細に記述します。ユースケース図とその詳細な説明がよく使われます。
プロトタイプ：要件が正確かつ実現可能かを視覚的に確認するために、プロトタイプを作成することもあります。特にUI/UXの要件の場合、画面のモックアップを作成してフィードバックを得ます。

要件がすべてのステークホルダーのニーズを反映しているかを確認する段階です。この段階で、以下のことを行います：

プロジェクトの進行に伴い、要件が変更されることがあります。その際、変更管理プロセスを適切に運用することが大切です。

変更のトラッキング：変更要求が発生した場合、それを適切にトラッキングし、影響範囲を評価します。変更がプロジェクトの進行にどれほど影響を与えるかを判断することが必要です。
変更の承認プロセス：要件変更がビジネスにとって有益か、またはプロジェクトにおいて現実的かを検討し、関係者に承認を求めます。
コミュニケーション：変更が発生した場合、すべての関係者に変更内容を適切に伝え、認識を一致させることが重要です。

この要件定義のプロセスを順を追って実践することで、システム開発の初期段階で必要な要件をしっかりと固め、プロジェクトが円滑に進行できるようにすることができます。