ワイヤーフレームは要件の文書化に適していますか？
現在、設計、開発、テストの関係者が要件について話し合っています。
会話の一部は、ワイヤーフレームの目的と使用法についてです。私たちの変更アナリストは、開発またはテストの要件の一部としてワイヤーフレームを使用することに強く反対しています。これらは、必要な場合にのみ「追加情報」として使用されます-明確にするために「参照するもの」。
つまり、視覚的ではなく、書面による要件を使用します。
要件収集および文書化プロセスの一部としてワイヤーフレームを使用する必要がありますか？
ワイヤーフレームが開発やテストの主要な要件ドキュメントであるチームで働いたことがありますか？
編集：正式な要件ドキュメントとしてワイヤーフレームを使用することに偏りがあります。 the要件を文書化する唯一の形式である環境で数年間過ごしました-製品所有者（アジャイル環境）が署名するまで開発は始まりませんでしたワイヤーフレームをオフにします。その設定では非常に効率的です。
ここでは、要件と設計の議論のリスクを冒していると思います。ワイヤーフレームはかなり重要ですが、それをどのように概念化するかによります。以下は私の意見ですが、私の経験ではかなり標準的な業界プロセスに裏付けられています。
- 要件は、ソリューションが何をする必要があるかを説明しているという理由だけで、一般的に書かれるべきです。それらは、発生する必要のあるステップを明確に説明するのに十分な詳細でなければならず、対象となる製品のタイプに応じて論理バケットに分解する必要があります。
- ワイヤーフレームは、要件を満たすためにソリューションがどのように動作する必要があるかを記述するため、設計プロセスの一部です。メンタルマップやノードダイアグラムを作成したり、クライアントが要件をより明確に説明できるように何かを描いたりする必要がある場合がありますが、それはワイヤーフレームの目的ではありません。
- アプリケーションがどのようにフローするか、またはワイヤーフレーム（本質的にUIへの要素の配置を開始する）をすぐに構築する必要があるプロジェクトでは、常に設計プロセスにバイアスがかかり、通常、IMHOは大幅に変更されるか、完全に破棄されます。
要件は通常（常にではありませんが）ビジネスアナリストまたはPMであり、ユーザー中心の設計者ではありません。これらの役割は重複し、人々は両方をうまく行うことができますが、役割は要件の一部としての差別化されたワイヤーフレームは、通常、私の経験では機能しません。クライアントが製品の実行方法ではなく、製品に必要なことを承認した後、それらは必然的に後から発生します。
私は PowerPointのストーリーボード をかなり忠実に使用しています。書面によるドキュメントには大きな欠陥があることがわかりました。
人々は、テキストから想像することでインタラクティブ性に感情的に反応することはできません。何かがどのように機能するかについてのパラグラフを書き、人々にインタラクションデザインのニュアンスを理解させることはできません。まるで「紫をふんだんに使ったグラフィックデザインが美しくなります」と書くようなものです。どういう意味ですか？それを表示せずにどのように定義できますか？
Language sucks。対面での議論は、電子メールよりもずっと少ないです。電子メール（テキスト通信）は、誤解を招く可能性が非常に高くなります。一緒にいて、視覚的なものを見ると、物事はよりスムーズになります。さらに、私が知っている多くのエンジニアは、第一言語を話す人として英語ではありません。テキストはしばしば誤解されます。
テキストをテストすることはできません。ストーリーボードをテストして、人々の前に置いて反応を得ることができます。テキストはそのようには機能しません。
警告：すべての企業には、癖や特別な状況があります。自分に合った方法を見つける必要があります。あなたが間違っていると知っていることを人々に言わせないでください。必要な場合は、両方を行い、ストーリーボードをエンジニアに密かに提供してください。
BAとしての私の不満は、テスト可能なユニットである「要件」と、要件の一部として作成されたときに実際に要件になる「設計」との間の明確さの欠如です。ビジネスがローファイまたはハイファイのワイヤーフレームを承認するとき、彼らはその視覚化を要件にしました。次に、テストスクリプトを作成して、ワイヤーフレームが図のように正確に生成されることを確認します。粒度について話します。ADA、マーケティング基準、特定された生産性の向上など、正当なビジネスニーズをカバーする必要のあるデザインでない限り、要件はアプリケーションの機能に関するものであり、視覚的なデザインではありません。
多くの場合、ビジネスと開発者はビジュアルなしでは最終製品を概念化できないため、ビジュアルに依存しています。それは本を読むこととそれらの要件のビデオを見ることの違いです。これは、デザインと結婚し、ビジネスがそのデザインの「方法」を指示し始めた（保存ボタン、エラーメッセージング、データコレクション、ナビゲーションなど）の滑りやすい傾斜です。開発者がUXを指示するべきではないのと同じくらい彼らがUXとデザインのビジネスに従事しているのでなければ、ビジネスについて、そしてなぜ彼らは自分でコードを書いていないのかと思います。
多くの場合、大きなうめき声が集まって要件をより迅速に文書化するため、開発を開始できますが、なぜそれらをまったく書き出すのかという疑問が生じます。開発者が要件を読み取ることができず、設計なしで開発の構造化を開始できない場合、データの再作成を気にせず、設計の再作業は変更がはるかに不快です。要件の収集にとらわれないということは、不可知論的な設計の機会が開かれることを意味します-設計はプラットフォームに拘束されておらず、制約です。ワイヤーフレームにサインオフするプロセスを作成することで、必要なものを与えるのではなく、提供したいものを受け入れるようにビジネスを設定します。その後、プロセスは、アプリケーションの機能ではなく、きれいな画像について終了します。
間違いなく...プロジェクトに表示する必要があるさまざまなインタラクションすべてを表示するために、UIチームがワイヤーフレームを持つことが不可欠だと思います。
プロジェクトについての説明を書くことで十分であると私が言う人もいますが、言葉だけではプロジェクトの全体像をつかめないことがあります。
特にダイナミックワイヤフレームを使用すると、たとえばメニューが何をするべきかというアイデアをデザイナーが簡単に持つことができます。
また、クライアントがプロジェクトのためにプログラムする予定の内容を明確に把握できるため、クライアントと協力することもできます。
これにより、プログラミング側の時間を大幅に節約でき、UIのやり取りも私にとっては優れたワイヤフレームは、優れた文書のグラフィカルな表現です。
私の頭には、きめ細かくインタラクティブなワイヤーフレームの価値が間違いないでしょう。
ワイヤーフレームは要件のドキュメントではありません。要件ドキュメントはワイヤーフレームではありません。ただし、両者は互いに依存し、影響を及ぼします。
私は、それらが並行して最もうまく機能することを発見しました。つまり、両方が一緒に進化します（一方が他方の開始前に終了するのとは対照的に）。
あなたはアジャイル環境での要件としてワイヤーフレームを使用すると述べています。それはおそらく例外だと思います。理想的には、すべてがアジャイル環境で実行されます。
そのシナリオでは、ワイヤーフレームは実際にはナプキンのスケッチです。これらは、すぐに構築できるようにアイデアを伝えるための内部ドキュメントです。
アジャイルの優れた点は、（IMHO）正しく実行すると、一般的にドキュメントの必要性が大幅に減少し、ある意味で、この特定の質問の関連性が低くなることです。
「プロトタイピング：プラクティショナーズガイド」の本にあるアイデアは、書かれたMRDが以前ほど役に立たない場合があることを示す好例であり、時々示すという考えに基づいて、伝えるよりも優れています。本の詳細がプロトタイピングに関するものであるとすれば、同じアイデアがワイヤーフレームにもまた渡り得ると私は感じています。
- プロトタイピングは生成的です。つまり、プロトタイピングプロセス（またはワイヤーフレーミング）を実行すると、何百ものアイデアを通過することになります。素晴らしいものもあればそうでないものもあります。しかし、それほど華麗ではないアイデアは、華麗なソリューションの触媒になる可能性があります。
- プロトタイピングはshow and tellを介して通信します。
- プロトタイピングは誤解を減らします。 60ページの要件のドキュメントを取ります。部屋に15人を連れてきます。それを配ってください。それらすべてを読んでみましょう。次に、何を構築しているのかを尋ねます。 15の異なる答えを取得します。 200ページのMRDで同じことを試してみてください。さらに悪化します...
- プロトタイピングは迅速なフィードバックループを作成し、最終的に時間、労力、お金を節約し、リスクを軽減します。
これらすべてを念頭に置いて、これに対する議論は、プロトタイピング/ワイヤーフレーミングが特定のプロジェクトにとって過剰になることもあるので、実際には、すべてがプロジェクトに大きく依存しています。
絶対にありません-ワイヤーフレームは要件に属しません。
ワイヤーフレームは以下の場合に最適な方法です。
- 要件を生成する
- 要件に対するソリューションを設計する
しかし、それらを要件に入れるのは悪夢であり、混乱した混乱した考えと文書化（多くの場合、形式と機能の融合）につながります。
これは特に規制された環境または契約での問題です-ユーザーインターフェイスがドロップドロップリストをリストビューに変更する場合は、次のように見てください。
- 要件はもはや満たされておらず、デフォルトでは規制上または契約上の失敗です。製品は引き続き正常に機能しますが、書類は法的責任となります。
- ドキュメントは、ユーザーインターフェイスが変更されるたびにやり直す必要があります-これは非常識です。
- 以前は会社に勤務していましたが、要件にワイヤーフレームを入れるだけでなく、対応するテストにも夢中になりました！その狂気は、ユーザーインターフェイスが新しいデザインとツールキットでオーバーホールされたときに、すべてのドキュメントをやり直さなければならないことを意味しました（プロジェクトの見積もりで考慮されていなかったもの）。
私はあなたが単にユーザーインターフェースのワイヤーフレームを意味していると思います。ブロック図、フローチャートなどが不可欠です。
作成している最終製品はWebアプリケーションです。
ワイヤーフレームは、わずかな労力で途中まで到達できるため、ステップ間に適切な粒度が含まれている限り、ワイヤーフレームを要件として使用することは理にかなっています。
それ以外の場合、不十分に行われたワイヤフレームは、書かれた要件とほとんど同じくらい簡単に誤解される可能性があることを発見しました。
ただし、すべてのフローを文書化するには、書面による要件が依然として不可欠です。それらがないと、構造化されたユーザー受け入れテストとQAテストを行うことが難しくなります。
これは私があなたの要求が機知になることができると私が信じるところです-ビルディングブロック図とフローチャート。
http://www.leacock.com/deliverables/block_diagram_ex2.pdf
ここでは、フローチャートでプロセスを説明します。これもまた、単なるドキュメンテーションよりも優れています。ワイヤーフレームの使用には時間と予算が必要ですが、ブロック図とフローチャートの使用はより有意義であり、他の開発者やチームメンバーがドキュメントに取り組むのに役立ちます。
ほとんどの人は、私の経験では誰もそれを10分以上見るように誘惑しないテキスト情報を見ることを好まない。私たちはクライアントに向けたプロジェクトを行いました。そこでは、テキストデータと並行してワイヤーフレームを表示することで大きなメリットを得ました。人々は私たちが文書化しようとしているものを理解し始めました。しかし、それは多くの努力を必要とします。リソースをそのままに保つ理想的な方法は、フローチャートとブロック図を使用してリソースを面白くすることです。