ユーザーの要件検証、ハウツー？
回答:
顧客/ユーザーに頻繁にフィードバックすることを強いる反復的な開発を使用します。
また、プロジェクトマネージャーやビジネスアナリスト（非常に複雑なビジネスドメインでは非常に必要になる場合があります）などの（通常は役に立たない）中間体を削除して、開発者とユーザー間のコラボレーションを強化します。
これはほんの一部の推奨事項です。この件については言うことがたくさんあります。
スクラムをご覧になることを強くお勧めします。それは私の命を救った。
彼らは実際にこれで訓練されているので、ビジネスアナリストのような中間体を排除しないことから始めます。そのような人がいない場合は、少なくとも1人の開発者がこのスキルを開発する必要があることを受け入れてください。
次に、時間の経過とともに、プロジェクトの後半でよく求められるようなことについての本能のセットを蓄積し、プロジェクトの早い段階で会話に持ち込みます。「すべての注文で割引は常に同じですか、それとも顧客によって異なりますか？」「すべてのユーザーがすべてのレポートを見ることができますか、それとも監督者だけのためのものですか？」「消費税は常に同じですか、それとも顧客の所在地によって異なりますか？」等々。
さらに、コードが次のような変更の影響を受けないようにコードを書いてみてください。何であれ、いくつかの変更が遅れる可能性があるためです。ボタンのクリックハンドラーにビジネスロジックがある場合、これらの変更は本当に害を及ぼします。特定のクラスにビジネスロジックがあり、その名前で見つけやすく、ポリモーフィズムを活用して、たとえば、通常の注文と急ぎの注文があり、各注文が独自の配送料を計算する場合、それらの変更求められることははるかに少ない痛みです。
遅い変更を防ぐことはできません。法律が変わり、ビジネスの推進要因（顧客、売り上げが期待されているもの、CEOが飛行機で何かを読んでいるときに素晴らしいアイデア）が変わります。コードを変更可能に設計することで、できることを防ぎ、残りの部分を受け入れます。
あなたは本当にあなたがそこにリストされた基準を満たしていることを確認する道に沿って本当に必要です。たとえば、「すべてのユーザーが機能xを利用できるようにする必要がある」と表示されている場合は、これが正しいことを確認してください。
開発プロセスの早い段階ではこれは難しくなりますが、期限に近づくほど、確認できるようになります。
おそらくまだ実装していないものは、設計上の考慮事項に含まれていることを確認して、開発の初期段階で考慮されていることを確認できます。
私はビジネス会議に参加していて、ビジネスアナリストの1人に、常に一定の仕様に取り組む開発者であることは素晴らしいことだと言ったことを覚えています。
現実の世界では、これを大いに助けるいくつかのことがあります。最初の1つは、これらの最後の詳細が現実の事実であることを受け入れることです。最終製品の唯一完全な仕様はソースコードです。顧客がすでにこれを持っている場合、彼らはあなたがそれを書く必要はありませんか？
2番目に行うことは、欠落している仕様の詳細を積極的に洗い出すことです。これで、顧客に300ページのユースケースドキュメントやその他の契約上のメカニズムをサインオフさせることができますが、結局、100％の自信を持って、最善の方法はソフトウェアを顧客に提供することです。確認して使用し、仕様をニーズに合わせて変更するよう積極的に働きかけます（必要に応じて、作業に課金するように依頼します）。一部の機能だけが実装されている場合でも、顧客からのフィードバックが重要です。
3つ目は、仕様を読むときに、この要件を変更する原因と、バリエーションの処理方法について考えます。多くの場合、表示されない可能性のある変更については、過度に設計することは賢明ではありませんが、計画を立てること、そして同じくらい重要なことに、余分な困難を考慮せずに設計することで、生活がはるかに容易になります。 「私たちはそれを...で処理することができ、それを行うには約4日かかります。」あなたに自信を持たせるように他の人を刺激します。
反対側も忘れてはいけないと思います。どのユーザーにとっても、必要な詳細の完全なリストを作成することは困難です。自分のことを考え、常に新しいことを考えます。
漠然としたアイデアしか持っていないもののすべての要件と詳細を考え出すのは、信じられないほど大変な仕事です。誰にもできないと思います。
70年代の「なぜソフトウェアプロジェクトが失敗するのか」という本を持っています。ブログを読んでIT雑誌を入手すると、表紙で「ソフトウェアプロジェクトが失敗する理由」を読みました。本の内容を現在のリストと比較すると、何も変わっていません。反復的な開発：はい、多くのバリエーションがあり、あるレベルで役立ちます。しかし、結局のところ、雑誌の内容は同じカバーを持っています。あなたが私を信じていない場合は、過去の方法からいくつかの雑誌を掘り下げて、現在のテキストをコピーして貼り付ける方法を確認してください。
この問題はIT側では解決できません。私たちは新しいツール、プロセス、チェックリスト、要件分析スキーム、（ビジネス）ユースケース、開発フレームワーク、BPM、SOAを発明してきましたが、それでも同じ問題が存在します...
「要件指定子」を中心にこれを最適化する必要があります。したがって、レベルを上げるための適切なツールをそれらの人々に提供する必要があります。
たとえば、これらの人の場合：すぐに使えるスペックパターン、同じことを行う他のプロジェクトや会社からの入力、最終結果の要件とレッスンをコピーし、そこに未経験の人を集め、この人が物事を特定するのを助けることができますこれは最大の問題を引き起こし、「些細なこと」ではありませんが、それを行った後にのみ学ぶことができます（たとえば、他の会社で同じことを行う上級技術コンサルタント）、保険、銀行、電話会社などに、作曲者ツールをこれらの人々に要求します... ：独自のプロセスを発明しないで、すぐに使用できる汎用プロセスなどを購入します。開発者がツールやパターン、フレームワークを必要とするのと同じように、ツールが必要です。
それは解決しませんが、大幅に改善します。改善は、その領域の周りであり、後の段階ではないはずです。
開発者のように、これらの人たちはできる限り最善を尽くそうとします。しかし、その分野の開発者とは異なり、30年後に私たちが当たり前と思っていることのほとんどは、その分野にさえ存在していません。一般的に、彼らのツールはOutlook、Excel、Word、Boardです。彼らのプロセスはブレインストーミングセッションです。この分野では多くの改善が可能です。もちろん、問題は主に彼らがITの「外」に座っていることです。そのため、その分野の状況を改善するためのCIOの計画でさえ耳が聞こえません...しかし、これは別の質問です。これを「販売」する方法です。
鶏卵問題
苦労しているのは、ソフトウェア要件分析フェーズでの鶏卵問題と呼ばれます。クライアントは詳細なアーキテクチャを知らないため、要件の詳細を共有しません。また、すべての要件の詳細を知らないため、設計者は詳細なアーキテクチャを作成できません。
ツインピークソリューション
ただし、この問題のよく知られた解決策があります。それがツインピークモデルです。このモデルでは、一般的な要件から特定の要件に至るまで、クライアントとの通信を数回繰り返す必要があります。また、アーキテクチャを一般的なものから特定の詳細に進化させる必要があります。
Twin-Peakモデルの利点：
- 要件はシステム制限を考慮に入れます
- 代替設計の迅速な開発
- プロトタイプの迅速な作成
- 既存のソリューションの使用によるアーキテクチャの効率的な開発
- 要件のワークロードは、最初の大まかなアーキテクチャ計画から推定できます
- ソリューションの開発前に「非現実的な」要件が特定されるため、コストの削減
- 開発におけるリスク低減
プロジェクトで「要件」が特定されるほど、コストが高くなることをユーザーに知らせる必要があります。結局、彼らは本当に変更を必要としないと決めるかもしれません。彼らが変更を主張するが、追加のコスト/時間遅延を拒否する場合は、交渉が必要な問題があります。それは、技術や計画を通じてではなく、販売と顧客関係の管理によって解決されるでしょう。
彼らの前で動作するソフトウェアを継続的に入手し、使用/テスト/評価する努力を彼らに要求することはあなたの最善の策です。契約、仕様、図、ユーザーストーリーを完全に理解することはできません。
これは、ジョエルテストの一部です。開発プロセス全体を通じて、ソフトウェアをテストするために、見つけられる人なら誰でも入手できます。
本当に仕事をしたい場合は、コードの作成やアーキテクチャの設計を始める前に、コードのユーザーとなる人たち（彼らの管理や他の上位レベルの利害関係者ではない）と一緒に座り、それらを入手してください。彼らの仕事をする方法をあなたに示すために。理想的には、実際に1〜2日仕事をします。これにより、現在のシステムが機能する方法とそれを実行している人々のタイプを理解することができます。また、現在のシステムに対する不満や、生産性に影響を与えているものも表示されます。日々の不満や煩わしさもすべて聞く必要があります。つまり、彼らの意見を組織の他のメンバーに伝えるという考えがある場合は、あなたやあなたの設計チームが彼らのフィードバックを止めるために必要なことをしなければならないかもしれません。それを阻害する可能性があります。
ユーザーのグループごとに、ソフトウェアのその部分の開発に取り組む誰かに同じことをしてもらう必要があります。次に、すべての人が集まり、シャドーイングした役割で学んだことを話し合って、クロスオーバーの領域があるかどうか、関係者全員にとって最も簡単な方法にする方法を確認します。
これが他の要件収集プロセスを置き換えることはお勧めしませんが、実際のユーザーがシステムから何を必要としているかを理解するための補足です。管理が必要と考えるものは何であれ、マネージャーやビジネスアナリストはシステムの実際のユーザーではない可能性がありますが、それらのユーザーにとってシステムを適切に機能させることができれば、生産性が向上し、マネージャーを満足させ、あなたの会社を美しく見せます。