開発プロジェクトの過程で、ユーザーはいつでもいくつかの新しい要件を提示し、開発者にそれらを解決するように依頼します。これらの要件は、開発フェーズ中および開発フェーズ後に提示される場合があります。需要分析の隣接する2つのサブフェーズ、または反復サイクルの需要分析では、後者の期間またはサイクルの需要分析結果が前の期間またはサイクルの需要分析結果と一致していません。この不一致を需要変化と呼びます。需要が変化する主な理由は次のとおりです。
（1）要件分析段階では、開発者とユーザー間のコミュニケーションが不十分です。ニーズ分析の段階では、開発者とユーザーのコミュニケーションがうまくいかず、開発者はユーザーから提供されたおおよその情報に基づいてユーザーのニーズを導き出します。この種の需要分析を通じて得られた需要は、多くの場合、ユーザーの実際の需要とはかけ離れており、ユーザーの変更要求につながります。
（2）プロジェクトの実施サイクルが長すぎる。時間の経過とともに、システム全体に対するユーザーの理解はますます深くなっています。彼らは、モジュールのインターフェース、機能、およびパフォーマンスに関して、ますます多くの要件を提示します。
（3）テクノロジーの更新が速すぎます。技術の急速な更新により、企業はいくつかの新しい機器を導入する可能性があり、これらの機器はターゲットシステムと直接的な関係がある可能性があります。この変更はユーザーの元の問題の解決前または解決中に発生する可能性があるため、開発者はしてはなりません。この新しい要求に参加しないでください。
頻繁な変更の解決策
1.ビジネスの状況に関係なく、以前の技術契約では、達成できる機能を明確に説明する必要があります。
2.顧客との連絡により確認されたすべての変更は、文書の提出プロセスに厳密に従って行われるものとします。
3.いつでも技術契約を確認して、顧客の変更が契約の範囲内にあるかどうかを確認します。
4.情報を使用して、顧客が不当な変更を提案したり、回数が多すぎたりした場合、顧客と交渉して、そのような変更を行うか、プロジェクトの第2フェーズに変更を導くかについて話し合うことができます。
5.頻繁な変更を引き起こすビジネス要因があるため、プロジェクトマネージャーがリソースをどのように使用するかに応じて、ビジネス要因を使用して頻繁な変更を減らすこともできます。
6.実装中に顧客のニーズを導くことは非常に重要であり、オンサイトの実装担当者は対応する役割を果たす必要があります。
多くのプロジェクトマネージャーは、プロジェクトの実施準備が整ったときに実際に参加し、基本的には技術者です。プロジェクトの全体的な状況と関連リソースについて可能な限り多くの知識を持ち、早期かつ合理的に使用するために複数のリソースを使用する必要があります。
ソフトウェア開発中の要件の変更を回避する方法
需要の変化を可能な限り回避し、需要分析の高い安定性を確保するために、次の方法を使用できます。
（1）開発者に専門的なトレーニングを提供します。開発者は開発中のシステムのドメインを必ずしも知っているとは限らないため、開発者がユーザーのニーズをよりよく理解するために、要件分析の初期段階で、開発者はこの分野の関連知識のトレーニングを受けます。
（2）開発者は、ユーザーと協力して通信します。ユーザーが需要の変化を提案する場合、開発者はユーザーの要求に注意深く耳を傾け、それを整理して分析する必要があります。要件の変更の理由を分析し、実行可能な代替案を提案すると同時に、要件のこれらの変更がプロジェクト全体の開発にもたらす悪影響をユーザーに説明します。
（3）契約上の制約。要件の変更はプロジェクト全体に影響を与える可能性があるため、開発者とユーザーは、プロジェクト契約に署名するときに、要件の変更にいくつかの関連する契約条項を追加できます。
（4）要件文書を作成し、バージョン管理を実行します。要件分析の最終結果は、顧客と開発者が開発された製品について合意に達したという文書です。このドキュメントでは、開発者の役割が変わっても、要件分析の準備作業に影響を与えることはありません。新しいバージョンは、各要件の変更を識別するために使用されます。
（5）要件のレビューと要件ベースラインの確立。開発者がユーザーのニーズを詳細に理解し、さまざまな担当者がさまざまな角度から要件を検証できるようにするために、ユーザーは要求者として、要件のレビュープロセス中に多くの貴重な意見を提示できることがよくあります。同時に、ユーザーが要件を確定する機会でもあり、要件の変更の発生を効果的に減らすことができます。要件が正式なレビューと承認に合格した後、要件のベースラインを決定する必要があります。さらに要件を変更するには、このベースラインに基づいて、プロジェクトで定義された変更プロセスに従います。要件のベースラインを設定すると、変更によって引き起こされる問題を最小限に抑えることができます。