要件分析は、ソフトウェア要件（ソフトウェア）の収集、システム化、関係の識別、および文書化など、ソフトウェア開発プロセスの一部です。彼らのほとんどはすでに何が危機にatしているのかを直観的に理解していますが、要件を分析し、使用に適したものを得るという質問で彼らの直感に導かれる人々にはまだ会っていません。
https://ru.wikipedia.org/wiki/requirement analysis
多くの場合、すべてがチェックマーク用にコンパイルされた未完成のテーブルで終わり、システムの実際の機能から隔離されています。
私の意見では、この状況を回避するには、プロセスを別の角度から見る必要があります...
私の意見では、要件を収集する主な問題は、ウィキペディアの記事や専門文献で使用されている定式化にあります。
要件は、特定の設計、製品、またはプロセスが実行できる必要がある、物理的および機能的な文書化された特異なニーズです。これらの定義を読んで、ほとんどの専門家は、要件の分析の結果として、システムの機能（作業シナリオ）の高レベルの説明が表示されるべきであるという結論に達します。
https://en.wikipedia.org/wiki/Requirement
ソフトウェア要件-実装するソフトウェアシステムの属性、プロパティ、または品質に関する一連のステートメント。
https://en.wikipedia.org/wiki/ソフトウェア要件
次に、ユーザーや顧客と通信し、混乱し、矛盾し、一貫性のない一連の情報を作成し、インターネットを皮肉で満たし、タスクの主観的な理解に基づいてシステムを設計します。
このアプローチの結果は、製品の承認または発売の段階でのみ、少なくとも一度は各自が聞いたフレーズの形で完全に現れます-「私たちはこれを望んでいません、あなたは悪い仕事をしました。」
ウォーターフォールプロセスの場合、リスクは部分的に顧客がプロジェクトのドキュメントを承認するという事実によってカバーされ、「私たちは自分自身を責めることです！」と言うことができますが、本質的に何が変わりますか？
私の意見では、要件の定義には重要な詳細が欠けています。
要件は「特定の製品が実行できる必要がある」ことではなく、「特定の製品が実行できる特定の人への期待」である。新しいコンテキストでは、要件分析プロセスを変更するための多くのアイデアがありますが、個人的には、次の3つが最も重要であると考えています。
まず、要件はシステムの機能ではなく、特定の人が解決したいタスクまたは問題の説明です。
顧客と一緒に、システムの運用シナリオを高い確率で設計しようとすると、結果の品質が低下します。 要件を理解し、反対のことを行う最良の方法は、共感を示し、顧客の用語、タスク、およびプロセスに没頭することです。 この後、私たちの経験と知識をこれに適用し、顧客に一貫した効果的なソリューションを提供することが可能になります。
第二に：要件は数人の欲求であるため、要件の分析は、システムが考慮しなければならない欲求を持つ個人の識別から始まります。
すべての利害関係者の特定とそれぞれの独立した調査は、ほとんどの場合無視される作業であり、この作業の必要性を理解していないために抵抗を与えるのはプロジェクトの顧客とスポンサーです。
もちろん、結果の複雑さと品質の間のバランスを維持する必要がありますが、スタートアップと企業システムの実装のほとんどの失敗の理由は、ユーザーが必要とするものについての顧客とクリエイターの意見が現実と一致しないためです。
第三に：要件、これは期待、つまり、まだ何かです。 未来の不確実性は自然そのものによって引き起こされ、人間の欲求は絶えず変化に適応します。 そして、これは数週間や数ヶ月ではなく、質問をする時間帯によって要件は異なります。
要件は期待です。 期待は解決せず、期待を管理します。
要件を収集して署名するだけでは十分ではありません。すべての関係者にそれらを「販売」する必要があります。そうすれば、プロジェクト全体のプロセスで機能の混乱と突然の変化に対処する必要があります。
「販売」という言葉-プロセスを正確に説明しますが、否定的な意味合いがあります。 これに関連して、これは欺deや操作を意味するものではありません。
要件はシステムに影響を与える多くの人々によって与えられるので、確かに矛盾があり、誰かの利益が侵害されます。
妥協により、それらの一部がシステムに対して無関心または否定的に傾いている場合、要件分析プロセスは成功とは見なされません。 あなたが彼らに彼らの問題の解決策を提供しないならば、彼らは彼ら自身のものを思いつき、あなたにそれらを実現させます:)
注意していただきありがとうございます、上記のアイデアと例は新しいものではなく、アジャイルマニフェストやPMBoKなどの基本的な文書から始めて、多くの人が何らかの形で言及していますが、私の解釈オプションも役立つことを願っています
PS：書かれたものはすべて個人的な意見であり、コメントで議論する準備ができています。