JP2000353082A - 要求仕様記述支援装置およびその方法、記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 要求仕様からシステムの動きを表すシナリオ
を容易に生成できるようにすることにより、正確な要求
仕様を記述することを支援できるようにする。 【解決手段】 所定の基準に従ってユースケースの形で
記述された要求仕様に基づいて、要求仕様中に含まれる
各ユースケースを順次実行するユースケース実行部３
と、各ユースケースの実行過程を記録して履歴をとるロ
グ記録部５とを設け、要求仕様中に含まれる各ユースケ
ースの実行過程をログとして記録することにより、ユー
スケースを順次実行していくだけで、システムの動きを
表すシナリオを容易に生成することができるようにす
る。ユーザは、この生成されたシナリオを参照すること
により、記述された要求仕様中でユースケースの抜けや
記述漏れがないかどうか等を容易に確認することができ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は要求仕様記述支援装
置およびその方法、記録媒体に関し、特に、ソフトウェ
ア等のシステム開発で用いる要求仕様の記述を支援する
ための装置に用いて好適なものである。

【０００２】

【従来の技術】一般に、コンピュータを利用したシステ
ム開発は、その要求仕様の定義から基本設計、詳細設計
などの過程を経て最終的にコーディングされ、必要に応
じてデバッグされて完成となる。この中で、特に要求仕
様の定義は、システム開発を行う上で非常に重要な意味
を持つものである。すなわち、要求仕様の中で曖昧な記
述や誤解を生じるような記述をしていると、その内容を
もとに設計され作成されたシステムは、全く使えないも
のか、ユーザの全く期待していなかったものになってし
まうことが多い。

【０００３】また、要求仕様をきちんと記述していない
場合、システム開発においてその要求定義の問題が発覚
するのは、設計が終わったとき、あるいはコーディング
を開始してからであることが多いが、この段階で間違い
を直すのは簡単ではなく、莫大な開発コストがかかる。
これに対して、最初の要求仕様をきちんと記述しておけ
ば、その後で発生する手戻り作業を極力抑えることがで
きる。したがって、要求仕様をきちんと記述しておくこ
とは、極めて重要であると言える。

【０００４】従来、要求仕様は、システム開発の前段階
において、現状システムと改善後のシステム、あるいは
新しいシステムの内容などについて、システムが備える
機能を中心として、人間が行う作業、データの発生や流
れ、データの出力などを人間の言葉や図面を用いて記述
していた。また、最近では、要求仕様を記述するのに種
々の方法が用いられるようになってきており、その中の
１つに、システムの機能ではなく用途に着目して記述を
行うユースケースと呼ばれるものも登場してきている。

【０００５】

【発明が解決しようとする課題】しかしながら、要求仕
様の記述方法としては色々なものがあるが、何れの方法
によっても、その記述された内容からシステム設計に漏
れや誤り等がないかどうかをチェックするのは、人手に
よっていた。例えば、要求仕様として記述された文章や
図面そのものを人間が見て、そこからデータの発生、利
用関係、出力等や、誰が何を入力してどんな作業を行う
のかなどの色々なチェックをその人間の判断で行ってい
た。

【０００６】ところが、これらのチェックは、人間が手
作業で行うものなので、見落としや間違いなどが発生し
やすい。また、コンピュータ等を利用してもある程度は
チェックできるが、どのように行えばチェックが正確か
つ容易になるかは、明確でなかった。特に、作成した要
求仕様に基づきシステムの動きをチェックすることは、
要求仕様の記述の間違いや抜け等をチェックする上で重
要であるが、これは非常に面倒で、時間のかかるもので
あった。

【０００７】本発明は、このような実情に鑑みて成され
たものであり、一定の基準に基づいて記述されたシステ
ムの要求仕様から、システムの動きを表すシナリオを容
易に生成できるようにすることにより、正確な要求仕様
を記述することを支援できるようにした要求仕様記述支
援装置および方法を提供することを目的とする。

【０００８】

【課題を解決するための手段】本発明の要求仕様記述支
援装置は、所定の基準に従ってユースケースの形で記述
された要求仕様に基づいて、上記要求仕様中に含まれる
各ユースケースを順次実行するユースケース実行手段
と、上記ユースケース実行手段による上記各ユースケー
スの実行過程を記録して履歴をとる履歴記録手段とを備
えたことを特徴とする。

【０００９】本発明の他の態様では、上記ユースケース
の実行過程で現れる分岐において、次に実行するユース
ケースをユーザに選択させる分岐選択手段を備え、上記
ユースケース実行手段は、ユーザとの対話的処理により
各ユースケースを順次実行するようにしても良い。ま
た、上記ユースケース実行手段は、上記ユースケースの
実行過程で現れる分岐において次に実行するユースケー
スを自動的に選択して、上記要求仕様中に含まれる各ユ
ースケースを順次実行するようにしても良い。

【００１０】また、上記要求仕様中に含まれる各ユース
ケースを実行する上での条件を上記ユースケース実行手
段に対して与える条件設定手段を備え、上記ユースケー
ス実行手段は、与えられた条件の範囲内で、上記ユース
ケースの実行過程で現れる分岐において次に実行するユ
ースケースを自動的に選択して各ユースケースを順次実
行するようにしても良い。

【００１１】さらに、上記ユースケース実行手段は、上
記ユースケースの実行過程で現れる分岐において、次に
実行するユースケースとして取り得る全ての分岐先を自
動的に順次選択して、上記要求仕様中に含まれる各ユー
スケースを順次実行するようにしても良い。

【００１２】本発明のその他の態様では、基本的な流れ
を表す基本系列のユースケースと、例外的な流れを表す
代替系列のユースケースとを相互に関連付けて記述でき
るようになされた上記所定の基準に従って上記要求仕様
を記述する要求仕様記述手段を備える。

【００１３】本発明のその他の態様では、上記ユースケ
ースの形で記述された要求仕様の各構成要素について、
ある構成要素から他の構成要素を利用する利用関係、元
の構成要素に対して部分的な変更を加えて新たな構成要
素を作る汎化関係、ある構成要素において特定の条件を
満たしたときに別の構成要素の処理を行う拡張関係の少
なくとも１つを用いて上記各構成要素を構造化する構造
化手段を備える。

【００１４】ここで、上記利用関係および上記拡張関係
については、上記ユースケース内のイベントと他のユー
スケースとの関係を構造化するようにしても良い。ま
た、上記ユースケース実行手段は、上記構造化手段によ
り構造化されたユースケースの利用、汎化、拡張の関係
に従って、あるユースケース内のイベントから他のユー
スケースに分岐して各ユースケースを順次実行していく
ようにしても良い。また、基本系列のユースケースと代
替系列のユースケースとの間に張られた関連に従って、
あるユースケースから他のユースケースに分岐して各ユ
ースケースを順次実行していく第１のモードと、上記構
造化手段により構造化されたユースケースの利用、汎
化、拡張の関係に従って、あるユースケース内のイベン
トから他のユースケースに分岐して各ユースケースを順
次実行していく第２のモードとを有しても良い。

【００１５】本発明のその他の態様では、上記要求仕様
を記述する際に、個々のユースケース毎にその処理時間
を記述する要求仕様記述手段と、上記要求仕様記述手段
により記述された個々のユースケースの処理時間に基づ
いて、上記履歴記録手段により記録された履歴により示
される一連の処理を行うのにかかる総処理時間を演算す
る総時間演算手段とを備える。

【００１６】本発明のその他の態様では、上記履歴記録
手段により記録された履歴に対して重要度および利用頻
度の少なくとも一方を設定する重要度／利用頻度設定手
段と、上記重要度および利用頻度の少なくとも一方が設
定された履歴を解析して、その履歴に含まれる個々のユ
ースケースの重要度および利用頻度の少なくとも一方を
求める履歴解析手段とを備える。

【００１７】また、本発明の要求仕様記述支援方法は、
所定の基準に従ってユースケースの形で記述された要求
仕様に基づいて、上記要求仕様中に含まれる各ユースケ
ースを順次実行し、その実行過程を記録するようにした
ことを特徴とする。

【００１８】本発明の他の態様では、上記ユースケース
の形で記述された要求仕様の各構成要素について、ある
構成要素から他の構成要素を利用する利用関係、元の構
成要素に対して部分的な変更を加えて新たな構成要素を
作る汎化関係、ある構成要素において特定の条件を満た
したときに別の構成要素の処理を行う拡張関係の少なく
とも１つを用いて上記各構成要素を構造化するようにす
る。

【００１９】本発明のその他の態様では、上記要求仕様
を記述する際に、個々のユースケース毎にその処理時間
を記述するようにし、上記記述された個々のユースケー
スの処理時間に基づいて、上記各ユースケースの実行過
程が記録された履歴により示される一連の処理を行うの
にかかる総処理時間を演算するようにする。

【００２０】本発明のその他の態様では、上記各ユース
ケースの実行過程が記録された履歴に対して重要度およ
び利用頻度の少なくとも一方を設定し、上記重要度およ
び利用頻度の少なくとも一方が設定された履歴を解析し
て、その履歴に含まれる個々のユースケースの重要度お
よび利用頻度の少なくとも一方を求めるようにする。

