クライアントをUIモックアップから一連の実際の要件に移動するにはどうすればよいですか？

アプリケーションの視覚状態の25の画面のモックアップが提供されたとします。これは、完成したアプリケーションとして開発し、元の利害関係者または顧客に渡すことができると確信するのに十分であり、満足することを期待しています。当然のことながら、UIを思い付くために使用された多くの質問を関係者に繰り返し求めることになりますが、これは無駄です。

しかし、これは十分ではないことが何度もあります。アプリケーションを開発する過程で、インターフェイスを複製しているために要件が曖昧になり、最終的に顧客が最初に思ったほど満足していませんUIを作成するためにすべての情報を要求したとき。

私は他に何を求めるべきか分からず、具体的になり、要件と全体的な目標の理解を求めましたが、私は何を求めるべきかわかりません。今始めたばかりの場合、UIに至るすべての情報を再ハッシュするのに多くの時間が無駄になり、この段階では、顧客が本来持っていた多くの重要な理由が失われます。

UIモックアップに基づいて要件をロックダウンできないことを人々に理解させるにはどうすればよいでしょうか？

エンドユーザー向けのアプリケーション開発タスクを適切に実行するために、理想的には何から始めますか？

他に必要なものは次のとおりです。

• ユースケースまたはワークフローの説明：画面がどのように見えるかを知っているからといって、不適切な入力がどのように処理されるかを知っていますか？すべての場合に画面を切り替える方法を知っていますか？ここにもエラー処理を含めることができます。

• 高レベルのシステムの説明：これらの25個の画面の対象となるシステム全体の目的と、それらが何をするのかを説明するもの。

• データモデル：これらの画面からデータモデルを推測することは可能ですか？使用する必要のあるデータモデルはありますか、それとも仕事を遂行するために独自に設計できますか？

• 技術要件：ライセンスの理由または統合の理由で使用する必要のある特定の技術ですか？

• パフォーマンス要件：検索画面がある場合、検索できるものと応答の速さについて期待がありますか？他のタイプのアクションに対する応答はどうですか？それらの一部を非同期にすることができますか、またはする必要があります（ユーザーがジョブを送信し、後で戻ってきます）。

• セキュリティ要件：アプリケーションは潜在的に機密/個人データを保存していますか？一定レベルのコンプライアンス（クレジットカード支払いを行うためのPCIコンプライアンスなど）を満たす必要がありますか？

また、あなたを支援するために必要となるかもしれない特別なビジネス分野の知識はありますか？保険、銀行、医療健康記録などの一部の業界には、あらゆる種類の複雑なビジネスロジックがあります。そのようなプロジェクトは、そのドメインを知っているビジネスアナリストの助けなしに試みるべきではありません。ただし、一般的なウィジェットのショッピングカート/情報サイトだけの場合は、そのようなチームメンバーは必要ないかもしれません。

UIモックでは動作するプログラムを作成するには不十分であると人々に理解させる方法：

私はこれを類推して扱います。私はちょっと車が好きなので、その道を行きます。

「私は車について何も知らないふりをします。フェラーリの写真を何枚か手渡してくれます。車の外側からのカップルと車内からのカップル（車のコントロールが見えるように運転席から撮影）。私は写真のように見え、すべてのコントロールを備えています。残念ながら、これらのコントロールは何にも接続されていません（車については何も知らないため）車が何をすべきかさえわからないので、推測することすらできません。

「それで、フェラーリは何をしますか？」「これにより、あるポイントから別のポイントにすばやく移動できます。」「わかりました。では、このサークルは何をしますか？」「ああ、それがハンドルです。ハンドルを回すと、車の外側の車輪の向きを変えることができます。これにより、車の動きが変わります。」「OK、そしてこのペダルはどうですか？」「それがアクセルペダルです。エンジンが速くなり、車が速くなります。」...数分後...「わかりました、それではどのようなエンジンが必要ですか？私はいくつかの研究をしました、そしてゴルフカートとスポーツカー用のエンジンを見つけました。どちらを使うべきですか？」...など...」

次に、類推を説明できます。開発者に画面のモックを渡すと、画面の外観だけが表示され、機能は表示されません。開発者は、プログラムがどのような問題を解決するか、またはどのように使用されるかを知る必要があります（車が何をするかを知ることで車の設計が容易になり、何をすべきかについて経験に基づいた推測をすることができます）。彼らは、使用することが期待される種類（すなわち、ゴルフカートエンジンとスポーツカーエンジン）およびその他の非UI要件（車は速くなるはずです）を知る必要があります。

私が求めるもの：

一般/高レベルの問題の説明

ユースケース/ユーザーストーリー

