要求交換フォーマット(ReqIF)を調べてみた。(2)

ReqIF XML

OMGが公開している要求交換フォーマット(ReqIF:Requirements Interchange Format)について調べている。ReqIFの仕様書の7章「概要とユースケース」を読んでみた。ユースケースについては前回提示したので、今回は仕様の概要だ。



    7.1 要求記述ツールが情報をどのように扱うのか？ 

    7.2 ReqIFが要求記述ツールからの情報をどのように扱うのか？

    7.3 ReqIFがさまざまなツールでどのように扱われるか？
という構成だ。情報といっているのは要求仕様のことだ。要求仕様を要求記述ツールがどのように扱えるかと説明している。要求記述ツールとは、EA、astah*、要件のツボなどのモデリングツールがReqIFを扱えるように拡張されたものをイメージするといい。以下の記事も参照のこと。

7.1 要求記述ツールが情報をどのように扱うのか？

要求記述ツールは、ほとんどWORDと同じように使える必要がある。これまでWORDを使って要求仕様を記述してきた人でも、似たような操作で要求記述ツールを利用できることが望ましい。仕様書では、WORDで作成されたテキスト文書を、要求記述ツール上の仕様記述に変換したサンプルが図示されている。

要求記述ツールには、8つの機能が規定されている。そのうち3つはWORDと同等の機能を実現することであり、5つは要求記述ツール固有の機能である。

  • A-1: 階層的な仕様構造
  • A-2: テキストの強調表現
  • A-3: バイナリファイルの参照
  • B-4: 要求の一意性
  • B-5: 要求属性
  • B-6: 要求間の関係
  • B-7: 関係のグループ化
  • B-8: アクセス制限
8つの機能の説明は以下の通りだ。

A-1: 階層的な仕様構造
WORDの利用者は、節と項の階層構造で記述し、WORDは自動的に先頭に番号を振り、アウトラインを生成できる。要求記述ツールでも、仕様を階層構造で生成でき、利用者は要求をツリー構造で記述できるようにすること。
A-2: テキストの強調表現
WORDでは、いろいろな箇所で太字、下線、斜体字、取り消し線、箇条書きの黒丸や通番が利用できる。要求記述ツールでも、太字、下線、斜体字、取り消し線、箇条書きの黒丸や通番が、要求の属性値で利用できるようにすること。
A-3: バイナリファイルの参照
WORDでは、EXCELやPPTなどのバイナリファイルが文書内から参照できる。要求記述ツールでも、要求の属性値からバイナリファイルの参照ができるようにすること。
B-4: 要求の一意性
要求記述ツールは、個々の要求を区別できるように自動的にユニークなIDを付与できること。
B-5: 要求属性
要求記述ツールの利用者は、任意に属性を定義でき、それらを要求に付加できること。(※まず属性を定義し、それを要求に付加するという手順のようだ。)
要求の集合は、同じ属性を共有できること。これらの属性は、各要求で異なった値を持ち、値はそれぞれ異なった基本データタイプを許すこと。例えば、要求記述ツールの利用者が、仕様に不可欠な属性として、ID、説明(description)、優先度(priority)、ステータス(status)、部類(department)を定義したとしよう。優先度は整数型、ステータスや部類は列挙型、説明は文字列型としたり、各要求では、それぞれの属性に異なった値を持つことができなければならない。(※ごく当り前の説明だ。)
B-6: 要求間の関係
要求記述ツールの利用者は、要求間の関係を定義できること。関係の目的は、トレーサビリティの確立であっても、非機能要求を機能要求に紐付けすることであってもよい。
B-7: 関係のグループ化
要求記述ツールでは、関係の新しいタイプを定義し、それらのタイプで関係をグループ化できること。
例えば、要求記述ツールは、利用者が、2つの要求間に新しい矛盾関係(contradicts)を定義できること。(※contradictは一方が成立すれば、もう一方が成立しない関係のこと) さらに、利用者は矛盾関係のグループを定義できること。このような関係のグループは、関係する要求を束ねることができ、仕様のレビューや再考の際に活用できる。
B-8: アクセス制限
要求記述ツールでは、情報にアクセス制限が設定できること。
例えば、仕様の交換において、パートナー会社が受け取ったCRS(顧客要求仕様)では要求の優先度という属性を変更できないように設定できること。

7.2 ReqIFが要求記述ツールからの情報をどのように扱うのか？

ReqIFは、要求記述ツール間で仕様を交換する目的で構築されるものであり、前節(7.1節)で記述された情報が表現されなければならない。前節で記述された機能がフォーマットの中でどのように表現されるかが提示されている。前述の8つの機能ごとに説明されている。各機能の説明では、構文と要素記述についてのリファレンスが添えられているので、詳細はそちらを参照のこと。

