project-management - プロジェクトの要件を理解していることを示す方法

Question

あなたが彼らの要件を理解したことをあなたのクライアント/雇用者にどのように示しますか？

何を使うことをお勧めしますか？ユースケース図？フローチャート？データフロー図？デシジョンツリー？

私は本当に詳細な答えを求めているわけではありません。要件を書いた人とコミュニケーションを取り、両方が同じページにいるかどうかを確認するのに役立つ簡単なものです。

Answer 1

私は通常、プロジェクトのかなり早い段階でPowerPointデッキをまとめ、プロジェクトの概要を、いくつかのアーキテクチャ図（シンプルであるほど良い）と画面のモックアップ/ワイヤーフレームとともに示します。次に、要件レビューのための「キックオフ」ミーティングを行い、ビジネス上の問題と提案されたソリューションについて話し合います。

Answer 2

要件を自分の言語で説明し、前提条件を提供し、制限を追加します。

要件は「クリックするとボタンが緑色に変わる」である可能性があります

「わかりました。ユーザーがボタンをクリックすると、ボタンの背景色は緑色に変わりますが、テキストは同じ色のままですか？」と質問します。

基本的に、要件を与える人に、それがどのように機能することを想定しているかを説明するよう促します。

Answer 3

私の役割には多くの要件があります。私が見つけた最善の方法は、PowerPointプレゼンテーションを通じて、すべてをシンプルかつ高レベルに保ち、概念実証またはモックアップを示すという2つのアプローチです。歩いて顧客に話しかけると、「色を変えることができますか？」などの多くの「もしも」と顧客が応答するのがわかります。これにより、誰もが何を得ているかについて幅広いアイデアを得ることができます。ユーザーが触れて遊ぶことができるものを手に入れることができれば、それは隠されたものを明らかにするのに非常にうまく機能します。

次に、この高レベルを、非常に詳細な低レベル要件でバックアップします。点線の「i」と交差した「t」を綴ります。POC以外の作業を行う前に、ユーザーに読み通して署名してもらいます。一般的に、スクリーンショットがたくさんある単語はうまく機能します。

ユーザーがUMLとデータフローチャートを持ってくることができない限り、顧客が見たり署名したりするものにそれらを使用しないでください。それが顧客によって署名されており、「もしも」を満たすためにバックエンドを再登録する必要がある場合は、すべてを完全に辞任する必要があります。

最後に、顧客が自分の要件について自分の言葉であなたに話しかけ、得ているものを詳しく説明できるようにすることです。これを行う1つの方法は、中間管理職が上級管理職に売却することに参加することです。

土壇場で何かを変更したい場合は、時間とお金でコストを説明し、これが完全に必要かどうかを尋ねてください。これを行うと、多くの場合、人々が些細な変更を行うのをやめ、変更が必要な理由を考えさせることになります。

要件は、顧客が望むものから顧客が必要とするものを取得することです。

編集-スクリーンショットを早期に表示するという点まで-これには、時間スケールとすべてがどこにあるかを顧客に知らせるための優れたPMが必要になる場合があります。PMが適切な時間枠と期待を設定するのに役立つ場合、顧客は興奮しません。POCとスクリーンショットの良いところは、人々がそれがどのようなものであるかというイメージを取得し、それを頭の中でうまく機能させることができることです。

スクリーンショットを避けたい場合は、ワイヤーフレームの外観を作成するか、ホワイトボードと20分の描画を使用してください。ホワイトボードをホイップする前に、写真として保存することを忘れないでください。

ホワイトボード（および古き良きOHP）は、要件収集の天の恵みになる可能性があります。明確なスタイルの描画コンセプトを開発することで、ワークショップの時間を節約できます。

Answer 4

フローチャートは、データフロー図だけでなく、一部の非技術者（つまりクライアント）を混乱させる傾向があります。ユースケースは、ビジネス要件と技術要件のドキュメント、ある種の大まかなワイヤーフレームスケッチと同様に、よく理解できるものです。

Answer 5

それは本当にあなたが話している要件に依存します。

• 機能要件？たぶん、UMLはの厳密なツールです。しかし、私はテストoテスト仕様を好みます
• GUI要件？紙と鉛筆に勝るものはありません。
• セキュリティ要件？セキュリティの限界を説明することで、予期しない欺瞞を回避できます。
• 信頼性要件？テストメカニズムとソフトウェア/ハードウェアのバックアップ/リカバリ計画の両方。
• その他の要件：クライアントによって異なります。

しかし、とにかく、覚えておいて、要件は開発段階で変更され、それは常にコストと機能性の間の議論と妥協になることをクライアントに説明してください。正直であることはあなたの顧客により多くの自信を与えます。

Answer 6

クライアントのアイデアを本当に理解していることを示す最良の方法は、プロトタイプを作成することだと思います。

ちなみに、私は要求工学会議の最終版とワークショップの1つ（MERE）に出席しましたが、シーメンスはクライアントのアイデアのビデオを作成することに基づいて興味深いソフトウェアを見せていました（ソフトウェアに限定されないプロジェクト用でした）すべての要件が完全に理解されていることを確認するためだけに。

とにかく、事はそれらを示すための創造的な方法がより良い場合があるということです。標準の図に限定しないでください。

Answer 7

ドメインの用語とその意味と関係を使用して簡単な語彙を作成し、それを調べて、全員がすべてに同意することを確認するという良い経験をしました.

語彙を書いて議論することで、「後でそれを理解する」と考えるだけでなく、考えることを強いられます。

もちろん、これは特効薬ではなく、機能要件の仕様やプロトタイプなどの他の手段と併用する必要があります。