プロジェクトの要件を理解していることを示す方法 [終了]

Question

顧客や雇用主の要件を理解していることをどのようにして示しますか?

何を使うのがおすすめですか？ユースケース図?フローチャート?データフロー図?ディシジョンツリー?

あまり詳しい答えを求めているわけではありません。要件を作成した人とコミュニケーションを取り、両者が同じ認識を持っているかどうかを確認するのに役立つ簡単な情報です。

Answer 1

私は通常、プロジェクトのかなり早い段階で PowerPoint デッキを作成し、いくつかのアーキテクチャ図 (シンプルであるほど良い) と画面のモックアップ/ワイヤーフレームとともに、プロジェクトの概要を示します。次に、要件を検討するための「キックオフ」会議を開き、ビジネス上の問題と提案された解決策について話し合います。

Answer 2

私は自分の言語で要件を説明し、私の仮定を提供し、制限を追加するだけです。

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

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

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

Answer 3

私の役割では、多くの要件を収集する必要があります。私が見つけた最良の方法は、2 つの側面からのアプローチです。PowerPoint プレゼンテーションを通じてすべてをシンプルかつハイレベルに保ち、概念実証またはモックアップを示します。顧客が歩いて話すと、「色をチャンスできますか？」など、多くの「what's」で応答するのがわかります。これは、誰もが彼らが何を得ているのかという幅広いアイデアを与えます。ユーザーが触って遊べるものを手に入れることができれば、隠された「もしも」を明らかにするのに非常に効果的です。

次に、この高レベルを非常に詳細な低レベルの要件でバックアップします。点線「i」とバツ印「t」をスペルアウトします。POC 以外の作業が行われる前に、ユーザーに内容を読んで署名してもらいます。一般に、多くのスクリーンショットを含む Word はうまく機能します。

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

最後に、顧客が自分の要件について自分の言葉で話し、何が得られるのかを説明できるようにすることです。これを行う 1 つの方法は、中間管理職が上級管理職に売り込むのに参加することです。

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

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

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

スクリーンショットを避けたい場合は、ワイヤーフレームで表示するか、ホワイトボードを使用して 20 分間描画します。ホワイトボードを作成する前に、必ず写真として保存してください。

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

Answer 4

フローチャートは、データ フロー図と同様に、一部の非技術者 (つまりクライアント) を混乱させる傾向があります。ユースケースはわかりやすく、ビジネス要件や技術要件の文書、ある種の大まかなワイヤーフレームのスケッチなども含まれます。

Answer 5

それは本当にあなたが話している要件によって異なります。

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

ただし、いずれにせよ、要件は開発段階で変化するものであり、コストと機能の間で常に議論と妥協が必要であることを念頭に置いて、クライアントに説明してください。正直であることで、顧客にさらなる信頼を与えることができます。

Answer 6

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

ところで、私は前回の要件エンジニアリングカンファレンスに出席しており、そのワークショップの 1 つ (MERE) では、シーメンスがクライアントのアイデアのビデオを作成した興味深いソフトウェアを展示していました (ソフトウェアに限定されないプロジェクトが対象でした)。すべての要件が完全に理解されていることを確認するためだけに。

いずれにせよ、場合によってはクリエイティブな方法で見せたほうが良い場合もあります。標準的な図表に限定されないでください。

Answer 7

私は、その分野の用語とその意味と関係性を含む簡単な語彙を作成し、それを検討して全員がすべてに同意していることを確認するという良い経験をしてきました。

語彙について書いたり話し合ったりすると、単に「後でそれを理解しよう」と考えるのではなく、考える必要があります。

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