ICTソリューション総合誌　月刊ビジネスコミュニケーション

ホーム >  要求工学 >  2008年8号 >  第46回：アクタ関係から見るユースケースと要求獲得

要求を獲得しようとユースケース図を描いて顧客に見せたところ、わら人形を描いて持ってきてどうするつもりだと叱られたという話を聞いた。ご存知だと思うが、わら人形と言われたのは丸印「○」と漢字の「大」に似た線を組み合わせて人の形を表現するアクタの絵のことだ。

ユースケース図はUML（Unified Modeling Language）で標準化されているとは言っても、システム開発の現場で使おうとすると、この話のように、扱い方が難しい面もあるのも事実である。顧客とのコミュニケーションにおけるユースケース図の活用法についてはまだ十分に確立しているとは言えないようである。ところでユースケース図は要求を獲得する手段の一つではないのか？ユースケース図を使う目的はそもそも何であるのか、という基本的な問いに立ち返らないといけないのではないか？その根本的な目的に対してユースケース図が果たして本当に必要なのか？

今回は、ユースケース図が表す内容をアクタ関係という視点から整理することで、顧客とのコミュニケーションを改善する手法を紹介する。なおユースケースについてご存じない方は、すでにたくさんの教科書が出ているが、筆者も文献[1]で解説したので参照していただきたい。

要求獲得で用いる表現方法

要求獲得では、まず対象世界を理解した上で、システム要求を獲得・選択する[2]。

対象世界の理解段階では、リッチピクチャ、CATWOE記述[2][3]、リソースモデル（クラス図）、コンテクスト図、ユースケース図、状態図、マインドマップを作成する。

システム要求の獲得・選択段階では、ゴール指向分析図、シナリオ、ユースケース図、ミスユースケース図、要求機能カードを作成する。トローリング[4]では獲得した要求機能を帳票形式で記述するカードのことをスノー・カードと呼ぶ。要求獲得技術で用いられるこれらの生産物を表１に示す。この表では要求獲得生産物を関係型と列挙型に分類している。

リッチピクチャ、マインドマップ、カードを列挙型として、それ以外は関係型にした。リッチピクチャでは、様々な観点から解決すべき課題を図で分かりやすく記述しようとするものだが、結局は課題を収集して列挙している。マインドマップも中心的な要求や課題を図の中央に置き、それから派生する次の課題をその周辺に配置し、この手順を繰り返しながら課題を段階的に具体化していく。出来上がったマインドマップの絵が何を表現しているかといえば、階層的に列挙された課題の集まりである。カードも同じように要求を個別的に記述して列挙することができる。

以下では関係型の要求獲得生産物に対してアクタ関係がどのように対応するかを考える。

アクタ関係表

アクタ間の関係を表すN行N列の表をアクタ関係表という。アクタ関係行列[5][6][7]とも言うが、ここでは分かりやすくアクタ関係表ということにする。

さてアクタ関係表の対角要素にはアクタi自身の要求やゴール（目標）、タスク、リソースを記述する。それ以外の行列要素には、アクタiからアクタjに対する要求やゴール（目標）、タスク、リソースを記述する。

本連載でも紹介したように、アクタ関係表により代表的なゴール指向要求モデルであるi*フレームワークを記述できることが分かっている[5][6]。

以下では、要求獲得技術で使用されるこのような多種類の生産物の中で、特にユースケースとアクタ関係表との関係について解説する。

ユースケース

ユースケースでは、ビジネスのライフサイクルに関してアクタと外部や他のアクタとの相互作用を記述する。ユースケースの事前条件と事後条件はアクタ自身の条件だから、対角要素に記述する。ユースケースの基本系列と代替系列に含まれる相互作用は、アクタ間の関係として記述する。これにより、ユースケースをアクタ関係表で表現できる。

文献[1]にある「酒の注文受付ユースケース」をユースケース図で図１に示した。ユースケースはアクタ間の相互作用を記述する楕円である。たとえば「酒の注文を受付ける」ユースケースは、顧客と受注担当者の相互作用である。また、システムの範囲を矩形で囲むことになっている。システムもアクタであると考えられるが、ユースケースを含むシステムについてはこのように矩形で囲むのである。一方、外部システムなどのようにその内部を記述する必要がない場合にはアクタとして記述する。図１では、在庫管理システムの内部に酒の「在庫量を知る」と「酒の在庫量を更新する」という２つのユースケースが記述されている。

図１のユースケースをアクタ関係表で記述した例を表２に示す。ここで◆記号によりタスクを示した。在庫管理システムや配送担当の行に何も記述されていないのは、配送結果についての手続きがこのユースケースの範囲外だからである。アクタ関係表では、複数のユースケースを統合的に記述できることが分かる。また、ユースケース全体での抜けや漏れがないことを保証するためにアクタ関係表が役立つと思われる。

ミスユースケース

システムに脅威をもたらすアクタ（ネガティブアクタ）を、記述できるように拡張したユースケースをミスユースケースという。ユースケースに対して脅威となるミスユースケースと、そのミスユースケースによる脅威を緩和する対策としてのユースケースを繰り返し対応付けて記述していくことにより、システムの脅威を分析することができる。

ミスユースケースをアクタ関係表で表現するためには、次の２点に留意する必要がある。

• （１）ミスユースケースとユースケースとの脅威と緩和という関係をアクタ関係表でも対応付けて記述する。
• （２）ネガティブアクタを明記できるようにする。

文献[1]で紹介されている金庫に対するミスユースケースを、アクタ関係表で表現した例を表３に示す。

