通常の実践では、ケース スタディを使用し、ワークフローやデータ フローを構築します。しかし、これは必ずしもユーザー/スポンサーとアナリスト/デザイナーの間で共通の語彙を作成するわけではありません。他の専門分野の「内部」の用語と見解であり、これは通常、誤解や明確化のための会議 (Evolutionary Prototyping などの RAD 手法への参加) などにつながります。
ユーザー/スポンサーは、自分のニーズ/環境に焦点を当てており、関係のない「プログラミング用語」を彼らの観点から取得することを望んでおらず、取得することを強制されるべきでもありません。新しい環境を学ぶ責任は、アナリスト/デザイナー (/プログラマー) にあります。
学習曲線をどのように克服しますか? ソフトウェア ソリューションを必要としているユーザーに直面した場合、何が効果的でしょうか?
私はコメントを使用します
「物理学をバーテンダーに説明できない場合、それはあまり良い物理学とは言えません」および「祖母に説明できなければ、何かを本当に理解することはできません」（ラザフォードとアインシュタインに帰せられる）
お客様と要件について話しているときのマントラとして。
ハイレベルなパワーポイントまたはホワイトボード プレゼンテーションの 2 つのアプローチを採用し、POC またはモックアップでユーザーを解放できるかどうかを判断します。
次に、詳細な行ごとの要件を実行します。悪魔は細部に宿る。これらの詳細を承認してもらいます。行ごとに分析できるように、ラベルを付けて番号を付けます。
高レベル セットの前に詳細な要件を設定すると、ユーザーは設計の概念を理解することができず、細部の詳細な仕様に行き詰まることはありません。フレームワークやコンセプトがなければ、ユーザーはピンの頭の天使の数だけ回転します。
顧客と開発チームが同様の言語を話すことができる限り、敏捷性と反復性は良好です。期待が設定され、満たされていることを確認します。
優れたインタラクションデザイナーは、ソフトウェアの動作を素人の言葉で説明できる必要があります。そうでなければ、彼はフロントエンドを行うべきではありません、私見。
ユーザーと最終的な実装者の間の中間ステップをできる限り排除するようにしてください。そのようなすべてのステップは、情報を覆い隠し、失います。あなたのチームの最も価値のあるメンバーは、両方のスーツを着ることができる人、つまりユーザーとの「インターフェース」を持ち、実際に物事を実装できる人かもしれません.
そうでない場合は、迅速な反復を行い、反復的に実装してください。それを漸進的に混同するのは簡単です。違いは、反復アプローチでは、小さいながらも均一な程度で幅広い機能を実装できることです。インクリメンタル アプローチでは、機能の大きなチャンクを次々と実装します。
反復的なアプローチでは、俊敏性という利点があります。ユーザーの気が変わったのか、それとも誤解があったのか? 問題ありません。まだ変更の余地があります。うまくいけば、多くの努力は費やされていません。
これにはさまざまなテクニックが必要であり、双方が相手のビジネスをある程度理解することを学ぶ必要があります。つまり、アナリストはユーザーのドメインを理解し、ユーザーはアナリストのテクニックの一部に慣れる必要があります。
プロセス フローは、ビジネスがどのように運営されているかを高いレベルで合意するために、開始するのに適した方法だと思います。一部のユーザーはデータ モデル (ERD など) に長けていますが、一般的にはそうではないと思います。たとえば、ルールがテキストで詳しく説明されている場合に、より適切に反応することがよくあります。
彼らは、ERD の品質をチェックするよりもはるかに簡単に、それらを読み通し、チェックを入れたり交差させたりすることができます。
次に、入力画面のスケッチとレポートに勝るものはなく、ユーザーが必要なものの詳細に集中できるようにします。