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

Description

【０００１】
【発明の属する技術分野】
本発明は要求仕様記述支援装置およびその方法、記録媒体に関し、特に、ソフトウェア等のシステム開発で用いる要求仕様の記述を支援するための装置に用いて好適なものである。
【０００２】
【従来の技術】
一般に、コンピュータを利用したシステム開発は、その要求仕様の定義から基本設計、詳細設計などの過程を経て最終的にコーディングされ、必要に応じてデバッグされて完成となる。この中で、特に要求仕様の定義は、システム開発を行う上で非常に重要な意味を持つものである。すなわち、要求仕様の中で曖昧な記述や誤解を生じるような記述をしていると、その内容をもとに設計され作成されたシステムは、全く使えないものか、ユーザの全く期待していなかったものになってしまうことが多い。
【０００３】
また、要求仕様をきちんと記述していない場合、システム開発においてその要求定義の問題が発覚するのは、設計が終わったとき、あるいはコーディングを開始してからであることが多いが、この段階で間違いを直すのは簡単ではなく、莫大な開発コストがかかる。これに対して、最初の要求仕様をきちんと記述しておけば、その後で発生する手戻り作業を極力抑えることができる。したがって、要求仕様をきちんと記述しておくことは、極めて重要であると言える。
【０００４】
従来、要求仕様は、システム開発の前段階において、現状システムと改善後のシステム、あるいは新しいシステムの内容などについて、システムが備える機能を中心として、人間が行う作業、データの発生や流れ、データの出力などを人間の言葉や図面を用いて記述していた。また、最近では、要求仕様を記述するのに種々の方法が用いられるようになってきており、その中の１つに、システムの機能ではなく用途に着目して記述を行うユースケースと呼ばれるものも登場してきている。
【０００５】
【発明が解決しようとする課題】
しかしながら、要求仕様の記述方法としては色々なものがあるが、何れの方法によっても、その記述された内容からシステム設計に漏れや誤り等がないかどうかをチェックするのは、人手によっていた。例えば、要求仕様として記述された文章や図面そのものを人間が見て、そこからデータの発生、利用関係、出力等や、誰が何を入力してどんな作業を行うのかなどの色々なチェックをその人間の判断で行っていた。
【０００６】
ところが、これらのチェックは、人間が手作業で行うものなので、見落としや間違いなどが発生しやすい。また、コンピュータ等を利用してもある程度はチェックできるが、どのように行えばチェックが正確かつ容易になるかは、明確でなかった。特に、作成した要求仕様に基づきシステムの動きをチェックすることは、要求仕様の記述の間違いや抜け等をチェックする上で重要であるが、これは非常に面倒で、時間のかかるものであった。
【０００７】
本発明は、このような実情に鑑みて成されたものであり、一定の基準に基づいて記述されたシステムの要求仕様から、システムの動きを表すシナリオを容易に生成できるようにすることにより、正確な要求仕様を記述することを支援できるようにした要求仕様記述支援装置および方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明の要求仕様記述支援装置は、複数のユースケースにより構成される要求仕様の記述を支援するための要求仕様記述支援装置であって、所定のフォーマットに従って自然言語で記述された上記複数のユースケースと、上記複数のユースケース間に予め設定されたリンク先を表すリンク情報とを記憶する記憶手段と、上記リンク情報に従ってリンク先のユースケースを順次読み出すユースケース実行手段と、上記ユースケース実行手段によってユースケースが読み出された過程を特定可能な履歴を履歴記憶手段に記録する履歴記録手段と、を備えたことを特徴とする。
本発明の要求仕様記述支援方法は、複数のユースケースにより構成される要求仕様の記述を支援するための要求仕様記述支援装置であって、所定のフォーマットに従って自然言語で記述された上記複数のユースケースと、上記複数のユースケース間に予め設定されたリンク先を表すリンク情報とを記憶する記憶手段と、ユースケース実行手段と、履歴記録手段と、履歴記憶手段とを備えた要求仕様記述支援装置によって実行される要求仕様記述支援方法であって、上記ユースケース実行手段が、上記リンク情報に従ってリンク先のユースケースを順次読み出すユースケース実行ステップと、上記履歴記録手段が、上記ユースケース実行ステップによってユースケースが読み出された過程を特定可能な履歴を上記履歴記憶手段に記録する履歴記録ステップとを備えたことを特徴とする。
本発明のコンピュータ読み取り可能な記録媒体は、コンピュータを、複数のユースケースにより構成される要求仕様の記述を支援するための要求仕様記述支援装置として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、コンピュータを、所定のフォーマットに従って自然言語で記述された上記複数のユースケースと、上記複数のユースケース間に予め設定されたリンク先を表すリンク情報とを記憶する記憶手段と、上記リンク情報に従ってリンク先のユースケースを順次読み出すユースケース実行手段と、上記ユースケース実行手段によってユースケースが読み出された過程を特定可能な履歴を履歴記憶手段に記録する履歴記録手段として機能させるためのプログラムを記録したことを特徴とする。
【００２５】
本発明は上記技術手段より成るので、所定の基準に従って記述された要求仕様中に含まれる各ユースケースが順次実行される過程で、実行されたユースケースが順次履歴として記録されていくこととなり、その結果、ユースケースの実行の流れ、つまりシステムの動きを表すシナリオが生成される。なお、ここで言う所定の基準とは、例えば、要求仕様の記述中にユースケース間のリンク情報が含まれるように定められたものであり、またユースケースの実行とは、例えばリンク先のユースケースを読み込んで表示することを言う。ユーザは、このように生成されたシナリオを参照することによって、本来あるべきユースケースに漏れがないかどうかとか、未実行のユースケースがないかどうかなどを確認することで、要求仕様が適切に書かれているかどうかをチェックすることが可能となる。
【００２６】
本発明の他の特徴によれば、構造化されたユースケースの利用、汎化、拡張の関係に従って、あるユースケース内のイベントからそのリンク先のユースケースを読み出しながら各ユースケースが順次実行され、その実行過程が履歴として記録されていくこととなり、その結果、ユースケースの流れだけでなく、更に各ユースケース内に含まれるイベントの流れまで表すシナリオが生成される。これにより、各ユースケースによる処理の流れがより詳細に分かるようになる。
【００２７】
本発明のその他の特徴によれば、生成されたシナリオを用いて、そのシナリオ通りに一連の処理を実行した場合に必要な総処理時間が演算される。このように、生成されたシナリオを実行するのに必要な総処理時間を算出することにより、現行業務の分析、システム化に対する要求の妥当性あるいは実現可能性などを判断するための１つの指標を得ることができる。
【００２８】
本発明のその他の特徴によれば、個々のユースケースに対して重要度や利用頻度等を設定するのではなく、生成されたシナリオに対して重要度や利用頻度等を設定すると、その設定内容から個々のユースケースの重要度や利用頻度等が求められることとなる。これにより、重要度や利用頻度等の設定作業を簡易にすることが可能となるとともに、その設定をユーザにとって分かりやすいものとすることが可能となる。
【００２９】
【発明の実施の形態】
以下、本発明の一実施形態について図面を参照しながら説明する。
【００３０】
（第１の実施形態）
図１は、本発明の第１の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
図１において、要求仕様記述部１は、あらかじめ定められた所定のフォーマットに従って、要求仕様をユースケースの形で記述するものである。ここで、ユースケースとは、開発するシステムが業務上どのように利用されるのかという点に着目して、システムの稼働時にオペレータが行う一連のアクション（イベント）等を、トランザクション毎に自然言語で記述したものを言う。
【００３１】
図２は、本実施形態による要求仕様の入力画面の例を示す図である。図２において、ツリー構造表示画面２１は、あるシステムの開発プロジェクトについて定義した要求仕様モデルをツリー構造にて表示するための画面である。この画面２１の下方には、タグ２２ａ，２２ｂが設けられており、一方のタグ２２ａをクリックすると、図２に示されるようにユースケースの入力画面となり、もう一方のタグ２２ｂをクリックすると、図示しないビジネスルールの入力画面となる。なお、ビジネスルールは、開発されたシステムによって業務を遂行する上で守るべきルールを示すものである。
【００３２】
図２の例では、プログラミングの教育システムを開発するプロジェクトにおいて要求仕様として定義する情報の例を示しており、上記ツリー構造表示画面２１内には、そのプロジェクトにおけるユースケースの利用関係とアクタ（ユースケース中のそれぞれのアクションを誰が行うかを示すもの）の一覧とが示されている。すなわち、ここに示されるツリー構造としては、“プロジェクト”の下層に“ユースケース”と“アクタ”があり、上記“ユースケース”の下層に“外部”、“内部”および“情報システム”がある。
【００３３】
更にここでは、ユースケース“外部”の中のユースケースの利用関係を特に示している。すなわち、ユースケース“外部”と書かれた階層の下の階層には、“演習問題の提供”、“評価”および“○○知識獲得”というユースケースがあり、上記“演習問題の提供”の下の階層には更に“事前準備”および“演習問題の公開”というユースケースがある。さらに、上記“演習問題の公開”の下の階層には更に“演習問題の実装”というユースケースがある。
【００３４】
このように、ある業務システムを作成する１つのプロジェクトに関する要求仕様は、システム上で行う個々の業務を単位として記述した複数のユースケースから構成される。
ここで、例えばツリー構造表示画面２１内で任意のユースケースの部分をマウスでクリックすると、そのユースケースの入力画面２３がツリー構造表示画面２１の右側に表示される。
【００３５】
図２の例では、“演習問題の実装”というユースケースの部分がクリックされたときの様子を示している。このユースケース入力画面２３では、ユースケース名の表示の後に、目的、事前条件、基本系列、代替系列、事後条件およびデータの入力画面が表示される。なお、図２中では代替系列、事後条件およびデータの入力画面が表されていないが、これらはユースケース入力画面２３を下にスクロールさせると見えてくるようになっている。
【００３６】
上記ユースケース入力画面２３内の目的の欄には、そのユースケースにおいてどんな業務を行うのかの大まかな内容を定義する。また、事前条件の欄には、その業務を行うために事前に行われていることが必要な条件を定義する。図２の例では、“演習問題の実装”の目的である演習問題に対する解答の提出を行うための事前条件として、その演習問題が箇所研修生に公開されている、ということが定義されている。
【００３７】
また、事後条件の欄には、そのユースケースで定義されている動作を行った後にどんな状態となるかについて定義する。例えば、動作が成功に終わった場合と、失敗に終わった場合とに分けて、それぞれの場合にどういう状態となるかを定義する。なお、例えばここに、次に実行すべきユースケースを記述することにより、ユースケースのジャンプ先にリンクを張るようにしても良い。また、データの欄には、そのユースケースで定義されたアクション（イベント）を行う際に、どんなデータを入出力するかについて定義する。
【００３８】
また、基本系列の欄には、そのユースケースで誰が何を行うか等の具体的な内容を定義する。ここでは、業務の基本的な流れを表す具体的な動作の内容を示すイベントと、それを誰が行うかを表すアクタと、そのイベントを行う際に利用する他のユースケースとを各動作毎に順番に記述していく。なお、図２の例では、ツリー構造表示画面２１内から“箇所研修生”をドラッグしてきてアクタの欄に張り付けている状態を示している。
【００３９】
代替系列の欄も上記基本系列の欄と同様に、そのユースケースで誰が何を行うか等の具体的な内容を定義する。ただし、基本系列では業務の基本的な流れを表すイベントを記述するのに対して、代替系列では業務の例外的な流れを表すイベントを記述する点で異なる。図３は、この代替系列の入力画面の例を示す図である。
【００４０】
図３に示すように、代替系列の欄には、代替される対象となる基本系列の番号と、その基本系列のイベントの代わりに行われる具体的な動作の内容を表すイベントと、そのイベントを行う際に利用する他のユースケースと、イベント終了後の処理の内容を表す後処理とを各動作毎に順番に記述していく。
【００４１】
図３の例では、図２に示した上から３番目の基本系列の処理（解答の提出）を行う際に、どうしても解けない場合には講師に質問をするということが代替系列のイベントとして定義されている。また、その質問のイベントが終了した後は、上記３番目の基本系列の処理に戻るということが後処理として定義されている。なお、後処理の他の例として、例えばその代替系列のイベントが終わった後は基本系列に戻ることなくそのまま処理を終了するとか、他の基本系列あるいは代替系列のイベントにジャンプするということ等を定義できる。
【００４２】
このように、代替系列の欄において、代替の対象となる基本系列の番号や後処理などを記述することにより、基本系列のユースケースと代替系列のユースケースとの間にリンクが張られることになる。このように基本系列と代替系列との間でリンクが張られた部分は、後にユースケースの実行過程を表すをシナリオを生成する際に、次に実行するユースケースの分岐点として現れることとなる。
【００４３】
また、次に実行すべきユースケースの指定は、１つ上の階層のユースケースの利用ＵＣ（ユースケース）の欄に記述することにより行われる。利用されるユースケースの基本系列が終わった後は、利用元のユースケースの実行に戻り、最初に起動したユースケースの基本系列が全て終了すると、１つのシナリオが完成することになる。
【００４４】
以上のように、本実施形態では、図面等とは異なり、誰もが同じように理解できる自然言語で各種の情報を入力していくことによって要求仕様を記述するようにしているので、開発するシステムの機能とそれを用いて行う業務との対応関係を明確にすることができ、食い違いの発生を極力少なくすることができる。その際、あらかじめ定められた入力項目に対して記述を行えば良いので、ユースケースの記述がしやすく、簡単に入力することができる。また、図２に示すように、入力項目の記述をドラッグ＆ドロップ操作によって行うこともできるので、入力ミスを防止することもできる。
【００４５】
図１の要求仕様記述部１では、上記図２に示したフォーマット入力画面に基づいて、目的、条件、基本系列、代替系列、データなどの各種情報を含んだユースケースを業務単位毎に順次入力していくとともに、対応するビジネスルールを同じく業務単位毎に順次入力していく。要求仕様格納部２は、このように入力された要求仕様の情報を格納するためのものである。ここでは、定義された個々のユースケースおよびビジネスルール毎に要求仕様の情報が格納される。
【００４６】
ユースケース実行部３は、図２のように定められた一定の基準に従って記述され、要求仕様格納部２に格納された要求仕様の情報に基づいて、当該要求仕様中に含まれる各ユースケースを順次実行する。具体的には、各ユースケースの記述時に張られたリンクに従って、リンク先のユースケースを順次読み出してモニタ上に表示するという処理を行う。このとき、ユースケースの分岐があればその分岐先の選択肢を表示し、次にどのユースケースを実行するのかをユーザに選択させる。この選択は、表示された選択肢の中の１つをマウス等のポインティングデバイスによって選択指示するための分岐選択部４を用いて行う。
【００４７】
また、ログ記録部５は、上記ユースケース実行部３による各ユースケースの実行過程を記録することにより、使用された各ユースケースの履歴をとるものである。すなわち、ユースケースが読み出される毎あるいはモニタ上に表示される毎に、そのユースケースを順次記録していくことにより、システム上でユースケースがどのように処理されていくかの流れ、つまり、そのシステム上の一連の業務がどういう動きで実現されるのかを表したシナリオを生成する。
【００４８】
このように生成されたシナリオは、例えばデータベースから成るシナリオ記憶部６に記憶される。シナリオ出力部７は、シナリオがシナリオ記憶部６に記憶されるのと同時、あるいはその後任意の時点において、生成されたシナリオを例えばモニタ上に出力するものである。ユーザは、ここで表示されたシナリオを参照することによって、要求仕様として記述されたシステムの動きを容易に把握することが可能となる。
【００４９】
図４は、本実施形態の要求仕様記述支援装置がユーザとの対話的処理によりシナリオを生成している途中の画面例を示す図である。
図４の例は、「演習問題の公開」（ユースケースナンバー：ＵＣ００６）を指定してシナリオ生成コマンドを実行したときの例を示している。この場合、まず最初にユースケース実行部３は、「演習問題の公開」のユースケースを要求仕様格納部２から読み込み、そのユースケース中に記述されている事前条件と基本系列のイベントとを表示する。
【００５０】
このとき、例えばある基本系列のイベントに対して代替系列のイベントが定義されている場合には、分岐先の選択肢を表す分岐メニューをポップアップ表示する。これに対応してユーザが分岐選択部４を用いて何れかの分岐先を選択すると、その選択された内容が表示される。なお、分岐がある場合は、図４中に示したように＜分岐＞のマークが表示される。図４のユースケース「演習問題の公開」の中では、表示された分岐メニューの中から「演習問題を公開する」という基本系列のイベントを選択した状態を示している。
【００５１】
このように分岐先が選択されると、その選択された分岐先に応じて、要求仕様の記述時に定義されたリンクに従って次のユースケースが要求仕様格納部２から読み出されて表示される。図４では、次に「演習問題の実装」（ユースケースナンバー：ＵＣ０１２）のユースケースが読み出されて表示されている。このユースケースの中でも、３番目の基本系列のイベントに対して代替系列のイベントが定義されており、分岐先の選択肢を表す分岐メニューがポップアップ表示されている。
【００５２】
このようなユースケース実行部３および分岐選択部４によるインタラクティブ処理によって各ユースケースを順次実行していく際に、ログ記録部５は、その実行過程で使用されたユースケースをシナリオ記憶部６に順に記録していく。図５は、このようなシナリオの生成結果の例を示す図である。この図５には、シナリオ００１〜００３の３つのシナリオ（使用されたユースケースの名称を列挙したもの）が示されているが、これらはそれぞれ、ユースケースの実行過程で発生した分岐点において異なる分岐先を選択して各々生成したものである。
【００５３】
図６は、ユースケース実行部３の動作を示すフローチャートである。図６において、ユーザにより特定のユースケースが指定されてシナリオ生成の実行が指示されると、ユースケース実行部３は、ステップＳ１で、その指定されたユースケースを要求仕様格納部２の中から読み出す。そして、ステップＳ２で、その読み出したユースケース中に記述されている事前条件を表示する。
【００５４】
次に、ステップＳ３で、そのユースケース中に代替系列が定義されているかどうかを判断し、定義されていない場合にはステップＳ４に進み、基本系列を表示する。一方、代替系列がある場合には、ステップＳ５に進み、図４に示したような分岐マークを付与して表示するとともに、ステップＳ６で、その代替系列のイベントと、代替の対象となっている基本系列のイベントとを含む複数の選択肢（選択メニュー）をポップアップ表示する。
【００５５】
そして、ステップＳ７で、表示された選択肢の中から基本系列あるいは代替系列のどちらが選択されたかを判断し、基本系列が選択された場合は、ステップＳ４に進み、その選択された基本系列のイベントを表示する。さらに、ステップＳ９で、利用するユースケースがあるかどうかを判断し、ない場合にはステップＳ１０に進んでユースケースの終了を判定し、終了していなければステップＳ３に戻り、上述の動作を再び実行する。
【００５６】
上記ステップＳ１０でユースケースが終了していると判断されたときは、ステップＳ１１に進み、その終了したユースケースが最初に起動したユースケースかどうかを判定し、最初に起動したものであれば、処理は終了する。また、最初に起動したユースケースでない場合は、ステップＳ１２に進み、１つ上の階層のユースケースである元のユースケースの実行に戻り、その後ステップＳ３に戻って上述の動作を再び実行する。
【００５７】
一方、上記ステップＳ９で、利用するユースケースがあると判断した場合は、ステップＳ１に戻り、その別のユースケースを要求仕様格納部２から新たに読み出す。そして、ステップＳ２以降の処理をその新たなユースケースについて同様に行う。
【００５８】
また、上記ステップＳ７で代替系列が選択された場合は、ステップＳ８に進み、その選択された代替系列のイベントをそれまでの表示に続けて表示する。さらに、ステップＳ９で、利用するユースケースがあるかどうかを判断し、ある場合にはステップＳ１に戻ってその別のユースケースを要求仕様格納部２から新たに読み出して、ステップＳ２以降の処理をその新たなユースケースについて同様に行う。一方、利用するユースケースがない場合は、ステップＳ１０に進み、それ以降は上述した処理を実行する。
【００５９】
この図６に示すような動作をユースケース実行部３が実行することにより、複数のユースケースがユーザとの対話的処理により順次実行されていく。このとき図１のログ記録部５が、実行された各ユースケースをそれらが実行される毎にシナリオ記憶部６にログとして記録していくことにより、ユースケースの実行過程を表したシナリオが自動的に生成される。つまり、ユーザが必要に応じて分岐先を選択するだけで、システムの動きを表すシナリオを生成することができる。
【００６０】
ユーザは、この生成されたシナリオを見ることによって、システムの動きを容易に確認することができる。これにより、そのシステムにおけるビジネスプロセスの要求仕様の整合性を検証することが容易となり、ビジネスプロセスの問題点を容易に把握することができるようになる。また、必ず通らなければならないユースケースがある場合に、それがシナリオ内で使用されているかどうかを見ることで、ユースケースの抜けや記述漏れなどがないかどうかをチェックしたり、未実行のユースケースがないかどうかをチェックすることもできる。
【００６１】
また、上述のように生成されたシナリオを参照することによってシステムの動きをログとして確認することができることの他に、本実施形態ではユーザとの対話的な処理によって各ユースケースを順次実行するようにしているので、ユースケースを用いて要求仕様を記述したシステムの動きを、そのシステムを実際に設計・実装する前に疑似的に体験することもできる。
【００６２】
そのため、記述した要求仕様に基づきシステムの設計・実装に入る前の段階で当該システムを疑似的に動かすことができる。必要であればそこで要求仕様の手直しをすることにより、システムを開発する上で必要な要求仕様を、最終的に矛盾や抜けがなく、かつユーザが満足するように記述することができる。これにより、その後の設計段階や実装段階で手戻り作業が発生してしまう不都合を極力抑えることができ、システム開発のコストを大幅に削減することができる。
【００６３】
なお、上記実施形態では、分岐点は代替系列が定義されているところに発生するが、ユースケース入力画面の事後条件の欄に、ジャンプ先として複数のユースケースを記述することにより、ここもユースケース実行の分岐点とするようにしても良い。この場合、分岐先の選択肢を表す分岐メニューは、代替系列が定義されているところに限らず、事後条件によって複数の分岐先が定義されているところでも表示されることになる。
【００６４】
また、上記実施形態では、ユースケースの実行過程で現れる分岐において、次に実行するユースケースをユーザに選択させることにより、ユーザとの対話的処理に基づきシナリオを生成するようにしているが、本発明はこのような手法には限定されない。
【００６５】
例えば、分岐点において次に実行するユースケースを装置が自動的に選択することにより、いくつかのシナリオを自動的に生成するようにしても良い。また、この場合、図１に示すように条件設定部８を設け、各ユースケースを実行する際の条件（例えば、代替系列には絶対に飛ばずに、基本系列だけでユースケースを実行する等の条件）をユースケース実行部３にあらかじめ与えておき、その条件の範囲内で自動的に分岐処理を行ってシナリオを生成するようにしても良い。
【００６６】
さらに、上記のように自動分岐を行ってシナリオを生成する場合、分岐先としてある１つのパターンあるいは数種類のパターンを選択してシナリオを自動生成するようにしても良いし、各分岐点において次に実行するユースケースとして取り得る全ての分岐先を順次選択することにより、あらゆるパターンのシナリオを全て自動的に生成するようにしても良い。
【００６７】
また、上記実施形態では、記録されるシナリオ中には、図６に示したようにユースケースの名称と番号だけが含まれるが、そのユースケースに関係するアクタや入出力されるデータなど、ユースケースを構成する他の構成要素を一緒に表示するようにしても良い。また、本実施形態において記録されるシナリオでは、それを見ただけではどこでどういう分岐があったかが分からないので、分岐条件だけのログをシナリオ中あるいはこれとは別に記録するようにしても良い。
【００６８】
また、上記実施形態では、必ず通らなければならないユースケースの抜けなどを、生成されたシナリオをユーザが目で見て判断していたが、そのようなユースケースをあらかじめ設定しておくことにより、装置が自動的にチェックを行うようにしても良い。また、シナリオが途中で終わってしまっていないかどうかを検証するために、ある特定のユースケースでシナリオが終わっているかどうかを装置が自動的にチェックするようにしても良い。さらに、これらの場合、不備があったときにエラーメッセージを出力するようにしても良い。
【００６９】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
第２の実施形態は、要求仕様をユースケースの形態で記述する際に、ユースケースやアクタなどを構造的に記述できるようにしたものである。構造化されたユースケースやアクタの記述方法として、ここではＵＭＬ（Unified Modeling Language ）を利用する。
【００７０】
上記ＵＭＬにおいては、構成要素間の関係の種類として、利用（uses）、汎化（generalization）、拡張（extends ）の３つが定義されている。利用にはユースケース間の利用があり、汎化にはユースケース間およびアクタ間の汎化があり、拡張にはユースケース間の拡張がある。ここで言う利用、汎化、拡張は、ＵＭＬのバージョン1.1 における定義に基づいたものであるが、ＵＭＬのバージョン1.3 における定義に基づくものに置き換えることも可能である。
【００７１】
本実施形態では、ユースケース間の関係を定義する際、あるユースケース内の基本系列を構成する１個のイベントを他の１個のユースケースに対応させて構造化している点に特徴がある。このようにすることにより、ユースケースやアクタを構造化したときの詳細な関係を分かり易くすることができる。
【００７２】
ここで、利用とは、複数のユースケース間で共通に利用可能な共通サブユースケースがあるときに、あるユースケースからその共通サブユースケースを利用する関係を言う。汎化とは、元のユースケースや元のアクタに対して部分的な変更を加えて新たなユースケースや新たなアクタを作る関係を言う。なお、あるユースケースＡをベースに、それを継承して差分を記述して別のユースケースＢを定義した場合、ユースケースＡはユースケースＢを汎化したものであると言い、ユースケースＢはユースケースＡを特殊化したものであると言い、両者の関係を汎化関係という。また、拡張とは、基本的なイベントの流れを規定したユースケースにおいて、ある特定の条件を満たしたときに別の拡張ユースケースの処理を行う関係を言う。
【００７３】
図７は、本実施形態によるユースケースの入力画面の例を示す図であり、基本系列を定義する部分を特にピックアップして示している。この図７に示す基本系列の入力欄においては、図２の場合と同様に、そのユースケースで誰が何を行うか等の具体的な内容をイベント欄３１およびアクタ欄３２に記述する。このとき、特定のイベントにおいて共通サブユースケースを利用することがあれば、その利用する共通サブユースケースの名称を利用ユースケース（利用ＵＣ）の欄３３に記述する。
【００７４】
図７の例では、“ユースケース１”の基本系列において“イベント２”の中で利用する共通サブユースケースとして“ユースケース５”を定義している。これにより、“ユースケース１”と“ユースケース５”との間に利用（uses）の関係が張られる。
【００７５】
また、図７の入力画面には、利用ＵＣ作成ボタン３４、特殊化ボタン３５および拡張ボタン３６が設けられている。このうち、利用ＵＣ作成ボタン３４は、複数のイベント列を指定して共通サブユースケースを作成することを指示するためのボタンである。
【００７６】
例えば、図７に示す入力画面上で、共通サブユースケースに落とし込みたいイベント列を指定して利用ＵＣ作成ボタン３４をマウスでクリックすると、その指定したイベント列を要素とする共通サブユースケースの名称や概要（目的）の入力を促す画面が現れる。この画面で共通サブユースケースの名称や概要（目的）を入力してＯＫボタンを押すことにより、共通サブユースケースが作成される。
【００７７】
図８は、この共通サブユースケースを作成する際の動作を説明するための図である。図８では、ａ〜ｆを内容とするイベント列から成るユースケース▲１▼があったときに、ａ〜ｄの内容は複数のユースケースで利用する可能性があるためにこれを共通サブユースケースとして作成しようとする場合の例を示している。
【００７８】
この場合、図８（ａ）に示す元のユースケース▲１▼において、共通サブユースケースとすべきイベント列ａ〜ｄを指定して利用ＵＣ作成ボタン３４をクリックし、更に当該共通サブユースケースの名称として“ユースケース▲２▼”を入力するとともに、概要として“Ｘ”を入力すると、図８（ｂ）に示すような共通サブユースケース▲２▼が作成される。また、図８（ｃ）に示すように、元のユースケース▲１▼の４つのイベント列ａ〜ｄが１つのイベントＸ（共通サブユースケース▲２▼を利用したもの）に置き換えられたユースケース▲１▼′が自動的に作られる。
【００７９】
このようにして共通サブユースケース▲２▼を作成した後は、ユースケース▲１▼′以外の他のユースケースからもこの共通サブユースケース▲２▼を利用することが可能となる。
このように共通サブユースケースを作成してこれを複数のユースケースで共通に利用できるようにすることにより、ユースケースの再利用を容易にすることができ、オペレータがユースケースを記述する際の作業負担を軽減することができる。
【００８０】
また、特殊化ボタン３５は、あるユースケースと汎化関係にある他のユースケースを作成することを指示するためのボタンである。例えば、図７に示す入力画面上で特殊化ボタン３５をクリックすると、そのとき表示されていたものと同内容のイベント列を有するユースケースが別の入力画面として現れる。ここで、所望の箇所を変更した上で、新たなユースケースの名称や概要（目的）を入力してＯＫボタンを押すことにより、元のユースケースと汎化関係にある別の特殊化されたユースケースが作成される。
【００８１】
図９は、この特殊化されたユースケースを作成する際の動作を説明するための図である。図９（ａ）のようにａ〜ｅを内容とするイベント列から成るユースケース▲１▼があるときに、特殊化ボタン３５を押すと、図９（ｂ）に示すように、ユースケース▲１▼のイベント列ａ〜ｅをそのまま反映した別のユースケースの入力画面が現れる。このとき、特殊化用のユースケースが新たに作られているが、この段階では、元のユースケースを特殊化したものであることを示す情報のみが新たな記憶領域に格納され、中身の情報は何も格納されていない状態である。
【００８２】
次に、図９（ｂ）に示す入力画面上で所望の箇所を変更する。図９の例では、イベントｃの内容をイベントｘに変更している。さらに、特殊化用ユースケースの名称として“ユースケース▲２▼”を入力すると、図９（ｃ）に示すように特殊化されたユースケース▲２▼が作成される。このとき、特殊化用ユースケースの記憶領域には、元のユースケース▲１▼から変更があった部分の差分データのみ、つまりイベントｘのデータのみが格納される。他の変更されていない部分の情報は、元のユースケース▲１▼が格納されている記憶領域からデータを読み出して画面上に表示している。
【００８３】
様々なユースケースを記述していく際、異なるユースケースでも同内容の入力を繰り返し行うことが少なからずある。この場合において、従来は全てのユースケースについて最初から記述していたが、本実施形態によれば、一部のみが異なるユースケースを継承し、異なる部分の定義だけを記述すれば良いので、オペレータの作業量を格段に少なくすることができる。
【００８４】
また、特殊化されたユースケースでは、その親のユースケースとの差分データだけを格納しているので、親のユースケースにおいて共通の部分に修正が行われたとしても、その修正内容は特殊化されたユースケースにも反映され、常に整合性を正しく維持することができる。したがって、全ての記述をオペレータの手作業で入力していた従来と比べて、修正漏れや入力の間違いを少なくすることができ、より正確な要求仕様を記述することができるようになる。
【００８５】
また、拡張ボタン３６は、あるユースケースと拡張の関係にある他のユースケースを作成することを指示するためのボタンである。例えば、図７に示す入力画面上で拡張ボタン３６をクリックすると、拡張ユースケースを記述するための別の入力画面が現れる。ここで、元のユースケースからの分岐条件と、その条件を満たした場合に実行するイベント列とを入力するとともに、元のユースケースから分岐する分岐場所と、拡張ユースケースの処理が終わった後に戻る元のユースケースの戻り場所とを入力することにより、元のユースケースと拡張の関係にある別のユースケースが作成される。
【００８６】
図１０は、この拡張されたユースケースを作成する際の動作を説明するための図である。図１０（ａ）のようにａ〜ｅを内容とするイベント列から成るユースケース▲１▼があるときに、拡張ボタン３６を押すと、拡張ユースケースを記述するための別の入力画面が現れる。ここで、例えば、分岐条件の内容を含むイベント列ｘ〜ｚを入力するとともに、元のユースケース▲１▼の分岐場所としてイベントｃ、拡張ユースケースのイベント列ｘ〜ｚを実行した後に戻る元のユースケース▲１▼の戻り場所としてイベントｄを入力することにより、図１０（ｂ）に示すような拡張ユースケース▲２▼が作成される。
【００８７】
図１１は、上述のようにユースケース等の構造化を行うことができるようにした第２の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。なお、この図１１において、図１に示した符号と同一の符号を付したものは、同一の機能を有するものであるので、これについての詳細な説明は省略する。
【００８８】
図１１において、要求仕様記述部１１は、図１に示した要求仕様記述部１と同様に、あらかじめ定められた所定のフォーマットに従って、要求仕様をユースケースの形で記述するものである。本実施形態の要求仕様記述部１１はさらに、個々のユースケースごとに、そのユースケースで示される業務を実行するのにどれくらいの時間がかかるか（例えば、最低でどれくらいの時間がかかるか）を表した時間情報も記述する。
【００８９】
構造化指定部１２は、要求仕様格納部２に格納されている要求仕様の情報に対して利用、汎化、拡張の何れかの関係を指定するものである。構造化指定部１２は、これら３つの関係の種類を指定するだけでなく、必要に応じて構造化を行う範囲も指定する。要求仕様格納部２に格納されている元の要求仕様情報から構造化指定部１２により生成された利用、汎化あるいは拡張の関係を有する要求仕様情報も、要求仕様格納部２に格納される。
【００９０】
例えば、要求仕様格納部２に格納されているあるユースケースのイベント列の中から共通サブユースケースを作成しようとするときは、構造化指定部１２により利用関係を指定するとともに、作成対象とするイベント列の範囲を指定する。さらに、要求仕様記述部１１を用いて必要な事項（当該共通サブユースケースの目的、事前条件、事後条件など）を記述することにより、共通サブユースケースに関する要求仕様の情報が要求仕様格納部２内に作られる。
【００９１】
また、要求仕様格納部２に格納されているあるユースケースを特殊化して別のユースケースを作成しようとするときは、構造化指定部１２により汎化関係を指定する。このとき、要求仕様格納部２には、特殊化用のユースケースを格納するための領域が確保されるが、この段階では、元のユースケースを特殊化したものであることを示す情報のみがこの新たな記憶領域に格納される。
【００９２】
さらに、要求仕様記述部１１を用いて所望の箇所を修正するとともに、必要な事項（当該特殊化ユースケースの目的、事前条件、事後条件など）を記述することにより、特殊化されたユースケースに関する要求仕様の情報が要求仕様格納部２内に作られる。このとき要求仕様格納部２に格納される情報は、当該要求仕様格納部２に格納されている元のユースケースとの差分データのみである。
【００９３】
また、要求仕様格納部２に格納されているあるユースケースを拡張して別のユースケースを作成しようとするときは、構造化指定部１２により拡張関係を指定する。さらに、要求仕様記述部１１を用いて必要な事項（当該拡張ユースケースの目的、事前条件、拡張ユースケースの基本系列、事後条件など）を記述することにより、拡張ユースケースに関する要求仕様の情報が要求仕様格納部２内に作られる。
【００９４】
モード指定部１３は、ユースケース実行部３や分岐選択部４を用いて要求仕様中に含まれる各ユースケースを順次実行してその実行過程を記録する際に、簡易なログをとる簡易モードと、詳細なログをとる詳細モードとの何れかを指定するものである。このモード指定部１３により指定されたモード情報は、ユースケース実行部３および分岐選択部４に伝えられ、指定されたモードに応じた処理がこのユースケース実行部３および分岐選択部４において行われる。
【００９５】
上記簡易モードは、第１の実施形態のように、基本系列のユースケースと代替系列のユースケースとの間に張られたリンクに従って、あるユースケースからそのリンク先のユースケースを順次読み出しながらシナリオを作っていくモードである。この簡易モードを指定したときに生成されるシナリオは、図５のようにユースケース間の流れのみを示したものである。
【００９６】
一方、詳細モードは、基本系列のユースケースと代替系列のユースケースとの間に張られたリンクに加え、構造化されたユースケースの利用、汎化、拡張の関係（リンク）に従って、あるユースケース内のイベントからそのリンク先のユースケースを順次読み出しながらシナリオを作っていくモードである。構造化されたユースケース間の関係は、上述したように、あるユースケースを構成するイベントと他のユースケースとの間に張られた関係である。したがって、この詳細モードを指定したときに生成されるシナリオは、図１２に示すように、ユースケースの流れだけでなく、更に各ユースケース内に含まれるイベントの流れまで示したものとなる。
【００９７】
図１２に示すシナリオ００１では、ユースケース００１のイベント１およびイベント２の処理を行った段階でユースケース００５のイベント１〜３の処理を実行し、その後再びユースケース００１に戻り、イベント３から処理を続行していることが履歴として記録されている。このように、本実施形態のシナリオによれば、処理の流れがより詳細に分かるようになり、ユースケースの記述漏れや未実行のユースケースなど、要求仕様が適切に記述されているかどうかのチェックをより詳細に行うことができる。
【００９８】
図１３は、詳細モードでシナリオを生成する際のユースケース実行部３の動作を示すフローチャートである。図１３において、ユーザにより特定のユースケースが指定されてシナリオ生成の実行が指示されると、ユースケース実行部３は、ステップＳ１１で、その指定されたユースケースを要求仕様格納部２の中から読み出す。そして、ステップＳ１２で、その読み出したユースケースに対して拡張ユースケースが定義されているかどうかを判断する。
【００９９】
ここで、拡張ユースケースが定義されている場合は、ステップＳ１３に進み、図４に示したような分岐マークを付与して表示するとともに、ステップＳ１４で、その拡張ユースケース内の先頭のイベントと、拡張の対象となっている元のユースケース内のイベントとを含む複数の選択肢（選択メニュー）をポップアップ表示する。
【０１００】
そして、ステップＳ１５で、表示された選択肢の中から拡張ユースケースのイベントが選択されたかどうかを判断し、拡張ユースケースのイベントが選択された場合は、ステップＳ１１に戻り、その選択された拡張ユースケースを要求仕様格納部２の中から読み出す。そして、その読み出した拡張ユースケースに対して以上と同様の処理を行う。一方、拡張ユースケースのイベントが選択されていない場合は、ステップＳ１６で元のユースケースの実行に戻り、ステップＳ１８に進む。
【０１０１】
また、上記ステップＳ１２において、要求仕様格納部２の中から読み出したユースケースに対して拡張ユースケースが定義されていないと判断した場合は、ステップＳ１７で、その読み出したユースケース中に記述されている事前条件を表示した後、ステップＳ１８に進む。
【０１０２】
ステップＳ１８では、対象としているユースケースが別のユースケースを特殊化したものであるかどうかを判断する。ここで、別のユースケースを特殊化したものである場合は、ステップＳ１９に進み、継承元のユースケースとそれを特殊化したユースケースの差分データとを要求仕様格納部２の中から読み出す。そして、ステップＳ２０で、上記読み出した継承元のユースケースと特殊化したユースケースの差分データとを合わせて特殊化したユースケースを作成する。
【０１０３】
さらに、ステップＳ２１で、上記作成した特殊化ユースケース中に記述されている事前条件を表示した後、ステップＳ２２に進む。一方、上記ステップＳ１８において、対象としているユースケースが別のユースケースを特殊化したものでないと判断した場合は、上記ステップＳ１９〜Ｓ２１の処理は行うことなく、ステップＳ２２に進む。
【０１０４】
ステップＳ２２では、現在対象としているユースケース中に代替系列が定義されているかどうかを判断し、定義されていない場合にはステップＳ２６に進み、基本系列を表示する。一方、代替系列がある場合には、ステップＳ２３に進み、図４に示したような分岐マークを付与して表示するとともに、ステップＳ２４で、その代替系列のイベントと、代替の対象となっている基本系列のイベントとを含む複数の選択肢（選択メニュー）をポップアップ表示する。
【０１０５】
そして、ステップＳ２５で、表示された選択肢の中から基本系列あるいは代替系列のどちらが選択されたかを判断し、基本系列が選択された場合は、ステップＳ２６に進み、その選択された基本系列のイベントを表示する。さらに、ステップＳ２８で、拡張ユースケースがあるかどうかを判断し、ある場合にはステップＳ１１に戻るが、ない場合にはステップＳ２９に進む。
【０１０６】
ステップＳ２９では、利用するユースケースがあるかどうかを判断し、ない場合にはステップＳ３０に進んでユースケースの終了を判定し、終了していなければステップＳ２２に戻り、上述の動作を再び実行する。
【０１０７】
上記ステップＳ３０でユースケースが終了していると判断されたときは、ステップＳ３１に進み、その終了したユースケースが最初に起動したユースケースかどうかを判定し、最初に起動したものであれば、処理は終了する。また、最初に起動したユースケースでない場合は、ステップＳ３２に進み、１つ上の階層のユースケースである元のユースケースの実行に戻り、その後ステップＳ２２に戻って上述の動作を再び実行する。
【０１０８】
一方、上記ステップＳ２９で、利用するユースケースがあると判断した場合は、ステップＳ１１に戻り、その別のユースケースを要求仕様格納部２から新たに読み出す。そして、ステップＳ１２以降の処理をその新たなユースケースについて同様に行う。
【０１０９】
また、上記ステップＳ２５で代替系列が選択された場合は、ステップＳ２７に進み、その選択された代替系列のイベントをそれまでの表示に続けて表示する。さらに、ステップＳ２８で、拡張ユースケースがあるかどうかを判断し、ない場合にはステップＳ２９で更に利用するユースケースがあるかどうかを判断する。利用するユースケースがある場合にはステップＳ１１に戻ってその別のユースケースを要求仕様格納部２から新たに読み出して、ステップＳ１２以降の処理をその新たなユースケースについて同様に行う。一方、利用するユースケースがない場合は、ステップＳ３０に進み、それ以降は上述した処理を実行する。
【０１１０】
この図１３に示すような動作をユースケース実行部３が実行することにより、複数のユースケースのイベントがユーザとの対話的処理により順次実行されていく。このとき図１１のログ記録部５が、実行された各ユースケースおよび各イベントをそれらが実行される毎にシナリオ記憶部６にログとして記録していくことにより、ユースケースとその内部のイベントの実行過程を表したシナリオが自動的に生成される。つまり、ユーザが必要に応じて分岐先を選択するだけで、システムの動きを表す詳細なシナリオを生成することができる。
【０１１１】
図１１の説明に戻る。総時間演算部１４は、シナリオ記憶部６に記憶されたシナリオを用いて、そのシナリオ通りに一連の処理を実行した場合に必要なトータルの要処理時間を演算するものである。すなわち、本実施形態では、個々のユースケースごとに、そのユースケースの業務を実行するのにかかる時間が要求仕様記述部１１により記述されている。そこで、総時間演算部１４では、シナリオ中に含まれる各ユースケースの処理に必要な時間を合計することにより、そのシナリオのように業務を遂行した場合の仮想的な総実行時間を算出する。
【０１１２】
このように、生成されたシナリオを実行するのに必要なトータルの要処理時間を算出することにより、現行業務の分析、システム化に対する要求の妥当性あるいは実現可能性などを判断する際の１つの目安を得ることができる。例えば、シナリオを実行するのに非常に多くの時間がかかってしまうことが判明した場合に、そのシナリオを修正する、あるいは作り直すなどの対応をとることが可能となる。
なお、ここでは個々のユースケース毎にその処理時間を設定するようにしているが、ユースケース内の個々のイベント毎にその処理時間を設定するようにしても良い。
【０１１３】
重要度／利用頻度設定部１５は、シナリオ記憶部６に記憶されたシナリオに対して、重要度や利用頻度等を設定するものである。また、シナリオ解析部１６は、上記重要度／利用頻度設定部１５によりシナリオに設定された重要度や利用頻度等を解析し、当該シナリオに含まれる個々のユースケースの重要度や利用頻度等を求めるものである。
【０１１４】
上記シナリオ解析部１６は、あらかじめ設定されたロジックに従って個々のユースケースに重要度や利用頻度等を設定する。例えば、シナリオ解析部１６は、重要度／利用頻度設定部１５によってシナリオに設定された重要度や利用頻度の値を、当該シナリオに含まれる個々のユースケースにそのまま設定する。ここで、複数のシナリオに同じユースケースが含まれる場合において、それぞれのシナリオに異なる重要度が設定されたときには、最大の重要度をそのユースケースに設定する。また、複数のシナリオで利用される回数が所定値より大きいユースケースについては、そのユースケースを含むシナリオに設定された重要度よりも高い重要度を設定するなどのロジックを用いても良い。
【０１１５】
要求仕様を作成する際、作成した要求仕様の内容を後からチェックするためなどの便宜上から、個々のユースケースに重要度や利用頻度を設定することが行われる。例えば、業務の流れとして重要なユースケース、あるいは従来手作業で行っていて処理が煩雑なのでシステム化の要望が大きいユースケースなどには、値の大きな重要度が設定される。
【０１１６】
通常、このような重要度や利用頻度等は、要求仕様記述部１１によって個々のユースケース毎に設定されるが、ユースケースの数が多くなってくると、その作業は非常に煩雑なものとなる。また、要求仕様を記述するオペレータが個々のユースケース毎に重要度や利用頻度等を判断することは必ずしも容易でない。
【０１１７】
本実施形態では、個々のユースケースに対して重要度や利用頻度等を設定することも勿論可能であるが、重要度／利用頻度設定部１５を用いることにより、作成されたシナリオに対して重要度や利用頻度等を設定できるようにしている。これにより、全てのユースケースを網羅するシナリオが全ユースケース数よりも少ない数で実現できた場合には、それらのシナリオに対して重要度や利用頻度等を設定することにより、その設定作業を簡易にすることができる。
【０１１８】
また、個々のユースケース毎に細かく見るのではなく、ユースケースの流れを表したシナリオに基づき重要度や利用頻度等を全体として見ることができるので、重要度や利用頻度等がユーザにとって分かりやすく、これらの設定を行いやすくすることができる。
【０１１９】
なお、本実施形態で設定する処理時間、重要度、利用頻度は単なる例に過ぎない。すなわち、個々のユースケースに対して値を定義（または計測）する方が簡単で、それをもとにシナリオに対する値を算出でき、そちらの方が値として意味があるもの、またはその逆に、シナリオに対して値を定義（または計測）する方が簡単で、それをもとに個々のユースケースに対する値を算出でき、そちらの方が値として意味があるものであれば、何れにも適用することが可能である。
【０１２０】
（本発明の他の実施形態）
なお、以上に説明した本実施形態の要求仕様記述支援装置は、コンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。記録媒体としては、ＣＤ−ＲＯＭ以外に、フロッピーディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。
【０１２１】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
【０１２２】
また、本発明をネットワーク環境で利用するべく、全部あるいは一部のプログラムが他のコンピュータで実行されるようになっていても良い。例えば、画面入力処理は、遠隔端末コンピュータで行われ、各種判断、ログ記録等は他のセンターコンピュータ等で行われるようにしても良い。
【０１２３】
なお、上記に示した実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１２４】
【発明の効果】
本発明は上述したように、所定の基準に従ってユースケースの形で記述された要求仕様に基づいて、上記要求仕様中に含まれる各ユースケースを順次実行し、その実行過程を記録するようにしたので、ユースケースを順次実行していくだけで、システムの動きを表すシナリオを容易に生成することができる。そして、この生成されたシナリオを参照することにより、ユースケースの抜けや記述漏れがないかどうか等を確認することができる。
【０１２５】
これにより、要求仕様が適切に書かれているかどうかのチェックを容易に行うことができ、必要に応じてそのチェック結果を要求仕様の記述にフィードバックすることにより、システムを開発する上で必要な要求仕様を正確に記述することができる。したがって、その後の設計段階や実装段階で手戻り作業が発生してしまう不都合を未然に防止することができ、従来に比べてシステムの開発コストを大幅に削減することができる。
【０１２６】
本発明の他の特徴によれば、ユースケースの形で記述された要求仕様の各構成要素について、利用、汎化、拡張の少なくとも１つの関係を用いて各構成要素を構造化するようにしたので、構造化されたユースケースの利用、汎化、拡張の関係に従って、あるユースケース内のイベントからそのリンク先のユースケースを順次読み出しながらその過程を履歴として記録していくことができ、その結果、ユースケースの流れだけでなく、更に各ユースケース内に含まれるイベントの流れまで表した詳細なシナリオを生成することができる。これにより、処理の流れがより詳細に分かるようになり、システムを開発する上で必要な要求仕様に関してユースケースの記述漏れや未実行のユースケースがないかなど、要求仕様が適切に記述されているかどうかのチェックをより詳細に行って、要求仕様を正確に記述することができる。
【０１２７】
本発明のその他の特徴によれば、要求仕様を記述する際に、個々のユースケース毎にその処理時間を記述し、ユースケースの実行に伴い履歴として記録されたシナリオについて、その一連の処理を行うのにかかる総処理時間を演算するようにしたので、そのシナリオの善し悪しを判断するための１つの指標を得ることができる。これにより、その指標に基づき要求仕様の修正の必要性などを判断し、必要に応じて要求仕様をより適切なものに記述し直すことができるようになる。
【０１２８】
本発明のその他の特徴によれば、生成された履歴に対して重要度および利用頻度の少なくとも一方を設定し、この重要度や利用頻度が設定された履歴を解析して、その履歴に含まれる個々のユースケースの重要度および利用頻度を求めるようにしたので、各ユースケースに対して重要度や利用頻度等を個別に設定する場合と比べて、重要度や利用頻度等の設定作業を簡易にすることができるとともに、その設定をユーザにとって分かりやすくすることができ、これらの設定を行いやすくすることができる。
【図面の簡単な説明】
【図１】本発明による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【図２】基本系列を含むユースケースの入力画面の例を示す図である。
【図３】代替系列の入力画面の例を示す図である。
【図４】本実施形態の要求仕様記述支援装置がユーザとの対話的処理によりシナリオを生成している途中の画面例を示す図である。
【図５】第１の実施形態によるシナリオの生成結果の例を示す図である。
【図６】図１のユースケース実行部が行う動作を示すフローチャートである。
【図７】第２の実施形態によるユースケースの入力画面の例を示す図である。
【図８】共通サブユースケースを作成する際の動作を説明するための図である。
【図９】特殊化されたユースケースを作成する際の動作を説明するための図である。
【図１０】拡張されたユースケースを作成する際の動作を説明するための図である。
【図１１】第２の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【図１２】第２の実施形態によるシナリオの生成結果の例を示す図である。
【図１３】図１１のユースケース実行部が行う動作を示すフローチャートである。
【符号の説明】
１ 要求仕様記述部
２ 要求仕様格納部
３ ユースケース実行部
４ 分岐選択部
５ ログ記録部
６ シナリオ記憶部
７ シナリオ出力部
８ 条件設定部
１１ 要求仕様記述部
１２ 構造化指定部
１３ モード指定部
１４ 総時間演算部
１５ 重要度／利用頻度設定部
１６ シナリオ解析部
２１ ツリー構造表示画面
２２ａ ユースケース用タグ
２２ｂ ビジネスモデル用タグ
２３ ユースケース入力画面
３１ イベント欄
３２ アクタ欄
３３ 利用ＵＣ欄
３４ 利用ＵＣ作成ボタン
３５ 特殊化ボタン
３６ 拡張ボタン