この表では脅威と緩和策との関係を点線で示した。点線の始点が緩和策で、矢印の付いた終点が緩和される対象としての脅威である。また、アクタの背景色を灰色にすることでネガティブアクタを示した。

アクタ関係表を用いた要求獲得手法

前述したように、関係構造を記述するための要求獲得モデルをアクタ関係表で表現できることが明らかになった。表という誰でも理解できる言語によって、要求者と要求分析者がコミュニケーションできるようになる。要求者が、モデリングのための技術を学ぶ必要がなくなる可能性がある。ただし、これまでの要求獲得モデルが不要になるわけではない。要求分析者はアクタ関係表を要求者に提示して、その結果を多様な要求獲得モデルで表現することでより深く効果的な分析ができるからである。コミュニケーションに起因する要求獲得の欠陥を防ぎ、要求獲得モデルの習得コストを軽減することが、アクタ関係表による要求獲得手法の目的である。

アクタ関係表を用いた要求獲得手法を、アクタ関係表によって表現すると表４のようになる。ここで記号□により要求者と要求分析者とで交換される資源としての情報を示している。要求者の目的は、アクタ関係表を理解し確認することである。要求分析者の目的は、アクタ関係表を理解し、ユースケースなどの要求獲得モデルを用いて分析し、アクタ関係表に翻訳することにより要求者の確認を得て、要求を獲得することである。要求者から見た要求分析者への期待は、対象世界を理解して要求を獲得してもらうことである。要求分析者から見た要求者への期待は、獲得したと要求分析者が考える要求を確認し、選択してもらうことである。

アクタ関係の位置づけ

上述したようにアクタ関係が複数の要求獲得モデルで記述されている。この理由はParnasの変数モデルで説明できる[4]。変数モデルでは、利用環境にある環境変数が入力デバイスによってシステムへの入力データに変換される。入力データがシステムによって処理され、出力データが出力デバイスに入力される。出力デバイスがシステムの出力データを用いて、制御変数を利用環境に返されることで利用環境を制御する。

利用環境がアクタに対応すると考えると、利用環境からのイベントによってシステムの機能が実行される。その結果がアクタに返されることになる。

つまり、図２に示すようにParnasの変数モデルとアクタ関係を自然に対応付けることができるのである。

図と表

図の方が理解しやすいことも多い。しかし図だけでは断片的な記述になりやすいし、網羅的に分析するのが難しいという面もある。また、同じ内容なのに一見すると異なる図のように見える場合もある。２つの図が同じ内容を表現しているかどうかを比較することも、かなりやっかいになることであろう。

これに対して、表であれば比較するのも容易である。しかし理解しやすいのはどちらかといわれると、いくつかの意見があると思われる。図に習熟した人は、図の方が簡単に書きやすいし理解しやすいというだろう。図に習熟していない人は、図の表記法そのものの理解でつまずく恐れが大きくなることだろう。また冒頭で紹介したように、表記法を心理的に受付けない人もいるかもしれない。逆に、表はどうしても好きになれないという人もいるかもしれない。

アクタ数や関係数が多くなればなるほど、図が複雑になり編集や一貫性の管理は難しくなると思われる。表の場合には要素は増えるかもしれないが、一覧性や拡張性の点で図に比べれば編集や一貫性の管理は容易であろう。

アクタ数は少ないが、関係数が多い場合にも、表の方が記述しやすいと思われる。たとえば、２つのアクタ間に多くの関係がある場合を考えれば、関係ごとに図の要素を記述するのはやっかいだと気づく。表であれば、枠の中に関係名を列挙していくだけでよい。

アクタ数は多いがアクタ関係が少ない場合、表では関係が記述されていない空欄が多くなり、スペース効率が悪くなる。図の場合は、関係するところだけしか記述しないから理解しやすいし、スペース効率も良いといえる。

アクタと関係の数がともに少ない場合は、図でも表でもあまり差がないと思われる。

まとめ

今回は、アクタ関係表に基づく要求獲得手法を紹介した。この手法の良い点はユースケース図などを学ぶことなく、誰でも理解できる表を用いて要求獲得のためのコミュニケーションができる点にある。もちろん、ユースケース図を組み合わせることもできる。図と表をうまく活用することで、双方を補完しあうことができれば素晴らしい。

今後、要求獲得コミュニケーションを改善するための要求工学手法が活発に研究開発されることを期待したい。

---

■参考文献

• [1] 山本修一郎，UMLの基礎と応用第２回，ユースケース，http://www.bcm.co.jp/site/2002/uml/uml2.htm
• [2] 中谷多哉子，要求獲得技術，情報処理，vol.49, No.4, 2008, pp.357-363
• [3] 山本修一郎，要求工学，ソフトシステム方法論再考，http://www.bcm.co.jp/site/youkyu/youkyu20.html
• [4] Robertson, S. and Robertson, J., 要件プロセス完全修得法，三元社, 2002
• [5] 山本修一郎，要求工学，アクタ関係分析，http://www.bcm.co.jp/site/youkyu/youkyu39.html
• [6] 井部己文、山本修一郎、佐藤友合子，アクタ関係行列を用いたiスターフレームワーク作成方法の提案，第158回 ソフトウェア工学研究会，2007
• [7] 山本修一郎，井部己文，佐藤友合子，アクタ関係に基づく要求獲得に関する一考察，電子情報通信学会，知能ソフトウェア工学研究会，2008
• [8] Parnas, D.L. and Madey, J., Functional documentation for computer systems. Science of Computer Programming, 25(1):pp.41-61, 1995.