なぜ、誰がそれを必要とし、どのようにそれを行うか
私は何度も自問しました：システムの着信要件を整理することは、どのように快適になりますか？要件が収集されるだけで、質問が出され、回答が表明され、すべてが絶えず変更および修正され、さらにいくつかのシステムが実装に関与している場合でも、その他...
私はとてもしたい：
- 関係を参照してください。要件➝質問demand需要の変化➝新しい要件。
- 要件/質問の重複を避けます。
- 実装に関与するシステムを追跡する（逆から：各システムの代表者が要件を確認し、その実装は少なくとも何らかの形で彼のシステムに関連する）;
- 各要件の確認を受け取る-はい、要件が理解され、実装が可能であることを正しく記録します。
- 私たちのプロジェクトに非常によく似た別のプロジェクトの要件との関係を追跡する-これが既にそこに実装されていることを知るために、達成された成果を使用します。
とにかく。
しかし、プロジェクトでこれらの問題をすべて解決済みの場合、おそらく以下のテキストは役に立たないでしょうが、コメントで共有することは間違いありません。
以下のすべてがプロジェクトのフレームワーク内で要件を収集する問題を解決することをすぐに言わなければなりません。ここですべてのアイデアが生じました。 、提案されたシナリオを変更してニーズに合わせます。 ただし、以下の情報は、ツールを作成するための基礎となり、その実装のアイデアを思い付くことができます。
私の場合、これはプロジェクトです：
- いくつかのシステムが関係している（Webサイト、CRM、ERP、レター送信システムなど）
- したがって、複数の請負業者、
- 一人の顧客
- 現在でも、同様の機能セットを備えた同様のシステムが実装されており、これらの開発（アイデア、顧客要件、コード）を作業に使用できます。
別の重要な注意：以下で説明するのは、機会を提供するツールである
Googleスプレッドシートを使用して行われたものです。
- ドキュメントへのすべての参加者の同時アクセス。
- ドキュメントのリアルタイムの変更。
- データのフィルタリング。
もちろん、このサービスはより多くの機会を提供しますが、ここでは、記事で説明されている問題を解決するための重要なタスクをリストしました。
だから
整理方法
2つのシートの通常のテーブルファイル：要件と質問。
それぞれを個別に（そして一緒に）分析します。
必要条件
以下に、要件シートの表の列を示します。
クレームが修正される日付。 まあ、何も説明する必要はありません。すべてが明確です。 後でこの情報を何らかの方法で使用する予定がある場合は、ここで唯一、リクエストのソース（手紙、会議、個人的なコミュニケーションなど）を指定することもできます。
ブロックする 要件はブロックに分割する必要があります-これは理解できます。 しかし、本当に非常に重要なのは、これらのブロックの境界の理解が、パフォーマーと顧客の両方にとって誰にとっても同じになるようにすることです。
たとえば、参加者が異なれば、「チェックアウト」プロセスの理解も異なります。 ここでは、ユーザーバスケットの形成も含まれており、誰かがこれらのプロセスを個別に検討します（バスケットは独自のデータ交換シナリオのセットを持つ別個のプロセスであるため）。 そして、「注文の段階で、これを表示します」（顧客から）または「私たちはあなたにそのようなデータを提供します」（別のシステムから）というフレーズは、皆にとって異なる最終的な意味を持つかもしれません。このプロジェクトでは、要件の収集と並行して、すぐに
PBXを作成し、スキームの名前に応じたブロックを作成しました。 ファイルでは、列のセルにこのドロップダウンを作成しました。
Googleスプレッドシートでは、これは次のように行われます：データ➝検証。 「基準」フィールドで「値のリスト」項目を選択し、右側のフィールドで、コンマで区切られたブロックの名前をリストします（私の場合、これらは交換の名前です）。これは非常に便利です。要件を作成するときに、要件がどのプロセスに関連するかがすぐにわかります。 さらに、ブロックごとにフィルターをかけることができます（特定のブロックに関連する要件のみを表示します-詳細は後述します）。 また、スキームを解析するときでも、新たに出現する要件をすぐに作成できます。
実際、
要件のエッセンス列に
は、要件のテキストが含まれています。 さらに、何らかの形で頭に表明され修正されるとすぐに、すべての要件をすぐに作成することを提案します。 次に、それらを掘り下げ、それらに基づいて新しい要件を作成し、質問をすることができます（「質問」シートで）。
要件を（当然のことながら合理的な制限に）分割し、異なる行に配置する方が良いと考えています（1行に2つの要件があるべきではありません-これは将来それらを扱うことを複雑にします）。
project％project name％へのリンク。 さて、このコラムは、私が上記で述べたことを正確に担当しています。これは、プロジェクトと非常によく似た並列プロジェクトの要件との関係を追跡するのに役立ちます。
ここでは、1）同じ機能が別のプロジェクトのフレームワークに実装されているか、2）この要件の機能が別のプロジェクトの機能に関連していることを示しています。 必要に応じて、簡潔な「食事」または詳細を配置できます。質問列には、オンデマンドで質問の番号が含まれています（以下の「質問」シートの詳細）。
「
確認済み」列があります-作成者と直接実行者が確認を入れます（はい、要件は正しく定式化されています）。 プロジェクトで、彼女は、要件が作成されてから2日以内にこれを行うことを提案しました（「日付」列を参照）。 そして、2日後、たとえマークに価値がないとしても、要件が真であると考えてください。
もちろん、これは必須のコラムとはほど遠いですが、すべての参加者が要件について共通の理解を持っていることを知る方が個人的には快適です。システム -実装に関係するシステムの要件を示します。
[
変更 ]列には、現在の要件に関連付けられた同じドキュメントから新しい要件の番号が入力されます（要件は変更され、関連性はなくなりましたが、関連するものは）。 この列の詳細については、以下の記事（「質問」セクションのスクリプト内）で説明しています。
このリストに「
要件の作成者」列を含めることもできますが、私は自分で作成しませんでした。 私の場合、著者は一人であったか、すべての人がすぐに要求を表明して定式化しました。 しかし、要件が複数の人々から収集されるとき、彼はまだ必要だと思います。
ステータス列を作成して、たとえば、要件実装のステータスを示すことができます（プロジェクトが要件の文書化を必要とせず、タスクがバックログに基づいて定式化されるか、要件の形成と同時に開発が行われる場合に役立ちます）：ステータスもプロジェクトのニーズに基づいて形成されます-可能なオプションをここにリストしません。
要件の関連ステータスを個別に表示することはお勧めしません。
変更された列は、この点で優れた働きをします（新しい要件がある場合、この要件がもはや関係ないことは明らかです。
取り消し線フォントを作成することもできます-確かに）および
Confirmed 。
また、要件の実装の優先度が示される列を作成することもできます-これも非常に便利な属性です。 または、
wiframe /レイアウトの名前の列で、視覚的なデザインを確認できます。
バグトラッカーのタスク番号と同じ列をここに含めることができます。 バグトラッカーの最上位のタスクは、ブロック（スキーム）の名前で呼び出すことができ、「ブロック」列でフィルタリングすると、タスク内のすべての要件をすぐに表示できます。
フィルタリングといえば。 これはとてもクールです！ ブロックによるフィルタリング（バグトラッカーのPBX /タスクを考慮して、それらに適用されるすべての要件を確認できるように）、システム（特定のシステムで作業を確認し、それらに基づいてバックログを形成する）、テーブル内の何か別のもの。
Googleスプレッドシートでは、これは次のように行われます：データ➝フィルター。 最初に、フィルタリングされた領域を選択する必要があります（フィルタリングは列で実行されます）。ご質問
列が含まれます：
- 問題が修正された日付。
- ブロック;
- 質問;
- 責任者;
- ステータス
- 回答;
- 要件とのコミュニケーション。
それらの一部は、上記の「要件」で説明されています。 パーツの内容は直感的に理解できます（たとえば、「回答」と「責任」）。 例を使用して、質問と要件を含む一連の作業を少し書きます。
- 要件を「要件」シートに記録し（たとえば55行目 ）、列に要件に関する情報を記入しました。
- 要件について質問が発生し、「質問」シートの質問を修正し、列の情報を記入しました。 「要件との接続」列には、質問に関連するシート「要件」（この例ではこれは55行目 ）からの要件の番号が示されています。
- 質問が発生した要件については、列「質問」にシート「質問」の質問の番号が示されています。
- 答えを得て、質問の反対の答えを記録しました。
- 回答に基づいて要件を作成し、「要件」シートに入力しました（たとえば、 行60 ）。 要件の場合、「変更済み」列の55 行目は行番号60を示しています。
さて、プロセス全体で質問自体のステータスを変更することを忘れないでください（ステータスは、未解決、特定の回答、解決済みを使用できます）。
このシナリオでは、次のことを行います。
要件を記録し、それについて質問し、回答を記録しました（1〜4項）。
新しい要件を策定しました（古い要件は無関係になりました-パラグラフ5）。
そして今、私たちは要件の変更を（そして日付によっても）追跡することができます。
もちろん、ブロック、要件、責任、ステータスなどによるフィルタリングオプションについても忘れないでください。
各プロジェクトでの作業の過程で、テーブルでの作業の微妙な違いが発生します-それらを考慮してスクリプトに追加し、それらに従ってテーブルを変更します。 必要なもの、今何が欠けているのかを自問することを忘れないでください。次に、なぜこれを行う必要があるのか、どの問題を解決するのか、プロセスを促進するのか複雑にするのかをもう一度尋ねてください。
頑張ってね:)