要件が変更されることがわかっているのに、なぜ要件を収集する必要があるのでしょうか。
私は常に、ソフトウェア開発の最初に行う最も重要なことの1つが要件の収集であることを教えられてきました。私はまた、クライアントが自分が何を望んでいるのか本当にわからなかったため、または彼が自分を変えたために、プロジェクトの最初と最後で要件が常に（ほとんどの場合）劇的に変化することも教えられましたいくつかの機能について、または他の理由で気にしてください。
だから私は質問があります：
それほど遠くない将来にそれらが無効になり、変更されることがわかっている場合、最初に詳細な要件を収集するのにそれほど多くの時間を費やすのはなぜですか？
すべての要件が変化するわけではなく、すべての要件が同じように変化するわけではないからです。倉庫を管理するためのソフトウェアの開発にしばらく時間を費やすことはありません。突然、代わりにソフトウェアを再構築して歯科医の予約をスケジュールすることを決定するだけです。
実行するOSを変更するなど、一部の要件は変更されて大きな影響があり、場合によっては、テキストボックスでラベルを書き換えるように要件が変更されることもあります。ただし、テキストラベルの言い換えははるかに可能性が高く、OSはそうではありません。したがって、ソフトウェアの多くの側面を考えて書き留めることに価値があります。
さまざまな異なる人々やドメイン向けに多くのソフトウェアを構築するにつれて、空中にあるものとそうでないものを感じ始め、同様にソフトウェアをどのように設計するかという感じをつかむでしょう適切な場所で柔軟。
それほど遠くない将来にそれらが無効になり、変更されることがわかっている場合、最初に詳細な要件を収集するのにそれほど多くの時間を費やすのはなぜですか？
コードの作成とデモンストレーションが要件の理解を伝える最も効果的な方法になった瞬間に、要件の収集を停止する時が来ました。このポイントを超えて集まり続けると、物事が遅くなります。ただし、この時点までに要件を収集しないと、物事が遅くなります。
正しく実行している場合、収集とデモの両方で要件が変わります。どうして？変化は効果的なコミュニケーションの結果だからです。
あなたは学ぶべきです（あなたの製品所有者もそうであるはずです）。つまり、あなたが最も愚かであるときのプロジェクトのポイントは、最初にあります。だからあなたはスタートを固めたくない。意味のある変化を引き起こしなくなったときに要件の収集を停止します。
電子レンジのポップコーンに少し似ています。ポップの間の時間が過ぎたら止まります。
この一面。要件がない場合、なぜコードを作成するのですか？それ自体を満足させるコードは存在しません。あなたが書いている理由が何であれ、それに隠されている要件があり、実際に何が重要であるかをより早く理解すれば、成功へと導く決定を下すことができます。
「完了」がどのように見えるかを知る必要があります。そうでないと、ランダムに失敗し、偶然に有用なソフトウェアを作成したいと思っているだけです。
あなたがおそらく考えているのは Big Design Up Front であり、そうです、それは必ずしもソフトウェアプロジェクトを管理するための最良の方法ではありません。
しかし、新しいソフトウェア開発プロジェクトに着手したときに達成したいことを明確に把握する必要があります。おおまかに言って、新しいソフトウェアに期待するメリット、節約できる費用、およびその機能（幅広いブラシストローク）を知る必要があります。具体的には、ビジネスプロセスがどのように見えるか、およびそれらのビジネスプロセスが新しいソフトウェアにどのように組み込まれるかを詳細に知る必要があります。
問題は、コーディングを開始する前に詳細な手順が必要なことです。それ以外の場合は、どうすればよいのかがわかりますか？これらの指示は、必ずしも正式なもの（ラフなスケッチの形でもかまいません）である必要はなく、非常に詳細である必要はありませんが、必要になるとわかっている特定の要素があります。データベースの設計が必要です。 UIデザインが必要です。ビジネスプロセスを実装するメソッドが必要です。等々。これらを実現する唯一の方法は、機能を要件に変換することです。これは、関係者とのミーティング、ビジネスプロセスの理解、モックアップの表示、高速機能プロトタイプの作成などによって行います。
アジャイルソフトウェア開発プロセスは、要件を終点としてではなく、開始点として捉えています。要件が何らかの形で不十分であることが明らかになった場合、要件は進化することが許されます。いずれにせよ、コードを記述できるほど詳細な指示が必要であり、「ケーキを焼く」というのは十分具体的ではありません。
私は常に、ソフトウェア開発の最初に行う最も重要なことの1つが要件収集であることを教えられてきました。
さて、30年以上のソフトウェア開発で、詳細な要件分析（つまり、「収集」によって）がソフトウェアの次の機能または機能スライスを開発するために本当に重要であるという直接的な経験をしました。これらの機能大きすぎてはいけません（そのため、大きな機能をスライスに分割する必要があります）。そして、ここ数年、この経験は主流になり、いわゆる「アジャイル」手法の一部となっています。だから、これを教えた人は誰でも、過去の時代遅れの学術的なことを教えてくれたようです。
だから答え
なぜ最初に詳細な要件を収集するのにそれほど多くの時間を費やすのですか
は-"私たちがしない"、効果的なソフトウェア開発の経験がなく、アジャイル開発の意味がわからない、過去の理論家だけが行います。
もちろん、プロジェクトの開始時に要件収集に多くの時間を費やす必要があるのには、合理的な理由がある場合があります。
潜在的なクライアントに定額のオファーをする必要があるからです。価格を計算するとき、顧客のウィッシュリストの42ページの半分の文のどこかに隠れている要件を見逃したくないので、開発にさらに数か月または数年かかります。
または、クライアントの場合、潜在的な請負業者が特定の金額で彼に期待するすべての機能を開発できるようにしたいので、契約の詳細な要件リストを作成します。
システムに関するアーキテクチャ上の決定を事前に行う必要があり、選択したアーキテクチャと直接衝突する要件を見逃したくないため
ただし、これらの理由のいずれも、時間の経過とともに要件が変化しないこと、またはコードの最初の行の記述を開始する前にソフトウェアのすべての機能をあらゆる詳細に分析することを期待していません。たとえば、要件1、2および3で契約を結び、要件3が要件4に置き換えられた場合、これは契約を再交渉するための適切な基礎となります。または、アーキテクチャ上の決定を行います。これらは通常、非機能要件に関するいくつかの一般的な概念に基づいており、機能要件が変更されても本質的に間違っているわけではなく、非機能要件がある程度の範囲内で変更されても間違っていない。
「要件の収集」は必ずしも詳細な分析を意味するものではないことをもう1つ述べておきます。常に、バックログや課題追跡で新機能や改善点のアイデアを収集することは良い考えですプロジェクト全体を通じて、プロジェクトの開始時だけでなく、開発活動と並行して、いつでも製品を改善できる優れたアイデアが思い付きます。これは、実際に要件管理の重要な部分です。これにより、後でこれらのアイデアのどれを優先するかを決定できるため、詳細に分析して新機能として実装するのに十分なメリットがあります。
なぜ詳細な要件を収集するのにそれほど多くの時間を費やしているのですか...？
要件は、開発チームとクライアント間の契約を形成します。要件を収集しないと、誰が何を構築するかを実際に知ることはできず、成功の望みはありません。
...初めに、それらが無効にされ、それほど遠くない将来に変更されることがわかっている場合はどうなりますか？
要件が収集される時間は、使用するプロセスによって異なります。 ウォーターフォール プロセスは、要件がプロジェクトの最初に収集され、変更してはならないことを示します。ウォーターフォールプロセスでの要件の変更は大きな問題であり、要件の変更時にプロセスのどこまで進んだかに応じて、再構築、再設計、再実装、再テストにつながる可能性があります。このため、ウォーターフォールプロセスを使用する場合、要件を正しく設定するために多くの時間が費やされます。多くの場合、クライアントによって ソフトウェア要件仕様 （SRS）ドキュメントが作成および承認されます。
ウォーターフォールによる要件の変更は非常にコストがかかり、要件も頻繁に変わるため、変化する要件を管理するためのより良いプロセスがあります。 アジャイル は、（ ユーザーストーリー と表現されることが多い）要件が優先され、2〜4週間の開発作業を満たすのに十分な要件が選択され、実装される非常に人気のあるプロセス方法論です。スプリント。スプリント要件中は変更しないでくださいが、スプリントが終了すると、お客様は製品を確認して、要件の変更、追加、または削除を決定できます。次のスプリント。サイクルは、お客様が要件がないと判断するまで繰り返されます。
さまざまな方法で要件を収集するプロセスモデルは多数あり、使用するプロセスはプロジェクトに基づいて選択する必要があります。
また、プロジェクトの最初と最後の間では、常に（ほとんどの場合）要件が劇的に変化することも教えられました。
要件は変更される可能性がありますが、要件の変更を制限/管理するための手順（使用するプロセスによって決定される）を用意する必要があります。
複雑なシステムの場合、実際に必要な要件を把握することは困難です。自分が持っていると思う要件を述べることから始める場合は、後で一歩後ろに戻って全体像を見て、突然、本当に必要なものを理解することができます。
多くの人は自分が何を望んでいるのか知りません。要件を明確に表現することはできません。したがって、ソフトウェア開発者は、要件をできる限り収集して要件を示し、実際の要件と要件が一致していないことを簡単に見つけることができます。したがって、最初に必要な要件は次のとおりです。実際の要件を取得するチャンス。