【００２１】また、本発明のコンピュータ読み取り可能
な記録媒体は、所定の基準に従ってユースケースの形で
記述された要求仕様に基づいて、上記要求仕様中に含ま
れる各ユースケースを順次実行するユースケース実行手
段と、上記ユースケース実行手段による上記各ユースケ
ースの実行過程を記録して履歴をとる履歴記録手段とし
てコンピュータを機能させるためのプログラムを記録し
たことを特徴とする。

【００２２】本発明の他の態様では、上記ユースケース
の形で記述された要求仕様の各構成要素について、ある
構成要素から他の構成要素を利用する利用関係、元の構
成要素に対して部分的な変更を加えて新たな構成要素を
作る汎化関係、ある構成要素において特定の条件を満た
したときに別の構成要素の処理を行う拡張関係の少なく
とも１つを用いて上記各構成要素を構造化する構造化手
段としての機能を更にコンピュータに実現させるための
プログラムを記録する。

【００２３】本発明のその他の態様では、上記要求仕様
を記述する際に、個々のユースケース毎にその処理時間
を記述する要求仕様記述手段と、上記要求仕様記述手段
により記述された個々のユースケースの処理時間に基づ
いて、上記履歴記録手段により記録された履歴により示
される一連の処理を行うのにかかる総処理時間を演算す
る総時間演算手段としての機能を更にコンピュータに実
現させるためのプログラムを記録する。

【００２４】本発明のその他の態様では、上記履歴記録
手段により記録された履歴に対して重要度および利用頻
度の少なくとも一方を設定する重要度／利用頻度設定手
段と、上記重要度および利用頻度の少なくとも一方が設
定された履歴を解析して、その履歴に含まれる個々のユ
ースケースの重要度および利用頻度の少なくとも一方を
求める履歴解析手段としての機能を更にコンピュータに
実現させるためのプログラムを記録する。

【００２５】本発明は上記技術手段より成るので、所定
の基準に従って記述された要求仕様中に含まれる各ユー
スケースが順次実行される過程で、実行されたユースケ
ースが順次履歴として記録されていくこととなり、その
結果、ユースケースの実行の流れ、つまりシステムの動
きを表すシナリオが生成される。なお、ここで言う所定
の基準とは、例えば、要求仕様の記述中にユースケース
間のリンク情報が含まれるように定められたものであ
り、またユースケースの実行とは、例えばリンク先のユ
ースケースを読み込んで表示することを言う。ユーザ
は、このように生成されたシナリオを参照することによ
って、本来あるべきユースケースに漏れがないかどうか
とか、未実行のユースケースがないかどうかなどを確認
することで、要求仕様が適切に書かれているかどうかを
チェックすることが可能となる。

【００２６】本発明の他の特徴によれば、構造化された
ユースケースの利用、汎化、拡張の関係に従って、ある
ユースケース内のイベントからそのリンク先のユースケ
ースを読み出しながら各ユースケースが順次実行され、
その実行過程が履歴として記録されていくこととなり、
その結果、ユースケースの流れだけでなく、更に各ユー
スケース内に含まれるイベントの流れまで表すシナリオ
が生成される。これにより、各ユースケースによる処理
の流れがより詳細に分かるようになる。

【００２７】本発明のその他の特徴によれば、生成され
たシナリオを用いて、そのシナリオ通りに一連の処理を
実行した場合に必要な総処理時間が演算される。このよ
うに、生成されたシナリオを実行するのに必要な総処理
時間を算出することにより、現行業務の分析、システム
化に対する要求の妥当性あるいは実現可能性などを判断
するための１つの指標を得ることができる。

【００２８】本発明のその他の特徴によれば、個々のユ
ースケースに対して重要度や利用頻度等を設定するので
はなく、生成されたシナリオに対して重要度や利用頻度
等を設定すると、その設定内容から個々のユースケース
の重要度や利用頻度等が求められることとなる。これに
より、重要度や利用頻度等の設定作業を簡易にすること
が可能となるとともに、その設定をユーザにとって分か
りやすいものとすることが可能となる。

【００２９】

【発明の実施の形態】以下、本発明の一実施形態につい
て図面を参照しながら説明する。

【００３０】（第１の実施形態）図１は、本発明の第１
の実施形態による要求仕様記述支援装置の要素的特徴を
表す機能構成ブロック図である。図１において、要求仕
様記述部１は、あらかじめ定められた所定のフォーマッ
トに従って、要求仕様をユースケースの形で記述するも
のである。ここで、ユースケースとは、開発するシステ
ムが業務上どのように利用されるのかという点に着目し
て、システムの稼働時にオペレータが行う一連のアクシ
ョン（イベント）等を、トランザクション毎に自然言語
で記述したものを言う。

【００３１】図２は、本実施形態による要求仕様の入力
画面の例を示す図である。図２において、ツリー構造表
示画面２１は、あるシステムの開発プロジェクトについ
て定義した要求仕様モデルをツリー構造にて表示するた
めの画面である。この画面２１の下方には、タグ２２
ａ，２２ｂが設けられており、一方のタグ２２ａをクリ
ックすると、図２に示されるようにユースケースの入力
画面となり、もう一方のタグ２２ｂをクリックすると、
図示しないビジネスルールの入力画面となる。なお、ビ
ジネスルールは、開発されたシステムによって業務を遂
行する上で守るべきルールを示すものである。

【００３２】図２の例では、プログラミングの教育シス
テムを開発するプロジェクトにおいて要求仕様として定
義する情報の例を示しており、上記ツリー構造表示画面
２１内には、そのプロジェクトにおけるユースケースの
利用関係とアクタ（ユースケース中のそれぞれのアクシ
ョンを誰が行うかを示すもの）の一覧とが示されてい
る。すなわち、ここに示されるツリー構造としては、
“プロジェクト”の下層に“ユースケース”と“アク
タ”があり、上記“ユースケース”の下層に“外部”、
“内部”および“情報システム”がある。

【００３３】更にここでは、ユースケース“外部”の中
のユースケースの利用関係を特に示している。すなわ
ち、ユースケース“外部”と書かれた階層の下の階層に
は、“演習問題の提供”、“評価”および“○○知識獲
得”というユースケースがあり、上記“演習問題の提
供”の下の階層には更に“事前準備”および“演習問題
の公開”というユースケースがある。さらに、上記“演
習問題の公開”の下の階層には更に“演習問題の実装”
というユースケースがある。

【００３４】このように、ある業務システムを作成する
１つのプロジェクトに関する要求仕様は、システム上で
行う個々の業務を単位として記述した複数のユースケー
スから構成される。ここで、例えばツリー構造表示画面
２１内で任意のユースケースの部分をマウスでクリック
すると、そのユースケースの入力画面２３がツリー構造
表示画面２１の右側に表示される。

【００３５】図２の例では、“演習問題の実装”という
ユースケースの部分がクリックされたときの様子を示し
ている。このユースケース入力画面２３では、ユースケ
ース名の表示の後に、目的、事前条件、基本系列、代替
系列、事後条件およびデータの入力画面が表示される。
なお、図２中では代替系列、事後条件およびデータの入
力画面が表されていないが、これらはユースケース入力
画面２３を下にスクロールさせると見えてくるようにな
っている。

【００３６】上記ユースケース入力画面２３内の目的の
欄には、そのユースケースにおいてどんな業務を行うの
かの大まかな内容を定義する。また、事前条件の欄に
は、その業務を行うために事前に行われていることが必
要な条件を定義する。図２の例では、“演習問題の実
装”の目的である演習問題に対する解答の提出を行うた
めの事前条件として、その演習問題が箇所研修生に公開
されている、ということが定義されている。

【００３７】また、事後条件の欄には、そのユースケー
スで定義されている動作を行った後にどんな状態となる
かについて定義する。例えば、動作が成功に終わった場
合と、失敗に終わった場合とに分けて、それぞれの場合
にどういう状態となるかを定義する。なお、例えばここ
に、次に実行すべきユースケースを記述することによ
り、ユースケースのジャンプ先にリンクを張るようにし
ても良い。また、データの欄には、そのユースケースで
定義されたアクション（イベント）を行う際に、どんな
データを入出力するかについて定義する。

【００３８】また、基本系列の欄には、そのユースケー
スで誰が何を行うか等の具体的な内容を定義する。ここ
では、業務の基本的な流れを表す具体的な動作の内容を
示すイベントと、それを誰が行うかを表すアクタと、そ
のイベントを行う際に利用する他のユースケースとを各
動作毎に順番に記述していく。なお、図２の例では、ツ
リー構造表示画面２１内から“箇所研修生”をドラッグ
してきてアクタの欄に張り付けている状態を示してい
る。

【００３９】代替系列の欄も上記基本系列の欄と同様
に、そのユースケースで誰が何を行うか等の具体的な内
容を定義する。ただし、基本系列では業務の基本的な流
れを表すイベントを記述するのに対して、代替系列では
業務の例外的な流れを表すイベントを記述する点で異な
る。図３は、この代替系列の入力画面の例を示す図であ
る。

