ソフトウェア・シンポジウム2017 in 宮崎

ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察‐酒屋倉庫問題の場合‐
岡野道太郎
筑波大学大学院ビジネス科学研究科
okano@gssm.otsuka.tsukuba.ac.jp

要旨

中谷 多哉子
放送大学 情報コース
tinakatani@ouj.ac.jpの一手法である KAOS[1] を用いる．KAOS については２章で詳述するが，簡潔に述べると，KAOS はシステム

本稿は，要求仕様書に書かれるべき，設計・実装・テの目標であるトップゴールからゴールの詳細化を繰り返ストに必要な情報を獲得するためにはどのような手法をすことで要求を獲得する手法である．我々の今までの研用いればよいかの知見を得ることを目標とする．この目

究ではゴールを「状態 P から状態 Q への状態遷移」と標へのアプローチとして，ゴール指向要求分析の一手法し，詳細化手法として，状態遷移を詳細化するマイルスである KAOS を用いる．この手法はシステムの目標でトーン分解 [1] と，状態 Q を詳細化する要素分解 [2] をあるトップゴールから，ゴールの詳細化を繰り返すこと利用してきた．つまり，状態 P は詳細化しなかったが，により要求を獲得する．本稿ではゴール P → Q の詳細化

詳細化する必要がないのだろうかということについて，手法として，状態遷移→部分を詳細化するマイルストー

本稿では考察する．その結果，分解を行わないと依存性

ン分解と，状態 Q を分解する要素分解を用いる．そのに関して問題が生じ，設計に必要な情報が欠けることが際，状態 P については分解していないが，状態 P を分判明したので，依存性に対する提案を行い，「酒屋倉庫問解する必要があるかについて考察した．考察を行うため題」の事例を用いて提案を評価する．に「酒屋倉庫問題」のゴール分解を行った．すると，状本稿の構成を以下に述べる．まず第二章で用語の説明

態Ｐを分解しないと依存性に関して問題が生じることがを行う．第三章で，上述した状態 P の分解について「酒判明した．そこで本稿では状態Ｐの部分を分解し，依存屋倉庫問題」を利用して考察する．第四章では，考察時に性を明記する表記法を提案する．関連研究では本稿の手生じた問題を解決する手法を提案し，その手法を酒屋倉法と他の要求抽出手法との関連について議論し，今後の庫問題に適用する．第五章では，提案手法について考察

研究において本稿で取り上げた達成ゴール以外のゴールする．第六章では関連研究として，本稿と i*[3],UML[4]について述べる．の関連について述べる．第七章では今後の研究について述べ，第八章でまとめる．

1. はじめに

2. 用語の説明
2.1. KAOS について

ソフトウェア開発は，要求分析の後，設計・実装・テストの各工程が続く．そのため要求分析では，設計・実装・テストに必要な情報が獲得される必要がある．このKAOS は，ゴールを要求獲得に活用する，ゴール指「設計・実装・テストに必要な情報」は何であり，その情向要求分析の一手法である．はじめにシステムが満たす報を要求分析の工程で獲得するには，どのような手法をぺきゴールをトップゴールとして１つ挙げ，そのゴール用いればよいかの知見を得ることが本稿の目標である．

を詳細化して，いくつかのゴールに分解し（この「詳細この目標へのアプローチとして，筆者はゴール指向分析化により分解されたゴール」をサブゴールと記す），サ139

SEAソフトウェア・シンポジウム2017 in 宮崎

ブゴールを再度詳細化してサブゴールのサブゴールへ分をまとめてエージェントと記す）が実現できる Single–

解するというように，詳細化を繰り返す．すると，トッ
プゴールでは，多くの人が関わり，実現に複雑な過程をagent goal に分解される．この Single–agent goal は，対象システムのエージェントが実現する場合「要求」とな経るとしても，最終的には１人あるいは１システム（こり，それ以外のエージェントが実現する場合「期待」とれをエージェントと呼ぶ）が満たせる程度のゴールとななる．

る．このとき分解を終了し，末端ゴールをエージェント