A-1: 階層的な仕様構造
■ReqIFは、要求の階層構造で構成される仕様コンセプトを提供できること。
※要求仕様の基本は、10.3を参照のこと。
※階層構造の構文は、10.4を参照のこと。
※仕様のクラス記述は、10.8.37を参照のこと。
※要求のクラス記述は、10.8.39を参照のこと。
※階層構造のクラス記述は、10.8.36を参照のこと。
A-2: テキストの強調表現
■フォーマットされたテキストでは、一般的な複合トピック(※太字、下線、斜体字、取り消し線、箇条書きの黒丸や通番などのこと)を表現できること。
■ReqIFは、フォーマットの実装を容易にするために、W3CのXHTMLモジュールのサブセットを利用すること。XHTMLコンテンツは、特定の属性値で使われてもよい。
※フォーマットされたコンテンツのデータタイプについては、10.6.3を参照のこと。※クラス記述については、10.8.11, 10.8.29, 10.8.20を参照のこと。
A-3: バイナリファイルの参照
■属性値の中からバイナリファイルを参照できること。
■メカニズムとして利用できるフォーマットされたテキストやXHTMLも含むこと。
※クラス記述については、10.8.20を参照のこと。
B-4: 要求の一意性
■ReqIFは、要求に一意なIDを付与するメカニズムを提供すること。
※構文については、10.2を参照のこと。
※クラス記述については、10.8.32を参照のこと。
B-5: 要求属性
■ReqIFは、要求に属性を付与できること。
■属性の定義(属性名、属性データタイプなど)は、属性の値と分離して行えること。
※要求に属性を付与する方法については、10.3を参照のこと。
※属性データタイプについては、10.5を参照のこと。
B-6: 要求間の関係
■ReqIFは、自由に意味定義できる関係を表現できること。
※構文については、10.4を参照のこと。
※クラス記述については、10.8.41を参照のこと。
B-7: 関係のグループ化
■ReqIFは、関係をグループ化できること。
※クラス記述については、10.8.42と10.8.33を参照のこと。
B-8: アクセス制限
■ReqIFは、特定の情報要素を編集できないように設定できること。
※10.7を参照のこと。

7.3 ReqIFがさまざまなツールでどのように扱われるか？

要求記述ツールがサポートすべき機能は広範囲だが、すべての要求記述ツールをサポートするような要求のための統一言語はないし、要求記述ツール間で共有されるメタモデルもないのが、実情だ。ReqIFは、当面、市場にあるツールで扱われることになる。その際に考慮されなければならない2つの場面が提示されている。

  • 同じ要求記述ツールで異なった用語を使うとき
  • 異なった要求記述ツールで要求仕様を交換するとき

(1) 同じ要求記述ツールで異なった用語を使うとき

同じ要求記述ツールであっても、同じ概念を異なった用語で用いている場合があるだろう。例えば、ある要求記述ツールで「オブジェクト」と呼んでいるものが他の記述ツールでは「要求」と呼ばれているかもしれない。
■ReqIFは、概念の制限された集合のみで構成されているが、市場のさまざまな要求記述ツールに非公式にマッピングできること。このようなマッピングを提供するための実装ガイドリファレンスを「付録A」で提供しているので参照せよとある。付録Aには、さらに以下を参照せよとだけ記述されている。(※私もまだ参照していない)
ｈttp://www.prostep.org/de/downloads/guidelines-use-cases.html
[2011/08/15追記]上記のリンク先はドイツ語だし、それらしいimplementation guideline ReqIFは有料で90ポンドになっている。どういうことだ。後日調べてみます。

(2) 異なった要求記述ツールで要求仕様を交換するとき

ユーザーが2つの異なった要求記述ツールで仕様を交換するときに、異なったツールのために情報が失われるかもしれないという想定である。たとえば、A社の要求記述ツールでエクスポートした仕様をB社に送り、B社で異なった要求記述ツールにインポートする場合、インポート時に情報が失われるかもしれない。
仕様交換するパートナーは、交換を行う前に、利用する要求記述ツールとツールの能力に同意しなければならない。ReqIFは、要求記述ツールで実装されるコンセプトを幅広く捉えている。各要求記述ツールでは、フォーマットされたコンテンツをどのように表現するか、また特定のキャラクタ(※文字の強調表現のことと思われる)をどのように扱うかで、差異が生じるのだ。
■そのために、ReqIFでは、フォーマットされた属性値として「簡略化(isSimplified)」というフラグのメカニズムを提供すること。8節や10.8.20を参照のこと。通常、要求仕様とすべての属性がエクスポートされるが、isSimplified=trueの場合、属性のエクスポートを行わない仕組みのようだ。それによって変換文書のサイズも小さくなるし、エクスポート／インポートも高速化できるということだと思われる。※ただこのあたりのメカニズムはちょっと難解な感じがする。まだ、なぜisSimplifiedが必要かがはっきりとは分かっていない。次回までに勉強しておこう。
■各要求記述ツールでの個々の機能を大切にするために、ReqIFでは、ツール拡張のコンセプトを提供すること。詳細は9.1.4を参照のこと。ReqIFToolExtensionというクラスで実現するようだ。

今日はここまでとしておく。

8章以降は以下のような構成だ。8章では要求交換プロセスがアクティビティ図に沿って解説されている。9章、10章はクラス記述だ。11章はXMLスキーマの説明のようだ。次回に見てみたい。