Claims (15)

1. 複数のユースケースにより構成される要求仕様の記述を支援するための要求仕様記述支援装置であって、
   所定のフォーマットに従って自然言語で記述された上記複数のユースケースと、上記複数のユースケース間に予め設定されたリンク先を表すリンク情報とを記憶する記憶手段と、
   上記リンク情報に従ってリンク先のユースケースを順次読み出すユースケース実行手段と、
   上記ユースケース実行手段によってユースケースが読み出された過程を特定可能な履歴を履歴記憶手段に記録する履歴記録手段と、を備えたことを特徴とする要求仕様記述支援装置。
2. 上記リンク情報にリンク先として複数のユースケースが含まれている場合、当該リンク先として含まれる複数のユースケースをユーザに提示し、提示したユースケースのうち、ユーザによって選択されたユースケースを受け付ける分岐選択手段をさらに備え、
   上記ユースケース実行手段は、上記選択されたユースケースを読み出すことを特徴とする請求項１に記載の要求仕様記述支援装置。
3. 上記ユースケース実行手段は、上記リンク情報にリンク先として複数のユースケースが含まれている場合、当該リンク先として含まれる複数のユースケースの中から、予め定められた条件に従ってユースケースを選択し、選択したユースケースを読み出すことを特徴とする請求項１に記載の要求仕様記述支援装置。
4. 上記記憶手段は、個々のユースケースごとに対応する業務の処理にかかる処理時間を記憶しており、
   上記記憶手段に記憶された上記処理時間に基づいて、上記履歴記録手段により記録された履歴に含まれるユースケースに対応する一連の業務の処理にかかる総処理時間を演算する総時間演算手段をさらに備えたことを特徴とする請求項１乃至３のいずれか１項に記載の要求仕様記述支援装置。