つまり，文は意図を含むか否かにより，記述的な「ドに対する要求とする．このようにＫＡＯＳを用いれば，メイン知識」「，システム固有情報」と，規範的な「要求」，要求はゴールの詳細化によって抽出できるが，そもそも，「期待」とに分かれる．よって，「設計・実装・テストに必「ゴールとは何か，「設計・実装・テストに必要な情報は要

要な要求仕様書で表現されるべき文」は，対象システム求だけなのか」，「詳細化はどのように行うのか」についに関する文なので（「期待」を除いた）「要求」，「ドメイては説明していない．そこで，まず，「設計・実装・テスン知識」，「システム固有情報」であるといえる．すなわ

トに必要な情報は要求だけなのか」について説明する．

ち要求以外にも必要な情報はあるが，少なくとも要求は必要であると言えるので，まず要求について分析する．

2.2. 設計・実装・テストに必要な情報と要求の関係

そして「要求」はゴールを分解することによって得られる．次に「ゴールとは何か」について説明する．

「設計・実装・テストに必要な情報」は，要求仕様書に文や図としてまとめられる．図は文章で表現すること

2.3. ゴールとは何かも可能なので，「設計・実装・テストに必要な情報」は文で表現することが可能であるとみなすことが出来る．そゴールとは，Lamsweerde[1] によると，「エージェン

して文を Lamsweerde は図 1 のように分類している [1]．

トの協調によって満足すべき意図を示した規範的な文」であるとしている．ゴールにはいくつかのタイプがある（詳細は「６．今後の研究」にて述べる）が，本稿では達成ゴールを取り扱う．達成ゴールは，振る舞いを表したゴールの一種で，状態遷移の連続であると [1] では定義している．よって，達成ゴールは「状態 P から状態 Q へ状態への遷移が完了している」のように記述できる．このような状態遷移を本稿では P → Q と表現する．P が状態変化が起こる前の状態（本稿では事前状態と呼ぶ），Q は状態変化が起こった後の状態（本稿では事後状態と呼ぶ），→は P から Q へ状態が遷移する過程について表している．なお達成ゴールを [1] では，様相論理を用い
図 1. 文の分類（[1] を元に作成）て P →◇ Q で表現している．本稿ではそこまで厳密な定義をせず，ある状態から別の状態に遷移すれば，その文は意図を含むか否かにより，prescriptive な文と，de-scriptive な文に分けられる．本稿では前者を規範的な文，後者を記述的な文と記す．記述的な文は，自然法則のよ

状態遷移を P → Q と表現し，それを達成ゴールとする．
よってトップゴールも達成ゴールの形式で書かれる．
そして詳細化すると最終的に要求が達成ゴールの形で得うなシステム開発者の意図とは関係なく従わなければなられるが，どのように詳細化したら，要求が得られるからない domain property と，本システム開発上，そのについては説明していない．そこで次に詳細化の方法にようになっているという（例えば，本社は東京にあるなついて述べる．

ど）domain hypothesis がある．本稿では，前者をドメイン知識，後者をシステム固有情報と記す．そして規範

2.4. 詳細化はどのように行うのか的な文はゴールであり，このゴールは多くの人が関わる

Multi–agent goal から，詳細化を繰り返すことにより，一人または一システム（本稿ではこれらの人とシステム140

達成ゴール P → Q の詳細化を，本稿では２つの方法で行う．一つは P → Q のうち，状態遷移（→）を分解SEA

ソフトウェア・シンポジウム2017 in 宮崎

するマイルストーン分解であり，もう一つは Q の部分問題である．酒屋倉庫問題における本稿に関係のある事を分解する要素分解である．

項についてのみ，以下に記載する．

マイルストーン分解は [1] で述べられている．マイル• 酒屋についてストーン分解とは，P から Q への状態遷移が起こる過程において，マイルストーン M の状態を経るのであれ– 酒屋には倉庫係，受付係がある

ば P → M と M → Q に分解できるとする分解法である．
要素分解 [2] は，P から Q への状態遷移が起こったとき，事後状態 Q がいくつかの要素｛Q1 ,Q2 ,・・・Qn ｝か• 入庫について– 倉庫係はコンテナ入りの酒を倉庫に保管し，積ら成り立つとき，状態遷移 P → Q を事前状態 P，事後荷票を受付係へ渡す

