ReqIF データからの新しいプロジェクトの作成
ReqIF データをインポートすることが顧客要件の場合は、そのための新しいプロジェクトを作成することを推奨します。Codebeamer 内では、認定、コメントの付加、参照のみを行う必要があり、それ以外の場合は未変更のまま保持する必要があります。インポートされたデータへの書き込みアクセスを制限し、インポート元/顧客と Codebeamer との間で修正/更新を継続的/反復的に交換する必要がある場合は、インポートされたデータモデル (トラッカーコンフィギュレーション) の大きな構造変更を避ける必要があります。その点において、インポートされたトラッカーへの新しいフィールドの追加は、問題ありません。当然、これは単なる推奨事項です。
ReqIF を介して新しい要件をインポートするには、次の手順を実行します。
• Codebeamer 「プロジェクト」メニューから「新規プロジェクト」を選択します。
• 「新しいプロジェクトを作成」を選択します。
• インポートする ReqIF ファイル (*.reqif) またはアーカイブ (*.reqifz) を添付します。
次の画面では、新しいプロジェクトの名前を追加できます。ReqIF データをマッピングして、新しいプロジェクト内のターゲットトラッカーにインポートできます。インポートする ReqIF ファイル内のオブジェクトモデルが表示されます。
Codebeamer 9.4 以降では、ReqIF データの「ソース」を選択するか、デフォルト名の「インポート元」を受け入れることができます。
Codebeamer 9.4 以降では、「ソース」フィールドにドロップダウンリストが追加され、インポートする ReqIF ファイルのヘッダーが表示されます。
Codebeamer 8.2 以降では、ReqIF メタデータの仕様別のグループ化が試行されます。
• 1 つの仕様によって仕様タイプが排他的に使用されている場合、「仕様」は、その仕様のトラッカーという名前の子として表示されます。
• 特定のアイテムタイプのアイテムが 1 つの仕様によって排他的に使用されている場合、そのアイテムタイプは仕様の子として表示され、仕様と同じターゲットトラッカーに自動的に関連付けられます。
◦ 仕様にアイテムのタイプが 1 つしかない場合は、アイテムタイプにアイテムという名前が使用されます。例 2: IBM Rational DOORS。
◦ 仕様に複数のタイプのアイテムがある場合、各アイテムタイプは独自の名前で表示され、ターゲットトラッカーでこのタイプのアイテムを識別する一意の修飾子のセットも指定する必要があります。例 3: IBM Rational Requirements
次のスクリーンショットは単なる例です。インポートする ReqIF ファイルのデータモデルによって、まったく異なる外観となる場合があります。
例 1: SparxSystems Enterprise Architect
この例の ReqIF ファイルには、排他的仕様タイプ (トラッカー) の 1 つの「仕様」と 2 つの「アイテム」が含まれています。
「アイテム」に関する特別な点は次のとおりです。
• アイテム名/サマリーに追加の属性 (ReqIF.Name または ReqIF.ChapterName) がないので、SpecObject (アイテム) の LONG-NAME がアイテム名/サマリーとして使用されます。
• アイテムの説明には追加の属性がありますが、その名前は提案された名前 (ReqIF.Text) ではありません。
◦ アイテムの説明の属性 (「Scalability Requirement」など) がない場合は、SpecObject (アイテム) の DESC がアイテムの説明として使用されます。
また、「ユーザーストーリー」などの、どの仕様にも関連しない追加のアイテムタイプもあります。
「ユーザーストーリー」はデフォルトのユーザーストーリートラッカーにマッピングできますが、現在の例では、このタイプのアイテムがないので、マッピング/インポートはされません (--無視--)。
空の「仕様」、「アイテムタイプ」、または「リレーション」、および空の属性を無視すると、インポートされたデータの編集を目的とする場合に、不適切な状態になることがあります。
例:
• 新しいトラッカーアイテムを追加します。
• (空の) フィールドの値を設定します。
• 新しいアイテムの関連付けを追加します。
その後、修正されたデータを再エクスポートします。
例 2: IBM Rational DOORS。
IBM Rational DOORS によって生成された ReqIF ファイルでは、通常、各「仕様」は独自のタイプを持ち、単一タイプの「アイテム」のみが含まれます。
仕様とアイテムタイプの間の関連付けは、 > > > を介して間接的にのみ定義されるので、空の仕様のアイテムタイプは未定義であり、非排他的/共有アイテムタイプの下に一覧されます。
DOORS 要件には (ほかの多くの属性と共に)、それぞれ次が含まれます。
• ReqIF.ChapterName
• ReqIF.Name
• ReqIF.Text
ただし、属性に実際に値があるかどうかは、要件のタイプによって異なります。
• DOORS 見出しには ReqIF.ChapterName 値がありますが、ReqIF.Name と ReqIF.Text は通常は空です。
• たとえば、見出し以外のタイプの要件には ReqIF.Text の値がありますが、ReqIF.Name と ReqIF.ChapterName の両方は通常は空です。
ReqIF 属性のターゲットフィールドへのマッピングが不明確な場合、たとえば、ReqIF.ChapterName と ReqIF.Name の両方を Summary にマッピングできる場合などは、フィールドに値を持つアイテム数に基づき、最初の 10 フィールドの値のリストを使用して、最適な一致を見つけることができます。
上記の例では、1 つのアイテムのみが ReqIF.Name を持ち、9 つのアイテムは ReqIF.ChapterName を持つため、Summary には ReqIF.ChapterName を使用します。
例 3: IBM Rational Requirements
IBM Rational Requirements によって生成された ReqIF ファイルでは、「仕様」には通常、次のような異なるタイプのアイテムが含まれています: 「見出し」、「情報」、「要件」など
これらのアイテムはすべて同じターゲットトラッカーにマッピングされるので、トラッカーでこのタイプのアイテムを識別するには、各アイテムタイプに一意の修飾子セットが必要です。
たとえば、「見出し」アイテムは、「タイプ」 == 「フォルダ」のターゲットトラッカー内のアイテムです。
「仕様」は、「アクター」などの「仕様」自体の一部ではない (コンフィギュレーション) アイテムも参照できます。
これらの個別の「アイテムタイプ」は、通常、「アクター」などの適切なコンフィギュレーションアイテムトラッカーにマッピングする必要があります。
IBM Rational Requirements では、すべてのアイテムタイプに「ReqIF.Name」と「ReqIF.Text」があり、アイテムのサマリーと「説明」にマッピングする必要があります。
「見出し」アイテムタイプにも ReqIF.ChapterName がありますが、この属性の値は「ReqIF.Name」と同じなので、無視しても問題ありません。