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

OMGが公開している要求交換フォーマット(ReqIF:Requirements Interchange Format)について調べてみた。以下のURLからダウンロードしたReqIFの仕様書を読んでいるところだ。2011-04-02にリリースされている。
http://www.omg.org/spec/ReqIF/1.0.1/

以下の記事も参照のこと。

ReqIFは、要求を記述したファイルをXMLの統一規格で定義して、企業間やツール間で扱いやすくしようというものだ。これまで「要求仕様」は、WORDやEXCELで記述したり、リーズナブルなツールならスパークシステムズのEA、チェンジビジョンのastah*などで記述していたのではないだろうか。最近では、バリューソースの「要件のツボ」などもある。そのほかにもいろいろあるだろう。これらのツール間で相互に、記述した要求仕様をReqIFというフォーマットでインポート／エクスポートできるようにしようというコンセプトだ。電子商取引で使われるEDI(Electronic Data Interchange)のフォーマットのようなものと言えるだろう。ReqIFは、所有権のないオープンな交換フォーマットだ。誰でも実装できる。

ネットで調べてみると、スパークシステムズでは、すでにReqIFの実装を開始検討しているそうだ。チェンジビジョンのastah*やバリューソースの要件のツボでの対応は不明だ。またReqIFをEclipseのEMFベースで作ろうという活動も進んでいるようだ。Eclipse-based Requirement Modeling Framework(Eclipse RMF)と呼ぶらしい。ReqIFは、もともと自動車関連のモデルを扱いたかったようだが、ビジネス全般に汎化させたものであるようだ。

[2011/08/15追記] 一般にUMLでは要求を扱いにくいが、要求を扱えるように拡張されたSysMLなら適している。SysMLが扱えるモデリングツールがReqIFには対応しやすいと言えるだろう。スパークシステムズのEAや、Eclipse RMFでの実装に期待できる。

ちょっと余談だ。ReqIFが普及するためには、まずBABOKの普及が必須だろうか。これは半分冗談だが、ある程度は関連もあるだろう。それにしても、最近、いろいろな視点から上流が取り上げられていると感じる。BABOKやReqIFもそうだし、神崎さんの「要件のツボ」もそうだ。私もちょうどJSTQB Advancedに関わっていたが、テストにおいてもWモデルやSTEPのような上流から開始するテスト設計が重視されてきているようだ。rabbit2goさんの最近のブログでも、上流と下流という表現が変なゆがみを生じさせてきたと言及されていたばかりだ。属人的で、上流階級的で、コードもWORDやPPTでさえ満足に書けない人たちで占められてきたいわゆる「上流」に、やっと、確かなエンジニアリングが浸透しようとしているのだろう。これが実現できるのも、これまで下流といわれながらも確実に体系的に創造を繰り返してきた人たちが上流に関われるようになった恩恵とも言えそうだ。(※ちょっと言い過ぎたかも)

話を戻す。ReqIFの普及のための第1ステップは、やはりツールベンダーがモデリングツールや要求記述ツール(＝要求オーサリングツール)に、ReqIF形式のXMLファイル(＝交換XML文書)をインポート／エクスポートできる機能を提供してくれることだろう。第2ステップは、WORDやEXCELで記述した要求仕様をReqIF形式に変換したり、ReqIF形式をWORDやEXCELに変換できるツールが登場することだろう。

少しReqIFの仕様書を読んでみる。1章から6章まではコンセプトの背景や用語の説明などだ。7章「概要とユースケース」からが仕様の説明になっている。さすがOMGなので、仕様の大半はUMLで記述されているので、直感的に分かりやすい。

    7.1 要求記述ツールが情報をどのように扱うのか？ 
    7.2 ReqIFが要求記述ツールからの情報をどのように扱うのか？
    7.3 ReqIFがさまざまなツールでどのように扱われるか？
    7.4 交換シナリオ
        7.4.1 アクター
        7.4.2 第1交換シナリオ (片道)
        7.4.3 第2交換シナリオ (往復)
    7.5 詳細ユースケース
        7.5.1 ユースケース図
        7.5.2 ユースケース記述