5. 上記履歴記憶手段は、上記履歴に対してユーザによって設定された重要度及び利用頻度のうちの少なくともいずれか一方を記憶しており、
   上記ユーザによって設定された重要度及び利用頻度のうちの少なくともいずれか一方に基づいて、上記履歴に含まれる個々のユースケースに対して、重要度及び利用頻度のうちの少なくともいずれか一方を設定する履歴解析手段とをさらに備えたことを特徴とする請求項１乃至４のいずれか１項に記載の要求仕様記述支援装置。
6. 複数のユースケースにより構成される要求仕様の記述を支援するための要求仕様記述支援装置であって、所定のフォーマットに従って自然言語で記述された上記複数のユースケースと、上記複数のユースケース間に予め設定されたリンク先を表すリンク情報とを記憶する記憶手段と、ユースケース実行手段と、履歴記録手段と、履歴記憶手段とを備えた要求仕様記述支援装置によって実行される要求仕様記述支援方法であって、
   上記ユースケース実行手段が、上記リンク情報に従ってリンク先のユースケースを順次読み出すユースケース実行ステップと、
   上記履歴記録手段が、上記ユースケース実行ステップによってユースケースが読み出された過程を特定可能な履歴を上記履歴記憶手段に記録する履歴記録ステップとを備えたことを特徴とする要求仕様記述支援方法。