性能要件

必要なテクノロジー/プラットフォーム（Windows、Linux、Web）

FrustratedWithFormsのすべてが彼の答えにあります

開発努力の80％の効果は、フリンジユースケースの20％に向けられます。スクリーンショットではユースケースが示されないため、アクティブな開発の80％が暗闇になります。

クライアントがプロジェクトの要件により深く関与することがどれほど重要であるかを理解し、伝えようとしているのは良いことですが、そうしないとプロジェクトが失敗するように設定されてしまいます。それはあなたのせいではありません。

クライアントがソフトウェア開発プロセスに十分に関与していないため、ソフトウェアプロジェクトの大部分は失敗します。これは新しい問題ではなく、ソフトウェアプロジェクトが失敗する理由の謎ではありませんが、このような状況のために業界では何度も繰り返し発生しています。

情報の壁を壁に放り投げて、すべての希望と夢をソフトウェアパッケージの形で取り戻すことを期待することはできません。ソフトウェア開発はこの方法では機能しません。あなたがアジャイルショップであろうとウォーターフォールショップであろうと、プロジェクトの成功または失敗にはしっかりしたクライアントの指示が必要です。

人々が尋ねることを忘れているように思われることの1つは、データが入力された後に使用されることです レポートが必要ですか？梱包票を生成し、出荷などのために倉庫に送信する必要がありますか。管理決定にデータを使用し、レポートが必要な場合、データベース設計が変更される可能性があります。また、レポートの複雑さによっては、開発にかなりの時間がかかる場合があります。

また、可能な決定ごとにパスがあることを確認する必要があります。管理の承認が必要な場合-不承認の場合はどうするか、承認された場合はどうするか。X時間以内に承認または不承認にならない場合、どうなりますか？彼らが製品を選択し、在庫切れの場合、注文はどうなりますか？これらの種類の質問。

また、各フィールドに入力するデータに特定の制限があるかどうかを知る必要もあります。必要な値はありますか。どこから入手するのですか？それらはどのように更新されますか？エラーを処理する方法を知る必要があります。データベースを監査する必要があるかどうか、または履歴パースペクティブからデータを再作成できるようにする必要があるかどうか（これらの厄介なレポートに戻る）を知る必要があります。

私が起こっているもう一つのことは、データがその後どのように維持されるかを考慮せずに、リリースに到達するだけでアプリケーションを設計できることです。管理者ページが必要な値のリストを更新できることを確認する必要がありますか？他のシステムとデータをやり取りする必要がありますか？データベースに初期データをどのように取得しますか？

個人的には、クライアントとの半日から1日のミーティングを依頼して、UIの設計と目標を確認し、すべてが揃っていることを確認します。

シンプルに始めましょう。あなたに与えられた情報では、これらの画面は何もしません。ユースケース、不適切な入力動作などに関する詳細はありません。うまくいきません。鈍い一般化の説明は、詳細を説明するよりも簡単です。なぜなら、ポイントが失われることはないからです。画面のモックアップだけでは不十分な理由をより複雑な理由で説明しようとすると、問題を認めるのではなく、定義を混乱させる機会が与えられます。バックエンドの開発者が英語（または画面の表示言語）を話せなかったことを想像してもらいます。次に、知識がまったくない開発者にとって、この状況がどの程度異なるかを尋ねます彼らのビジネスプロセスの。次に、ある程度の知識はあるものの、自分のビジネスロジックを決定するのは適切ではないと信じて正当化される、より現実的な自分の例を構築します。

ソフトウェアを開発していない人は、ソフトウェア開発者が知っておくべきことを知りません。要件仕様やユースケースを独自に作成することは期待できません。必要な情報を取得するには、要件抽出手法を適用する必要があります。クライアント（および、できればさまざまな役割のユーザーのサンプル）と協力して、必要なものや必要なものを判断します。このための一般的な手法は、インタビューやユーザーの観察、ユースケースとユーザーストーリーの特定、プロトタイピングです。

要件があいまい、不完全、または十分に理解されていないため、この場合は反復および増分開発手法を適用することを強くお勧めします。ライフサイクル計画に対処するためのスパイラルモデルとともに、さまざまなアジャイル方法論をご覧ください。

このソフトウェアの開発を推進するビジネス目標を取得することから始めます。クライアントとユーザーにインタビューし、可能であれば職場でそれらを見る。解決しようとしている問題を特定してください。現在使用しているツールを確認し、それらをどのように使用しているかを確認して、現在のやり方を改善できます。この機会を利用してドメインとその言語を学習します-ソフトウェア開発者とクライアント/ユーザーがすべて同じ言語を話すと、コミュニケーションが無限に容易になります（クライアント/ユーザーがソフトウェア用語で話すことを期待しないでください）。

