前回、要求の曖昧さとアクタに着目して要求の曖昧さを検出する手法を紹介した。今回はアクタ間の依存関係を分析するにはどうすればいいのか?ということについて考えよう。
さらにアクタ関係分析に基づいて、代表的なゴール指向分析手法であるi*フレームワークの戦略依存図を作成する手法を紹介しよう。
アクタ関係
前回述べたように、情報システムを取り巻く関係者としてのアクタは多様である。情報システムの利用者や情報システムそのものもアクタであると考えることもできる。このようなアクタ間の関係を分析するにはどうしたらいいのだろうか?
以下では、アクタ間の関係を表で分析する簡単な方法を紹介する。ここで扱うアクタ間の関係は、情報システムや人間活動で必要となる「サービスの依頼と提供」についての期待という基本的な関係である。
アクタは、あるサービスの提供者と受益者という2つの側面を持つと考える。そうすると、異なるアクタ間にどのようなサービスの可能性があるか、あるいはまた、そのサービスの提供者と受益者はどちらのアクタなのかということを分析することができることが分かるだろう。
また、アクタ自身はなぜアクタ関係を必要とするのだろうか、ということについても分析する必要があることに気づくだろう。つまりアクタの目標である。アクタが何か達成したい目標を持つから、そのために他のアクタに対してサービスを提供したり、他のアクタからサービスを受けたりするのである。換言すると、アクタのフロントルームとバックルームを識別するということである。アクタが最も強みとしていて、自分でやるべき価値のある仕事がフロントルームである。これに対して、必ずしも自分でやらなければならないことではない仕事がバックルームである。バックルームの仕事は、それを得意とする他のアクタに依頼すればいい。これは企業が何に集中し、何を外部に委託するかという問題と同じである。アクタがすべきことと、他のアクタに依頼することを明確に定義することが重要だ。
つまり、アクタの目標を明らかにすることは、他のアクタとの関係を明らかにすることと表裏一体になっているということが分かる。
アクタ関係の分析例
アクタ関係に着目することで、どんな要求記述の曖昧さが指摘できるかを具体的に示すために、次のような要求記述のアクタ関係をレビュしてみよう。
【要求記述例】商品販売の販売管理サービスのシナリオ
- (R1)顧客が出庫を依頼する
- (R2)在庫を確認する
- (R3)在庫不足なら不足品を発注係に発注する
- (R4)在庫があれば倉庫係に出庫を指示する
- (R5)倉庫係が出荷を確認する
- (R6)在庫を更新する
- (R7)顧客に請求書と納品書を提示する
- (R8)顧客が料金を支払う
【アクタ関係分析例】
R1:顧客がアクタである。しかし、出庫を依頼するためのアクタが不明である。この不明なアクタをシステムだと仮定する。R1から次の2つのアクタを抽出した。
A1:顧客
A2:システム
また、次のアクタ関係を抽出した。
D1:出庫を依頼する(受益者:A2、提供者:A1)
R2:誰が誰に「在庫を確認する」かが不明である。在庫は倉庫にあると考えて、倉庫係をアクタとすると、システムが倉庫係に在庫を確認することになる。R2から新たに次のアクタを抽出した。
A3:倉庫係
また、次のアクタ関係を抽出した。
D2:在庫を確認する(受益者:A2、提供者:A3)。
R3:発注係が新たなアクタである。不足品を発注するアクタが不明なので、システムであると仮定する。R3から新たに次のアクタを抽出した。
A4:発注係
また、次のアクタ関係を抽出した。
D3:不足品発注を指示する(受益者:A4、提供者:A2)。
R4:出庫を指示するアクタが不明であるため、やはりシステムであると仮定する。R4には新たなアクタは出現していない。次のアクタ関係を抽出する。
D4:出庫を指示する(受益者:A3、提供者:A2)。
R5:新たなアクタは登場しない。また、アクタ間の関係も登場しない。倉庫係の仕事として次を抽出する。
D5:出荷を確認する(A3)。
R6:在庫を更新するのは在庫を持つ倉庫係であると考える。この場合にもアクタ間の関係は登場しない。倉庫係の仕事として次を抽出する。
D6:在庫を更新する(A3)。
R7:請求書と納品書を提示するアクタが不明である.請求書と納品書は品物が配達されないと顧客に提示できないから、たとえば配達係が顧客にこれらを提示すると仮定する。新たなアクタとして配達係を抽出する。
A5:配達係
また、次の関係を抽出する。
D7:請求書を提示する(受益者:A1、提供者:A5)。
D8:納品書を提示する(受益者:A1、提供者:A5)。
R8:顧客が料金を支払う対象としてのアクタが不明であるため、アクタとして出納係を抽出する。
A6:出納係
また、次の関係を抽出する。
D9:料金を支払う(受益者:A6、提供者:A1)。
この結果を表で整理すると、表1のようになり、この表をアクタ関係表と呼ぶ。
アクタ関係表の構成
アクタ関係表の構成要素は、次の3つである。
対角要素
表のI行I列要素には、アクタ自身の達成すべき目標を記入する。
たとえば、倉庫係の目標「出荷を確認する」ことが、表1の倉庫係の行と列に対応する升目に記入されている。
上三角要素
表のI行J列要素(I<J)には、受益者側アクタIが提供者側アクタJに期待するサービスを記入する。
たとえば、システムが倉庫係に期待することとして「在庫を確認する」ことが、システムの行と倉庫係の列が交差する升目に記入されている。
下三角要素
表のI行J列要素(J<I)には、提供者側アクタIが受益者側アクタJから期待されるサービスを記入する。この場合、受益者と提供者が上三角要素と逆転していることに注意する。
たとえば、倉庫係がシステムに期待することとして「出庫を指示する」ことが、倉庫の行とシステムの列が交差する升目に記入されている。
アクタ関係表を用いたレビュ
さて、このようなアクタ関係表を見て何が分かるだろうか?
まず、アクタ間の関係が疎であることに気づくのではないだろうか?
例題の要求記述だけだとなんとなく機能が列挙されていていいような気になるが、アクタ関係表を見ると、もっと必要な関係があるのではないかと心配になりそうである。
実はこれが重要なポイントだ。アクタ関係表を記述することで、アクタやアクタ間の依存関係の漏れを調べるのに役立つ。
たとえば、出納係の列が何も記入されていない。これは出納係が顧客から徴収した金額をどこで管理するのか不明であることを意味する。
一方、配達係の行にも何も記入がない。これは配達係が他のアクタに期待するサービスが抜けていることを示している。たとえば、倉庫係がシステムから出庫を指示された後で配達係りに配達を指示することが抜けているのではないだろうか?もしそうなら、配達係の行と倉庫係の列が交差する升目に「配達を指示する」という記述が必要となる。
また各アクタに対応する対角行列に記述が抜けている。これはアクタがなぜ必要なのか、アクタの活動の達成目標が漏れていることを示している。
このようにアクタ関係表を記述することで、アクタやアクタ間の関係に由来する要求の漏れを防ぐことができるはずである。
アクタ関係表とi*フレームワーク
実は、アクタ関係表は、本連載でもたびたび紹介した代表的なゴール指向要求工学手法であるi*フレームワークの戦略依存図(Strategic Dependency Diagram、SD図)に変換できる。
直感的に言えば、アクタ関係表のアクタをSD図のアクタとし、アクタ関係表の升目の中の記述をSD図のソフトゴールに対応付ければいい。
たとえば、表1のアクタ関係表が図1のSD図に対応することは明らかであろう。詳細な変換手続きについては、文献[4]を参考にしていただきたい。なお、文献ではアクタ関係表のことをアクタ関係行列ARM(Actor Relationship Matrix)と呼んでいる。アクタ関係表は筆者らがi*フレームワークのゴール図を作成する上で様々な課題があることに気づいたことから考案した方法である。つまり、ゴール図を構成する上で本質的な要素だけを抽出して、それを特別な図ではなく、誰でも知っている表を用いて表現したのである。なおi*フレームワークの課題の詳細については文献[3]を参考にしていただきたい。
図1 i*フレームワークのSD図
表を用いることによって、アクタとアクタ間の依存関係についての網羅的なレビュが可能になっただけでなく、抽出作業を容易化できるようになった点は大きな副産物であったと思う。
まとめ
今回は、要求の曖昧さと要求レビュに役立つアクタ関係表について説明した。前回、前々回も指摘したとおり、要求仕様の曖昧さについては古くから問題だとして指摘されてはいるが、現実には強力なモデリング手法が現場レベルで浸透していない。しかし、今回紹介したような手法であれば、誰でもすぐに使おうと思えば使うことができる簡単で強力な手法である。今後もこのような現実的なアプローチによって、要求の曖昧さを低減する手法の開発が望まれる。
たとえば、前回紹介した要求記述の構成要素が実はアクタ関係に対応している。前回紹介した方法では、要求をアクタ、アクタの状況、イベント、入力、動作、アクタに及ぼす結果に基づいて明確に記述する。これは、アクタ関係を具体化しているのと同じである。つまりアクタとアクタ間の関係を分析できれば、アクタが他のアクタに対する期待としての要求が、どんな状況で、どのようなイベントを契機として発生し、そのイベントではどのような入力があり、それに基づいてどのような処理が必要となるのか?その結果として何が出力され、アクタの状況はどのように変化するのか?これらを明確に記述することができれば、要求の漏れを防ぐことができるようになる。アクタやアクタ間の関係に漏れがあれば、必要な要求を抽出できないことは明らかである。現在、筆者らはこのような観点から要求定義・管理方法の研究を進めている。
先日、名古屋で開催されたソフトウェア工学の国際会議(APSEC)[5]で何人かの研究者と話したが、要求工学の分野で、要求レビュの研究がほとんどないので、新たにこの分野の研究を立ち上げるべきだということで意見が一致した。アクタ関係に着目した要求レビュの研究が進展することを期待している。
■参考文献
- [1] i*homepage:http://www.cs.toronto.edu/km/istar/
- [2] 山本修一郎 著:~ゴール指向による!!~
システム要求管理技法、ソフトリサーチセンター、2007 - [3] 井部己文、山本修一郎:利用シーンを考慮した、iスターフレームワークの適用上の課題、第157回ソフトウェア工学研究発表会、2007
- [4] 井部己文、山本修一郎、佐藤友合子:アクタ関係行列を用いたiスターフレームワーク作成方法の提案、第158回ソフトウェア工学研究発表会、2007
- [5] http://apsec2007.fuka.info.waseda.ac.jp/
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要