7. 上記リンク情報にリンク先として複数のユースケースが含まれている場合、当該リンク先として含まれる複数のユースケースをユーザに提示し、提示したユースケースのうち、ユーザによって選択されたユースケースを受け付ける分岐選択ステップをさらに備え、
   上記ユースケース実行ステップは、上記選択されたユースケースを読み出すことを特徴とする請求項６に記載の要求仕様記述支援方法。
8. 上記ユースケース実行ステップは、上記リンク情報にリンク先として複数のユースケースが含まれている場合、当該リンク先として含まれる複数のユースケースの中から、予め定められた条件に従ってユースケースを選択し、選択したユースケースを読み出すことを特徴とする請求項６に記載の要求仕様記述支援方法。
9. 上記記憶ステップは、個々のユースケースごとに対応する業務の処理にかかる処理時間を記憶し、
   上記記憶ステップにより記憶された上記処理時間に基づいて、上記履歴記録ステップにより記録された履歴に含まれるユースケースに対応する一連の業務の処理にかかる総処理時間を演算する総時間演算ステップをさらに備えたことを特徴とする請求項６乃至８のいずれか１項に記載の要求仕様記述支援方法。
10. 上記履歴記録ステップにより記録された上記履歴に対してユーザによって設定された重要度及び利用頻度のうちの少なくともいずれか一方を記憶する重要度／利用頻度記憶ステップと、
    上記ユーザによって設定された重要度及び利用頻度のうちの少なくともいずれか一方に基づいて、上記履歴に含まれる個々のユースケースに対して、重要度及び利用頻度のうちの少なくともいずれか一方を設定する履歴解析ステップとをさらに備えたことを特徴とする請求項６乃至９のいずれか１項に記載の要求仕様記述支援方法。