状態を各要素として分解する方法である．すると，P →– 積荷票の項目はコンテナ番号と搬入年月，日

Q1 ,P → Q2 ,・・・P → Qn に分解できるが，それだけでは時，内蔵品目と数量の繰り返しである｛Q1 ,Q2 ,・・・Qn ｝という各要素が存在する状態になるだ• 出庫についてけで，それが結合した状態にならないので，｛Q1 ,Q2 ,・・・Qn ｝→ Q という状態遷移も付加することもあるとする– 受付係は出庫依頼を受ける分解法である．例えば，「お皿の上にスパゲティが盛り付けてある」を分解するとき，「お皿がある」「スパゲティ– 出庫依頼を基に倉庫係へ出庫指示書を出すがある」だけでは，お皿の上にスパゲティがあるかどうかわからない．そこで「お皿とスパゲティがある状態か– 出庫指示書の項目は注文番号，送り先名，コンテナ番号，品名，数量であるら，スパゲティをお皿の上に盛り付けられている」とい– 出庫依頼の項目は，品名，数量，送り先名でうゴールを追加して分解する．なお要素分解における要ある

素は，分解時に着目する視点によって様々に変わる．例– 在庫がない場合は依頼者に電話連絡し，在庫不足リストに記載する

えば，ユースケースに着目して，ユースケースごとに分解することも考えられるし，構成部品に着目し，部品ごとに分解することも考えられる．さらに機能に着目し，機能ごとに分解することもあり得る．

– 在庫不足リストの項目は，送り先名，品名，数量である– 空になる予定のコンテナを倉庫係に知らせる

2.5. 詳細化と本稿での考察との関係（出庫指示書に記載）– 倉庫内のコンテナ数はできる限り最小にする

我々は既に，達成ゴールをマイルストーン分解と要素– 出庫指示書の項目は，注文番号，送り先名，コ分解を用いて詳細化し，要求を導き出し，それとドメイ

ンテナ番号，品名，数量，空コンテナ搬出マー

ン知識・システム固有情報をもとに実装が行えるものがクであるあることを，電気工事の事例により示した [2]．
しかしここで疑問がある．状態遷移→と状態 Q は分

なお，「在庫なし連絡」のための計算機プログラムと解したが，事前状態の P は分解する必要はないのだろう

は，本稿では，以下の項目の「在庫なし連絡票」を作る

か．本稿ではその事前状態 P の分解について考察する．

こととする．

• 在庫なし連絡票：注文番号，送り先名，品名，注文数量，不足数量

3. 事前状態 P の分解の必要性「酒屋倉庫問題」による考察

ここで，「帳票出力が行われている」というゴール分解
酒屋倉庫問題とは，情報処理 [5] に記載されている「あを行うと，図 2 のような分解を一例として挙げることがる酒類販売会社」（以下酒屋と記す）における「受付係できる．これ以外の分解方法も可能ではあるが，本稿での仕事（在庫なし連絡，出庫指示書作成，在庫不足リスは問題点が明示しやすいため，この分解を元に議論を進ト作成）のための計算機プログラムを作成する」というめる．

141

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 2. 一般的な帳票作成のゴール分解
ここで図 2 の表記法について述べる．この表記はKAOS を基にしている．すなわち，始めにトップゴー

点により表現が異なる場合がある．このため同じ最終状ルを挙げ，トップゴールをマイルストーン分解か要素分

図 2 に対し，帳票が「在庫なし連絡票」，「出庫指示態のゴールでもラベルの表現が違うことがある．

解を行ってサブゴールを挙げる．この際，マイルストー書」，「在庫不足リスト」であることをトップゴール直下

ン分解を行ったか，要素分解を行ったかについては，注のサブゴールにそれぞれ適用すると，図 3 のようになる．

釈として記述している．さらに各サブゴールに対し，マ

