私はウェブアーキテクトとして大規模な複数年のプロジェクトに取り組んできました。
これまでの私の責任は、顧客のアナリストから提供された要件ドキュメントを取得し、それらを技術設計ドキュメントに変換することでした。
「力」は、私が要件文書を引き継ぎ、それらを技術設計への取り組みと組み合わせることを示唆しています。
要件と技術設計を1つのステップにまとめることで、特定の問題が発生しますか？
すでに開発が進んでいるため、多くの技術的な選択肢（OS、アプリフレームワーク、データベース、サーバーなど）がすでに決定されていることに注意してください。
「要件と技術設計を1つのステップにまとめることで、特定の問題が発生しますか？」
はい。
要件は、技術設計とはほとんど関係ありません。
要件は、「何が」起こらなければならないかを定義します。デザインは、それを実現するために「どのように」構築されるかを説明します。
たとえば、ビールが欲しいのですが、それが私の要件です。
技術設計は
私の椅子を降りて、階下を歩いてください。低価格。ここにはリスクがあります。ビールがないかもしれません。
私の椅子を降りて、パブに歩いてください。より高いコスト。ここにはほとんどリスクがありません。休業日曜日を除きます。
妻に聞いてください。ここには大きなリスクがあります。考えられる意図しない結果。しかし、私は問題を委任しました、そして彼女は今家でビールを見つけるか、店に走るか、または私に自分のものを手に入れるように言わなければなりません。彼女がとにかく外出する場合、私たちは低コストに戻り、リスクはありません。
1つの要件。ソリューションの複数の設計。 1つのステップで両方に取り組むことはできません。
要件（アクター、ユースケース、概念データモデル、概念処理モデル）を文書化する必要があります
次に、ソリューションを設計する必要があります。解決策には、新しいソフトウェアの作成が含まれる場合と含まれない場合があります。
要件を調査するとき、ユーザーが作業方法を変更する必要がある状況を見つけることがよくあります。要件は、さまざまな方法で満たすことができます。
1人で要件を文書化し、設計を行うことができます。ただし、個別に行う必要があります。ユーザーが問題の性質と問題の解決を宣言するために必要なものを理解して同意する方法で、要件を文書化する必要があります。
次に、個別に、コスト、リスク、納期、スキル、利用可能なテクノロジーを最適化して、問題の解決策を提供するための最善の方法を決定します。
あなたが「開発に精通している」なら、私は要件の大部分がかなりしっかりしていることを望みます。開発が始まる前に要件を確定する必要があるとは言いませんが（天国は禁じられています）、この時点でどのようなものを構築しているのかがかなり確実になることを願っています。したがって、これまでのポイントが（顧客が探しているものを実際に掘り下げるのではなく）単なる「要件文書」である場合、ここでは深刻な問題は見られません。
開発を「顧客擁護」の役割から分離することには一定の利点がありますが、プロの開発者は、利害の衝突を発生させることなく要件を追跡するのに苦労するべきではありません。他に気になる問題はありますか？この時点で、要件の文書化は大きな作業でさえありますか？顧客と開発者の間のレイヤーの数を減らすことは、実際にはかなり良いことのように思えます。
はい。要件と技術設計を組み合わせると、思考が曇ってしまいます。これにより、後で別の技術的アプローチ/最適化を行ってシステムを改善する方法について新しいアイデアを思いつくことができなくなります。
特に新しいテクノロジー分野では、間違ったアプローチから始める可能性があります。技術的な設計と要件を組み合わせると、技術的なアプローチを要件として考えるようになります。これは、廃棄されて別の方法で行われる可能性が非常に高い場合です。
また、テストするとき（実際にはその時間は設計前でなければなりません）、ポーグラムが実際に行う必要があることではなく、技術的なアプローチをテストしている可能性があります。
要件と設計を同じ人が行うことには大きな価値があると思います。
要件を取得している場合は、実際にビジネスと話していることになります。それはあなたにビジネスを学び、彼らが本当に必要としているものを聞く機会を与えてくれます。技術的な解決策を想定してすぐに設計するのではなく、ビジネス用語で問題について話すように説得する機会があります（たとえば、「この列をこのテーブルに追加し、このページのこのテキストボックスに結び付けます」。 ）たぶん、彼らが存在すら知らなかった問題を攻撃する方法を見ることができるでしょう。
私にはアジャイルチームやスクラムチームで働く機会がなく、それらを適用する機会もありません。私は1〜3ヶ月間、お客様のために1回限りの開発作業をたくさん行っています。しかし、この種の環境で私が学んだことの1つは、次のとおりです。
プロジェクトのすべての段階で顧客とサインオフします。
これはあなたの質問に次のように答えます： 要件を設計ドキュメントと決して混ぜないでください。
実際、それはそれを超えています。
私たちは何度も、要件を常に変化させている不合理な顧客を見てきました。ただし、これらの変更に対して支払うことは期待していません。適切に管理されていない場合、プロジェクトのコストはプロジェクトの収入を大幅に上回り、上回ります。
サインオフされたSoWを使用すると、範囲外の要件から保護されます。「ベンダーはアプリxxxをインストールします」、そして突然、「クライアントはアプリxxxへの通信を保護するためにPKIインフラストラクチャ全体をインストールすることを望んでいます」。
サインオフされた要件を持つことで、「アプリxxxへの通信を保護および暗号化する必要はありません」という上記の同様のケースに続いて、突然の不合理な要件からユーザーを保護します。
これらは法的保護であることに注意してください。クライアントからの新しい要件を実行するかどうかを決定するのは、まだあなた次第です。ただし、それらが要件に含まれておらず、純粋に善意から行われていることを強調するのは依然として良いことです。
設計ドキュメントをメインの要件ドキュメントにマージすると、要件ドキュメントを承認できなくなります。顧客はこれに非常に満足しますが、開発チームは可能なクランチタイムを嫌うと思います。
私は人々が持っている別のアプローチを見ました（しかし、デザインを要件とマージすることではありません）。
要件ドキュメントを個別の付録ファイルを含むメインファイルに分割します。重要で具体的なことを要件文書に保管してください。これにより、要件ドキュメントを承認すると同時に、後の段階で付録の変更を行うことができます。付録として、サポートドキュメントにこのアプローチを主に使用します。付録としてのデザインドキュメントで動作するかもしれませんが、私は付録としてのデザインドキュメントを見たことがありません。
さらに、一部のプロジェクトでは、開発を開始する前に設計ドキュメントを承認することもできます。または、これらの設計/要件/SoWは配信またはマイルストーン支払いです。
本当に、それらをマージすることは避けてください。
要件とは、何をする必要があるかを指します。技術設計とは、要件をどのように満たすことができるかを指します。
短所：
考えられる利点：
2つの違いは、要件開発にはクライアント（外部または内部クライアント）との広範な連絡が必要であり、多くの優れた技術者には、クライアントとの関係をうまく管理したり、侮辱せずにactaulユーザーと話したりするスキルがないことです。あなたがそうするならあなただけが言うことができます。あなたはそれをしていなかった場合にあなたが考えるよりもはるかに難しくそしてより複雑であることに気付くでしょう。さらに、あなたの専門知識は開発者と設計者の視点にあるため、ユーザーの視点を見ることができないため、間違った質問をしていることに気付くかもしれません。
個人的には、複数の人が設計プロセスに関与すること（要件を収集してそれらを設計に変換すること）は、アイデアの生成や他の人が見逃したかもしれないことの考え方の観点からも役立つと思います。これを行う2人から1人に移動することは、チームの相乗効果の観点からは良い考えではないかもしれません。同じ人が両方を行う場合、あなたが慣れている方法でのみ物事を行うのは簡単であり、あなたが変更するのがより困難になる道にはるかに沿って行くまで、あなたの仮定に挑戦する人は誰もいません。