【００４０】図３に示すように、代替系列の欄には、代
替される対象となる基本系列の番号と、その基本系列の
イベントの代わりに行われる具体的な動作の内容を表す
イベントと、そのイベントを行う際に利用する他のユー
スケースと、イベント終了後の処理の内容を表す後処理
とを各動作毎に順番に記述していく。

【００４１】図３の例では、図２に示した上から３番目
の基本系列の処理（解答の提出）を行う際に、どうして
も解けない場合には講師に質問をするということが代替
系列のイベントとして定義されている。また、その質問
のイベントが終了した後は、上記３番目の基本系列の処
理に戻るということが後処理として定義されている。な
お、後処理の他の例として、例えばその代替系列のイベ
ントが終わった後は基本系列に戻ることなくそのまま処
理を終了するとか、他の基本系列あるいは代替系列のイ
ベントにジャンプするということ等を定義できる。

【００４２】このように、代替系列の欄において、代替
の対象となる基本系列の番号や後処理などを記述するこ
とにより、基本系列のユースケースと代替系列のユース
ケースとの間にリンクが張られることになる。このよう
に基本系列と代替系列との間でリンクが張られた部分
は、後にユースケースの実行過程を表すをシナリオを生
成する際に、次に実行するユースケースの分岐点として
現れることとなる。

【００４３】また、次に実行すべきユースケースの指定
は、１つ上の階層のユースケースの利用ＵＣ（ユースケ
ース）の欄に記述することにより行われる。利用される
ユースケースの基本系列が終わった後は、利用元のユー
スケースの実行に戻り、最初に起動したユースケースの
基本系列が全て終了すると、１つのシナリオが完成する
ことになる。

【００４４】以上のように、本実施形態では、図面等と
は異なり、誰もが同じように理解できる自然言語で各種
の情報を入力していくことによって要求仕様を記述する
ようにしているので、開発するシステムの機能とそれを
用いて行う業務との対応関係を明確にすることができ、
食い違いの発生を極力少なくすることができる。その
際、あらかじめ定められた入力項目に対して記述を行え
ば良いので、ユースケースの記述がしやすく、簡単に入
力することができる。また、図２に示すように、入力項
目の記述をドラッグ＆ドロップ操作によって行うことも
できるので、入力ミスを防止することもできる。

【００４５】図１の要求仕様記述部１では、上記図２に
示したフォーマット入力画面に基づいて、目的、条件、
基本系列、代替系列、データなどの各種情報を含んだユ
ースケースを業務単位毎に順次入力していくとともに、
対応するビジネスルールを同じく業務単位毎に順次入力
していく。要求仕様格納部２は、このように入力された
要求仕様の情報を格納するためのものである。ここで
は、定義された個々のユースケースおよびビジネスルー
ル毎に要求仕様の情報が格納される。

【００４６】ユースケース実行部３は、図２のように定
められた一定の基準に従って記述され、要求仕様格納部
２に格納された要求仕様の情報に基づいて、当該要求仕
様中に含まれる各ユースケースを順次実行する。具体的
には、各ユースケースの記述時に張られたリンクに従っ
て、リンク先のユースケースを順次読み出してモニタ上
に表示するという処理を行う。このとき、ユースケース
の分岐があればその分岐先の選択肢を表示し、次にどの
ユースケースを実行するのかをユーザに選択させる。こ
の選択は、表示された選択肢の中の１つをマウス等のポ
インティングデバイスによって選択指示するための分岐
選択部４を用いて行う。

【００４７】また、ログ記録部５は、上記ユースケース
実行部３による各ユースケースの実行過程を記録するこ
とにより、使用された各ユースケースの履歴をとるもの
である。すなわち、ユースケースが読み出される毎ある
いはモニタ上に表示される毎に、そのユースケースを順
次記録していくことにより、システム上でユースケース
がどのように処理されていくかの流れ、つまり、そのシ
ステム上の一連の業務がどういう動きで実現されるのか
を表したシナリオを生成する。

【００４８】このように生成されたシナリオは、例えば
データベースから成るシナリオ記憶部６に記憶される。
シナリオ出力部７は、シナリオがシナリオ記憶部６に記
憶されるのと同時、あるいはその後任意の時点におい
て、生成されたシナリオを例えばモニタ上に出力するも
のである。ユーザは、ここで表示されたシナリオを参照
することによって、要求仕様として記述されたシステム
の動きを容易に把握することが可能となる。

【００４９】図４は、本実施形態の要求仕様記述支援装
置がユーザとの対話的処理によりシナリオを生成してい
る途中の画面例を示す図である。図４の例は、「演習問
題の公開」（ユースケースナンバー：ＵＣ００６）を指
定してシナリオ生成コマンドを実行したときの例を示し
ている。この場合、まず最初にユースケース実行部３
は、「演習問題の公開」のユースケースを要求仕様格納
部２から読み込み、そのユースケース中に記述されてい
る事前条件と基本系列のイベントとを表示する。

【００５０】このとき、例えばある基本系列のイベント
に対して代替系列のイベントが定義されている場合に
は、分岐先の選択肢を表す分岐メニューをポップアップ
表示する。これに対応してユーザが分岐選択部４を用い
て何れかの分岐先を選択すると、その選択された内容が
表示される。なお、分岐がある場合は、図４中に示した
ように＜分岐＞のマークが表示される。図４のユースケ
ース「演習問題の公開」の中では、表示された分岐メニ
ューの中から「演習問題を公開する」という基本系列の
イベントを選択した状態を示している。

【００５１】このように分岐先が選択されると、その選
択された分岐先に応じて、要求仕様の記述時に定義され
たリンクに従って次のユースケースが要求仕様格納部２
から読み出されて表示される。図４では、次に「演習問
題の実装」（ユースケースナンバー：ＵＣ０１２）のユ
ースケースが読み出されて表示されている。このユース
ケースの中でも、３番目の基本系列のイベントに対して
代替系列のイベントが定義されており、分岐先の選択肢
を表す分岐メニューがポップアップ表示されている。

【００５２】このようなユースケース実行部３および分
岐選択部４によるインタラクティブ処理によって各ユー
スケースを順次実行していく際に、ログ記録部５は、そ
の実行過程で使用されたユースケースをシナリオ記憶部
６に順に記録していく。図５は、このようなシナリオの
生成結果の例を示す図である。この図５には、シナリオ
００１〜００３の３つのシナリオ（使用されたユースケ
ースの名称を列挙したもの）が示されているが、これら
はそれぞれ、ユースケースの実行過程で発生した分岐点
において異なる分岐先を選択して各々生成したものであ
る。

【００５３】図６は、ユースケース実行部３の動作を示
すフローチャートである。図６において、ユーザにより
特定のユースケースが指定されてシナリオ生成の実行が
指示されると、ユースケース実行部３は、ステップＳ１
で、その指定されたユースケースを要求仕様格納部２の
中から読み出す。そして、ステップＳ２で、その読み出
したユースケース中に記述されている事前条件を表示す
る。

【００５４】次に、ステップＳ３で、そのユースケース
中に代替系列が定義されているかどうかを判断し、定義
されていない場合にはステップＳ４に進み、基本系列を
表示する。一方、代替系列がある場合には、ステップＳ
５に進み、図４に示したような分岐マークを付与して表
示するとともに、ステップＳ６で、その代替系列のイベ
ントと、代替の対象となっている基本系列のイベントと
を含む複数の選択肢（選択メニュー）をポップアップ表
示する。

【００５５】そして、ステップＳ７で、表示された選択
肢の中から基本系列あるいは代替系列のどちらが選択さ
れたかを判断し、基本系列が選択された場合は、ステッ
プＳ４に進み、その選択された基本系列のイベントを表
示する。さらに、ステップＳ９で、利用するユースケー
スがあるかどうかを判断し、ない場合にはステップＳ１
０に進んでユースケースの終了を判定し、終了していな
ければステップＳ３に戻り、上述の動作を再び実行す
る。

【００５６】上記ステップＳ１０でユースケースが終了
していると判断されたときは、ステップＳ１１に進み、
その終了したユースケースが最初に起動したユースケー
スかどうかを判定し、最初に起動したものであれば、処
理は終了する。また、最初に起動したユースケースでな
い場合は、ステップＳ１２に進み、１つ上の階層のユー
スケースである元のユースケースの実行に戻り、その後
ステップＳ３に戻って上述の動作を再び実行する。

【００５７】一方、上記ステップＳ９で、利用するユー
スケースがあると判断した場合は、ステップＳ１に戻
り、その別のユースケースを要求仕様格納部２から新た
に読み出す。そして、ステップＳ２以降の処理をその新
たなユースケースについて同様に行う。

【００５８】また、上記ステップＳ７で代替系列が選択
された場合は、ステップＳ８に進み、その選択された代
替系列のイベントをそれまでの表示に続けて表示する。
さらに、ステップＳ９で、利用するユースケースがある
かどうかを判断し、ある場合にはステップＳ１に戻って
その別のユースケースを要求仕様格納部２から新たに読
み出して、ステップＳ２以降の処理をその新たなユース
ケースについて同様に行う。一方、利用するユースケー
スがない場合は、ステップＳ１０に進み、それ以降は上
述した処理を実行する。

