最近、見込み客から非常に複雑な Web アプリケーションのリクエストを受け取りました。
彼らは、「本当の」作業が始まる前に、私に仕様書を書くように求めました。
彼らが見ているように、仕様はアプリとDBを説明する言葉だけであるべきです。
私が見つけた最良のアプローチは、アプリケーションが持つ画面のプロトタイプを「ペイント」または「構築」することです（特に、このフェーズだけでWYSIWYGを使用する場合は、本を書くよりもhtmlの方が簡単です...標準は重要ではありませんこの点）。
目の前に画面があると、どの要素が必要か (カレンダー/フォト ギャラリー/主要なリンク、検索ボックスなど) がすぐに明らかになります。
それで、私のアプローチは間違っていますか？それとも、顧客は物事を行う正しい方法について間違った情報を持っていますか?
構築するシステムの範囲とコストについては、ある程度の合意が必要であることに同意しますが、システムを顧客に提供する前に、システムを完全に仕様化できると考えるのは難しいと思います。あなたが発見したように、顧客は実際にそれを見るまで彼が何を望んでいるのかわからないことがよくあります。これに対処する1つの方法は、慣れているモックアップを使用することです。設計や企画の際にも使います。
ただし、ほとんどの場合、実際の製品を顧客の手に渡して、何が機能し、何が機能しないかについての必然的なフィードバックを得る必要があります。開発の後半に発生する変更は、少なくとも従来の方法でははるかに困難で費用がかかるため、これを後で行うよりも早く行う方がよいでしょう。動作するソフトウェアを早期に頻繁に提供するアジャイル手法を使用し、十分な計画とドキュメントを組み合わせることで、顧客が望まない（または少なくとも望んでいる）製品の一連の仕様を繰り返すよりも、顧客からのフィードバックを向上させることができます。彼らが言ったように）。
プロジェクトの範囲を大まかに概説したいくつかの文書が必要であることをお勧めします。システムの一部であるものとそうでないものについて合意できるように十分です。在庫管理アプリケーションを構築している場合、たとえば、顧客関係管理システムも取得することを期待するべきではありません。次に、アジャイル開発手法の手法を適用して、軽量な方法で目的の機能を追跡し、作業コードをできるだけ早く、その後は定期的に手に入れます。これにはすべての関係者からの信頼が必要になるため、小さなプロジェクトとタイムラインから始めて、その信頼を構築することをお勧めします。
仕様は、プロジェクトの最も重要な部分（実行するのに最も長い部分）です。それはあなた（そしてあなたのクライアント）にあなたが何を構築しているのか、そして彼らがあなたに何を支払っているのかを教えてくれます。
ビルドを進めて、クライアントを見つけることは別の考えを念頭に置いていたので、良いことはありません。仕様は、あなたがすべて同じ本から読んでいることを保証します。そこにいくつかのGUIのアイデアをバンドルすることも良いアイデアです。
要するに、作業を開始する前に、あなたとクライアントの両方が何を期待するかを知る必要があります。画面とモックアップは、より広範な仕様の一部である必要があります
大規模なアプリケーションでは、アプローチが少し壊れているようです。彼らの期待は私には正しいようです。
Balsamiqでスクリーンモックアップを使用しています。それは、デザインの美学に追われることなく、一般的な外観とユーザーエクスペリエンスを示しています
まず、用語が間違っています。質問のタイトルで、「Webアプリケーションを設計するための正しいアプローチ」と質問しますが、注：クライアントからアプリケーションの仕様を作成するように求められました。
仕様はデザインと同じではありません。それらを同一視しようとするのは危険です。
別の回答者が言ったように、仕様はあなたとあなたのクライアントの両方があなたが何を構築しているのかを知るためのものです。デザインはそれを構築する方法の芸術です。
仕様には通常、モックアップは含まれていません。一言で言えば、ソフトウェアが何をすべきかを正確に説明するステートメントが含まれています。これは、実行方法とは大きく異なることに注意してください。Webアプリケーションの場合、モックアップは設計段階で行う必要があると私は主張します。そうです、あなたの質問に答えるために、あなたはあなたのアプローチが間違っています。
仕様の詳細については、ウィキペディアのこの記事を参照することをお勧めします。
編集： 私が言ったことは技術的には正しいですが、tvanfossonが指摘しているように、開発を開始する前にシステムを完全に特定することは困難です。彼の答えを読み、より現実的なアプローチを採用することについてクライアントと話すことをお勧めします。
次の記事があなたのコミュニケーションに役立つかもしれません：
残りの部分について考えるのに役立つ場合は、HTMLを自分でモックアップできることを忘れないでください。大体において、HTMLデザインがあなたの決定になります。
個人的には、FITとFitnessの仕様のファンです。これらは、最新の状態に保つのを容易にし、コードが仕様を満たしていることを確認するためのいくつかのテストを含みます。
もう1つ覚えておくべきことは、原則として、顧客は自分が何を望んでいるかを完全には理解していないため、完全な仕様であっても、完全に修正されたとは見なさないことです。
ユーザー インターフェイスはアプリの最も重要な部分ではありません。この部分に早くから注目すると、誤った仮定につながり、機能ではなくインターフェイスに基づいて選択を迫られる可能性があります。
アプリが画面上でどのように表示されるかではなく、アプリに期待される機能に同意するために、最初に機能に焦点を当てることをお勧めします。インターフェイスは時間の経過とともに変化します。クライアントは、このボタンを右ではなく左に配置し、黄色ではなく青に色付けし、このテキスト ボックスを大きくし、別のフォントを使用することを望んでいます。これらは、仕様を備えたインターフェイスを提供する場合の詳細については後述します。重要な機能の代わりに、これらの小さな詳細について話し合うリスクがあります。
Applying UML and Patternsをご覧ください。役に立つと思います。「Extreme Programming」シリーズの本のうちの 1 冊も良かったです。後で正確にどの本かを確認します。
ソフトウェア開発へのアプローチは人それぞれです。あなたの方法は、クライアントの方法と同じくらい実行可能です。ただし、クライアントはあなたにお金を払っているので、彼らの基準に従うか、あなたの方法を提案して彼らの反応を見ることをお勧めします.
次の質問への回答をご覧になることをお勧めします。質問は中規模のものですが、それでもかなり複雑になる可能性があります。
中規模の Web サイトを作成したい人に尋ねる基本的な質問は何ですか?
図やプロトタイプのスクリーンショットが推奨されない理由を顧客に尋ねましたか? これには、「実際の」作業が始まる前に行う作業の量を制限しようとするなど、独自の理由がある場合があります。アイデアとしては、彼らが以前に他の人と仕様を作成したことがあり、そのプロセスに満足しているとすれば、それはそれほど悪いことではありません. これが初めての場合は、なぜそれらのプロトタイプが必要なのかを話し合う価値があるかもしれません。たとえば、言葉には解釈の余地があり、これは写真が簡単に示す千の言葉よりも写真の方が簡単に解決できる場合があります。