非公式ユーザーのニーズの説明に基づいて、最良のデザインを正式に把握する方法
私は叔父の友人にソフトウェアを書くつもりですが、ユーザーのニーズを満たすために必要なすべての要素が正確にわかっているわけではないので、まだデザインを策定することはできません。問題はスプレッドシート、マクロ、フォーム、およびデータベースによって（小規模で非実用的な規模で）ある程度解決できるので、私はそれを正確に行っており、その過程で、何らかの形で存在しなければならない要素を理解しています私のデザイン。
これを行うには別の方法、つまり、ユーザーが自分の問題を劣った手段で解決しようとするエミュレートの中間ステップなしでユーザーのニーズに基づいてシステムを設計する正式な方法が必要だと思います。確かにそのようなことがあるとしたら、そのような規律/テクニックの名前は何ですか？
あなたは実際にはマークから遠くないです。あなたのクライアントが彼が何を望んでいるのかはっきりと言えない場合は、1.彼と話してください！ 2.クイックプロトタイプをノックアップします。3.彼の言うことを聞きます。あなたの一人が十分になるまで繰り返し、
これは実際にはアジャイルソフトウェア開発として知られています。
「顧客」の期待に応えることは、多くの理由で、閉じた形式の分析ソリューションがないマルチパラメトリックな解決不可能な問題であり、その1つで十分なはずです（それが世界に大きな違いをもたらすため）。顧客（つまり、ユーザー）は通常、自分が何を望んでいるのかわかりません。
ジョエル・スポルスキーは実際にこの爪を頭に当てています かなりハード ：
すべてのジュニアコンサルタントが、2500 RPMの強力なDeWaltドリルで頭に注入しなければならないことが1つあるとしたら、それはお客様が何を望んでいるのかわからないということです。顧客が欲しいものを知っていると期待するのをやめる。それは決して起こらないでしょう。それを乗り越えなさい。
Joelが説明を続けているように、エキスパートデザイナー（たとえば、建築家ですが、ソフトウェアエンジニアも同じです）に行くと、彼らはよりよく知っているので、彼らに行きます。したがって、まずこれに対処する必要があります。
重要なのは、いくつかの代替案を提供すること、顧客の問題をいくらか深く掘り下げて顧客のニーズを「理解」すること、感じ、彼らのニーズを満たすためにあなたの知識のベストを適用するようにしてください。顧客は時々重要なミスを犯し、彼らのニーズに期待を置きます。彼らは故意にその間違いをしませんが、あなたはそれを覚えておく必要があります。その理由は、やや明らかに、期待は主に過去の経験に基づいて形成され、非常に主観的である可能性があります（通常は主観的です）が、ニーズは通常客観的であり、実際の問題から生じます。反対するのは難しい。
あなたは、相互作用の道を進む顧客の「味方」でなければなりません。残念ながら、これには、多くの場合、あなたに顧客に何が必要かを説明することが含まれます。したがって、顧客の「世界」に入り込み、顧客のニーズを理解し、顧客の期待を積極的に形にして、顧客が望むものを達成するのに役立つ結果を生み出す必要があります。
この「哲学的」おしゃべりを超えて、あなたが得ることができる唯一の有用なアドバイスは、クライアントと質の高い時間を過ごす必要があるということです。聞いて、聞いて、もう一度聞いてください。すべての詳細を収集し、合理的に選択されたいくつかの代替案を準備します。demonstrateそれぞれの長所と短所、通信クライアントに明確に伝えます。
要件エンジニアリング という用語を探していると思います。 ウォーターフォール（1956）として知られている冗談※ソフトウェア方法論のフェーズと混同しないでください。
反復的および段階的な開発 は Deming Cycle （1959）であり、ソフトウェア固有の考慮事項があります。参照 継続的改善プロセス （1951）。これは、より成熟したエンジニアリング分野がそうであったように、ソフトウェアエンジニアリングがとるべき方法でした。
そして、はい、アジャイルはあなたがそうすべきだと言います（アジャイルマニフェストの原則1から3）。そして、アジャイルの原則に従うことはあなたのプロジェクトにとって良い考えであることに同意します。 スクラム（1986）と混同しないでください
※： ウォーターフォールペーパー を読んだ場合、問題の原因がすべてです。
それを行うための最も良い方法を見つけました：顧客と話し合い、何かを構築し、話し合い、解決策が明確になるまでそれを変更します。基本的に、問題が単独で解決できるときはいつでも、あなたがしたようにしてください。
課題がより複雑になり、より多くの人々が関与する必要がある場合、アジャイルバリアントは顧客と話し合い、いくつか書き留めます ser stories 、チーム スプリントを実行 最初のバージョンの場合は、それを顧客に提示し、より多くのユーザーストーリーをメモして、製品が完成するまで次のスプリントに進みます。
それが本当に複雑になったら、ユーザーストーリーマッピングまたは se-case 2. を使用する方がよいでしょう。ワークショップで全体像を把握し、それをいくつかの初期ユーザーストーリーまたはユースケーススライスに切り分け、必要に応じてフローに新しいものを追加します。ストーリーまたはスライスは上記のようにスプリントで処理されます。作業を行うには、より多くのスプリントが必要なだけです。各イテレーションが配信、提示、ディスカッションを行うことに注意してください（叔父と話し合うときと同様に、ユーザーからの早いフィードバックが重要です）。
時にはそれは本当に複雑ですが、始める前に良い製品コンセプトを持っている必要があります。たとえば、ベンチャーキャピタルが募集するチームの資金を調達したい場合などです。この場合、design sprintで開始できます。 Jeff Knappの本を読んでください。ソフトウェア、ロボット、AirBnB（本のネタバレ警告）を構築するかどうかに関係なく適用できます。設計スプリントは製品設計（主な機能、ルックアンドフィールなど）に関するものであることに注意してください。チームを雇用したら、上記のアプローチの1つに戻ってください。
さて、絵を完成させるために：巨大な組織で働いている場合、またはソフトウェアがはるかに大きな努力のほんの一部である場合、ドラフトを開始する必要があるかもしれませんa ソフトウェア要件仕様 およびV-modelに従って、システム、コンポーネント、およびすべての対応するテストを設計します。これは、いくつかの 宇宙空間の衛星または火星のロボット を送信するなどの非常に要求の厳しいドメインでうまく機能します。しかし、他の多くのドメインでは、このより伝統的なアプローチにはいくつかのリスクがあります。要件によっては、書くのに非常に長い時間がかかる場合があります。ユーザーがあなたの意味をまったく理解していない（または他のことを理解している）にもかかわらず、ユーザーがそれを承認する場合があります。結局のところ、提供された製品は ユーザーが期待したものではない であるか、またはその間に進化したユーザー要件にもはや適合しない可能性があります。