【００５９】この図６に示すような動作をユースケース
実行部３が実行することにより、複数のユースケースが
ユーザとの対話的処理により順次実行されていく。この
とき図１のログ記録部５が、実行された各ユースケース
をそれらが実行される毎にシナリオ記憶部６にログとし
て記録していくことにより、ユースケースの実行過程を
表したシナリオが自動的に生成される。つまり、ユーザ
が必要に応じて分岐先を選択するだけで、システムの動
きを表すシナリオを生成することができる。

【００６０】ユーザは、この生成されたシナリオを見る
ことによって、システムの動きを容易に確認することが
できる。これにより、そのシステムにおけるビジネスプ
ロセスの要求仕様の整合性を検証することが容易とな
り、ビジネスプロセスの問題点を容易に把握することが
できるようになる。また、必ず通らなければならないユ
ースケースがある場合に、それがシナリオ内で使用され
ているかどうかを見ることで、ユースケースの抜けや記
述漏れなどがないかどうかをチェックしたり、未実行の
ユースケースがないかどうかをチェックすることもでき
る。

【００６１】また、上述のように生成されたシナリオを
参照することによってシステムの動きをログとして確認
することができることの他に、本実施形態ではユーザと
の対話的な処理によって各ユースケースを順次実行する
ようにしているので、ユースケースを用いて要求仕様を
記述したシステムの動きを、そのシステムを実際に設計
・実装する前に疑似的に体験することもできる。

【００６２】そのため、記述した要求仕様に基づきシス
テムの設計・実装に入る前の段階で当該システムを疑似
的に動かすことができる。必要であればそこで要求仕様
の手直しをすることにより、システムを開発する上で必
要な要求仕様を、最終的に矛盾や抜けがなく、かつユー
ザが満足するように記述することができる。これによ
り、その後の設計段階や実装段階で手戻り作業が発生し
てしまう不都合を極力抑えることができ、システム開発
のコストを大幅に削減することができる。

【００６３】なお、上記実施形態では、分岐点は代替系
列が定義されているところに発生するが、ユースケース
入力画面の事後条件の欄に、ジャンプ先として複数のユ
ースケースを記述することにより、ここもユースケース
実行の分岐点とするようにしても良い。この場合、分岐
先の選択肢を表す分岐メニューは、代替系列が定義され
ているところに限らず、事後条件によって複数の分岐先
が定義されているところでも表示されることになる。

【００６４】また、上記実施形態では、ユースケースの
実行過程で現れる分岐において、次に実行するユースケ
ースをユーザに選択させることにより、ユーザとの対話
的処理に基づきシナリオを生成するようにしているが、
本発明はこのような手法には限定されない。

【００６５】例えば、分岐点において次に実行するユー
スケースを装置が自動的に選択することにより、いくつ
かのシナリオを自動的に生成するようにしても良い。ま
た、この場合、図１に示すように条件設定部８を設け、
各ユースケースを実行する際の条件（例えば、代替系列
には絶対に飛ばずに、基本系列だけでユースケースを実
行する等の条件）をユースケース実行部３にあらかじめ
与えておき、その条件の範囲内で自動的に分岐処理を行
ってシナリオを生成するようにしても良い。

【００６６】さらに、上記のように自動分岐を行ってシ
ナリオを生成する場合、分岐先としてある１つのパター
ンあるいは数種類のパターンを選択してシナリオを自動
生成するようにしても良いし、各分岐点において次に実
行するユースケースとして取り得る全ての分岐先を順次
選択することにより、あらゆるパターンのシナリオを全
て自動的に生成するようにしても良い。

【００６７】また、上記実施形態では、記録されるシナ
リオ中には、図６に示したようにユースケースの名称と
番号だけが含まれるが、そのユースケースに関係するア
クタや入出力されるデータなど、ユースケースを構成す
る他の構成要素を一緒に表示するようにしても良い。ま
た、本実施形態において記録されるシナリオでは、それ
を見ただけではどこでどういう分岐があったかが分から
ないので、分岐条件だけのログをシナリオ中あるいはこ
れとは別に記録するようにしても良い。

【００６８】また、上記実施形態では、必ず通らなけれ
ばならないユースケースの抜けなどを、生成されたシナ
リオをユーザが目で見て判断していたが、そのようなユ
ースケースをあらかじめ設定しておくことにより、装置
が自動的にチェックを行うようにしても良い。また、シ
ナリオが途中で終わってしまっていないかどうかを検証
するために、ある特定のユースケースでシナリオが終わ
っているかどうかを装置が自動的にチェックするように
しても良い。さらに、これらの場合、不備があったとき
にエラーメッセージを出力するようにしても良い。

【００６９】（第２の実施形態）次に、本発明の第２の
実施形態について説明する。第２の実施形態は、要求仕
様をユースケースの形態で記述する際に、ユースケース
やアクタなどを構造的に記述できるようにしたものであ
る。構造化されたユースケースやアクタの記述方法とし
て、ここではＵＭＬ（Unified Modeling Language ）を
利用する。

【００７０】上記ＵＭＬにおいては、構成要素間の関係
の種類として、利用（uses）、汎化（generalizatio
n）、拡張（extends ）の３つが定義されている。利用
にはユースケース間の利用があり、汎化にはユースケー
ス間およびアクタ間の汎化があり、拡張にはユースケー
ス間の拡張がある。ここで言う利用、汎化、拡張は、Ｕ
ＭＬのバージョン1.1 における定義に基づいたものであ
るが、ＵＭＬのバージョン1.3 における定義に基づくも
のに置き換えることも可能である。

【００７１】本実施形態では、ユースケース間の関係を
定義する際、あるユースケース内の基本系列を構成する
１個のイベントを他の１個のユースケースに対応させて
構造化している点に特徴がある。このようにすることに
より、ユースケースやアクタを構造化したときの詳細な
関係を分かり易くすることができる。

【００７２】ここで、利用とは、複数のユースケース間
で共通に利用可能な共通サブユースケースがあるとき
に、あるユースケースからその共通サブユースケースを
利用する関係を言う。汎化とは、元のユースケースや元
のアクタに対して部分的な変更を加えて新たなユースケ
ースや新たなアクタを作る関係を言う。なお、あるユー
スケースＡをベースに、それを継承して差分を記述して
別のユースケースＢを定義した場合、ユースケースＡは
ユースケースＢを汎化したものであると言い、ユースケ
ースＢはユースケースＡを特殊化したものであると言
い、両者の関係を汎化関係という。また、拡張とは、基
本的なイベントの流れを規定したユースケースにおい
て、ある特定の条件を満たしたときに別の拡張ユースケ
ースの処理を行う関係を言う。

【００７３】図７は、本実施形態によるユースケースの
入力画面の例を示す図であり、基本系列を定義する部分
を特にピックアップして示している。この図７に示す基
本系列の入力欄においては、図２の場合と同様に、その
ユースケースで誰が何を行うか等の具体的な内容をイベ
ント欄３１およびアクタ欄３２に記述する。このとき、
特定のイベントにおいて共通サブユースケースを利用す
ることがあれば、その利用する共通サブユースケースの
名称を利用ユースケース（利用ＵＣ）の欄３３に記述す
る。

【００７４】図７の例では、“ユースケース１”の基本
系列において“イベント２”の中で利用する共通サブユ
ースケースとして“ユースケース５”を定義している。
これにより、“ユースケース１”と“ユースケース５”
との間に利用（uses）の関係が張られる。

【００７５】また、図７の入力画面には、利用ＵＣ作成
ボタン３４、特殊化ボタン３５および拡張ボタン３６が
設けられている。このうち、利用ＵＣ作成ボタン３４
は、複数のイベント列を指定して共通サブユースケース
を作成することを指示するためのボタンである。

【００７６】例えば、図７に示す入力画面上で、共通サ
ブユースケースに落とし込みたいイベント列を指定して
利用ＵＣ作成ボタン３４をマウスでクリックすると、そ
の指定したイベント列を要素とする共通サブユースケー
スの名称や概要（目的）の入力を促す画面が現れる。こ
の画面で共通サブユースケースの名称や概要（目的）を
入力してＯＫボタンを押すことにより、共通サブユース
ケースが作成される。

【００７７】図８は、この共通サブユースケースを作成
する際の動作を説明するための図である。図８では、ａ
〜ｆを内容とするイベント列から成るユースケースが
あったときに、ａ〜ｄの内容は複数のユースケースで利
用する可能性があるためにこれを共通サブユースケース
として作成しようとする場合の例を示している。

【００７８】この場合、図８（ａ）に示す元のユースケ
ースにおいて、共通サブユースケースとすべきイベン
ト列ａ〜ｄを指定して利用ＵＣ作成ボタン３４をクリッ
クし、更に当該共通サブユースケースの名称として“ユ
ースケース”を入力するとともに、概要として“Ｘ”
を入力すると、図８（ｂ）に示すような共通サブユース
ケースが作成される。また、図８（ｃ）に示すよう
に、元のユースケースの４つのイベント列ａ〜ｄが１
つのイベントＸ（共通サブユースケースを利用したも
の）に置き換えられたユースケース′が自動的に作ら
れる。

