<プロジェクト名>
開発構想書
バージョン <1.0>
[メモ: 次のテンプレートは、Rational Unified Process で使用することを目的に提供されたものです。 大括弧で囲まれた青色のテキスト (style=InfoBlue) は、 作成者に対する説明用ですので、本文書を公開する前に削除してください。 このスタイルの後に入力した段落は自動的に通常の形式 (style=Body Text) に設定されます。]
改訂履歴
日付 |
バージョン |
説明 |
作成者 |
<yy/mm/dd> |
<x.x> |
<詳細> |
<名前> |
|
|
|
|
|
|
|
|
|
|
|
|
目次
10.3 インストール・ガイド、構成、Read Me ファイル
開発構想書
[この文書の目的は、<<System Name>> のニーズと機能の概略を収集、分析、定義することです。 中心となる内容は、利害関係者とターゲット・ユーザーが必要とする機能、およびこれらのニーズが存在する理由です。どのようにして <<System Name>> でこれらのニーズを実現するかについては、「ユースケース仕様書」と「補足仕様書」で詳しく説明されます。 メモ: この「開発構想書」テンプレートは、市場のニーズを推測して開発される一般向けの市販製品から、契約に基づき、特定の顧客の要求に合わせた 1 回限りのシステム開発まで、幅広い種類の開発をその対象にしています。 したがって、「製品」および「システム」という言葉は、漠然と「開発対象」という意味で使われており、明確な意味の区別はなされていない場合もあります。特定のアプリケーションに合わせてこの文書を作成する時点で、より厳密に区別するようにしてください。]
[「はじめに」には、開発構想書の全体的な概要を記述します。この開発構想書の目的、範囲、定義、頭字語、略語、参考資料、概要を記載します。]
[開発構想書の目的を定義します。]
[開発構想書の範囲について簡単に説明します。 関連するプロジェクト、その他、この文書が影響を及ぼす事項を記述します。]
[ここでは開発構想書を解釈する上で必要となるすべての用語、頭字語、略語の定義を記します。この用語等の定義については、プロジェクトの用語集を参照するようにしてもかまいません。]
[ここには開発構想書で参照されている参考資料の一覧を記載します。各資料は、タイトル、レポート番号 (該当する場合)、日付、および発行元を明記します。 その参考資料の入手先も記載してください。この参考資料については、付録または別の資料を参照するようにしてもかまいません。]
[ここでは開発構想書のこの項目以降の内容とその構成について説明します。]
[このプロジェクトによって得られるビジネス・チャンスについて簡潔に記述します。]
[このサブセクションでは、現行システムおよびビジネス環境の背景、目的およびスコープ (実情に応じて適用される方針、現行システムの機能、利害関係者、サポートの問題など) について記述します。]
[このサブセクションには、事業上または操作上の観点から変更の正当な理由と考えられる、新たに生じた事情またはニーズを記述します。提案された変更、および却下された変更と、関連する根拠を簡単に示します。 変更ニーズに関する業界の調査が既になされている場合は、それを引用することもできます。]
[このプロジェクトによって解決される問題を要約して記述します。 次の形式を使用できます。]
問題の内容 |
[問題の説明] |
問題の影響を受ける人 |
[問題によって影響を受ける利害関係者] |
問題の影響 |
[問題による影響の内容] |
適切な解決策 |
[適切な解決策の主な利点] |
[その製品が市場で獲得しようとしている独自の位置付けを、大まかに要約して記述します。次の形式を使用できます。]
対象 |
[対象顧客] |
ニーズまたはビジネス・チャンス |
[ニーズまたはビジネス・チャンスの記述] |
(製品名) |
[製品カテゴリー] |
製品の特徴 |
[製品の主な利点、強い購入の動機付けとなるセールス・ポイントの記述] |
競合製品 |
[主な競合製品] |
競合製品との差別化 |
[競合製品との差別化のポイント] |
[製品またはシステムの位置付けの記述によって、システムの目的とプロジェクトの重要性がプロジェクト関係者全員に伝達されます。]
[利害関係者とユーザーの真のニーズを満たす製品およびサービスを的確に提供するには、 要求モデリング・プロセスにすべての利害関係者を参加してもらうことが必要です。また、システムのユーザーを明確にして、利害関係者グループがユーザーの代表者として適切に機能できるようにする必要もあります。このセクションには、プロジェクトに関与する利害関係者とユーザーのプロファイル、およびその利害関係者とユーザーが、提案された解決策で解決する必要があると認識している主要な問題を記述します。利害関係者などの個別の具体的な要望や要求は、別の成果物、「利害関係者の要望」に記載されるため記述されません。 このセクションには、そのような具体的な要求ではなく、要求事項が必要とされる背景と正当性を示します。]
[製品決定の要因となる主な市場の人口統計を要約して記載します。対象となる市場セグメントを記述し、その位置付けを定めます。潜在的なユーザーの数、および開発する製品または製品の機能拡張によって満たすことのできるニーズに対して顧客が支払ってもよいとする金額を基に、その市場の規模および成長性を予測します。主要な業界動向と技術を調査します。 戦略上の以下の観点を検討します。
- 市場における自社の評価はどうか。
- 自社の市場評価をどのようにしたいか。
- この製品またはサービスは、その目標にどのように寄与するか。]
[当該開発に対して利害を持つ利害関係者は多数いますが、 そのすべてがユーザーというわけではありません。ここには、ユーザー以外の利害関係者を要約リストにまとめます。 (ユーザーについては、セクション 3.3 にその要約を記載します。)]
関係者名 |
説明 |
担当職務 |
[利害関係者のタイプを挙げます。] |
[その利害関係者について簡潔に説明します。] |
[開発中のシステムに関する利害関係者の主要な職務、利害関係者としての利害内容を要約して記載します。 利害関係者の職務には、例えば以下のようなものが考えられます。 - システムの保守性を保証する。 - 製品の機能に対して市場の需要があることを保証する。 - プロジェクトの進捗を監視する。 - 資金調達を承認する。 |
[確認された全ユーザーを要約リストにまとめます。]
ユーザーの種類 |
説明 |
担当職務 |
利害関係者 |
[ユーザー のタイプを挙げます。] |
[そのユーザーのシステムに関連した立場を簡潔に説明します。] |
[開発中のシステムに関連するユーザーの主要な職務を列挙します。 例えば、以下のような職務が考えられます。 - 詳細内容を収集する。 - レポートを作成する。 - 作業を調整する。] |
[そのユーザーの立場を直接代表するものがいない場合は、ユーザーの利害を代弁する利害関係者を指定します。] |
[対象ユーザーの作業環境を詳しく記述します。例えば、以下のような事項を考慮します。
タスクの完了に従事する人員の数は何人か。 その人数に変動はあるか。
タスク・サイクルの期間はどのぐらいか。 各作業の所要時間はどのぐらいか。この所要時間に変動はあるか。
モバイル、屋外、飛行機の機内など、環境上の特殊な制約はあるか。
現在使用しているシステム・プラットフォームは何か。将来のプラットフォームはどうか。
現在使用している他のシステム/アプリケーションは何か。開発するシステムは、現在のシステムを統合する必要があるか。
ここには、ビジネス・モデルから抽出した内容を入れて、 関係するタスクやビジネス・ワーカーなどの概要を示すことができます。]
[利害関係者のタイプごとに次の表に記入して、システム内の各利害関係者の説明を記載します。 利害関係者のタイプは、ユーザー、各種部門、技術開発者と多岐に渡ります。全プロファイルを網羅するには、 各タイプの利害関係者について、以下のような項目が必要になります。]
代表者 |
[プロジェクトに対する利害関係者の代表者は誰か (他の場所に記載がある場合は任意)。 ここには氏名を記入します。] |
説明 |
[利害関係者のタイプを簡潔に説明します。] |
タイプ |
[利害関係者の専門分野、技術的な経歴、技能レベル (エキスパート、上級者ユーザー、ビジネス・ユーザー、一時的なユーザーなど) を記述します。] |
担当職務 |
[開発中のシステムに関する利害関係者の主要な職務、利害関係者としての利害をリストします。] |
目標達成の基準 |
[利害関係者は、目標達成をどのように定義しているか。 利害関係者は、どのような報酬を得るか。] |
プロジェクトへの関与 |
[利害関係者はプロジェクトにどのように関与するか。可能であれば、Rational Unified Process のロール (要求レビュー担当者など) と関連付けて記述します。] |
納入物 |
[利害関係者によって要求されるその他の納入物があるか。プロジェクトの納入物や、開発中のシステムからの出力などがこれにあたります。] |
コメント/問題点 |
[目標達成の障害となる問題やその他の関連情報をここに記述します。] |
[ユーザーのタイプごとに次の表に記入して、システムの固有な各ユーザーの説明を記載します。 ユーザーのタイプは、エキスパートから初心者まで多岐に渡ります。例えば、エキスパートはプラットフォーム間をサポートする高機能で柔軟なツールを求めると思われますが、一方、初心者は使いやすくて分かりやすいツールを求めると思われます。全プロファイルを網羅するには、 各タイプのユーザーについて、以下のような項目が必要になります。]
代表者 |
[プロジェクトに対するユーザー代表者は誰か (他の場所に記載がある場合は任意 )。 これは、多くの場合、「利害関係者: 利害関係者 1」など、そのユーザー集合を代表する利害関係者を示します。] |
説明 |
[そのユーザー・タイプについて簡潔に説明します。] |
タイプ |
[ユーザーの専門分野、技術的な経歴、技能レベル (エキスパート、一時的ユーザーなど) を記述します。] |
担当職務 |
[開発中のシステムに関連するユーザーの主要な職務をリストします。 詳細内容の収集、レポートの作成、作業の調整などです。 |
目標達成の基準 |
[ユーザーは目標達成をどのように定義しているか。 ユーザーは、どのような報酬を得るか。] |
プロジェクトへの関与 |
[ユーザーはプロジェクトにどのように関与するか。可能であれば、Rational Unified Process のロール (要求レビュー担当者など) と関連付けて記述します。] |
納入物 |
[ユーザーが作成する納入物はあるか。ある場合は、誰に対して納入するものか。] |
コメント/問題点 |
[目標達成の障害となる問題やその他の関連情報をここに記述します。これには、ユーザーのジョブを容易にする、あるいは困難にする状況や傾向も含まれます。] |
[利害関係者が認識している既存のソリューションの主な問題を列挙します。各問題について以下の点を明確にします。
- この問題の原因は何か。
- 現在のそれをどのように解決しているか。
- 利害関係者やユーザーはどのようなソリューションを求めているか。]
[各問題を解決する上で、利害関係者やユーザーが考えている相対的な重要性を理解することが大切です。ランク付け法および累積投票法を使用すれば、 絶対に解決しなければならない問題と、対処が望まれる程度の問題が明確になります。
以下の表に記入します。 Rational RequisitePro を使用してニーズを把握する場合は、 このツールからの抽出またはレポートでもかまいません。]
ニーズ |
優先度 |
問題点 |
現在のソリューション |
提案されたソリューション |
|
ブロードキャスト・メッセージ |
|
|
|
|
|
[利害関係者が入手可能であると考える代替ソリューションを明確にします。 これには、競合他社の製品の購入、自社によるソリューションの開発が含まれる場合もありますし、単なる現状維持となる場合もあります。既存の競合品、またはこれから入手できるようになる既知の競合品を列挙します。 利害関係者またはユーザーが認識する各競合他社の主な長所と短所を盛り込みます。]
[このサブセクションでは、提案された製品に対して考えられる代替ソリューション、および関連する業界調査の結果を記述します。]
[このセクションでは、製品の機能、他のシステムとのインターフェース、およびシステム構成に関する概要を記述します。]
[開発構想書 のこのサブセクションでは、他の関連製品とユーザーの環境の観点から製品を捉えます。 製品が独立した製品で、必要な機能をすべて揃えている場合は、そのことをここに記述します。 製品が大きなシステムのコンポーネントである場合は、 それらの複数のシステムが互いにどのように相互作用するのか、システム間の関連するインターフェースを明確にします。大規模なシステムの主要コンポーネント、 相互接続、外部インターフェースを示す簡便な方法として、ブロック図の利用があります。
利害関係者および他のシステムに与える運用上、組織上、および開発上の影響を示します。]
[製品が提供する主な利便性と機能をまとめます。例えば、 顧客サポート・システムの開発構想書の場合、この部分に問題の記述、ルーティング、ステータス・レポートを記載しますが、これらの各機能が必要とする詳細な内容には触れません。
顧客や文書を初めて読む人にとってわかりやすいように機能を整理します。主要な利便性とそれをサポートする特徴的な機能を列挙した簡単な表で十分と思われます。次に例を示します。]
表 4-1 顧客サポート・システム
顧客にとっての利便性 |
サポートする機能 |
新人のサポート・スタッフでもすぐに情報を入手できる。 |
知識ベースが、既知の解決策や回避策を素早く特定できるようにサポート担当者をサポートします。 |
問題が見過ごされることがなくなり、顧客の満足度が向上する。 |
解決プロセスを通じて、 各問題が一意に識別、分類、追跡されます。過去の問題については自動通知が行われます。 |
管理者が問題の領域を識別し、スタッフの作業量を予測できる。 |
傾向レポートと分布レポートによって、問題の状況を広い視点から見直すことができます。 |
サポート・チームが分散している場合でも、協力して問題を解決できる。 |
複製サーバーによって現在のデータベース情報を企業全体で共有できます。 |
顧客自身が問題を解決できるので、サポート・コストが下がり、応答時間が向上する。 |
インターネットを介して知識ベースを利用できます。これには、ハイパーテキスト検索機能、グラフィカルなクエリー・エンジンが含まれます。 |
[開発構想書で示されている機能に影響を及ぼす要素を列挙します。変更があった場合、開発構想書の改訂が必要になる前提事項を列挙します。 例えば、開発構想書が大企業を前提に作成された場合、その前提に変更があった場合は、構想書を変更しなければならないことがあります。これには、経済的、政治的、法律的、および環境的要素などがあります。 また構想書が、設備、ソフトウェア、およびその他のシステム・コンポーネントの可用性、または特殊な専門的知識や技術の利用可能性に依存する場合もあります。]
[外部の顧客に販売される製品や多くの社内システムの場合、 コストと価格の問題はシステムの定義と実装に直接影響を及ぼします。このセクションには、関連するコストや価格の制約を記録します。例えば、システムの性質によっては、 販売コスト (ディスケットの数、CD-ROM の数、CD マスタリング) やその他の販売商品のコスト制約 (マニュアル、パッケージング) がプロジェクトの成否に重要な場合もあれば、あまり関連性がない場合もあります。]
[ライセンス付与とインストールの問題も、開発作業に直接影響を及ぼす場合があります。例えば、アクセス制御、 シリアル化、パスワード・セキュリティー、またはネットワーク・ライセンスをサポートすることがニーズにあれば、 開発作業時に考慮するべき追加のシステム要件が生じます。
インストール要件によっては、ソフトウェア構造に影響を及ぼしたり、 別のインストール・ソフトウェアが必要になったりする場合もあります。また、例えば、物理システムに特別なセキュリティーまたは耐久性に関する制約がある場合、その物理システムに特別なインストール要件が生じる可能性があります。]
[製品の基本機能を列挙し、簡潔に説明します。製品の基本機能は、 ユーザーに利便性を提供するために必要な、システムの持つ能力の概要です。また、各基本機能について、関連する性能特性に沿って説明します。何かの作業が「どのくらい良好に」行われるかを、一定の基準、例えば、時間を基準にする場合、応答時間とトランザクション速度に基づいて記述します。「基本機能」という言葉自体は、特に重要ではありません。「性能」や「能力」など他の言葉を使用してもかまいません。これらの言葉はすべてシステムまたは製品が実行すべき内容を示します。 各機能は外部から要望されるサービスであり、 求められている結果を達成するには、通常、一連の入力が必要です。例えば、問題追跡システムの基本機能は、 傾向報告書を提供する機能などになります。ユースケース・モデルが形作られる時点で、ユースケースに対応するように記述を変更します。
開発構想書は幅広い分野の関係担当者によって参照されるため、 関係者全員が理解できるように、一般向けの表現にする必要があります。ただし、ユースケース・モデルを作成するチームが、必要な詳細情報を入手できるようにしておく必要があります。
システムの複雑さを効果的に管理するには、 新規システムまたは既存システムの拡張について、機能をある程度高い複雑さのレベルまで概念化し、具体的には 25 から 99 までの基本機能になるようにすることをお勧めします。これらの基本機能が、 製品定義、範囲管理、プロジェクトマネジメントの基盤となります。各基本機能はユースケース・モデルでさらに詳細に記述されます。また、プロジェクトでユースケースを作成しないことを選択した場合には、自然言語で詳細に記述します。
このセクションを通じて、各基本機能が、ユーザー、オペレーター、その他の外部システムによって外部的に認識されます。これらの基本機能には、 機能の説明、および使いやすさに関して対処すべき問題があれば、それらを記載する必要があります。 次の指針が適用されます。
- 現在のそれをどのように解決しているか。基本機能の説明を一般的なレベルに留めてください。必要とされる機能と、 それらを実装しなければならない理由 (実装の方法論ではない) を中心に記述します。
- Rational RequisitePro ツールキットを使用する場合は、 参照と追跡が簡単に行えるように、すべてタイプを要求として選択する必要があります。]
[製品またはシステムの用途として、重要なあるいは関心を引くようなシステムとユーザー、環境、および他のシステムとの間の相互処理を示す事例をいくつか記述します。]
[このサブセクションでは、サポート組織、設備、メンテナンス周期、補充の手配など、サポートの提供方法を概念的に記述します。]
[設計上の制約、外部制約、その他の依存関係を記述します。]
[基本機能に記載されない性能、堅牢性、フォールト・トレランス、使いやすさ、その他の同様な特性について、その品質の範囲を定義します。]
[さまざまなシステム基本機能の優先度を定義します。]
[適用する標準や規格、ハードウェアまたはプラットフォームの要件、 性能要求、環境要求を大まかに記載します。]
[製品が準拠しなければならないすべての標準や規格をリストします。これらの標準には、法規制による通信標準 (FDA、UCC) の通信標準 (TCP/IP、ISDN)、 プラットフォーム準拠標準 (Windows、UNIX など)、品質や安全性の規格 (UL、ISO、CMM) などが考えられます。
[ソフトウェア・システムの開発の場合、アプリケーションをサポートするのに必要なすべてのシステム要件を定義します。これらの要求には、 サポートされているホスト・オペレーティング・システムとネットワーク・プラットフォーム、構成、メモリー、周辺機器、付属ソフトウェアなどがあります。]
[ここには性能要求の詳細を記述します。性能の問題には、ユーザーの負荷要素、帯域幅 (通信の処理能力)、スループット、精度、さまざまな負荷条件下での信頼性や応答時間などがあります。]
[必要に応じて環境要求を詳しく記述します。物理システムの場合、環境の問題には、気温、衝撃、湿度、熱放射などが含まれます。ソフトウェア・システムの場合、 環境の要素には、使用条件、ユーザー環境、リソースの可用性、メンテナンスの問題、エラー処理および回復などが含まれます。]
[重量、質量制限、またはサイズ制限などの物理的な要件がある場合は、このサブセクションに記述します。]
[ここには、システムの導入が適切に行われるようにするために作成する必要のある文書を記載します。]
[ユーザー・マニュアルの目的と内容について記述します。希望する文書の長さ、詳細度、索引の有無、用語集、チュートリアル方式にするか、 リファレンス・マニュアル方式にするかなどについて検討します。書式上と印刷上の制約も特定する必要があります。]
[多くのシステムでは、オンライン・ヘルプを提供してユーザーを補助しています。 オンライン・ヘルプ・システムの特質は、プログラミング (ハイパーリンクなど) の側面と、構成やプレゼンテーションなどのテクニカル・ライティングの側面を併せ持っており、独特と言えます。一般に、オンライン・ヘルプ・システムの開発は、プロジェクト内のプロジェクトで、先行的な範囲管理と計画立案作業を基に行うと有効なプロジェクトであると認められています。]
[インストール手順や構成のガイドラインを含む文書は、ソリューションの完全な提供という点で重要な文書です。Read Me ファイルも通常は標準コンポーネントとして含まれます。Read Me ファイルには、「このリリースの新機能」のセクションや、以前のリリースとの互換性に関する説明が記載されます。 既知のバグや問題の回避策に関する説明も Read Me ファイルに記載され、 多くのユーザーにとって有益な情報です。]
[今日のシステムでは、製品のパッケージングやマニフェストを始めとして、インストール・メニュー、スプラッシュ画面、ヘルプ・システム、GUI ダイアログなどにわたって、一貫性のある外観を提供するよう努力しています。ここでは、 システムに組み入れるラベル付けのニーズとタイプを定義します。例えば、著作権と特許の情報、会社ロゴ、標準化されたアイコンやその他のグラフィック要素の使用などがあります。]
[基本機能には、実装が提案された製品品目を評価、追跡、優先順位付け、 管理する場合に使用できる属性が与えられます。要求タイプと属性はすべて、「要求管理計画書」にその概要が示されますが、 一部選択した基本機能の属性をここで簡単にリストすることもできます。次のサブセクションでは、一連の基本機能の属性の例を示します。]
[プロジェクトマネジメント・チームによる調整とレビューが終わった後に設定します。プロジェクト・ベースラインの定義中に進捗を追跡します。]
提案済み |
[調整中であり、「公式の認定者」によってまだレビューや承認がなされていない基本機能を記述する場合に使用します。 公式の認定者には、プロジェクト・チーム、製品管理、 ユーザーまたは顧客の代表者で構成される作業グループなどがあります。] |
承認済み |
[有用で実現可能であると見なされ、公式の認定者によって実装が承認された機能。] |
導入済み |
[特定の時点で製品のベースラインに組み込まれた基本機能。] |
[マーケティング、製品管理者、ビジネス分析者によって設定されます。すべての要求が一様に作成されるわけではありません。ユーザーに対する相対的な利便性を基準に要求をランク付けする作業は、 顧客、分析者および開発チームのメンバーと話し合いをする端緒となります。範囲を管理するときや開発優先順位を決定するときに使用されます。]
必須 |
[欠かすことのできない基本機能です。この機能を実装することができなければ、システムは顧客のニーズを満たすことはできません。不可欠な基本機能は、すべてこのリリースで実装する必要があり、 実装できない場合は、リリース・スケジュールが遅れることになります。] |
重要 |
[ほとんどの用途で、 システムの効果的、効率的な運用に重要な基本機能です。この機能に代わる方法はなかなかありません。重要な基本機能を装備できなかった場合、 顧客やユーザーの満足度、さらには収益にも影響を及ぼす場合がありますが、重要な基本機能の欠落によるリリースの順延はありません。] |
有用 |
[あまり標準的でない用途をサポートする機能で、頻繁には使用されない機能、または、十分有効な次善策のある機能です。そのような機能をリリースに入れなかった場合でも、 収益や顧客の満足度に対する影響は大きくないと予想されます。] |
[開発チームによって設定されます。基本機能によっては、ほかの基本機能よりも多くの時間とリソースを必要とするものがあるため、複雑性を評価し、与えられた時間枠の中で実現できるものとできないものを予測する場合、チームの数または人週を見積もる、または、作業に関連する規模 (必要なコードの行数やソフトウェアに対する機能ポイント数など) を測定することが最も良い方法です。範囲を管理するときや開発優先順位を決定するときに使用されます。]
[予算の超過、スケジュールの遅延、あるいはプロジェクトの中止など、 プロジェクトに望ましくないイベントが発生する確率に基づいて、開発チームが設定します。ほとんどのプロジェクト管理者の場合、リスクを高、中、低に分類するだけで十分ですが、より細かく分類することもできます。リスクは、プロジェクト・チームによるスケジュール予測の不確実性 (範囲) を測定することによって、間接的に評価する場合もよくあります。]
[基本機能の変更、または基本機能に対するチームの理解が変わる可能性を基に、 分析者または開発者が設定します。 開発優先順位を設定し、 要求等をさらに引き出すことが次の作業として適切と考えられる項目を決定する場合の参考として使用します。]
[基本機能が最初に装備される予定の製品バージョンを記録します。このフィールドを使用して、 開発構想書に記述されている基本機能を特定のベースライン・リリースに割り当てることができます。ステータス・フィールドと組み合わせれば、チームが開発に深く関与していない場合でも、 リリースのさまざまな基本機能について提案、記録、討議することができます。ステータスが「導入済み」に設定され、対象リリースが定義された基本機能だけが実装されます。範囲管理の問題が生じた場合、 リリース目標のバージョン番号を大きくすることによって、その項目を開発構想書に残し、後日リリースするようにスケジュール設定することができます。]
[多くのプロジェクトでは、「基本機能チーム」に基本機能が割り当てられ、このチームがさらなる情報の引き出し、要求の取り込みおよび洗練、および実装を担当します。この簡単なプルダウン・リストによって、 プロジェクト・チームの全員が職務分担をより良く理解できます。]
[このテキスト・フィールドは、基本機能が要求された原因を追跡に使用します。要求には特定の理由があります。 このフィールドには、特定の説明、または説明の参照先を記録します。例えば、製品要求仕様のページ番号または行番号、 重要な顧客レビューのビデオに付けられる分単位マーカーを参照先として指定できます。]