ここで「Ｎ→Ｌ１：在庫なし連絡票の出力項目の求めイルストーン分解または要素分解を適用して詳細なサブ方が決まっている」について議論する．このゴールは事ゴールを導いている．このとき図 2 のように，ゴールと前状態Ｎ，すなわち「帳票出力項目が決まっている」をサブゴールの間にある円と，各サブゴールが線で結ばれ満たしている必要がある．このゴールで示す「帳票」とている場合がＡＮＤ分解，ゴールから各サブゴールに線が出ている（この場合，１本の線の間に１つの円がある）場合がＯＲ分解である．ＡＮＤ分解は，サブゴールの全は「在庫なし連絡票」，「出庫指示書」，「在庫不足リスト」の３つを指し，これらすべてが完了していないと事前状態Ｎを満たしていないことになる．しかし，Ｌ１のてが成立しないとゴールが成立しないものであり，ＯＲ状態「在庫なし連絡票の出力項目の求め方が決まってい分解は，サブゴールの一つが成立すればゴールが成立する」に遷移するためには「Ｍ→Ｎ１：在庫なし連絡票のるものである．ゴールの記号の内部に書かれている文字列をラベルと呼ぶ．本稿では，ラベルの前半にＰ→Ｑ等，状態遷移が始めに記されている．そして，その後に「帳票の要求が抽出されている」などの状態が記されている．
つまり，ラベルの前半にゴールの状態遷移，後半に最終出力項目が決まっている」は満たす必要はあるが，「Ｍ→Ｎ２：出庫指示書の出力項目が決まっている」を満たす必要は必ずしもない．つまり，現状の表記法ではＮ→Ｌ
１を実行するためには，Ｍ→Ｎ１，M →Ｎ２，Ｍ→Ｎ３が必要となってしまっているが，M →Ｎ２，Ｍ→Ｎ３は状態Ｑの状態を表すものとする．したがって，状態Ｐの必ずしも必要ではなく，その分，成立条件が厳しくなっ状態はＰを最終状態に持つゴールのラベルに記されていてしまっている．この問題を以下「問題１」と記す．

る．本来，最終状態が同じゴールの場合，ラベルの後半

また「Ｌ→Ｇ１：在庫なし連絡票のレイアウトが決まっも同じ表現になるはずであるが，同じ状態を指しても視ている」について議論すると，在庫なし連絡票のレイア

142

SEA

ソフトウェア・シンポジウム2017 in 宮崎

図 3. 酒屋倉庫問題のゴール分解ウトを決めるためには，「在庫なし連絡票の出力項目がが成立するためにはＰ→Ｍが成立しなければならない場決まっている」とともに，「在庫なし連絡票を出力するメ合，ゴールＭ→Ｑが達成するか否かは，ゴールＰ→Ｍがディアが決まっている」必要がある（ここでメディアと達成するか否かの結果に影響されるといえる．このようはＡ４の大きさのＰＤＦ等，出力先を示す）．そこで，に，ゴールＭ→Ｑの事前状態の成立が，ゴールＰ→ＭのＬ→Ｇ１のゴールの事前状態としては，「Ｎ→Ｌ１：在庫達成結果による場合，ゴールＭ→ＱはゴールＰ→Ｍに依なし連絡票の出力項目の求め方が決まっている」と「Ｐ存しているといい，この関係を依存性という．

→Ｍ１：在庫なし連絡票を出力するメディアが決まって問題１は事前状態 P を分解しないことにより生ずる問いる」の両方が満たされなければならない．ただし，「Ｐ題であり，事前状態の範囲，すなわち依存性の範囲を広→Ｍ１：在庫なし連絡票を出力するメディアが決まってく取りすぎている問題である．問題２は事前状態を分解いる」はレイアウトを決める直前までに決まっていればしたり，並行処理を認めたりした場合，それを認めなけよいのであって，「Ｎ→Ｌ１：在庫なし連絡票の出力項目れば必ず成立していたが，認めることにより成立するかの求め方が決まっている」と同時並行で行ってもかまわどうか確かではなくなる可能性がある場合の問題である．

ない．一般的に出力先等，大まかな事項を決定してから依存性は，「設計・実装・テストに必要な情報」である．

出力項目等の詳細項目を決めるので，Ｐ→Ｍ，Ｍ→Ｎ，なぜならば，もし依存性の情報がなく要求Ｐ→Ｑが成立Ｎ→Ｌという遷移にしただけであり，順序は必須ではなしているかテストを行おうとすると，事前状態Ｐが成立い．ところが図の表記法だと，同時並行を認めないようしていない状態でテストを行う可能性もあり，その場合に見えてしまい，その分，事前状態の成立条件が厳しく正しく実装されていても，テストに失敗する．したがっなってしまっている．この問題を以下「問題２」と記す．てテストを行う者にとって，テスト対象の依存性は必要