【００７９】このようにして共通サブユースケースを
作成した後は、ユースケース′以外の他のユースケー
スからもこの共通サブユースケースを利用することが
可能となる。このように共通サブユースケースを作成し
てこれを複数のユースケースで共通に利用できるように
することにより、ユースケースの再利用を容易にするこ
とができ、オペレータがユースケースを記述する際の作
業負担を軽減することができる。

【００８０】また、特殊化ボタン３５は、あるユースケ
ースと汎化関係にある他のユースケースを作成すること
を指示するためのボタンである。例えば、図７に示す入
力画面上で特殊化ボタン３５をクリックすると、そのと
き表示されていたものと同内容のイベント列を有するユ
ースケースが別の入力画面として現れる。ここで、所望
の箇所を変更した上で、新たなユースケースの名称や概
要（目的）を入力してＯＫボタンを押すことにより、元
のユースケースと汎化関係にある別の特殊化されたユー
スケースが作成される。

【００８１】図９は、この特殊化されたユースケースを
作成する際の動作を説明するための図である。図９
（ａ）のようにａ〜ｅを内容とするイベント列から成る
ユースケースがあるときに、特殊化ボタン３５を押す
と、図９（ｂ）に示すように、ユースケースのイベン
ト列ａ〜ｅをそのまま反映した別のユースケースの入力
画面が現れる。このとき、特殊化用のユースケースが新
たに作られているが、この段階では、元のユースケース
を特殊化したものであることを示す情報のみが新たな記
憶領域に格納され、中身の情報は何も格納されていない
状態である。

【００８２】次に、図９（ｂ）に示す入力画面上で所望
の箇所を変更する。図９の例では、イベントｃの内容を
イベントｘに変更している。さらに、特殊化用ユースケ
ースの名称として“ユースケース”を入力すると、図
９（ｃ）に示すように特殊化されたユースケースが作
成される。このとき、特殊化用ユースケースの記憶領域
には、元のユースケースから変更があった部分の差分
データのみ、つまりイベントｘのデータのみが格納され
る。他の変更されていない部分の情報は、元のユースケ
ースが格納されている記憶領域からデータを読み出し
て画面上に表示している。

【００８３】様々なユースケースを記述していく際、異
なるユースケースでも同内容の入力を繰り返し行うこと
が少なからずある。この場合において、従来は全てのユ
ースケースについて最初から記述していたが、本実施形
態によれば、一部のみが異なるユースケースを継承し、
異なる部分の定義だけを記述すれば良いので、オペレー
タの作業量を格段に少なくすることができる。

【００８４】また、特殊化されたユースケースでは、そ
の親のユースケースとの差分データだけを格納している
ので、親のユースケースにおいて共通の部分に修正が行
われたとしても、その修正内容は特殊化されたユースケ
ースにも反映され、常に整合性を正しく維持することが
できる。したがって、全ての記述をオペレータの手作業
で入力していた従来と比べて、修正漏れや入力の間違い
を少なくすることができ、より正確な要求仕様を記述す
ることができるようになる。

【００８５】また、拡張ボタン３６は、あるユースケー
スと拡張の関係にある他のユースケースを作成すること
を指示するためのボタンである。例えば、図７に示す入
力画面上で拡張ボタン３６をクリックすると、拡張ユー
スケースを記述するための別の入力画面が現れる。ここ
で、元のユースケースからの分岐条件と、その条件を満
たした場合に実行するイベント列とを入力するととも
に、元のユースケースから分岐する分岐場所と、拡張ユ
ースケースの処理が終わった後に戻る元のユースケース
の戻り場所とを入力することにより、元のユースケース
と拡張の関係にある別のユースケースが作成される。

【００８６】図１０は、この拡張されたユースケースを
作成する際の動作を説明するための図である。図１０
（ａ）のようにａ〜ｅを内容とするイベント列から成る
ユースケースがあるときに、拡張ボタン３６を押す
と、拡張ユースケースを記述するための別の入力画面が
現れる。ここで、例えば、分岐条件の内容を含むイベン
ト列ｘ〜ｚを入力するとともに、元のユースケースの
分岐場所としてイベントｃ、拡張ユースケースのイベン
ト列ｘ〜ｚを実行した後に戻る元のユースケースの戻
り場所としてイベントｄを入力することにより、図１０
（ｂ）に示すような拡張ユースケースが作成される。

【００８７】図１１は、上述のようにユースケース等の
構造化を行うことができるようにした第２の実施形態に
よる要求仕様記述支援装置の要素的特徴を表す機能構成
ブロック図である。なお、この図１１において、図１に
示した符号と同一の符号を付したものは、同一の機能を
有するものであるので、これについての詳細な説明は省
略する。

【００８８】図１１において、要求仕様記述部１１は、
図１に示した要求仕様記述部１と同様に、あらかじめ定
められた所定のフォーマットに従って、要求仕様をユー
スケースの形で記述するものである。本実施形態の要求
仕様記述部１１はさらに、個々のユースケースごとに、
そのユースケースで示される業務を実行するのにどれく
らいの時間がかかるか（例えば、最低でどれくらいの時
間がかかるか）を表した時間情報も記述する。

【００８９】構造化指定部１２は、要求仕様格納部２に
格納されている要求仕様の情報に対して利用、汎化、拡
張の何れかの関係を指定するものである。構造化指定部
１２は、これら３つの関係の種類を指定するだけでな
く、必要に応じて構造化を行う範囲も指定する。要求仕
様格納部２に格納されている元の要求仕様情報から構造
化指定部１２により生成された利用、汎化あるいは拡張
の関係を有する要求仕様情報も、要求仕様格納部２に格
納される。

【００９０】例えば、要求仕様格納部２に格納されてい
るあるユースケースのイベント列の中から共通サブユー
スケースを作成しようとするときは、構造化指定部１２
により利用関係を指定するとともに、作成対象とするイ
ベント列の範囲を指定する。さらに、要求仕様記述部１
１を用いて必要な事項（当該共通サブユースケースの目
的、事前条件、事後条件など）を記述することにより、
共通サブユースケースに関する要求仕様の情報が要求仕
様格納部２内に作られる。

【００９１】また、要求仕様格納部２に格納されている
あるユースケースを特殊化して別のユースケースを作成
しようとするときは、構造化指定部１２により汎化関係
を指定する。このとき、要求仕様格納部２には、特殊化
用のユースケースを格納するための領域が確保される
が、この段階では、元のユースケースを特殊化したもの
であることを示す情報のみがこの新たな記憶領域に格納
される。

【００９２】さらに、要求仕様記述部１１を用いて所望
の箇所を修正するとともに、必要な事項（当該特殊化ユ
ースケースの目的、事前条件、事後条件など）を記述す
ることにより、特殊化されたユースケースに関する要求
仕様の情報が要求仕様格納部２内に作られる。このとき
要求仕様格納部２に格納される情報は、当該要求仕様格
納部２に格納されている元のユースケースとの差分デー
タのみである。

【００９３】また、要求仕様格納部２に格納されている
あるユースケースを拡張して別のユースケースを作成し
ようとするときは、構造化指定部１２により拡張関係を
指定する。さらに、要求仕様記述部１１を用いて必要な
事項（当該拡張ユースケースの目的、事前条件、拡張ユ
ースケースの基本系列、事後条件など）を記述すること
により、拡張ユースケースに関する要求仕様の情報が要
求仕様格納部２内に作られる。

【００９４】モード指定部１３は、ユースケース実行部
３や分岐選択部４を用いて要求仕様中に含まれる各ユー
スケースを順次実行してその実行過程を記録する際に、
簡易なログをとる簡易モードと、詳細なログをとる詳細
モードとの何れかを指定するものである。このモード指
定部１３により指定されたモード情報は、ユースケース
実行部３および分岐選択部４に伝えられ、指定されたモ
ードに応じた処理がこのユースケース実行部３および分
岐選択部４において行われる。

【００９５】上記簡易モードは、第１の実施形態のよう
に、基本系列のユースケースと代替系列のユースケース
との間に張られたリンクに従って、あるユースケースか
らそのリンク先のユースケースを順次読み出しながらシ
ナリオを作っていくモードである。この簡易モードを指
定したときに生成されるシナリオは、図５のようにユー
スケース間の流れのみを示したものである。

【００９６】一方、詳細モードは、基本系列のユースケ
ースと代替系列のユースケースとの間に張られたリンク
に加え、構造化されたユースケースの利用、汎化、拡張
の関係（リンク）に従って、あるユースケース内のイベ
ントからそのリンク先のユースケースを順次読み出しな
がらシナリオを作っていくモードである。構造化された
ユースケース間の関係は、上述したように、あるユース
ケースを構成するイベントと他のユースケースとの間に
張られた関係である。したがって、この詳細モードを指
定したときに生成されるシナリオは、図１２に示すよう
に、ユースケースの流れだけでなく、更に各ユースケー
ス内に含まれるイベントの流れまで示したものとなる。

