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

2011年09月11日(日)

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

ReqIFの内部構造について、最後の解説だ。この話題にどれだけの方が関心あるかは分からないが、自身の学習のメモとして残しておきたい。以下の記事も参照のこと。

ReqIFのモデルで理解しにくい部分が3つくらいある。それを説明しておきたい。

グローバル参照とローカル参照
代替ID
アクセス制限

グローバル参照とローカル参照

ReqIFモデルの定義要素や要求、関係、仕様、関係グループなどの要素はidentifierを属性として持つ。いわゆるIDのことだが、このIDには全世界ユニークなものと、ローカルにユニークなものがある。すべて全世界ユニークなIDでいいのだが、これを表現するためにはかなりのバイト数が必要で、しかも暗号的なものとなってしまい、利用者が明示的に扱うには不便なものになってしまう。だから全世界ユニークなIDは必要最小限な範囲に留めるべきであろう。ローカルで十分であれば、利用者が直感的に意味とユニーク性を識別できるネーミングをidentifierとして利用できる。

ReqIFでグローバル参照を明示している部分は2箇所のみである。

1つは、要求間の関係(SpecRelation)で示される2つの要求(SpecObject)を特定する場合
もう1つは、仕様関係グループで示される2つの仕様(Specification)を特定する場合

このことは、つまり、要求(SpecObject)と仕様(Specification)のidentifierには全世界ユニークなIDが望ましいことを言っている。全世界ユニークなIDでなければならないということではないはずだ。非常にローカルな利用の場合には、必要ない。ネット上でいくつかのReqIFフォーマットのサンプルを覗いてみたが、要求(SpecObject)のidentifierには全世界ユニークなIDが使われているが、仕様(Specification)のidentifierにはローカルな意味のある字面が用いられているものしか見当たらなかった。このことは、現状では、要求(SpecObject)の再利用にとどまっていて、仕様(Specification)レベルでの再利用には到っていないということかもしれない。※ちなみにReqIFでの仕様(Specification)とは、要求(SpecObject)間の関係を階層化したものであり、システム要件やシステム仕様といったものの総称ではないので注意のこと。

代替ID (AlternativeID)

ReqIFモデルでの最大の難関は、代替ID(AlternativeID)だ。実は、私もまだ十分に理解できていない。その前提の上で説明してみたい。

前述の「グローバル参照とローカル参照」で示したようにReqIFモデルの定義要素や要求、関係、仕様、関係グループなどの要素はidentifierを属性として持っている。いわゆるIDのことであり、このIDには全世界ユニークなものとローカルにユニークなものがある。これらidentifierを個々の要求に対する要求属性の1つである「要求ID」と混同してはいけない。identifierは要求(SpecObject)のみならず、定義情報やその他の仕様要素の識別子となる。紛らわしいのだが、このidentifierを要求(SpecObject)の明示的な「要求ID」(つまり、ツール上で表現されるREQ-1,REQ-2といったものなど)として利用することも可能ではあるが、そういった利用例は見当たらない。

ReqIF仕様書では「交換文書内の情報要素は全世界ユニークなIDであるidentifierで識別される。このidentifierは情報要素の生成時に割り当てられる。割り当てられた後で、identifierは変更されてはいけないし、他の情報要素で再利用されてもいけない。これらのidentifierは、いくつかの交換文書を横断的に、情報要素のユニーク性を識別できる。」と書かれている。全世界ユニークなIDとなっているが、ローカルにユニークなものでも構わない。ローカルにユニークといっても、企業がパートナー間でユニーク、企業内でユニーク、要求管理ツール内でユニーク、交換文書内でユニークなど、いろいろなレベルがあるだろう。ReqIFはユニーク性のレベルをガイドしてくれるものではない。全世界ユニークなIDが望ましいとしか言っていない。全世界ユニークなIDと、分かりやすく扱いやすいローカルなIDの妥協点を見出すことが、ツールベンダや利用者に必要となる。

ReqIFでは、定義要素や要求、関係、仕様、関係グループなどの要素に対して、ツール固有の代替ID(AlternativeID)を付与することができる。ReqIF仕様書では「パートナー側の要求記述ツールがオリジナル側で生成された要素のidentifierを扱うことができない場合、パートナー側のツールでは、オリジナルのidentifierに対してツールに固有な代替のidentifier(AlternativeID)を付け足しすることができる。」と書かれている。AlternativeIDはツールで1つしか添えることはできない。