順序が前後するが概要を理解するために、まず「7.4 交換シナリオ」と「7.5 詳細ユースケース」を見ておくといいだろう。大したことは書かれていないが、こういったことを確実に定義しておく姿勢は必要だ。

7.4.1 アクター

アクターは、要求記述ツールと、そのツールの利用者の2つのみだ。

「要求記述ツール」は、要求を生成／修正する機能を持つツールであり、EA、astah*、要件のツボといったモデリングツールをイメージすればよい。勿論、ReqIFが扱えるように拡張されたツールでなければならない。「利用者」は、要求記述ツールから要求仕様を交換XML文書にエクスポートしたり、交換XML文書を要求記述ツールにインポートできる人だ。また、利用者は、要求記述ツールで仕様を変更できる必要もある。

7.4.2 第1交換シナリオ (片道)

シーケンス図が描かれている。利用者Ａが要求記述ツールＡから要求仕様を交換XML文書にエクスポートし、それを利用者Ｂに渡し、利用者Ｂが要求記述ツールＢに交換XML文書をインポートする流れだ。

7.4.3 第2交換シナリオ (往復)

これもシーケンス図が1枚。第1交換シナリオ (片道)までの流れは同じだ。それに引き続いたシナリオが記述されている。利用者Ｂは要求記述ツールＢで要求仕様の変更を行う。変更後に、利用者Ｂが要求記述ツールＢから要求仕様を交換XML文書にエクスポートし、それを利用者Ａに戻し、利用者Ａが要求記述ツールＡに交換XML文書をインポートするという流れだ。

7.5.1 ユースケース図

3つのユースケースが記述されているだけだ。

UC-1: 要求仕様をエクスポートする
UC-2: 新しい要求仕様をインポートする
UC-3: 要求仕様を変更する

3つのユースケースごとにユースケース記述が細かく書かれている。メインシナリオだけ説明しておけば十分だろう。

「UC-1: 要求仕様をエクスポートする」

(1) 利用者は、エクスポートしたい要求仕様を特定し、エクスポート開始を指示する。
(2) ReqIFツールは、各仕様を1つまたは複数の交換XML文書にエクスポートする。
※エクスポートされた交換XML文書には、要求、タイプ、属性を含む。オプションとして要求間のアクセスポリシーの関係を含む。関係はグループ化されてもいい。
※要求仕様のすべてをエクスポートできるだけでなく、要求仕様の一部分だけをエクスポートできる機能があってもよい。

「UC-2: 新しい要求仕様をインポートする」

(1) 利用者は、ReqIFツールでインポートしたい交換XML文書と、要求記述ツールに作成されたインポート先を特定し、インポートを開始する。
(2) ReqIFツールは、交換XML文書を要求記述ツールにインポートする。

「UC-3: 要求仕様を変更する」

(1) 利用者は、ReqIFツールで変更したいソースである交換XML文書と、変更したい要求記述ツール内の仕様を特定し、変更を開始する。
(2) ReqIFツールは、交換XML文書からの情報を要求記述ツール内の既存の要求仕様にマージする。

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

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

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

Permalink | コメント(2) | トラックバック(6)

コメントを書く

good_way 2011/09/19 14:05 ReqIFを初めて知りました。　有益な情報ありがとうございます。今後の投稿にも期待します。

tacohachi 2011/09/19 21:12 good_wayさん、コメントをありがとうございます。
「要件のツボ」もReqIFフォーマットのインタフェースをぜひ提供ください。ReqIFのモデルもXMLのスキーマもかなり分かってきました。基本部分のみの実装なら難しくはないでしょう。難しいのは各社ともおそらくツール依存の部分を結構盛り込んでくると思われので、当面は個々のツールがそれらをある程度吸収してやる必要もありそうです。まったく矛盾する話なのですが、それが現状のように思われます。