【００９７】図１２に示すシナリオ００１では、ユース
ケース００１のイベント１およびイベント２の処理を行
った段階でユースケース００５のイベント１〜３の処理
を実行し、その後再びユースケース００１に戻り、イベ
ント３から処理を続行していることが履歴として記録さ
れている。このように、本実施形態のシナリオによれ
ば、処理の流れがより詳細に分かるようになり、ユース
ケースの記述漏れや未実行のユースケースなど、要求仕
様が適切に記述されているかどうかのチェックをより詳
細に行うことができる。

【００９８】図１３は、詳細モードでシナリオを生成す
る際のユースケース実行部３の動作を示すフローチャー
トである。図１３において、ユーザにより特定のユース
ケースが指定されてシナリオ生成の実行が指示される
と、ユースケース実行部３は、ステップＳ１１で、その
指定されたユースケースを要求仕様格納部２の中から読
み出す。そして、ステップＳ１２で、その読み出したユ
ースケースに対して拡張ユースケースが定義されている
かどうかを判断する。

【００９９】ここで、拡張ユースケースが定義されてい
る場合は、ステップＳ１３に進み、図４に示したような
分岐マークを付与して表示するとともに、ステップＳ１
４で、その拡張ユースケース内の先頭のイベントと、拡
張の対象となっている元のユースケース内のイベントと
を含む複数の選択肢（選択メニュー）をポップアップ表
示する。

【０１００】そして、ステップＳ１５で、表示された選
択肢の中から拡張ユースケースのイベントが選択された
かどうかを判断し、拡張ユースケースのイベントが選択
された場合は、ステップＳ１１に戻り、その選択された
拡張ユースケースを要求仕様格納部２の中から読み出
す。そして、その読み出した拡張ユースケースに対して
以上と同様の処理を行う。一方、拡張ユースケースのイ
ベントが選択されていない場合は、ステップＳ１６で元
のユースケースの実行に戻り、ステップＳ１８に進む。

【０１０１】また、上記ステップＳ１２において、要求
仕様格納部２の中から読み出したユースケースに対して
拡張ユースケースが定義されていないと判断した場合
は、ステップＳ１７で、その読み出したユースケース中
に記述されている事前条件を表示した後、ステップＳ１
８に進む。

【０１０２】ステップＳ１８では、対象としているユー
スケースが別のユースケースを特殊化したものであるか
どうかを判断する。ここで、別のユースケースを特殊化
したものである場合は、ステップＳ１９に進み、継承元
のユースケースとそれを特殊化したユースケースの差分
データとを要求仕様格納部２の中から読み出す。そし
て、ステップＳ２０で、上記読み出した継承元のユース
ケースと特殊化したユースケースの差分データとを合わ
せて特殊化したユースケースを作成する。

【０１０３】さらに、ステップＳ２１で、上記作成した
特殊化ユースケース中に記述されている事前条件を表示
した後、ステップＳ２２に進む。一方、上記ステップＳ
１８において、対象としているユースケースが別のユー
スケースを特殊化したものでないと判断した場合は、上
記ステップＳ１９〜Ｓ２１の処理は行うことなく、ステ
ップＳ２２に進む。

【０１０４】ステップＳ２２では、現在対象としている
ユースケース中に代替系列が定義されているかどうかを
判断し、定義されていない場合にはステップＳ２６に進
み、基本系列を表示する。一方、代替系列がある場合に
は、ステップＳ２３に進み、図４に示したような分岐マ
ークを付与して表示するとともに、ステップＳ２４で、
その代替系列のイベントと、代替の対象となっている基
本系列のイベントとを含む複数の選択肢（選択メニュ
ー）をポップアップ表示する。

【０１０５】そして、ステップＳ２５で、表示された選
択肢の中から基本系列あるいは代替系列のどちらが選択
されたかを判断し、基本系列が選択された場合は、ステ
ップＳ２６に進み、その選択された基本系列のイベント
を表示する。さらに、ステップＳ２８で、拡張ユースケ
ースがあるかどうかを判断し、ある場合にはステップＳ
１１に戻るが、ない場合にはステップＳ２９に進む。

【０１０６】ステップＳ２９では、利用するユースケー
スがあるかどうかを判断し、ない場合にはステップＳ３
０に進んでユースケースの終了を判定し、終了していな
ければステップＳ２２に戻り、上述の動作を再び実行す
る。

【０１０７】上記ステップＳ３０でユースケースが終了
していると判断されたときは、ステップＳ３１に進み、
その終了したユースケースが最初に起動したユースケー
スかどうかを判定し、最初に起動したものであれば、処
理は終了する。また、最初に起動したユースケースでな
い場合は、ステップＳ３２に進み、１つ上の階層のユー
スケースである元のユースケースの実行に戻り、その後
ステップＳ２２に戻って上述の動作を再び実行する。

【０１０８】一方、上記ステップＳ２９で、利用するユ
ースケースがあると判断した場合は、ステップＳ１１に
戻り、その別のユースケースを要求仕様格納部２から新
たに読み出す。そして、ステップＳ１２以降の処理をそ
の新たなユースケースについて同様に行う。

【０１０９】また、上記ステップＳ２５で代替系列が選
択された場合は、ステップＳ２７に進み、その選択され
た代替系列のイベントをそれまでの表示に続けて表示す
る。さらに、ステップＳ２８で、拡張ユースケースがあ
るかどうかを判断し、ない場合にはステップＳ２９で更
に利用するユースケースがあるかどうかを判断する。利
用するユースケースがある場合にはステップＳ１１に戻
ってその別のユースケースを要求仕様格納部２から新た
に読み出して、ステップＳ１２以降の処理をその新たな
ユースケースについて同様に行う。一方、利用するユー
スケースがない場合は、ステップＳ３０に進み、それ以
降は上述した処理を実行する。

【０１１０】この図１３に示すような動作をユースケー
ス実行部３が実行することにより、複数のユースケース
のイベントがユーザとの対話的処理により順次実行され
ていく。このとき図１１のログ記録部５が、実行された
各ユースケースおよび各イベントをそれらが実行される
毎にシナリオ記憶部６にログとして記録していくことに
より、ユースケースとその内部のイベントの実行過程を
表したシナリオが自動的に生成される。つまり、ユーザ
が必要に応じて分岐先を選択するだけで、システムの動
きを表す詳細なシナリオを生成することができる。

【０１１１】図１１の説明に戻る。総時間演算部１４
は、シナリオ記憶部６に記憶されたシナリオを用いて、
そのシナリオ通りに一連の処理を実行した場合に必要な
トータルの要処理時間を演算するものである。すなわ
ち、本実施形態では、個々のユースケースごとに、その
ユースケースの業務を実行するのにかかる時間が要求仕
様記述部１１により記述されている。そこで、総時間演
算部１４では、シナリオ中に含まれる各ユースケースの
処理に必要な時間を合計することにより、そのシナリオ
のように業務を遂行した場合の仮想的な総実行時間を算
出する。

【０１１２】このように、生成されたシナリオを実行す
るのに必要なトータルの要処理時間を算出することによ
り、現行業務の分析、システム化に対する要求の妥当性
あるいは実現可能性などを判断する際の１つの目安を得
ることができる。例えば、シナリオを実行するのに非常
に多くの時間がかかってしまうことが判明した場合に、
そのシナリオを修正する、あるいは作り直すなどの対応
をとることが可能となる。なお、ここでは個々のユース
ケース毎にその処理時間を設定するようにしているが、
ユースケース内の個々のイベント毎にその処理時間を設
定するようにしても良い。

【０１１３】重要度／利用頻度設定部１５は、シナリオ
記憶部６に記憶されたシナリオに対して、重要度や利用
頻度等を設定するものである。また、シナリオ解析部１
６は、上記重要度／利用頻度設定部１５によりシナリオ
に設定された重要度や利用頻度等を解析し、当該シナリ
オに含まれる個々のユースケースの重要度や利用頻度等
を求めるものである。

【０１１４】上記シナリオ解析部１６は、あらかじめ設
定されたロジックに従って個々のユースケースに重要度
や利用頻度等を設定する。例えば、シナリオ解析部１６
は、重要度／利用頻度設定部１５によってシナリオに設
定された重要度や利用頻度の値を、当該シナリオに含ま
れる個々のユースケースにそのまま設定する。ここで、
複数のシナリオに同じユースケースが含まれる場合にお
いて、それぞれのシナリオに異なる重要度が設定された
ときには、最大の重要度をそのユースケースに設定す
る。また、複数のシナリオで利用される回数が所定値よ
り大きいユースケースについては、そのユースケースを
含むシナリオに設定された重要度よりも高い重要度を設
定するなどのロジックを用いても良い。

【０１１５】要求仕様を作成する際、作成した要求仕様
の内容を後からチェックするためなどの便宜上から、個
々のユースケースに重要度や利用頻度を設定することが
行われる。例えば、業務の流れとして重要なユースケー
ス、あるいは従来手作業で行っていて処理が煩雑なので
システム化の要望が大きいユースケースなどには、値の
大きな重要度が設定される。

