私は、ウォーターフォールのコンテキストで、正式な要件の収集についてかなり読んで教えられました。ユースケースを作り上げ、それらを仕様に変え、最終的には誰も望まない肥大化したクラップウェアを提供します。
私が現在取り組んでいるプロジェクトには、いくつかの特別な特徴があります。利害関係者は学者であり、開発チームは非常に小さく（2〜3 FTE）、全体的な時間枠は短く（3〜9か月）、利害関係者はかなり柔軟です。製品の最終的な形状について。（彼らはA、B、Cを要求しますが、A、X、Zを取得します-問題ありません。）利害関係者へのアクセスが制限されている場合、通常は定期的に取得します。たとえば、週に1時間です。
上記のいくつかの結果：
- 利害関係者のインタビュー時間から10時間以内にコーディングを取得する必要がありますが、多くの場合、それより短くなります。
- プロセス全体を通して要件を収集し続けることができます
- スコープは非常に柔軟です。時間と予算は固定されていますが、スコープは時間切れになったときに終了するものです。
明らかにアジャイル手法を使用していますが、チームメンバーシップは非常に動的であるため、たとえば、堅実なスクラムプロセスを構築する本当のチャンスはありません。
PM /クライアントリエゾンの役割で、次のカテゴリのスプレッドシート（Google Docs）を収集する要件を作成する習慣を身に付けました。
- 「私たちは今実装することができます」（私たちはそれを十分に理解していると思います、そしてそれはdefiniです
- 「詳細/ワークショッピングが必要」
- 「優先度が低い」（多くの場合、1人のユーザーが一度言及したものですが、それ以降は聞いていません）
- 「議論を続けるための大きな機能」（実質的な新機能セット、特に他のものとの統合。これらは多くの場合素晴らしいでしょうが、時間内にそれを成し遂げることができるかどうかはわかりません-その場合、私たちはすべきではありません始める。）
私の「方法論」が対処していない問題について、次の提案を聞きたいと思います。
- 早い段階でショートッパーをキャッチする-プラットフォーム/テクノロジー/ソリューション/の選択を大幅に制約する要件をスニッフィングします...
- 不確実性の霧にぶつかる前に、特定の機能セットで作業できる期間がわかるように、将来の要件収集セッションを構造化およびスケジュールします。
- 何かが確実に削減されるほど優先度が高いかどうかを知る（そうでない場合は、調査に時間を費やす必要はありません）
- 相互依存する機能のセットの管理
- さまざまな程度で開発できる機能の管理（たとえば、コストの30％で利益の80％を取得し、残りの70％を使用する必要があるかどうかをどのように判断しますか？）
- 選択肢の管理（1つのケースでは、認証メカニズムXまたはYを実装しますか？両方を実行することにはあまりメリットはありませんが、両方に大きな不確実性があります）
- 依存関係：多くの場合、ユーザーがXにどのように反応するかを確認するまで、Yの実装を開始しても意味がありません。
- 課題追跡システムにおける「要件」と「課題」の関係。トラッカーにすべてを投入し、問題について詳しく知るたびに問題を更新し続け、場合によってはそれらを分割またはマージしますか？
ですから、他の人がこれらの問題にどのように取り組んでいるのか興味があります。「要件ツール」を検索しても、何も役に立ちませんでした。エンタープライズデスクトップのCASEツールの集まりにすぎません。