要件は大きくなり、変化します。誰もがそれを主張できるとは思わない。
着信要求を収集および処理する方法。
私の経験では、新規または更新された要件を少数の開発プランナーに提供するためのフィルターとして機能する単一または非常に少数の顧客グループがある場合、要件を収集するのに役立ちます。彼らの側からだれでもそれらを提案するか、または書き上げることができますが、配達はごくわずかな少数を介してのみ行われるべきです。ある当事者から他の当事者への交換に関与する人が少なければ少ないほど良い。
少数の人々をフィルタリングする目的は、表面上で重複または一見重要ではないと思われる場合でも、他の人が投入した労力と情報を破棄または削減することではなく、情報の損失または誤った取り扱いの失敗ポイントを制限することです。これは、カプセル化とインターフェースの目的に似た原則に基づいています。つまり、プライベートデータを保護し、同様の要求を処理するための共通プロトコルを確立します。繰り返しますが、重複の提出は問題ありません。プランナーとして、それは彼らが話していることや提案していることが重要であることを教えてくれます。すべてを保存または記録します。
要件を追跡および整理する方法
短期的には、ローテクに行く
明らかに、ホワイトボード、付箋紙、ポスターボード、あなたが持っているものなど、入ってくる要件を整理し追跡するのに大いに効果的なローテクのソリューションがあります。これらは短期計画に最適です。それらは非常に見やすく、自由形式の表記を受け入れ、簡単に「再構成」できます。
長期的には、検索、ソート、リンク可能なソフトウェアツールを使用します
より長い範囲の努力のために、ある種のソフトウェアが価値があるでしょう。専用の要件管理ツールがあります：Doors、Clearcase / Clearquest、その他多数。これらの高度に専門化されたツールは、その機能に優れていますが、多くの場合、やり過ぎです。普通の古いスプレッドシートでさえ十分すぎる場合があります。個人的には、一般的な問題追跡システムはこれを達成するのに非常に有用であり、今のところ私のお気に入りはredmineですが、他の人も大丈夫だと確信しています。
問題追跡システムを使用すると、許可することを選択したユーザーは誰でも「新しい問題」または要件を作成し、含めると思われる詳細を追加できます。彼らは問題を監視し、あなたがそれに対して取る行動にフィードバックを与えることができます。あなたはそれを再分類し、優先順位を調整し、身体を書き直し、補足情報を添付し、他の「問題」と関連付け、より高いレベルの機能や「ユースケース」やストーリー、またはあなたのシステムに合ったどんな用語でも宣伝することができます。つまり、課題を介して、要件のトレーサビリティ、ソート、優先順位付け、履歴認識、関連リストを作成するために多くのことができます。さらに、すぐに使えるように構成可能であり、オープンソースであるため、ツールがどの時点でも必要なものや必要なものではない場合、プロセスのニーズに合わせてかなり簡単に変更できます。
ツールについての最後のメモとして、私が話をした一部の人々は、変更管理とバージョン管理システムでプレーンテキストファイルを使用してかなりの成功を収めています。彼らは明らかに歴史的なバージョンの恩恵を受けます。また、要件を見つけ、リンクし、カタログ化するために、基本オペレーティングシステムと補助ツールを利用します。構造化された関連メタ情報を追加することはできませんが、必要だとは感じておらず、努力しても十分な価値が追加されません。それはあなたの場合かもしれませんし、そうでないかもしれません。利点は、開発スタックで管理および保守するソフトウェアの数が少ない可能性があることです。
契約後の受賞/プロジェクト開発後のキックオフ要件
質問の最後の側面は、努力が始まった後に要件を管理する方法です。これには2つの主要な考えがあり、それらをどのように扱うかは顧客との関係の性質に依存していると思います：まず、固定値で契約されている場合、契約授与後に入る要件を組み込むことができます。含意は、彼らが努力の範囲を変えるかもしれないので、それらの余分なアイテムが配達されて受け入れられるとき、率または請求書はより高くなるでしょう。受け入れられた提案から同等の努力が取り除かれない限り。範囲の変更を予定している場合は、顧客が結果を理解して受け入れることを確認する必要があります。そうでない場合は、それらの遅れた提出物を提出する必要があります。
第二に、契約が締結されてから来る新しい要件については、契約は時間と物質的な努力（仕事の完成に必要なものは何でも）に向けられているので、顧客はその特定の段階でそれを含めることを主張します。あなたがすることを言うすべてが終われば、あなたはそれを含めても含めなくても支払いを受けます。
それらに精通していない場合は、かんばん方式とアジャイル方式を検討することをお勧めします。これらの手法は、長期的な開発目標を見失うことなく、当面の懸念に焦点を当てるのに役立ちます。
「仮定」シナリオとしてオプションを提示し、顧客に選択肢と決定を与える
どちらの場合でも、「what if」の見積もりは、顧客やチームと交渉する際に採用するのに適した戦略です。代替アプローチの同じ情報を示す列を使用して、タスク、タスクのコスト、および計画どおりのスケジュールを並べて比較します。Microsoft Projectは、ほぼ同様のタスクセットに基づいてさまざまな推定値を作成できるため、おそらくこれを行うのに適した候補です。
ただし、基本的なスプレッドシートでさえ、特定の変更または包含がコストとスケジュールにどのように影響するかを示すのに同じくらい効果的です。この場合のリストは、おそらくツリーが違いを示すのと同じくらい効果的です。これらのシナリオを構築するために選択するツールと方法は、プロジェクトとスタッフの規模に大きく依存します（ただし、MS ProjectのようなトリプルAソフトウェアでも、有用性と能力には独自の限界があります）。
これらのwhat ifシナリオを内部作業項目として検討し、プロジェクトの期間中保存します。これらは、意思決定および交渉プロセスにおける重要なデモンストレーションでした。また、それらを再訪するか、what ifsの連続したラウンドのためにそれらを繰り返す必要があります。
what ifシナリオを準備するとき、技術的または実装の観点からの賛否両論の補足説明（簡略化された用語）は、1つの代替案がこのような重要な影響を与える理由を正当化するのに役立つ場合があります。