【０１１６】通常、このような重要度や利用頻度等は、
要求仕様記述部１１によって個々のユースケース毎に設
定されるが、ユースケースの数が多くなってくると、そ
の作業は非常に煩雑なものとなる。また、要求仕様を記
述するオペレータが個々のユースケース毎に重要度や利
用頻度等を判断することは必ずしも容易でない。

【０１１７】本実施形態では、個々のユースケースに対
して重要度や利用頻度等を設定することも勿論可能であ
るが、重要度／利用頻度設定部１５を用いることによ
り、作成されたシナリオに対して重要度や利用頻度等を
設定できるようにしている。これにより、全てのユース
ケースを網羅するシナリオが全ユースケース数よりも少
ない数で実現できた場合には、それらのシナリオに対し
て重要度や利用頻度等を設定することにより、その設定
作業を簡易にすることができる。

【０１１８】また、個々のユースケース毎に細かく見る
のではなく、ユースケースの流れを表したシナリオに基
づき重要度や利用頻度等を全体として見ることができる
ので、重要度や利用頻度等がユーザにとって分かりやす
く、これらの設定を行いやすくすることができる。

【０１１９】なお、本実施形態で設定する処理時間、重
要度、利用頻度は単なる例に過ぎない。すなわち、個々
のユースケースに対して値を定義（または計測）する方
が簡単で、それをもとにシナリオに対する値を算出で
き、そちらの方が値として意味があるもの、またはその
逆に、シナリオに対して値を定義（または計測）する方
が簡単で、それをもとに個々のユースケースに対する値
を算出でき、そちらの方が値として意味があるものであ
れば、何れにも適用することが可能である。

【０１２０】（本発明の他の実施形態）なお、以上に説
明した本実施形態の要求仕様記述支援装置は、コンピュ
ータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構
成されるものであり、ＲＡＭやＲＯＭに記憶されたプロ
グラムが動作することによって実現できる。したがっ
て、コンピュータが上記機能を果たすように動作させる
プログラムを、例えばＣＤ−ＲＯＭのような記録媒体に
記録し、コンピュータに読み込ませることによって実現
できるものである。記録媒体としては、ＣＤ−ＲＯＭ以
外に、フロッピー（登録商標）ディスク、ハードディス
ク、磁気テープ、光磁気ディスク、不揮発性メモリカー
ド等を用いることができる。

【０１２１】また、コンピュータが供給されたプログラ
ムを実行することにより上述の実施形態の機能が実現さ
れるだけでなく、そのプログラムがコンピュータにおい
て稼働しているＯＳ（オペレーティングシステム）ある
いは他のアプリケーションソフト等と共同して上述の実
施形態の機能が実現される場合や、供給されたプログラ
ムの処理の全てあるいは一部がコンピュータの機能拡張
ボードや機能拡張ユニットにより行われて上述の実施形
態の機能が実現される場合も、かかるプログラムは本発
明の実施形態に含まれる。

【０１２２】また、本発明をネットワーク環境で利用す
るべく、全部あるいは一部のプログラムが他のコンピュ
ータで実行されるようになっていても良い。例えば、画
面入力処理は、遠隔端末コンピュータで行われ、各種判
断、ログ記録等は他のセンターコンピュータ等で行われ
るようにしても良い。

【０１２３】なお、上記に示した実施形態は、何れも本
発明を実施するにあたっての具体化の一例を示したもの
に過ぎず、これらによって本発明の技術的範囲が限定的
に解釈されてはならないものである。すなわち、本発明
はその精神、またはその主要な特徴から逸脱することな
く、様々な形で実施することができる。

【０１２４】

【発明の効果】本発明は上述したように、所定の基準に
従ってユースケースの形で記述された要求仕様に基づい
て、上記要求仕様中に含まれる各ユースケースを順次実
行し、その実行過程を記録するようにしたので、ユース
ケースを順次実行していくだけで、システムの動きを表
すシナリオを容易に生成することができる。そして、こ
の生成されたシナリオを参照することにより、ユースケ
ースの抜けや記述漏れがないかどうか等を確認すること
ができる。

【０１２５】これにより、要求仕様が適切に書かれてい
るかどうかのチェックを容易に行うことができ、必要に
応じてそのチェック結果を要求仕様の記述にフィードバ
ックすることにより、システムを開発する上で必要な要
求仕様を正確に記述することができる。したがって、そ
の後の設計段階や実装段階で手戻り作業が発生してしま
う不都合を未然に防止することができ、従来に比べてシ
ステムの開発コストを大幅に削減することができる。

【０１２６】本発明の他の特徴によれば、ユースケース
の形で記述された要求仕様の各構成要素について、利
用、汎化、拡張の少なくとも１つの関係を用いて各構成
要素を構造化するようにしたので、構造化されたユース
ケースの利用、汎化、拡張の関係に従って、あるユース
ケース内のイベントからそのリンク先のユースケースを
順次読み出しながらその過程を履歴として記録していく
ことができ、その結果、ユースケースの流れだけでな
く、更に各ユースケース内に含まれるイベントの流れま
で表した詳細なシナリオを生成することができる。これ
により、処理の流れがより詳細に分かるようになり、シ
ステムを開発する上で必要な要求仕様に関してユースケ
ースの記述漏れや未実行のユースケースがないかなど、
要求仕様が適切に記述されているかどうかのチェックを
より詳細に行って、要求仕様を正確に記述することがで
きる。

【０１２７】本発明のその他の特徴によれば、要求仕様
を記述する際に、個々のユースケース毎にその処理時間
を記述し、ユースケースの実行に伴い履歴として記録さ
れたシナリオについて、その一連の処理を行うのにかか
る総処理時間を演算するようにしたので、そのシナリオ
の善し悪しを判断するための１つの指標を得ることがで
きる。これにより、その指標に基づき要求仕様の修正の
必要性などを判断し、必要に応じて要求仕様をより適切
なものに記述し直すことができるようになる。

【０１２８】本発明のその他の特徴によれば、生成され
た履歴に対して重要度および利用頻度の少なくとも一方
を設定し、この重要度や利用頻度が設定された履歴を解
析して、その履歴に含まれる個々のユースケースの重要
度および利用頻度を求めるようにしたので、各ユースケ
ースに対して重要度や利用頻度等を個別に設定する場合
と比べて、重要度や利用頻度等の設定作業を簡易にする
ことができるとともに、その設定をユーザにとって分か
りやすくすることができ、これらの設定を行いやすくす
ることができる。

【図面の簡単な説明】

【図１】本発明による要求仕様記述支援装置の要素的特
徴を表す機能構成ブロック図である。

【図２】基本系列を含むユースケースの入力画面の例を
示す図である。

【図３】代替系列の入力画面の例を示す図である。

【図４】本実施形態の要求仕様記述支援装置がユーザと
の対話的処理によりシナリオを生成している途中の画面
例を示す図である。

【図５】第１の実施形態によるシナリオの生成結果の例
を示す図である。

【図６】図１のユースケース実行部が行う動作を示すフ
ローチャートである。

【図７】第２の実施形態によるユースケースの入力画面
の例を示す図である。

【図８】共通サブユースケースを作成する際の動作を説
明するための図である。

【図９】特殊化されたユースケースを作成する際の動作
を説明するための図である。

【図１０】拡張されたユースケースを作成する際の動作
を説明するための図である。

【図１１】第２の実施形態による要求仕様記述支援装置
の要素的特徴を表す機能構成ブロック図である。

【図１２】第２の実施形態によるシナリオの生成結果の
例を示す図である。

【図１３】図１１のユースケース実行部が行う動作を示
すフローチャートである。

【符号の説明】

１ 要求仕様記述部 ２ 要求仕様格納部 ３ ユースケース実行部 ４ 分岐選択部 ５ ログ記録部 ６ シナリオ記憶部 ７ シナリオ出力部 ８ 条件設定部 １１ 要求仕様記述部 １２ 構造化指定部 １３ モード指定部 １４ 総時間演算部 １５ 重要度／利用頻度設定部 １６ シナリオ解析部 ２１ ツリー構造表示画面 ２２ａ ユースケース用タグ ２２ｂ ビジネスモデル用タグ ２３ ユースケース入力画面 ３１ イベント欄 ３２ アクタ欄 ３３ 利用ＵＣ欄 ３４ 利用ＵＣ作成ボタン ３５ 特殊化ボタン ３６ 拡張ボタン