11. コンピュータを、複数のユースケースにより構成される要求仕様の記述を支援するための要求仕様記述支援装置として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
    コンピュータを、
    所定のフォーマットに従って自然言語で記述された上記複数のユースケースと、上記複数のユースケース間に予め設定されたリンク先を表すリンク情報とを記憶する記憶手段と、
    上記リンク情報に従ってリンク先のユースケースを順次読み出すユースケース実行手段と、
    上記ユースケース実行手段によってユースケースが読み出された過程を特定可能な履歴を履歴記憶手段に記録する履歴記録手段として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
12. 上記リンク情報にリンク先として複数のユースケースが含まれている場合、当該リンク先として含まれる複数のユースケースをユーザに提示し、提示したユースケースのうち、ユーザによって選択されたユースケースを受け付ける分岐選択ステップをさらにコンピュータに実行させ、
    上記ユースケース実行ステップは、上記選択されたユースケースを読み出すことを特徴とするプログラムを記録した請求項１１に記載のコンピュータ読み取り可能な記録媒体。
13. 上記ユースケース実行ステップは、上記リンク情報にリンク先として複数のユースケースが含まれている場合、当該リンク先として含まれる複数のユースケースの中から、予め定められた条件に従ってユースケースを選択し、選択したユースケースを読み出すことを特徴とするプログラムを記録した請求項１１に記載のコンピュータ読み取り可能な記録媒体。
14. 上記記憶ステップは、個々のユースケースごとに対応する業務の処理にかかる処理時間を記憶し、
    上記記憶ステップにより記憶された上記処理時間に基づいて、上記履歴記録ステップにより記録された履歴に含まれるユースケースに対応する一連の業務の処理にかかる総処理時間を演算する総時間演算ステップをさらにコンピュータに実行させるためのプログラムを記録した請求項１１乃至１３のいずれか１項に記載のコンピュータ読み取り可能な記録媒体。
15. 上記履歴記録ステップにより記録された上記履歴に対してユーザによって設定された重要度及び利用頻度のうちの少なくともいずれか一方を記憶する重要度／利用頻度記憶ステップと、
    上記ユーザによって設定された重要度及び利用頻度のうちの少なくともいずれか一方に基づいて、上記履歴に含まれる個々のユースケースに対して、重要度及び利用頻度のうちの少なくともいずれか一方を設定する履歴解析ステップとをさらにコンピュータに実行委させるためのプログラムを記録した請求項１１乃至１４のいずれか１項に記載のコンピュータ読み取り可能な記録媒体。

Images