これら問題１，２は依存性の問題といえる．本稿におな情報といえる．
「設計・実装・テストに必要な情報」をいて依存性とは，ゴールＰ→Ｍ，Ｍ→Ｑに対し，Ｍ→Ｑ獲得することが本稿の目的なので，依存性の問題を解決を達成するには事前状態Ｍが成立しなければならず，Ｍしないと，本稿の目的は達成できないことになる．そこ143SEA

ソフトウェア・シンポジウム2017 in 宮崎• Ｌ→Ｑのサブゴールにおいて，このときまでに，各帳票の出力項目とその求め方だけでなく，メディアも決まっていないといけないため，Ｌ⊃Ｌ１等の他で，問題１，２の解決法を次の章で提案する．

4. 提案手法にＬ＞Ｍ１等も加え，Ｌ⊃Ｌ１，Ｌ＞Ｍ１→Ｑ１等とした

ここでは，以下の表記法を提案する．
ゴールＰ→Ｑにおいて

なお，事前状態を分解したとき，その分解した状態が，• （問題１解決のための表記法）事前状態Ｐがいくつかの要素｛Ｐ１，Ｐ２，Ｐ３・・・Ｐｎ｝に分解可能
で，それらの要素の一部が成立すれば事前状態が成他のゴールの最終状態として存在するときは，その状態立したとみなせる場合，事前状態Ｐの後に⊃をつけ，なのでＮ１という状態名を使っている．もし分解されたその要素を列挙することにより，その列挙した状態事前状態が，他のゴールの事後状態にも表れず，初期状が成立すれば，事前状態が成立したとみなす．例え態Ｐでもない場合は，別の状態名をつけ，その状態の内ば，事前状態Ｐが｛Ｐ１，Ｐ２，Ｐ３｝に分解可能

容を注釈に記載する．

名を使う．たとえば，Ｎ⊃Ｎ１→Ｌ１の分解された事前状態Ｎ１は，Ｍ＞Ｐ１→Ｎ１の最終状態Ｎ１と同じ状態で，Ｐ１を満たせば事前状態が成立したとみなせる

5. 提案手法に対する考察

場合は，Ｐ⊃Ｐ１→Ｑと記述する．

• （問題２解決のための表記法）事前状態の分解を認めなければ成立した状態で，事前状態の分解を認めることにより，成立するかどうかが確かではない場

まず，この提案した表記法により，問題が解決したかを確認する．