───────────────────────────────────────────────────── フロントページの続き (72)発明者 野口 正浩 東京都千代田区大手町２−６−３ 新日本 製鐵株式会社内 (72)発明者 池田 佳隆 東京都千代田区大手町２−６−３ 新日本 製鐵株式会社内 Ｆターム(参考） 5B076 DB07 DC02 DC09 DD02

Claims (23)

【特許請求の範囲】
1. 【請求項１】 所定の基準に従ってユースケースの形で
   記述された要求仕様に基づいて、上記要求仕様中に含ま
   れる各ユースケースを順次実行するユースケース実行手
   段と、 上記ユースケース実行手段による上記各ユースケースの
   実行過程を記録して履歴をとる履歴記録手段とを備えた
   ことを特徴とする要求仕様記述支援装置。
2. 【請求項２】 上記ユースケースの実行過程で現れる分
   岐において、次に実行するユースケースをユーザに選択
   させる分岐選択手段を備え、 上記ユースケース実行手段は、ユーザとの対話的処理に
   より各ユースケースを順次実行することを特徴とする請
   求項１に記載の要求仕様記述支援装置。
3. 【請求項３】 上記ユースケース実行手段は、上記ユー
   スケースの実行過程で現れる分岐において次に実行する
   ユースケースを自動的に選択して、上記要求仕様中に含
   まれる各ユースケースを順次実行することを特徴とする
   請求項１に記載の要求仕様記述支援装置。
4. 【請求項４】 上記要求仕様中に含まれる各ユースケー
   スを実行する上での条件を上記ユースケース実行手段に
   対して与える条件設定手段を備え、 上記ユースケース実行手段は、与えられた条件の範囲内
   で、上記ユースケースの実行過程で現れる分岐において
   次に実行するユースケースを自動的に選択して各ユース
   ケースを順次実行することを特徴とする請求項１に記載
   の要求仕様記述支援装置。
5. 【請求項５】 上記ユースケース実行手段は、上記ユー
   スケースの実行過程で現れる分岐において、次に実行す
   るユースケースとして取り得る全ての分岐先を自動的に
   順次選択して、上記要求仕様中に含まれる各ユースケー
   スを順次実行することを特徴とする請求項３または４に
   記載の要求仕様記述支援装置。
6. 【請求項６】 基本的な流れを表す基本系列のユースケ
   ースと、例外的な流れを表す代替系列のユースケースと
   を相互に関連付けて記述できるようになされた上記所定
   の基準に従って上記要求仕様を記述する要求仕様記述手
   段を備えたことを特徴とする請求項１〜５の何れか１項
   に記載の要求仕様記述支援装置。
7. 【請求項７】 上記ユースケースの形で記述された要求
   仕様の各構成要素について、ある構成要素から他の構成
   要素を利用する利用関係、元の構成要素に対して部分的
   な変更を加えて新たな構成要素を作る汎化関係、ある構
   成要素において特定の条件を満たしたときに別の構成要
   素の処理を行う拡張関係の少なくとも１つを用いて上記
   各構成要素を構造化する構造化手段を備えたことを特徴
   とする請求項１〜６の何れか１項に記載の要求仕様記述
   支援装置。
8. 【請求項８】 上記利用関係および上記拡張関係につい
   ては、上記ユースケース内のイベントと他のユースケー
   スとの関係を構造化することを特徴とする請求項７に記
   載の要求仕様記述支援装置。
9. 【請求項９】 上記ユースケース実行手段は、上記構造
   化手段により構造化されたユースケースの利用、汎化、
   拡張の関係に従って、あるユースケース内のイベントか
   ら他のユースケースに分岐して各ユースケースを順次実
   行していくことを特徴とする請求項８に記載の要求仕様
   記述支援装置。
10. 【請求項１０】 基本系列のユースケースと代替系列の
    ユースケースとの間に張られた関連に従って、あるユー
    スケースから他のユースケースに分岐して各ユースケー
    スを順次実行していく第１のモードと、上記構造化手段
    により構造化されたユースケースの利用、汎化、拡張の
    関係に従って、あるユースケース内のイベントから他の
    ユースケースに分岐して各ユースケースを順次実行して
    いく第２のモードとを有することを特徴とする請求項８
    に記載の要求仕様記述支援装置。
11. 【請求項１１】 上記要求仕様を記述する際に、個々の
    ユースケース毎にその処理時間を記述する要求仕様記述
    手段と、 上記要求仕様記述手段により記述された個々のユースケ
    ースの処理時間に基づいて、上記履歴記録手段により記
    録された履歴により示される一連の処理を行うのにかか
    る総処理時間を演算する総時間演算手段とを備えたこと
    を特徴とする請求項１〜１０の何れか１項に記載の要求
    仕様記述支援装置。
12. 【請求項１２】 上記履歴記録手段により記録された履
    歴に対して重要度および利用頻度の少なくとも一方を設
    定する重要度／利用頻度設定手段と、 上記重要度および利用頻度の少なくとも一方が設定され
    た履歴を解析して、その履歴に含まれる個々のユースケ
    ースの重要度および利用頻度の少なくとも一方を求める
    履歴解析手段とを備えたことを特徴とする請求項１〜１
    １の何れか１項に記載の要求仕様記述支援装置。
13. 【請求項１３】 所定の基準に従ってユースケースの形
    で記述された要求仕様に基づいて、上記要求仕様中に含
    まれる各ユースケースを順次実行し、その実行過程を記
    録するようにしたことを特徴とする要求仕様記述支援方
    法。
14. 【請求項１４】 上記ユースケースの実行過程で現れる
    分岐において、次に実行するユースケースをユーザに選
    択させることにより、ユーザとの対話的処理により各ユ
    ースケースを順次実行するようにしたことを特徴とする
    請求項１３に記載の要求仕様記述支援方法。
15. 【請求項１５】 上記ユースケースの実行過程で現れる
    分岐において次に実行するユースケースを自動的に選択
    して各ユースケースを順次実行するようにしたことを特
    徴とする請求項１３に記載の要求仕様記述支援方法。
16. 【請求項１６】 上記ユースケースの形で記述された要
    求仕様の各構成要素について、ある構成要素から他の構
    成要素を利用する利用関係、元の構成要素に対して部分
    的な変更を加えて新たな構成要素を作る汎化関係、ある
    構成要素において特定の条件を満たしたときに別の構成
    要素の処理を行う拡張関係の少なくとも１つを用いて上
    記各構成要素を構造化するようにしたことを特徴とする
    請求項１３〜１５の何れか１項に記載の要求仕様記述支
    援方法。
17. 【請求項１７】 上記利用関係および上記拡張関係につ
    いては、上記ユースケース内のイベントと他のユースケ
    ースとの関係を構造化し、当該構造化されたユースケー
    スの利用、汎化、拡張の関係に従って、あるユースケー
    ス内のイベントから他のユースケースに分岐して各ユー
    スケースを順次実行していくようにしたことを特徴とす
    る請求項１６に記載の要求仕様記述支援方法。
18. 【請求項１８】 上記要求仕様を記述する際に、個々の
    ユースケース毎にその処理時間を記述するようにし、 上記記述された個々のユースケースの処理時間に基づい
    て、上記各ユースケースの実行過程が記録された履歴に
    より示される一連の処理を行うのにかかる総処理時間を
    演算するようにしたことを特徴とする請求項１３〜１７
    の何れか１項に記載の要求仕様記述支援方法。
19. 【請求項１９】 上記各ユースケースの実行過程が記録
    された履歴に対して重要度および利用頻度の少なくとも
    一方を設定し、上記重要度および利用頻度の少なくとも
    一方が設定された履歴を解析して、その履歴に含まれる
    個々のユースケースの重要度および利用頻度の少なくと
    も一方を求めるようにしたことを特徴とする請求項１３
    〜１８の何れか１項に記載の要求仕様記述支援方法。
20. 【請求項２０】 所定の基準に従ってユースケースの形
    で記述された要求仕様に基づいて、上記要求仕様中に含
    まれる各ユースケースを順次実行するユースケース実行
    手段と、 上記ユースケース実行手段による上記各ユースケースの
    実行過程を記録して履歴をとる履歴記録手段としてコン
    ピュータを機能させるためのプログラムを記録したこと
    を特徴とするコンピュータ読み取り可能な記録媒体。
21. 【請求項２１】 上記ユースケースの形で記述された要
    求仕様の各構成要素について、ある構成要素から他の構
    成要素を利用する利用関係、元の構成要素に対して部分
    的な変更を加えて新たな構成要素を作る汎化関係、ある
    構成要素において特定の条件を満たしたときに別の構成
    要素の処理を行う拡張関係の少なくとも１つを用いて上
    記各構成要素を構造化する構造化手段としての機能を更
    にコンピュータに実現させるためのプログラムを記録し
    たことを特徴とする請求項２０に記載のコンピュータ読
    み取り可能な記録媒体。
22. 【請求項２２】 上記要求仕様を記述する際に、個々の
    ユースケース毎にその処理時間を記述する要求仕様記述
    手段と、 上記要求仕様記述手段により記述された個々のユースケ
    ースの処理時間に基づいて、上記履歴記録手段により記
    録された履歴により示される一連の処理を行うのにかか
    る総処理時間を演算する総時間演算手段としての機能を
    更にコンピュータに実現させるためのプログラムを記録
    したことを特徴とする請求項２０または２１に記載のコ
    ンピュータ読み取り可能な記録媒体。
23. 【請求項２３】 上記履歴記録手段により記録された履
    歴に対して重要度および利用頻度の少なくとも一方を設
    定する重要度／利用頻度設定手段と、 上記重要度および利用頻度の少なくとも一方が設定され
    た履歴を解析して、その履歴に含まれる個々のユースケ
    ースの重要度および利用頻度の少なくとも一方を求める
    履歴解析手段としての機能を更にコンピュータに実現さ
    せるためのプログラムを記録したことを特徴とする請求
    項２０〜２２の何れか１項に記載のコンピュータ読み取
    り可能な記録媒体。