要件の収集は、デスクトップ、Web、モバイルアプリケーションなどの情報システムを作成するプロセス、または単に既存のソリューションを更新するプロセスの最も重要な段階の1つです。 要件の収集を開始する前に、システムを使用するすべての関係者（利害関係者）を識別する必要があります。 このリストが正確であればあるほど、要件はより完全になります。 したがって、まず第一に、これらの利害関係者が誰であるかを考慮してください。
利害関係者とは、プロジェクトに積極的に関与し、システムの作成プロセスだけでなく、プロジェクト自体が完了した直後にその利益に影響を与える可能性のある個人および/または組織のことです。 マネージャー、部門長、ディレクター、既成のソリューションと少なくとも何らかの方法でやり取りする組織の従業員、およびその要件（希望、アイデア、ニーズ、問題）を収集することができます。
顧客が何を望んでいるかをよりよく理解するのに役立つ多くの異なる要件収集手法があります。
主なものをより詳細に検討してください。
質問する
この方法には、オープン（回答者が回答を定式化する必要がある）およびクローズ（回答者が提案されたオプションから回答を選択する必要がある）質問を含むことができるアンケート（アンケート、要約）の準備が含まれます。
質問は、既知の要件を確認または詳細化し、ソリューションのパラメーターを選択するために使用されます。
アンケートの最も有名な例は、「サイトの開発に関する概要」-基本的な要件のリストと将来のサイトに関する情報を含むアンケートです。
利点 ：
- 高速な結果。
- 材料費が比較的低い。
欠点 ：
- この方法は、暗黙的な要件の検出には適していません。
- アンケートを作成する場合、必要なすべての質問を考慮することは物理的に不可能です。
インタビュー
この方法は、関心のある人と一対一での一種の「心と心」の会話として多くの人に知られています。
要件に関する特定のオプションを確認または反論するためには、情報を入手するために未解決の質問をし、情報を取得する必要があります。
この方法は、主に特定のトピックに関する情報を取得したり、要件を明確にするために使用されます。
これは多くの人にとっては簡単に思えるかもしれませんが、そうではありません。 良いインタビューは十分に難しいです。 面接対象者の反応に柔軟に対応し、必要に応じて、準備された質問の順序や文言を変更する必要があります。 インタビュー中にレコーダーをオンにするか、メモを取ることを忘れないでください。
プロから：
- ランダムな順序で質問をする機能。
- 補助材料を使用する機能。
- インタビュー対象者の非言語的反応の分析により、回答の信頼性について追加の結論を引き出すことができます。
マイナスのうち：
- インタビューには多くの時間と労力がかかります。
- 追加の課題は、インタビュー対象者から同じ回答を得ることです。
自動記録
この方法では、レコード、レター（電子メール）、および作成者が顧客またはエンドユーザー（つまり、利害関係者）である他のドキュメントを操作します。
実際には、これは、レコーダーまたは最も一般的なナプキンに話されたドキュメントおよび一連のアクションであり、顧客が彼のアイデア/問題/ウィッシュリストをスケッチしました。
このような方法の例としては、プロジェクトのコンセプトやビジョン（顧客自身が「TK」と呼ぶのが好きです）を操作することができます。これは、分析作業の開始時に送信されました。
利点：
- 複雑な手順またはプロセスをよりよく理解するのに役立ちます。
欠点：
- この方法は、顧客の経験と、顧客の考えを定式化して表現する能力に大きく依存します。
既存のドキュメントを調べる
この手法は、組織が顧客のニーズを判断するのに役立つドキュメントを持っている場合に使用できます。 ドキュメントの例には、規制、
プロセスの説明、組織構造、製品仕様、さまざまな手順、標準と指示、ドキュメントテンプレートなど
特定された要件は、さらなる分析の基礎であり、詳細にすべきです。
この手法は、たとえば、組織で確立された規制ビジネスプロセスの自動化に適用できます。
プラス：
- 迅速な情報検索。
マイナス：
- この方法は、会社が基本的なドキュメントのみを持っている場合（または完全に不在の場合）、またはお客様の会社がドキュメントの関連性をサポートしていない場合は適用できません。
再利用仕様
これらのプロジェクトの1つ以上が既に完了している場合、仕様を再利用できます。
前のプロジェクトで作成された参照条件は、要件の収集、分析、および開発の期間を短縮するために別のプロジェクトに使用できます。これにより、開発を迅速に開始できます。
たとえば、オンラインストアのTKは互いに類似しており、同じ要件が含まれています。
ほとんどの場合、ドキュメントの一部のみが新しいプロジェクトに関連しているため、顧客の現在の目標と目標を遵守するための要件を徹底的にチェックする必要があります。
利点：
- ドキュメントを作成する時間を短縮します。
短所：
- 最初のプロジェクトの高コスト。
- 要件を過度に詳細に記述すると、将来的にコストのかかる変更につながる可能性があります。
開発会社の顧客担当者
要件を収集するための最も効果的な方法の1つです。これにより、進捗状況をタイムリーに評価し、顧客の代表者から正しい実装を受け取り、短時間で要件を更新および開発するためのフィードバック（フィードバック）および追加情報を受け取ることができます。
この方法は、反復的な開発中に要件を収集および管理するためによく使用され、要件を迅速に収集、調整、および変更できます。
さらに、開発会社に顧客担当者を置くことは、アジャイルの主要なルールの1つであると言えます。
利点：
- 顧客からの迅速なフィードバックと情報。
短所：
- 顧客にとってはかなり高い価格。
- 従業員の適応にかかる時間。
「現場で」働く
「現場」での作業は、システムの将来のユーザーのアクティビティとプロセスを監視し、この観察に基づいて要件を決定することで構成されます。 簡単に言えば、これはユーザーの作業方法を監視し、プロセス、タスク、およびアクティビティの結果を文書化することです。
この方法は、利害関係者のニーズの説明と表現における困難に関連する問題を回避します。 場合によっては、監視プロセスに「インタビュー」ユーザーが同行して、作業とタスクの機能と詳細を明確にすることがあります。 観察の過程で、顧客のビジネスプロセスを最適化する方法を特定することもできます。
利点：
- 問題を視覚的に確認し、最適なソリューションを開発できます。
- 従業員の仕事を観察することにより、最も正確に要件を収集するのに役立ちます。
短所：
- 監視プロセス中に、いくつかの代替ビジネスプロセスシナリオが見落とされる場合があります。
- 秘密企業や危険な（有害な）産業に適用することは困難です。
トレーニング
トレーニングとは、プロセスを熟知しているお客様またはお客様の組織のその他の人物が、教師と生徒の原則についてアナリストを教育するプロセスです。
この方法は、顧客の従業員のプロセスと活動を他の方法を使用して説明することが困難な場合、または顧客が要件の適切な説明を提供できない場合に役立ちます。
トレーニングにより、複雑なビジネスプロセスをよりよく理解できるだけでなく、システムの将来のユーザーの間で抽象的な思考や自己表現の欠如に関連する困難を克服できます。
利点：
- 複雑なビジネスプロセスを理解できるため、最適なソリューションを提供できます。
短所：
- 高コストと耐久性。
- この方法は、危険な（有害な）産業には適用できません。
ブレーンストーミング
ブレーンストーミングは、顧客の組織またはシステム機能の新しい領域または十分に研究されていない領域に関連する要件を取得する最も一般的に使用される方法です。
これにより、さまざまな利害関係者（利害関係者）から多くのアイデアを最短時間でほぼ無料で収集できます。
ブレーンストーミングセッション中、参加者はこの問題の解決策に関するアイデアを「投げる」。
この手法を使用すると、特定の問題を解決するためのさまざまなオプションを作成したり、要件の競合を解決したりできます。
長所：
- これにより、多くの（非標準を含む）ソリューションオプションを生成でき、参加者が互いのアイデアを開発することもできます。
短所：
- ブレーンストーミングセッションの参加者は、アイデアに動機付けられるべきです。
- 分散したチームに適用するのは難しい。
ミーティング
ミーティング-特定され、事前に参加者に表明された特定の問題の議論に焦点を当てたミーティング。
このような会議には、現在の問題に関するさまざまな視点を持つ人々が参加し、さまざまな角度からの意見に基づいて要件を説明するのに役立ちます。 会議中に、要件の一般的なリストが明確になり、隠された要件が特定され、要件の競合が解決されます。
ミーティングは、アジャイルの重要なプラクティスの1つです。 プロジェクトの開発と問題の解決に関心のあるすべての関係者が関与します。
長所：
- 要件を作成および詳細化し、優先順位を特定できます。
短所：
- 会議の開催の難しさ、チームが地理的に分割されている場合、会議に必要なすべての人々の存在に問題が生じる可能性があります。
- 合意に達するとは限りません。
ユースケース
ユースケースまたはユースケースを使用すると、参加者に代わって機能要件を収集および定式化できますユースケース図は、ソリューションの境界を決定し、外部システムおよび参加者とのリンクを示します。
このメソッドを使用すると、ユーザーの観点から要件を詳細に記述でき、実装する機能を明確にして体系化することもできます。
長所：
- シナリオ（メインシナリオと代替シナリオ）の開発に関するすべてのオプションを解決できます。
短所：
- この方法は、非機能要件の収集には適用されません。
エピローグ
技術の組み合わせにより、要件の収集を改善し、「損失」を回避できます。
要件を収集するときは、機能要件（システムが行うこと）だけでなく、非機能要件（システムがこれを行う方法）も重要であることを覚えておく必要があります。
慎重に組み立てられた要件は、プロジェクトのリスクを最小限に抑えます システムの開発のための明確で理解しやすい基盤を作成できます。
この記事の情報は、 REQB Certified Professional for Requirements Engineering（Basic）tutorialから取得したものです 。