この「オリジナル側で生成された要素のidentifierを扱うことができない場合」というのが難解なのだ。参照しているidentifierの実体がないという場合（つまり、オリジナル側で生成されたidentifierをパートナー側で解決できない場合）もあるし、実体はあるが編集権限のない場合もある。実体があって編集権限もあれば、勝手に編集してよいので問題はない。

またパートナー側の要求記述ツールで、ツール固有の管理手順やルールに従って、それぞれの定義要素や仕様要素にIDを割り振りたいという用途もあるだろう。その場合にも代替IDを利用できそうだ。代替IDは、ツール内で閉じた、つまりツール内でローカルに認識できるIDである。

パートナー側の要求記述ツールで修正を加えた定義要素や仕様要素に代替IDを付与することで、オリジナル側のツールにround-tripで戻ってきたときに、その修正をオリジナルに伝達することにも利用できる。削除、変更、新規追加を伝達する手段としても利用できる。(※勿論、推奨される利用方法ではない。変更管理を支援するために代替IDを利用できる可能性があるということに過ぎない。)

ただ残念ながら、ReqIFはそのあたりの具体的な利用方法を全くガイドしてくれていない。代替ID(AlternativeID)という概念があれば、ツール固有のIDを表現できるし、ツール間での整合性を図ることにも利用できるだろうくらいにしか、現時点では判断できない。もう少し、事例を探って学習しておきたい。

要求(SpecObject)に関しては、明示的な「要求ID」として新たな要求属性を利用しなくてもAlternativeIDを利用することもできる。AlternativeIDを利用するべきか、要求属性として追加した「要求ID」を利用すべきかを、ReqIFはガイドしてくれるものではない。ツールベンダや利用者の判断となる。AlternativeIDは、ツール固有、つまりツールに閉じた範囲でしか利用できないが、要求属性として追加した「要求ID」は企業内、企業間でも利用できるので、そのあたりが判断基準となるだろう。

アクセス制限

ReqIF交換文書に記述された情報は誰でも参照できるが、編集して欲しくない情報にis-editable="false"を指定できる。当然、これはツール間でのround-tripを想定している。参照してほしくない情報は、交換文書に出力しなければいいので、編集権限の有無を示すフラグしか存在しない。

制御できる要素は、要求の属性定義(AttributeDefinition)の各属性定義と、仕様の階層構造(SpecHierarchy)の2つである。ReqIFモデルをみていただければ分かるだろう。アクセス制御は以下の3段階で、より細かく設定できる。

各属性定義にはis-editable="false"の指定ができる。これが指定された要求属性はすべて編集できない。交換文書内の該当する要求属性はすべて編集できない。
また、SpecHierarchyにもis-editable="false"の指定ができる。指定された階層の配下にある要求(SpecObject)のすべて(それら要求のすべての属性)は編集できない。
さらに、SpecHierarchyにはeditable-attsというリストで要求属性を個別に指定して、編集不可を回避できる。つまり、部分的に特定の属性ごとに編集可の設定が行える。

ReqIFのアクセス制限は、誰が設定できるとか、誰に対して制限をかけるかを指定する概念ではない。ReqIF交換文書内で制限されていれば、その交換文書を他のツールにインポートしたり、WORD/EXCELに交換出力した後で、利用者の編集操作が制限されることになる。

ReqIFファイルはテキストファイルであり、いくらでも編集できるし、改ざんできる。暗号化やセキュリティ上のことは別のテーマである。round-tripで交換文書が元の要求管理ツールや要求記述ツールに戻ってきたときには、アクセス制限をチェックできるだろうが、それまではほとんど何もできない。WORD/EXCEL上でアクセス制限が表現できたとしても、おそらくいくらでもその情報は変更でき、改ざんできる。ガイドラインで制限することしかできないだろう。

round-trip(往復)やjourney(行き来)ではおかしなことがおきる。ツールAでeditableだったものがツールBでread-onlyになり、再びツールAに戻ってくる。そのあたりの制御がどう実現されるべきなのかははっきりしていない。ツールAに再びインポートすると、その要求は上書きしていいのかどうかが分からない。ツール側でアクセス制限が変更になった要素の扱いが取り決められている必要がある。

以上だ。