製品要件ドキュメント

製品要件ドキュメント（PRD）は、特定の製品に対するすべての要件を記載した文書です。製品が何をすべきかを人々に理解してもらうために作成されます。しかし、PRDでは、インターフェース設計者やエンジニアが専門知識を活かして要件に対する最適なソリューションを提供できるように、製品がどのようにそれを実現するかを予測したり定義したりすることは避けるべきです。

適切に作成された製品要件ドキュメントにより、チーム全体が同じ認識を持つことができます。

PRDはソフトウェア製品向けに作成されることが最も多いですが、あらゆる種類の製品やサービスにも使用できます。通常、PRDはユーザー/クライアント、または企業のマーケティング部門（後者の場合はマーケティング要件ドキュメント（MRD）と呼ばれることもあります）によってユーザーの視点から作成されます。その後、 （潜在的な）メーカー/サプライヤーによってより技術的な観点から要件が分析され、機能仕様書（技術要件ドキュメントと呼ばれることもあります）に細分化・詳細化されます。

PRDの形式はプロジェクトごとに異なり、例えばプロジェクトの実施方法などによって異なります。[ 1 ] [ 2 ]ソフトウェア開発における最も一般的な2つのアプローチは、カスケーディングモデルとアジャイル開発手法です。[ 3 ]カスケード開発モデルでは、製品要件はプロジェクトの最初に全体的に定義され、準備が整うまで開発は開始されません。アジャイル開発モデルの場合、要件は優先順位付けを可能にするために最初に高いレベルで策定され、その後、各新しいサイクルの開始時に詳細に策定されます。[ 4 ]

PRDは、製品要件とアーキテクチャの不一致、技術的な依存関係の見落とし、実装の複雑さの過小評価など、ソフトウェア開発における重大な技術的問題を防ぐのにも役立ちます。[ 5 ]

コンポーネント

製品要件ドキュメント (PRD) の一般的なコンポーネントは次のとおりです。

  • タイトルと著者情報
  • 技術的およびビジネス的観点からの目的と範囲
  • ステークホルダーの特定
  • 市場評価とターゲット層
  • 製品の概要と使用例
  • 要件（含む）
    • 機能要件（例：製品が何をすべきか）
    • ユーザビリティ要件
    • 技術要件（例：セキュリティ、ネットワーク、プラットフォーム、統合、クライアント）
    • 環境要件
    • サポート要件
    • インタラクション要件（例：製品が他のシステムとどのように連携するか）
  • 仮定
  • 制約
  • 依存関係
  • 高レベルのワークフロー計画、タイムライン、マイルストーン（詳細はプロジェクト計画を通じて定義されます）
  • 評価計画とパフォーマンス指標

すべてのPRDがこれらの要素をすべて備えているわけではありません。特に、他の種類の製品（製造品など）のPRDでは、上記のリストからソフトウェア固有の要素が除外され、製造要件など、そのドメインに関連する追加要素が追加される場合があります。

PRD開発における一般的な問題

  • ユーザーの誤解。顧客が何を望んでいるかを完全に理解しなければ、顧客のすべての要件と期待を満たす効果的なドキュメントを作成することは事実上不可能です。
  • 不完全または不正確な情報 - もう一つの課題は、製品のPRDに必要な情報がすべて含まれていることを確認することです。これには、機能の説明からパフォーマンス指標まであらゆる情報が含まれ、新しい情報や変更があった場合は定期的に更新する必要があります。[ 6 ] [ 7 ]
  • 利害関係者とユーザーの間で要件が明確に伝わらないと、大幅な遅延が発生し、製品が予定通りにリリースされなくなる可能性があります。
  • ドキュメントには現実的なタイムフレームを設定することが重要です。そうすることで、関係者全員が各機能の開発から公開までにかかる時間を把握できます。非現実的なタイムラインを設定すると、プロジェクトの遅延や、場合によっては中止につながる可能性があります。

参照

参考文献

「 https://en.wikipedia.org/w/index.php?title=Product_requirements_document&oldid=1307471706」より取得