クライアントをUIモックアップから実際の要件のセットに移動するにはどうすればよいですか？
アプリケーションの視覚的状態の25画面のモックアップが表示されたとします。これは、私たちが開発して、それを元の利害関係者または顧客に完成したアプリケーションとして渡すことができると確信するのにこれで十分であり、それらは満足されます。当然、UIを思い付くために使用された多くの質問を関係者に何度も尋ねることになり、これは無駄です。
しかし、これは十分ではないことが何度もありました。アプリケーションを開発する過程で、インターフェースを複製しているという事実によって要件が不明瞭になり、最終的に顧客は最初に思われたほど満足していませんUIを作成するためのすべての情報を要求したとき。
他に何を求めればいいのかわからない。具体的に求め、要件と全体的な目標の理解を求めてきたが、何を求めればよいかわからない。今開始したばかりの場合、UIにつながるすべての情報を再ハッシュ化するために多くの時間が無駄になり、このフェーズ中に顧客が最初に持っていた多くの重要な理由が失われます。
UIモックアップに基づいて要件をロックダウンできないことを人々に理解させて、私たちのために作成できる実用的なものを求めることはできますか？
エンドユーザー向けのアプリケーション開発のタスクを適切に実行するために、理想的には何から始めますか？
あなたが必要とするかもしれない他のいくつかは：
ユースケースまたはワークフローの説明：画面の外観がわかっているからといって、不適切な入力がどのように処理されるか知っていますか？すべてのケースで画面間を遷移する方法を知っていますか？ここにもエラー処理を含めることができます。
高レベルのシステムの説明：説明するものwhatこれらの25の画面が対象とするシステム全体とその機能。
データモデル：これらの画面からデータモデルを推測することは可能ですか？使用する必要があるデータモデルはありますか、それとも自分で自由に設計して作業を完了できますか？
技術要件：必須である特定の技術は、ライセンスまたは統合の理由で使用されていますか？
パフォーマンス要件：検索画面がある場合、何を検索できるか、応答速度はどのくらいかを期待していますか？他のタイプのアクションに対する応答はどうですか？それらの一部を非同期にすることはできますか（ユーザーがジョブを送信して後で戻ってきます）？
セキュリティ要件：アプリケーションは機密性の高い/個人的なデータを格納していますか？その場合、どのような種類のデータとそれを安全に保つために何をする必要がありますか？あるレベルのコンプライアンス（クレジットカード決済を行うためのPCIコンプライアンスなど）を満たす必要がありますか？
また、あなたがそれらを支援するためにそれらを必要とするかもしれない特別なビジネスドメインの知識はありますか？保険、銀行、医療記録などの一部の業界には、あらゆる種類の複雑なビジネスロジックがあります。そのようなプロジェクトは、そのドメインを知っているビジネスアナリストの助けなしに試みるべきではありません。ただし、それが汎用ウィジェットのショッピングカート/情報サイトにすぎない場合は、そのようなチームメンバーは必要ない可能性があります。
Iモックでは機能するプログラムを作成するには不十分であることを人々に理解させる方法：
私はこれを類推して扱います。私は少し車のナットなので、私はそのルートに行きます。
「私は車について何も知らないふりをします。フェラーリの写真を何枚か手渡してください。車の外側から1組と車の内側から1組（運転席から撮ったので、車のコントロールを見ることができます）。あなたがフェラーリを構築するために私は写真のように見え、すべてのコントロールを備えたものを返します。残念ながら、これらのコントロールは何にも接続されていません（なぜなら私は車について何も知らないので）それらが何であるかわからないからですコントロールはそうするべきです。車が何をすべきかさえわからないので、私は推測すらできません。それで、私たちはこのような会話をします：
「では、フェラーリは何をしているのですか？」 「ある場所から別の場所にすばやく移動することができます。」 「じゃあ、このサークルのことは何をするの？」 「ああ、それがステアリングホイールです。ハンドルを回すと、車の外側にあるホイールの向きを変えることができます。これにより、車の動き方が変わります。」 「じゃあ、このペダルのことはどう？」 「それはアクセルペダルです。エンジンが速くなり、車が速くなります。」 ...数分後...「わかりました。それで、どのようなエンジンが必要ですか？私はいくつかの調査を行い、ゴルフカート用のエンジンとスポーツカー用のエンジンを見つけました。どちらを使用すればよいですか？」 ...など...」
次に、アナロジーを説明できます。画面のモックを開発者に渡すと、画面の外観ではなく、画面の状態がわかります。開発者は、プログラムがどのような問題を解決するか、またはそれがどのように使用されるかを知る必要があります（たとえば、車の機能を知ることで、車の設計が簡単になり、何をすべきかについて知識に基づいて推測することができます）。彼らは、どのような種類のものを使用することが期待されているか（つまり、ゴルフカートエンジンとスポーツカーエンジンの比較）と、UI以外の他の要件（車は速く進む必要がある）を知る必要があります。
お願いしたいこと：
一般/高レベルの問題の説明
ユースケース/ユーザーストーリー
性能要件
必要なテクノロジー/プラットフォーム（Windows、Linux、Web）
FrustratedWithFormsが彼の答えに持っているすべてのもの
開発作業の80％の効果の一部は、フリンジユースケースの20％に向かいます。スクリーンショットはユースケースについて教えてくれないので、アクティブな開発の80％は暗闇に陥ります。
クライアントがプロジェクトの要件により深く関与することがどれほど重要であるかを理解し、伝えようとしているのは良いことですが、クライアントがこれを行わない場合は、プロジェクトが失敗するように設定しています。それはあなたのせいではありません。
ソフトウェアプロジェクトの大部分は、クライアントがソフトウェア開発プロセスに十分関与していないために失敗します。これは新しい問題ではなく、ソフトウェアプロジェクトが失敗する理由を明らかにすることは間違いありませんが、このような状況が原因で、業界で繰り返し発生し続けています。
情報を少しずつ流し、ソフトウェアパッケージの形ですべての希望と夢を取り戻すことはできません。ソフトウェア開発はこの方法ではうまくいきません。アジャイルショップでもウォーターフォールショップでも、プロジェクトを成功または失敗させるには、確かなクライアントの方向性が必要です。
人々が尋ねるのを忘れているように思われることの1つは、データが入力された後にどのデータが使用されるのかということです。レポートが必要ですか？梱包伝票を生成して倉庫に送って発送するなどの必要がありますか。データを使用して管理の決定を行い、レポートが必要な場合、データベースの設計が変わる可能性があります。また、レポートの複雑さによっては、開発にかなりの時間がかかる可能性があります。
また、考えられる決定ごとにパスがあることを確認する必要があります。つまり、管理の承認が必要な場合-承認されなかった場合はどうしますか、承認された場合はどうしますか。 X時間以内に承認または不承認にならない場合、どうなりますか？彼らが製品を選択し、それが在庫切れの場合、注文はどうなりますか？そういう質問。
また、各フィールドに入力するデータに特定の制限があるかどうかを知る必要もあります。必要な値はありますか？あなたはそれらをどこから入手するのですか？どのように更新されますか？エラーの処理方法を知る必要があります。データベースに監査が必要かどうか、または履歴パースペクティブからデータを再作成できる必要があるかどうか（それらの厄介なレポートに戻る）を知る必要があります。
もう1つ私が目にしているのは、アプリケーションがリリースに到達するまで設計され、データがその後どのように維持されるかを考慮せずに設計される可能性があることです。必要な値のリストを更新できるようにするための管理ページが必要ですか？他のシステムとの間でデータを送受信する必要がありますか。どのようにして初期データをデータベースに取り込みますか？
個人的には、クライアントとの半日から1日のミーティングで、UIの設計と目標を確認し、すべてが揃っていることを確認するように依頼します。
簡単に始めましょう。あなたが与えられた情報でそれらの画面はどれも何もしませんであることを彼らに理解させます。ユースケース、不正な入力動作などに関する詳細はありません。うまくいきません。鈍い一般化を説明することは、詳細を説明することよりも簡単です。画面のモックアップだけでは不十分である理由をより複雑な理由で説明しようとすると、問題を認めるのではなく、定義を歪める機会が与えられます。バックエンドの開発者が英語（または画面が表示される言語）を話さなかったと想像してもらいます。次に、この状況が、ビジネスプロセスについてまったく知識がないを持っている開発者とどの程度異なるかを尋ねます。次に、ある程度の知識はあるが、自分のビジネスロジックを決定することが不適切であると信じて正当化できる自分のより現実的な例を作成します。
ソフトウェアを開発していない人は、ソフトウェア開発者が知っておくべきことを知りません。要件仕様やユースケースを独自に作成することは期待できません。知っておくべき情報を取得するには、 requirements elicitation テクニックを適用する必要があります。クライアント（できればさまざまな役割のユーザーのサンプル）と協力して、必要なものや必要なものを決定します。このための一般的な手法は、インタビューやユーザーの観察、ユースケースとユーザーストーリーの特定、プロトタイピングです。
この場合、反復的で段階的な開発手法を適用することを強くお勧めします。これは、あいまいな、不完全な、またはよく理解されていない要件があるためです。ライフサイクル計画に対処するためのスパイラルモデルと一緒に、さまざまなアジャイル手法を見てください。
このソフトウェアの開発を推進するビジネス目標を取得することから始めます。クライアントとユーザーにインタビューし、可能であれば、職場でそれらを観察します。彼らが解決しようとしている問題を特定してみてください。彼らが現在使用しているツールとその使用方法を確認して、現在のやり方を改善できるようにします。この機会を利用してドメインとその言語を学びましょう。ソフトウェア開発者とクライアント/ユーザーが同じ言語を話すと、コミュニケーションが非常に簡単になります（そしてクライアント/ユーザーがソフトウェア用語で話すことを期待しないでください）。
目的を理解したら、さまざまな画面がどのように組み合わされているかに基づいて、所有しているUIデザインのモックアップと「リバースエンジニア」のユースケースとそれらからのユーザーストーリーを使用して作業を開始できます。ユーザーストーリー形式は、技術者以外のユーザーに対処するためにうまく機能するでしょう。 As a <user type>, I want to <action> so that <reason>の形式は、開発者とクライアント/ユーザーが同じ言語を話すようにするという意味でうまくいきます。ユーザーストーリーを開始できるようになったら、プロトタイピングアプローチを開発に採用します。
私はプロトタイピングを使用してこれにアプローチすると思います。 進化的プロトタイピングまたは使い捨てプロトタイピングの観点 からこれにアプローチできますが、私はまず進化的プロトタイピングアプローチを検討します。最も快適で検証済みのユーザーストーリーから始めて、それらの実装を開始します。それらを実装するときに、顧客からフィードバックを得て、新しいユーザーストーリー、ユースケースを開発し、誤解を解決します。
また、これを「その下にある機能を備えたユーザーインターフェイスを実装する」とは考えないでください。代わりに、薄い垂直スライスと考えてください。すべてのユーザーインターフェイスを一度に実装してから、機能について心配する必要はありません。代わりに、ユーザーインターフェイスのモックアップを使用して機能やその他の要件を特定し、UIからビジネスロジックやデータストレージまでの垂直スライスを実装します。垂直スライスごとにこれを繰り返します。要件とユーザビリティの原則に基づいて、UIを改善するための提案を自由に行うこともできます。
Karl Wiegersによる2冊の本を読むことをお勧めします- ソフトウェア要件 および ソフトウェア要件の詳細 。これらは、この分野での要件エンジニアリングとベストプラクティスに役立つと思います。
まあ、これは恥ずかしいほど明白な最初のリファレンスですが、 Wikipedia は、あなたとユーザーが始めるための場所かもしれません。このことについてのエントリがあるという事実は、これが本当の問題であり、苦痛ではないことを彼らに納得させるのに役立つかもしれません。
より具体的には、モックアップを行った後でも、アプリケーションの動作に困惑しているだけですか？もしそうなら、それを認め、各フォームがどのデータを表示するべきか、それがどこから来るのか、他の画面や外部データからのデータなのか分からないことを説明しようとしますか？
someのアイデアがある場合は、方法がわからないものの例を考えてみてください（「選択するテンプレートのリストは1つのグローバルリストであるか、それらのいずれかがユーザーによるものか、それともユーザーによるものか、それがユーザーによるものでない場合、2人が同時に編集できるようにする必要がありますか？他の誰かが編集している場合、UIは何を表示する必要がありますか？そのための画面はありますか？誰かが使用されているすべてのテンプレートにテンプレートを使用し、そのテンプレートを編集したら、その変更をテンプレートで作成したものに反映させる必要がありますか？」）。
現在の知識レベルでは、残りの開発サイクルでは約90秒ごとに質問に回答する必要があり、回答が得られるまでほとんどの時間作業を続けることができないことを明確にしてください。目標は、何らかのプロセスがあるとすべてが簡単になる理由を明確にすることです。また、Q.A。あなたがするのと同じ情報が必要になるので、それをすべて書き留めておくと、誰でも利用できるようになり、誰も何も忘れないようになります。
記述したコードの一部は一度に複数の画面に影響を与えるため、できるだけ多くの回答を前もって取得しておけば、そのコードを適切に記述しやすくなり、後で変更する必要がなくなる可能性があります。
あなたstillが要件を取得できず、どうすればよいかわからない場合は、詳細情報（要件）が必要になるたびにメールを送信してください。 ）、その情報がないと作業を続行できない場合は、残念ながら作業を続行できないことを明記してください。作成する必要のあるコードは、質問への回答によって大きく異なるためです。 ）。文句を言わないでください。何をすべきかがわかるまでプログラムを書くことができないことを専門家に伝えてください。
アプリケーションの各フィールドの制限と範囲を知る必要があります。たとえば、フィールドが電話番号の場合、+ 1を処理することを期待していますか？どのフィールドが必要ですか？ユーザーが電話番号フィールドに「abc」と入力した場合、アプリケーションは何をしたいですか？すべてのユーザーが続行する必要がある順序ですべての25画面ですか？
それ以外の場合は、すべてをテキストフィールドとして作成すれば完了です。リード風船のように終わることを賭けたいですか？