目標が何であるかを理解したら、所有しているUIデザインモックアップを使用して作業を開始し、さまざまな画面がどのように適合するかに基づいて「リバースエンジニア」ユースケースとそれらからのユーザーストーリーを使用できます。ユーザーストーリーの形式は、技術に詳しくない視聴者にも対応できる可能性があります。の形式はAs a <user type>, I want to <action> so that <reason>、開発者とクライアント/ユーザーに同じ言語を話せるようにするという点でうまくいきます。ユーザーストーリーを開始できるようになったら、プロトタイプ開発アプローチを開発に採用します。

プロトタイピングを使用してこれにアプローチすると思います。進化的プロトタイピングまたは使い捨てプロトタイピングの観点からこれにアプローチできますが、最初に進化的プロトタイピングアプローチを検討します。最も快適で検証済みのユーザーストーリーから始め、それらの実装を開始します。それらを実装するとき、顧客からフィードバックを得て、新しいユーザーストーリーを開発し、ユースケースを作成し、誤解を解決します。

また、これを「その下の機能を備えたユーザーインターフェイスを実装する」と考えないでください。代わりに、薄い垂直スライスと考えてください。すべてのユーザーインターフェイスを一度に実装してから、機能を心配しないでください。代わりに、ユーザーインターフェイスモックアップを使用して機能やその他の要件を特定し、UIからビジネスロジックとデータストレージまでの垂直スライスを実装します。垂直スライスごとにこれを繰り返します。また、要件と使いやすさの原則に基づいてUIを改善するための提案を行うこともできます。

Karl Wiegersの2つの本（ソフトウェア要件とソフトウェア要件についての詳細）を読むことをお勧めします。これらは、この分野の要件エンジニアリングとベストプラクティスに役立つと思います。

まあ、これは恥ずかしいほど明白な開始リファレンスですが、ウィキペディアはあなたとユーザーが開始する場所かもしれません。このようなものに関するエントリがあるという事実は、これが本当の問題であり、あなたが痛みではないことを彼らに確信させるのに役立つかもしれません。

より具体的には、モックアップを調べた後でも、アプリケーションが何をするのか困惑していますか？もしそうなら、それを認めて、各フォームがどのデータを表示するべきか、それがどこから来るのかわからないということを、他の画面からのデータなのか外部データからなのか説明しようとするでしょうか？

あなたが持っている場合は、いくつかのアイデアを、（「選択したテンプレートの一覧が一つのグローバルリストになりますか、それはだ場合はそれらのいずれかが？ユーザー、または何か他のものであるあなたがする方法がわからないというものの例を思い付くしようユーザーではなく、2人で一度に編集できるようにする必要がありますか？他の人が編集している場合、UIに何を表示する必要がありますか？そのための画面はありますか？その変更をテンプレートで作成したものに反映する必要がありますか？」）。

現在の知識レベルでは、開発サイクルの残りの期間、約90秒ごとに質問に回答する必要があり、回答が得られるまで作業を続けることができない場合が多いことを明確にしてください。目標は、なんらかの種類のプロセスがあればそれがすべて簡単になる理由を明確にすることです。また、QAはあなたと同じ情報を必要とするので、すべての人が利用できるようにすべてを書き留めておくのが簡単になり、誰も何も忘れません。

記述するコードの一部は、一度に複数の画面に影響することに言及するのに役立つ場合があります。したがって、できるだけ多くの回答を事前に取得しておけば、そのコードを適切に記述しやすくなり、後で変更する必要がなくなります。

あなたは場合まだ要件を取得することはできません、あなたは本当に、続行する方法を知っているあなたはより多くの情報（つまり、要件）を必要とするたびに電子メールを送信しておらず、あなたがいることを明確にその情報、状態ずに作業を続けることができない場合残念ながら、作業を続けることはできません。なぜなら、あなたが書く必要があるコードは、あなたの質問に対する答えによって大きく異なるからです。文句を言わないでください。何をすべきかがわかるまでプログラムを書けないことを、非常に専門的に知らせてください。

アプリケーションの各フィールドの制限と範囲を知る必要があります。たとえば、フィールドが電話番号の場合、+ 1を処理することを期待していますか？どのフィールドが必須ですか？ユーザーが電話番号フィールドに「abc」と入力した場合、アプリケーションに何をしてもらいたいですか？25の画面すべてが、すべてのユーザーが続行する必要のある順序になっていますか？

それ以外の場合は、すべてをテキストフィールドとして作成すれば完了です。それは鉛風船のように行き渡るだろうか？