後に＞をつけ，その状態を列挙することにより，そ• 問題１については，「在庫なし連絡票の出力項目の求め方が決まっている」のゴールはＮ⊃Ｎ１→Ｌ１の列挙した状態が成立しなければ，事前状態が成立となり，このゴールは在庫なし連絡票以外には依存しないものとすることができる．例えば，Ｐ→Ｑが，しなくなっている．すなわち，依存する範囲を的確Ｐ→Ｍ，Ｍ→Ｑと分解でき，Ｐが｛Ｐ１，Ｐ２，Ｐに示していることなり，問題は解決した合や，その成立を明示したい場合は，事前状態Ｐの３｝，Ｍが｛Ｍ１，Ｍ２，Ｍ３｝，Ｑが｛Ｑ１，Ｑ２，Ｑ３｝に分解可能な時，Ｍ⊃Ｍ１→Ｑ１の事前状態• 問題２については，「在庫なし連絡票のレイアウトが決まっている」のゴールはＬ⊃Ｌ１，Ｌ＞Ｍ１→Ｍ１が成立する際に，Ｐ１，Ｐ２が成立する必要がＱ１となり，このゴールは在庫なし連絡票のメディある時（Ｐ３は必須でない）Ｍ⊃Ｍ１，Ｍ＞｛Ｐ１，ア (出力先等）と出力項目の求め方に依存している

Ｐ２｝→Ｑ１と記述する．

ことを明確に示している．すなわち，依存する範囲を的確に示していることなり，問題は解決した

この表記法を基に図 3 を分解すると，図 4 のようになる．

つまり，問題１，２は本提案の表記法により適切になり，本提案によって変わった点は，ゴールラベルの前半に依存性が的確に示せるようになった．本稿のゴール分解記述される状態遷移を表す部分である．

手法は KAOS を基にしているが，KAOS では依存性が明白に示せなかったことは，問題１，２が生じたことか• Ｍ→Ｎのサブゴールにおいて，このゴールはＰ→Ｍと並行して行っても問題を生じないため，Ｍ＞Ｐ→らもわかる．新たに本稿が提案する記法を導入することによって，依存性が明確に記述できるようになった点に

Ｎ１等，Ｐの時点すなわちはじめから実行可能であ

本稿の新規性，有用性がある．

ることを明記した．

ただし，本稿では事前状態Ｐを分解しているが，その• Ｎ→Ｌのサブゴールにおいて，Ｎは，それぞれの帳票に対する事前状態が成立していればよいので，Ｎ際，分解の妥当性は保障していない．つまり，事前状態⊃Ｎ１→Ｌ１等，該当する帳票の状態のみを事前状態Ｐに含まれているかということを保障するのは，その態に挙げるようにした分解を行った者の責任である．

ＰをＰ１，Ｐ２に分解した場合，Ｐ１は，本当に事前状

144

SEA

M>P→N2:出庫指示書の出力項目が決まっている

145

P→M3:在庫不足リストを出力するメディアが決まっているsakaya3 (1/1)

N⊃N1→L1:在庫なし連絡票の出力項目の求め方が決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

N⊃N2→L2:出庫指示書の出力項目の求め方が決まっているN⊃N3→L3:在庫不足リストの出力項目の求め方が決まっている

P→M2:出庫指示書を出力するメディアが決まっている

Ｐ→Ｍ１：在庫なし連絡票を出力するメディアが決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

L⊃L3,L>M3→Q3:在庫不足リストのレイアウトが決まっているL⊃L2,L>M2→Q2:出庫指示書のレイアウトが決まっている

L⊃L1,L>M1→Q1:在庫なし連絡票のレイアウトが決まっている

M>P→N1:在庫なし連絡票の出力項目が決まっている

L→Q:帳票レイアウトが決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

N→L:帳票出力項目の求め方が決まっている

要素分解:帳票{在庫なし連絡票，出庫指示書，在庫不足リスト}

M→N:帳票出力項目が決まっている

マイルストーン分解

M>P→N3:在庫不足リストの出力項目が決まっている

Ｐ→Ｍ：帳票出力するメディアが決まっている

P→Q:帳票の要求が抽出されている

ソフトウェア・シンポジウム2017 in 宮崎

図 4. 提案手法による酒屋倉庫問題のゴール分解

SEA

ソフトウェア・シンポジウム2017 in 宮崎

本稿で行っているマイルストーン分解は，状態遷移にゴール分解を行っている．マイルストーン分解は，振る基づく分解であるが，状態遷移はプロセスによって実現舞いゴールである達成ゴールを分解していることから，されるので，プロセス分解を行っているといえる．また，振る舞いの分解といえる．そして本稿の記述法により振要素分解は，最終状態の構成要素に着目して分解を行っる舞いゴール間の依存性を示すことができるようになっているが，それは構造を分解していることになる．そした．そこで，依存性を辿っていくことにより，一連の振て，「酒屋倉庫問題」の事例では，マイルストーン分解とる舞いの流れを辿ることができる．このような振る舞い要素分解の両方を用いている．したがって，今回の事例の流れを記述した図が「振る舞い図」であり，ＵＭＬ [4]はプロセス分解のみを行っているのでも，構造による分においては，アクティビティ図等が，振る舞い図に相当解のみを行っているのではなく，両方の分解を適切に切する．

り替えることによって分解が実現できているといえる．
一般にシステムは，一連の情報処理プロセスが続いて実要素分解は最終状態を各要素に分解している．その際，行される．この際，各プロセスの入出力データにはデー最終状態のデータ構造に着目し，データを構成する各要タ構造が存在する．よってシステムを分析するには，プ素に分解して，データ構造を表すことも出来る．そのよロセスの分析と各プロセスの入出力データのデータ構造うな構造を表す図には，ＥＲ図やＵＭＬのクラス図等の分析の両方が行える必要がある．マイルストーン分解と構造図がある．

要素分解を適切に組み合わせることにより，このプロセス分析とデータ構造分析が適切に行える．
次の章では，この依存性とプロセス分解を表現する振つまり本稿の表記法は，構造図と振る舞い図の両方をる舞い図や構造による分解を表現する構造図について，１つの図の中に統合している．実際の要求分析は，本稿既存の他の研究と本稿の関係について議論する．の酒屋倉庫問題の事例で示したように，プロセス分析と構造分析が適度に切り替えられて行われる．したがってこの分析結果は別々の図ではなく，統合した１つの図に6. 関連研究書かれることによって，その関係性が明示できる．その点で，本稿の表記法は優れている．ただし，実際にデー

本稿はゴール指向要求分析のＫＡＯＳを基にしていタベースのテーブルを定義するときは，プロセスは不要る．ゴール指向要求分析では，この他に i*[3] がある．i*

であり，データベースの構造のみが必要となる．そのよでは，ゴールとアクター間の依存性をＤの記号を用いてうな場合は，テーブル構造のみを明記できるＥＲ図がふ表すことにより明示している．ＫＡＯＳでは要求をエーさわしい．

ジェントに割り付けることにより，要求 (ゴール）とアクターを含むエージェントの関係を明示することができる．さらに本稿の研究により，要求（ゴール）間の依存関連研究と本稿の関係についてまとめると，本稿はＫ性も明記できるようになった．i*は KAOS のようにトッＡＯＳに新たな表記を加えることにより，依存性が明記

プゴールと要求の関係を明示できないので，本稿の表記できるようになり，これとマイルストーン分解，要素分法は，i*で表記できる依存性に加え，トップゴールから解により，依存性，振る舞い，構造を１つの統合した図の関係もゴールの詳細化により明示できる点で i*よりもで示せるようになった．前章で述べたとおり，システム多くの情報を表記できるといえる．ただし，as–is 分析のを分析するには，プロセスの分析と各プロセスの入出力場合，各エージェントが行っているゴールがトップゴーデータのデータ構造分析の両方が行える必要がある．プルを意識しているかどうかは定かではないため，この場ロセスの振る舞いと依存性，入出力データの構造を１つ合，トップゴールを明示しない i*のほうが描きやすい可の図で示せる点で，本稿の提案は優れており，有用性は能性はある．しかし to–be 分析においては，各エージェある．ただし，場合によっては，それらのうちの一部のントのゴールはトップゴールに貢献すべきであるので，情報のみが必要な場合があり，その場合には，依存性をトップゴールから各自のゴール，要求との関係が示せる

示す i*や振る舞いを表すＵＭＬの振る舞い図 (アクティ

本稿の表記法のほうが望ましいといえる．

ビティ図等），構造を示すＥＲ図やＵＭＬの構造図（クまた，本稿ではマイルストーン分解と要素分解によりラス図等）のほうがふさわしい．

146SEA

ソフトウェア・シンポジウム2017 in 宮崎

7. 今後の研究

ゴールから要求が抽出できることを確認する必要がある．
我々は [6] において，酒屋倉庫問題は，以下の点が抜け本稿では達成ゴールのゴールの詳細化について議論していることを指摘した．

た．しかしゴールには達成ゴール以外のゴールもある．
ゴールは，図 5 に示すように分類される [1]．すなわち，• 注文番号は出庫指示書の出力項目として挙げられているが，どのように生成されるか明示されていない• 積荷票からどのように出庫を割り当てるか，明示されていない
ゴール分解中に，これらの点が抜けていることを発見できるか確認することも必要となる．

8. まとめ本稿は，要求仕様書に書かれるべき，設計・実装・テ
図 5. ゴールの種類（ゴールタイプ）（[1] を元にストに必要な情報を獲得するためにはどのような手法を作成）用いればよいかの知見を得ることを目標とした．要求仕様書に書かれるべき情報は，要求，ドメイン知識，シスまずはじめにソフトゴールと振る舞いゴールに分かれ，テム固有情報であるが，本稿ではこのうち要求を獲得す振る舞いゴールは本稿で取り上げた達成ゴールの他に，る手法について対象とした．要求を獲得するアプローチ

維持ゴールや回避ゴールがある．ソフトゴールは，「レスとして，ゴール指向要求分析の一手法である KAOS をポンスが３秒以内にあること」のような望ましい状態を用いた．この手法はシステムの目標であるトップゴール示したゴールであり，非機能要求の中には，ソフトゴーから，ゴールの詳細化を繰り返すことにより要求を獲得ルで表現できるものもある（セキュリティ等は回避ゴーする．本稿ではゴール P → Q の詳細化手法として，状ルで示すものもある）．また，達成ゴールは最終状態で態遷移→部分を詳細化するマイルストーン分解と，状態ある「よいことがいつかは起こる」形のゴールであるが，Q 部分を分解する要素分解を用いた．その際，状態 P に回避ゴールは「悪いことは起こらない」という形のゴーついては分解していないが，状態 P を分解する必要があルであり，「不正アクセスが起こらない」といったセキュるかについて考察した．考察を行うために「酒屋倉庫問リティ要求を表現することができる．維持ゴールは「よ題」のゴール分解を行った．すると，Ｐの部分を分解しいことが起こり続ける」であり，「システムが稼働し続けないと，依存性に関して問題が生じることが分かった．ている」という運用・保守に関する要求を表現すること

そこで本稿では状態Ｐの部分を分解し，依存性を明記すができる．非機能要求やセキュリティ要求，保守・運用る表記法を提案し，酒屋倉庫問題で確認した．本提案にの要求は，設計上必要な情報なので，「要求仕様書に書より，依存性，振る舞い，構造を１つの統合した図で示くべき内容」であるが，本稿ではそれらについて触れらせるようになった．既存の手法でも i*は依存性，ＵＭＬれていない．今後研究する必要がある．その際に，達成は振る舞いや構造を示せるが，依存性・振る舞い・構造ゴールと i*,UML 等は関連があったが，他のゴールとのの関連を１つの図で示せる点で，本稿の提案は優れてお関連性はどうなのかについても研究する必要がある．達り，有用性がある．本稿で取り上げなかったゴールから，成ゴール以外のゴールもＫＡＯＳでは表現できるが，も非機能要求やセキュリティ要求，保守・運用の要求が抽し i*やＵＭＬでは表現できない場合，ゴール抽出をＵＭ出できる．これらも設計・実装・テストに必要な情報なのＬのみで行うと，要求仕様書に書くべき要求が抜けるこで，今後研究する必要がある．また，本稿は酒屋倉庫問とになるからである．

題の一部しかゴール分解していないので，ゴール分解をまた，本稿では酒屋倉庫問題の一部しか取り上げて完成させ，設計・実装に必要な要求が欠けていることがいない．酒屋倉庫問題のゴール分解を完成させ，トップ検出できるかどうか確認することも今後の課題である．

147

SEA

ソフトウェア・シンポジウム2017 in 宮崎

参考文献[1] Axel van Lamsweerde, Requirements Engineering:
From System Goals to UML Models to SoftwareSpecifications ,Wiley,2009.
[2] 岡野道太郎・中谷多哉子, 状態と状態遷移に着目した
ゴール指向要求分析手法の考察, 知能ソフトウェア工学研究会 (KBSE) , 電子情報通信学会技術研究報告: 信学技報 Vol.116 No.493,2017,pp25–30[3] i* homepage, http://www.cs.toronto.edu/km/
istar/(2017/3/12)[4] WHAT

ISUML,

http://www.uml.org/

what-is-uml.htm(2017/3/12)[5] 山崎利治, 共通問題によるプログラム設計技法解説，
情報処理 Vol25 No9(1984).

[6] 岡野道太郎・中谷多哉子, 出力データに着目したゴー
ル指向分析による機能要求抽出方法の提案‐酒屋倉庫問題のケース‐ , ソフトウェア エンジニアリング
シンポジウム 2015, 情報処理学会 ソフトウェア工学研究会,pp107 – 114

148

SEA