JP4629183B2 - 要求仕様記述支援装置およびその方法、記録媒体 - Google Patents
要求仕様記述支援装置およびその方法、記録媒体 Download PDFInfo
- Publication number
- JP4629183B2 JP4629183B2 JP2000078552A JP2000078552A JP4629183B2 JP 4629183 B2 JP4629183 B2 JP 4629183B2 JP 2000078552 A JP2000078552 A JP 2000078552A JP 2000078552 A JP2000078552 A JP 2000078552A JP 4629183 B2 JP4629183 B2 JP 4629183B2
- Authority
- JP
- Japan
- Prior art keywords
- relationship
- requirement specification
- use case
- analysis
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は要求仕様記述支援装置およびその方法、記録媒体に関し、特に、ソフトウェア等のシステム開発で用いる要求仕様の記述を支援するための装置に用いて好適なものである。
【０００２】
【従来の技術】
一般に、コンピュータを利用したシステム開発は、その要求仕様の定義から基本設計、詳細設計などの過程を経て最終的にコーディングされ、必要に応じてデバッグされて完成となる。この中で、特に要求仕様の定義は、システム開発を行う上で非常に重要な意味を持つものである。すなわち、要求仕様の中で曖昧な記述や誤解を生じるような記述をしていると、その内容をもとに設計され作成されたシステムは、全く使えないものか、ユーザの全く期待していなかったものになってしまうことが多い。
【０００３】
また、要求仕様をきちんと記述していない場合、システム開発においてその要求定義の問題が発覚するのは、設計が終わったとき、あるいはコーディングを開始してからであることが多いが、この段階で間違いを直すのは簡単ではなく、莫大な開発コストがかかる。これに対して、最初の要求仕様をきちんと記述しておけば、その後で発生する手戻り作業を極力抑えることができる。したがって、要求仕様をきちんと記述しておくことは、極めて重要であると言える。
【０００４】
【発明が解決しようとする課題】
しかしながら、このように要求仕様は極めて重要であるにもかかわらず、従来これを正確に記述することができないことが多かった。
【０００５】
すなわち、従来は、システム開発の前段階において、現状システムと改善後のシステム、あるいは新しいシステムの内容などについて、システムが備える機能を中心として、人間が行う作業、データの発生や流れ、データの出力などを人間の言葉や図面を用いて記述していた。また、最近では、要求仕様を記述するのに種々の方法が用いられるようになってきており、その中の１つに、システムの機能ではなく用途に着目して記述を行うユースケースと呼ばれるものも登場してきている。
【０００６】
しかし、何れの方法によっても、その記述された内容からシステム設計に漏れや誤り等がないかどうかをチェックするのは、人手によっていた。例えば、要求仕様として記述された文章や図面そのものを人間が見て、そこからデータの発生、利用関係、出力等や、誰が何を入力してどんな作業を行うのかなどの色々なチェックをその人間の判断で行っていた。
【０００７】
ところが、これらのチェックは、人間が手作業で行うものなので、見落としや間違いなどが発生しやすい。また、コンピュータ等を利用してもある程度はチェックできるが、どのように行えばチェックが正確かつ容易になるかは、明確でなかった。チェックのミスや漏れがあると、結局は正しい要求仕様を記述することができず、その後の手戻り作業が発生してしまうことになり、多くの開発コストがかかってしまう原因となる。
【０００８】
本発明は、このような実情に鑑みて成されたものであり、記述された要求仕様のチェックを正確かつ容易に行えるようにすることにより、正確な要求仕様を記述することを支援できるようにした要求仕様記述支援装置およびその方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明の要求仕様記述支援装置は、システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析手段と、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力手段とを備えたことを特徴とする。
本発明の要求仕様記述支援方法は、システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、関係解析手段と、関係出力手段とを備えた要求仕様記述支援装置によって実行される要求仕様記述支援方法であって、上記関係解析手段が、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析ステップと、上記関係出力手段が、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力ステップとを備えたことを特徴とする。
本発明のコンピュータ読み取り可能な記録媒体は、コンピュータを、システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析手段と、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力手段として機能させるためのプログラムを記録したことを特徴とする。
【００２３】
本発明は上記技術手段より成るので、要求仕様モデルの各構成要素間の関係が解析されて出力されることとなり、その出力された構成要素間の関係をオペレータが参照することによって、本来定義すべき関係に漏れがないかどうかや、不必要な関係が定義されていないかどうかなどを確認することにより、要求仕様が適切に書かれているかどうかをチェックすることが可能となる。
【００２４】
また、本発明の他の特徴によれば、要求仕様を記述するための情報入力画面として用意された複数のビューの中から、オペレータが書きやすいビューを用いて要求仕様の記述を行うことが可能となり、１つのビューを用いて要求仕様の定義内容を変更すると、それに連動して他のビューの定義内容も適切に更新されることとなる。
【００２５】
また、本発明のその他の特徴によれば、例えば利用関係を用いて共通の構成要素を作成することにより、複数の構成要素からこの共通構成要素を利用することが可能となり、構成要素の再利用を容易にすることが可能となる。また、汎化関係を用いて別の構成要素を作成することにより、様々な構成要素について要求仕様を記述していく際に、それらの構成要素間で共通の部分は繰り返し入力しなくても済む。このとき、汎化された構成要素は元の構成要素との差分だけをデータとして持つので、元の構成要素において行われた修正内容を、汎化された構成要素にも特別な処理を行うことなく反映させることが可能となる。また、拡張関係を用いて別の構成要素を作成することにより、ある構成要素から他の構成要素へと条件分岐させることが可能となる。
【００２６】
【発明の実施の形態】
以下、本発明の一実施形態について図面を参照しながら説明する。
【００２７】
（第１の実施形態）
図１は、本発明の第１の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【００２８】
図１において、要求仕様記述部１は、本実施形態による要求仕様モデルの各構成要素が全て含まれるようにあらかじめ定められた所定のフォーマットに従って、要求仕様の定義を記述する。すなわち、要求仕様の入力フォーマットとして、上記要求仕様モデルの各構成要素を全て含んだ入力画面を用意し、ここに各種情報を入力していくことによって、要求仕様を記述する。本実施形態の場合、要求仕様モデルの各構成要素としては、ユースケース、アクタ、データ、条件、ビジネスルールの５つを含む。
【００２９】
ユースケースとは、開発するシステムが業務上どのように利用されるのかという点に着目して、システムの稼働時にオペレータが行う一連のアクション（イベント）等を、トランザクション毎に各構成要素が明確になるように自然言語で記述したものを言う。また、アクタは、それぞれのアクションを誰が行うかを示すもの、データは、各アクションの際にどんなデータを入出力するかを示すもの、条件は、各アクション時に満たすべき状態等を示すもの、ビジネスルールは、開発されたシステムによって業務を遂行する上で守るべきルールを示すものである。
【００３０】
図２は、本実施形態による要求仕様の入力画面の例を示す図である。図２において、ツリー構造表示画面２１は、あるシステムの開発プロジェクトについて定義した要求仕様モデルをツリー構造にて表示するための画面である。この画面２１の下方には、タグ２２ａ，２２ｂが設けられており、一方のタグ２２ａをクリックすると、図２に示されるようにユースケースの入力画面となり、もう一方のタグ２２ｂをクリックすると、図示しないビジネスルールの入力画面となる。
【００３１】
図２の例では、プログラミングの教育システムを開発するプロジェクトで要求仕様として定義すべき情報の例を示しており、上記ツリー構造表示画面２１内には、そのプロジェクトにおけるユースケースの利用関係とアクタの一覧とが示されている。すなわち、ここに示されるツリー構造としては、“プロジェクト”の下層に“ユースケース”と“アクタ”があり、上記“ユースケース”の下層に“外部”、“内部”および“情報システム”がある。
【００３２】
さらにここでは、ユースケース“外部”の中のユースケースの利用関係を特に示している。すなわち、ユースケース“外部”と書かれた階層の下の階層には、“演習問題の提供”、“評価”および“○○知識獲得”というユースケースがあり、上記“演習問題の提供”の下の階層には更に“事前準備”および“演習問題の公開”というユースケースがある。さらに、上記“演習問題の公開”の下の階層には更に“演習問題の実装”というユースケースがある。
【００３３】
このように、ある業務システムを作成する１つのプロジェクトに関する要求仕様は、システム上で行う個々の業務を単位として記述した複数の単位要求仕様から成り、ツリー構造表示画面２１内に示される“演習問題の提供”、“評価”、“○○知識獲得”、“事前準備”、“演習問題の公開”、“演習問題の実装”などの各ユースケースは、それぞれ１つの単位要求仕様に該当する。
【００３４】
ここで、例えばツリー構造表示画面２１内の任意のユースケースの部分をマウスでクリックすると、そのユースケースの入力画面２３がツリー構造表示画面２１の右側に表示される。図２の例では、“演習問題の実装”というユースケースの部分がクリックされたときの様子を示している。このユースケース入力画面２３では、ユースケース名の表示の後に、目的、事前条件、基本系列、事後条件およびデータの入力画面が表示される。
【００３５】
上記ユースケース入力画面２３内の目的の欄には、そのユースケースにおいてどんな業務を行うのかの大まかな内容を定義する。また、事前条件の欄には、その業務を行うために事前に行われていることが必要な条件を定義する。また、基本系列の欄には、そのユースケースで誰が何を行うか等の具体的な内容を定義する。ここでは、具体的な動作の内容を表すイベントと、それを誰が行うかを表すアクタと、それを行う際に利用する他のユースケースとを各動作毎に順番に記述していく。図２では、ツリー構造表示画面２１内から“箇所研修生”をドラッグしてきてアクタの欄に張り付けている状態を示している。
【００３６】
また、事後条件の欄には、そのユースケースで定義されている動作を行った後にどんな状態となるかを定義する。例えば、動作が成功に終わった場合と、失敗に終わった場合とに分けて、それぞれの場合にどういう状態となるかを定義する。また、データの欄には、そのユースケースでどんなデータを入出力するかについて定義する。なお、図２中には事後条件およびデータの入力画面は現れていないが、これらは画面を下にスクロールさせると見えてくる。
【００３７】
このように、本実施形態では、図面等とは異なり、誰もが同じように理解できる自然言語で各種の情報を入力していくことによって要求仕様を記述するようにしているので、開発するシステムの機能とそれを用いて行う業務との対応関係を明確にすることができ、食い違いの発生を極力少なくすることができる。その際、あらかじめ定められた入力項目に対して記述を行えば良いので、ユースケース等の記述がしやすく、簡単に入力することができる。また、図２に示すように、構成要素の記述をドラッグ＆ドロップ操作によって行うこともできるので、入力ミスを防止することもできる。
【００３８】
図１の要求仕様記述部１では、上記図２に示したフォーマット入力画面に基づいて、目的、条件、基本系列、データなどの各種情報を含んだユースケースを単位要求仕様毎に順次入力していくとともに、対応するビジネスルールを同じく単位要求仕様毎に順次入力していく。要求仕様格納部２は、このように入力された個々の要求仕様の情報を格納するためのものである。ここでは、定義された個々のユースケースおよびビジネスルール毎に要求仕様が格納される。
【００３９】
関係解析部３は、上述のように定められたフォーマットに従って記述された要求仕様中の各構成要素間の関係を解析するものであり、構成要素抽出部３１と、第１の解析部３２と、解析結果格納部３３と、第２の解析部３４とを備える。ここで、構成要素抽出部３１は、要求仕様格納部２に格納されている要求仕様の情報中から、要求仕様モデルの構成要素（ユースケース、アクタ、データ、条件、ビジネスルール）に相当する部分を個々の単位要求仕様毎に抽出する。
【００４０】
また、第１の解析部３２は、構成要素抽出部３１により抽出された各構成要素の情報を用いて、単一の単位要求仕様内に含まれる各構成要素間の関係を夫々解析し、その結果を解析結果格納部３３に個々の単位要求仕様毎に格納する。ここでは、要求仕様モデルを構成する５つの構成要素のうち、同じ構成要素間あるいは異なる２つの構成要素間の関係を、構成要素の組み合わせを複数選んで各々解析する。
【００４１】
すなわち、ここで解析する構成要素間の関係は、５つの構成要素の中の２つの関係、例えばユースケースとアクタとの関係（誰がそのユースケースを実行するか等）、ユースケースとデータとの関係（そのユースケースでどんなデータが入出力されるか等）などである。また、同じ構成要素間の関係、例えばユースケースと他のユースケースとの関係（あるユースケースで他のどのユースケースを利用するか等）も解析する。また、解析する関係の種類としては、利用関係と拡張関係とがある。
【００４２】
さらに、第２の解析部３４は、上記第１の解析部３２により各単位要求仕様毎に解析され解析結果格納部３３に格納されたそれぞれの解析結果を用いて、１つのプロジェクト内に含まれる複数の単位要求仕様間にまたがる各構成要素間の関係を更に解析する。この第２の解析部３４でも、上述した第１の解析部３２と同様に、５つの構成要素のうち、同じ構成要素間あるいは異なる２つの構成要素間の関係を、構成要素の組み合わせを複数選んで各々解析する。
【００４３】
ただし、ここでは５つの構成要素のうちどれを対象として関係の解析を実行するかは、解析指定部４を用いてオペレータが指定する。すなわち、第２の解析部３４は、解析結果格納部３３に格納されている個々の単位要求仕様毎の解析結果を用いて、指定された構成要素間の関係を全要求仕様モデルに渡って解析する。関係出力部５は、上記第２の解析部３４により解析された結果を、例えば表示装置に出力することにより画面上に表示する。
【００４４】
図３は、上記解析指定部４により関係解析を行う構成要素を指定するための画面の一例を示す図である。図３に示すように、本実施形態では、５つの構成要素を縦軸および横軸のそれぞれに配したマトリクス表示を用い、マトリクス上の各マスに解析指定用のボタン４１を設けている。この解析指定用ボタン４１は、全てのマスに設けられるのではなく、関係のあり得るところにだけ表示される。例えば、ユースケースとビジネスルールとの関係はあり得るが、データとビジネスルールとの関係はあり得ない。
【００４５】
何れかの解析指定用ボタン４１をクリックすると、図３に示されるような、利用関係と拡張関係との何れかを選択するための関係種類選択画面４２がポップアップ表示される。ここでオペレータが利用関係か拡張関係かの何れかを選択すると、第２の解析部３４により当該指定された構成要素間の関係が全要求仕様モデルに渡って解析される。そして、その解析結果が関係出力部５により画面表示される。本実施形態では、指定された構成要素間の関係について解析された結果をマトリクス表示する。
【００４６】
図４〜図６は、上記解析結果のマトリクス表示の例を示す図である。図４は、アクタとユースケースとの関係を示す図である。この図４に示すマトリクス表示において、“Ｐ”はそのユースケースにとって主たるアクタ（プライマリアクタ）であることを示し、“Ｓ”は副次的なアクタ（セカンダリアクタ）であることを示す。プライマリアクタは、図２のユースケース入力画面で、基本系列の一番最初の欄に入力されたアクタがなる。一方、基本系列の二番目以降の欄に入力されたアクタは、全てセカンダリアクタとなる。
【００４７】
オペレータは、このようなアクタとユースケースとの関係を参照することにより、各ユースケース毎にどのアクタが関連しているかを一目瞭然で分かるようになる。
【００４８】
また、図５および図６は、ユースケースとユースケースとの関係を示す図である。このうち図５では、ユースケース間の利用関係を“Ｕ”で示している。これを見ることにより、例えば「事前準備」のユースケースが「研修環境の説明」というユースケースを利用しているといったことが一目で分かる。また、図６は、ユースケース間の拡張関係を“Ｅ”で示している。例えば「実装演習の提供」というユースケースは、「チェック」というユースケースを拡張していることが分かり、「チェック」のユースケースを拡張しているものには、他に「受入検査」というユースケースがあることが分かる。
【００４９】
オペレータは、このようなユースケース間の関係を参照することにより、各ユースケース毎にどのユースケースを利用あるいは拡張しているのかを一目瞭然で分かるようになる。
なお、図には示していないが、要求仕様モデルの他の構成要素間の関係についても同様にしてマトリクス表示を見ることができる。
【００５０】
オペレータは、これらのマトリクス表示を見ることにより、本来定義すべき関係に漏れがないかどうかとか、不必要な関係が定義されていないかどうかなどを容易に確認することができ、ひいては、要求仕様が適切に書かれているかどうかを簡単にチェックすることができる。これによって要求仕様が適切に書かれていないことが分かれば、その時点で要求仕様を正しく記述し直すことができ、システムの設計終了後等における手戻り作業を未然に防ぐことができる。
【００５１】
図７は、図１の関係解析部３が行う動作を示すフローチャートである。図３において、まずステップＳ１で、図２の入力画面に従って定義された各単位要求仕様（各階層のユースケース）をカウントするためのカウント値ｉを“０”に初期化した後、ステップＳ２でそのカウント値ｉを１つ増やし、ステップＳ３に進む。ステップＳ３で関係解析部３内の構成要素抽出部３１は、要求仕様格納部２の中から、ある１つの単位要求仕様について記述された要求仕様情報を読み込む。
【００５２】
そして、ステップＳ４で、その読み込んだ要求仕様情報の中から、要求仕様モデルの５つの構成要素を判別して抽出する。ここでは、図２のユースケース入力画面２３内で構成要素の入力欄として明示された部分の情報を読み込むことによって、各構成要素の情報を簡単に抽出することができる。例えば、基本系列欄の中のアクタは誰であるかとか、利用しているユースケースには何があるか、あるいは事前条件の有無やそのユースケース内で入出力されるデータは何であるか等といった情報を抽出する。また、構成要素の入力欄以外に入力された内容を読んで解析することにより、各構成要素を判別して抽出するようにしても良い。
【００５３】
次に、ステップＳ５で第１の解析部３２は、上記ステップＳ２にて１つの単位要求仕様の中から抽出した５つの構成要素に対して、同じ構成要素間あるいは異なる２つの構成要素間の関係を順次解析する。すなわち、オブジェクトモデルのクラス図を作成していくイメージで、互いに関係のある構成要素間にリンクを順次張っていくことにより、１つの単位要求仕様内での構成要素間の関係をチェックする。そして、その解析結果を解析結果格納部３３に格納する。
【００５４】
次に、ステップＳ６に進み、ある１つのプロジェクトについて定義された全ての単位要求仕様について関係解析の処理が終了したかどうかを判断し、まだ残りがある場合は、ステップＳ２に戻って当該残りの単位要求仕様の関係解析を実行する。一方、定義された全ての単位要求仕様について、構成要素間の関係解析が終了した場合には、ステップＳ７に進み、解析指定部４によって関係解析を行う構成要素の指定が行われたかどうかを判断する。ここで、指定が行われた場合はステップＳ８に進み、第２の解析部３４は、当該指定された構成要素間の関係を全要求仕様モデルに渡って解析する。そして、その解析結果を関係出力部５に出力して、処理を終了する。
【００５５】
以上詳しく説明したように、本実施形態の要求仕様記述支援装置によれば、定められたフォーマットに従って記述された要求仕様モデルの構成要素間の関係を解析し、その解析結果を例えば表示装置に表示するようにしたので、その表示された構成要素間の関係に漏れや矛盾等がないかどうかを見ることによって、記述された要求仕様が正確に記述されているか否かのチェックを容易に行うことができる。例えば、ここで要求仕様の不備が発見された場合には、その不備を補充するように要求仕様を記述し直すことにより、システムを開発する上で必要な要求仕様を、最終的に矛盾や抜けがないように正確に記述することができる。これにより、その後の設計段階や実装段階で手戻り作業が発生してしまう不都合を抑制することができる。
【００５６】
また、要求仕様の記述はユースケースの形態により自然言語で行うので、要求仕様を記述する作業者の負担を軽減することができるとともに、作成された要求仕様を後で誰が見ても容易に理解できるものとすることができる。なお、構成要素間の関係が簡単に分かるので、現行プロセスの解析などにおいても有効に利用することができる。
【００５７】
なお、上記実施形態では、第１の解析部３２による単位要求仕様毎の関係解析処理までは自動的に行い、第２の解析部３４による全要求仕様モデルに渡る関係解析処理は、解析指定部４による指定が行われたときにはじめて行っていた。これに対し、第１の解析部３２および第２の解析部３４による関係解析処理をあらかじめ全て行ってその解析結果を格納しておき、その後オペレータから構成要素の指定が行われたときに、指定された構成要素間の関係を選択して出力するようにしても良い。また、第１の解析部３２による解析処理と第２の解析部３４による解析処理の双方とも、オペレータから指定されたときにのみ、当該指定された構成要素間の関係を解析して出力するようにしても良い。
【００５８】
また、上記実施形態では、要求仕様モデルの構成要素として、ユースケース、アクタ、データ、条件、ビジネスルールの５つをあげたが、これらは単なる一例であって、本発明はこれに限定されるものではない。また、各構成要素間の関係の解析の方法も、上述した第１の解析部３２および第２の解析部３４のように、まず単位要求仕様内での関係を解析した後で全体での関係を解析する方法には限定されない。
【００５９】
また、上記実施形態では、解析指定部４により関係解析を行う所望の構成要素を指定する際に、図３のような指定用画面を用いていたが、図２の左側に示したツリー構造表示画面２１から指定を行うようにすることも可能である。図８は、マウスカーソルを“外部”と書かれたアイコンのところに移動させ、マウスの例えば右ボタンを押した後、カーソルを移動して“アクタ”のアイコンを選択したときの状態を示す。この場合は、図４に示すようなユースケースとアクタとの相関マトリクスが表示されることになる。
【００６０】
また、上記実施形態では、構成要素間の関係の解析結果を図４〜図６のようにマトリクス表示するだけであったが、このマトリクス上において所望のマスをクリックしたときに、そのマスに該当する入力画面を表示させるようにしても良い。オペレータは、マトリクス表示を見て何らかの矛盾や定義漏れがあると判断した場合には、要求仕様の入力画面に戻って再び定義を行うことになるが、上述のようにすれば、対応する入力画面に直ちに飛んでいくことができるので、作業の操作性および効率性を向上させることができる。
【００６１】
また、上記実施形態では、各構成要素間の関係について解析された結果をマトリクス表示していたが、ユースケース図として表示するようにしても良い。図９は、表示されるユースケース図の例を示す図である。図９において、楕円で示した部分はそれぞれ単位要求仕様のユースケースを示し、人の形をした部分はアクタを示している。また、このユースケース図では利用関係および拡張関係を両方とも表示している。このようにすれば、各構成要素間の関係をイメージとして確認することができる。
【００６２】
また、上記実施形態では、構成要素間の関係を表すマトリクス表示を見てオペレータ自身が要求仕様の矛盾や漏れを判断していたが、あるべきルールをあらかじめ登録しておくことにより、矛盾や漏れを装置に自動的に行わせるようにすることも可能である。例えば、プライマリアクタもセカンダリアクタも存在しない場合や、データが重複して２回以上使われている場合、あるいはデータの参照場所と入力場所との対応がとれていない場合などの一般的にチェック可能な項目に関しては、装置が自動的にチェックを行い、ルール違反があった場合にはエラーメッセージを出力するようにすることが可能である。
【００６３】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
図１０は、第２の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。なお、この図１０において、図１に示した符号と同一の符号を付したものは、同一の機能を有するものであるので、これについての詳細な説明は省略する。
【００６４】
図１０において、文章ベースの要求仕様記述部５１は、要求仕様モデルの各構成要素（ユースケース、アクタ、データ、条件、ビジネスルール）が全て含まれるようにあらかじめ定められた所定のフォーマットに従って、要求仕様の定義を文章ベースで記述するものであり、図１に示した要求仕様記述部１とほぼ同様のものである。ただし、本実施形態による文章ベースの要求仕様記述部５１は、要求仕様を記述するための入力画面として複数のビューを有する点で、図１の要求仕様記述部１と異なる。なお、この入力画面は、ＣＲＴやＬＣＤなどの表示部５５上に表示されるものである。
【００６５】
上記文章ベースの要求仕様記述部５１が有する複数のビューの例としては、要求仕様を必須項目だけで簡易的に記述できるようにした画面や、表（テーブル）形式によって一覧として要求仕様を記述するようにした画面、あらかじめ設定した１つ１つの入力項目を埋めながら詳細に要求仕様を記述していく画面などが考えられる。
【００６６】
また、本実施形態では、文章ベースで要求仕様を記述する文章ベースの要求仕様記述部５１の他に、図ベースで要求仕様を記述できるようにした図ベースの要求仕様記述部５２も備えている。この図ベースの要求仕様記述部５２も、要求仕様を記述するための入力画面として複数のビューを有している。上記文章ベースの要求仕様記述部５１および図ベースの要求仕様記述部５２が持つビューは、表示制御部５４の制御により、表示部５５上に複数を同時に表示させることが可能である。
【００６７】
これら文章ベースの要求仕様記述部５１で記述された要求仕様の情報、および図ベースの要求仕様記述部５２で記述された要求仕様の情報は、要求仕様格納部５３に格納される。ここでは、各要求仕様記述部５１，５２が持つ個々のビューごとに、定義された要求仕様の情報が別に格納される。
【００６８】
表示制御部５４は、要求仕様格納部５３に格納された各ビューに対応する要求仕様情報のうち、指定されたビューに対応する情報を選択的に表示部５５に表示させる制御を行う。このとき、表示制御部５４は、図ベースの要求仕様記述部５２で定義された要求仕様情報を表示部５５に表示する場合には、ＧＵＩ（Graphical User Interface）等を用いて表した所定のアイコンによってアクタやユースケースを表示する。このアイコン等の表示位置に関する情報は、要求仕様格納部５３に格納されている。表示制御部５４はまた、関係出力部５から出力される関係情報を表示部５５に表示させる制御も行う。
【００６９】
更新部５６は、文章ベースの要求仕様記述部５１および図ベースの要求仕様記述部５２が有する複数のビューのうち、あるビューを用いて追加、削除あるいは変更された定義内容を他のビューにも反映させるように、要求仕様格納部５３に格納されている要求仕様情報を更新するものである。
【００７０】
すなわち、ある１つのビューを用いて要求仕様の定義に追加、削除あるいは変更の操作が行われると、そのビューに対応して要求仕様格納部５３内に格納されている要求仕様情報が変更される。関係解析部３では、この変更された要求仕様情報を解析して各構成要素間の関係情報を解析結果格納部３３に格納する。更新部５６は、このとき解析結果格納部３３に格納された関係情報に基づいて、上記要求仕様の変更等が実際に行われたビュー以外の他のビューに対応する要求仕様情報を更新し、全てのビューの要求仕様が互いに同じ内容となるようにする。
【００７１】
このように、要求仕様格納部５３に格納されている各ビューに対応する要求仕様情報の更新が行われる場合において、図ベースのビューを更新するときは、自動レイアウト生成部５７は、要求仕様格納部５３に格納されているアイコン等の表示位置に関する情報も更新し、アイコン同士が重ならないように画面レイアウトを自動的に調整する。
【００７２】
なお、ここでは、更新部５６は、要求仕様の変更等が実際に行われたビュー以外のビューに対して要求仕様情報の更新を行うようにしているが、処理をより簡素化するために、要求仕様の変更等が実際に行われたビューを含む全てのビューに対して要求仕様情報の更新を行うようにしても良い。この場合、実際に変更等が行われたビューに対して要求仕様の更新を行っても、同じ内容で上書きするだけなので、特に問題はない。
【００７３】
このようにして要求仕様格納部５３に格納されている各ビューに対応する要求仕様情報を更新すると、表示制御部５４は、更新された新たな内容に従って要求仕様情報を表示部５５に表示することになる。これにより、表示部５５に表示されている複数のビューのうち何れかのビューで要求仕様の内容を変更すると、そのとき表示部５５に表示されている他のビュー内の要求仕様の内容がそれに合わせて変更される。
【００７４】
図１１は、本実施形態による表示部５５の表示画面の例を示す図である。図１１において、ツリー構造表示画面６１は、図２に示したツリー構造表示画面２１と同様、あるシステムの開発プロジェクトについて定義した要求仕様モデルをツリー構造にて表示するための画面である。このツリー構造表示画面６１において、アクタやユースケースの追加、削除あるいは変更などを任意に行うことが可能である。
【００７５】
図１１の例では、要求仕様を記述するための入力画面（ビュー）として、３つのビュー６２〜６４を表示している。また、記述された要求仕様に基づき解析された各構成要素間の関係を表示するための画面として、１つのマトリクス表示ビュー６５も表示している。
【００７６】
要求仕様を記述するためのビューの１つ目は、アクタの一覧をテーブル形式にて表示するアクタ一覧画面６２であり、２つ目は、ユースケースの一覧をテーブル形式にて表示するユースケース一覧画面６３である。これらの画面６２，６３は、文章ベースの要求仕様記述部５１によって要求仕様を記述するための入力画面である。３つ目は、アクタやユースケースをＧＵＩなどの図形式で表示するダイアグラム画面６４である。これは、図ベースの要求仕様記述部５２によって要求仕様を記述するための入力画面である。
【００７７】
１つ目のアクタ一覧画面６２の欄では、アクタの名称と、各アクタの内容を表す概要と、各アクタと関係を有するユースケース（そのアクタが実行するユースケース）とを定義する。また、２つ目のユースケース一覧画面６３の欄では、ユースケースの名称と、各ユースケースにおいてどんな業務を行うのかの大まかな内容を表す目的と、各ユースケースと関係を有するアクタ（そのユースケースを実行するアクタ）とを定義する。
【００７８】
また、３つ目のダイアグラム画面６４では、上記アクタ一覧画面６２あるいはユースケース一覧画面６３において文章ベースで定義される内容と同様の内容（アクタの概要やユースケースの目的は除く）を図ベースで定義する。この図１１の例では、アクタは人間の形をしたアイコンで表され、ユースケースは楕円形のアイコンで表される。また、アクタとユースケースとの間の関係は、その間に引かれた線によって表される。
【００７９】
このダイアグラム画面６４において要求仕様を定義する際には、アクタボタン６６をクリックすることによって新たなアクタを追加することができ、ユースケースボタン６７をクリックすることによって新たなユースケースを追加することができる。また、コミュニケーションボタン６８をクリックすることによって、アクタとユースケースとの間の関係を追加することができる。
【００８０】
この図１１に示す画面において、例えば所望のユースケースの部分をマウスでクリックすると、図２に示したような詳細なユースケースの入力画面が表示され、より詳細な定義を行うことができるようになっている。
なお、この図１１では既に要求仕様の定義が入力された状態を示しているが、最初はどのビューも空欄である。
【００８１】
ここで、例えばアクタ１，２およびユースケース１，２の定義まで終了している段階で、更にアクタ一覧画面６２を用いてアクタ３およびユースケース３を追加する場合を例にとってその動作を説明する。
【００８２】
まず、アクタ一覧画面６２内のアクタ名称の欄にアクタ３を追加する。この時点では、入力画面６３，６４を含む他のビューに対応する要求仕様の記述内容の更新処理はまだ行われないが、ユースケース一覧画面６３では、上記アクタ一覧画面６２で新たに定義されたアクタ３を、何らかのユースケースを実行するアクタとして選択可能な状態になる。
【００８３】
次に、ユースケース一覧画面６３内のユースケース名称の欄にユースケース３を追加する。この時点でも、入力画面６２，６４を含む他のビューに対応する要求仕様の記述内容の更新処理はまだ行われないが、アクタ一覧画面６２では、上記ユースケース一覧画面６３で新たに定義されたユースケース３を、何れかのアクタが実行するユースケースとして選択可能な状態になる。
【００８４】
次に、ユースケース３を実行するアクタとして、ユースケース一覧画面６３内のアクタの欄にアクタ３を追加する。すると、関係解析部３によってこのアクタ３とユースケース３との関係が解析され、その解析された関係情報に基づいて、更新部５６によって他のビューに対する定義内容の更新処理が行われる。
【００８５】
これにより、ユースケース一覧画面６３と同時に表示されている他の入力画面６２，６４の定義内容が、ユースケース一覧画面６３で追加された定義内容と同様となるように更新されて表示される。すなわち、アクタ一覧画面６２では、ユースケースの欄にユースケース３が追加表示される。また、ダイアグラム画面６４では、アクタ３のアイコンとユースケース３のアイコンとがその間に線が引かれた状態で追加表示される。
【００８６】
なお、ここでは、ある文章ベースのビューにおいて要求仕様の記述が変更された場合に、他の文章ベースのビューに対応した要求仕様および図ベースのビューに対応した要求仕様の記述を更新する例を示したが、これとは逆に、ある図ベースのビューにおいて要求仕様の記述が変更された場合には、他の図ベースのビューに対応した要求仕様および文章ベースのビューに対応した要求仕様の記述が更新される。
【００８７】
また、ここでは、ある文章ベースのビューで要求仕様の記述が変更された場合に、図ベースのビューに対応した要求仕様の表示を自動的に更新する例を示したが、オペレータからの指示に応じて更新内容を表示するようにしても良い。この指示を行うための構成が、図１０に示した図化範囲指定部５８である。
【００８８】
すなわち、ユースケース一覧画面６３内でアクタ３とユースケース３を追加したときに、アクタ一覧画面６２内の表示がそれに対応して更新されることは上述の場合と同じであるが、このときダイアグラム画面６４には、アクタ３とユースケース３の追加内容はまだ表示しない。ここで、オペレータが図化範囲指定部５８を用いて、例えばアクタ一覧画面６２内でアクタ３とユースケース３の範囲を指定し、これを図化することを指示すると、そのとき初めてアクタ３のアイコンとユースケース３のアイコンとをその間に線が引かれた状態で追加表示する。
【００８９】
つまり、アクタあるいはユースケースの削除および図に表示されている部分への更新については、その削除内容や更新内容を図ベースのビューに即時に反映させても良いが、新たな追加分については、それをその図ベースのビューに加えて表示するのが適切かどうか不明なことが多いので、自動的な追加は行わず、図化範囲指定部５８による指定を待って行うようにする。これは、あるユースケース図は、要求仕様の全体ではなくその一部だけを表示している場合があるからである。したがって、全要素を表示するように指定されているビューであれば、他のビューでの追加内容を自動的に反映させることとしても問題ない。
【００９０】
また、上述の動作例では、最初にアクタ一覧画面６２内のアクタ名称の欄にアクタ３を追加した時点では他のビューに対する記述内容の更新処理は行わないようにしていたが、この時点でも直ちに関係解析部３によってアクタ３の関係を解析し、その結果を他のビューに反映させるようにしても良い。
【００９１】
この場合、アクタ３の関係を解析すると、アクタ３に関係するユースケースは存在しないという結果が得られる。更新部５６は、この解析結果に基づいて、他のビューに対する記述内容の更新処理を行うようにする。すなわち、ここではアクタ３に関係するユースケースの更新処理は行えないが、アクタに関する入力項目を持つビューに対してはそのアクタ３を追加する処理を行う。これにより、アクタ一覧画面６２内のアクタ名称の欄にアクタ３を追加した時点で、例えばユースケース一覧画面６３のアクタ一覧の欄にアクタ３の名称が追加表示される。
【００９２】
その後、アクタ一覧画面６２内のユースケースの欄にユースケース３を追加すると、関係解析部３によってこのアクタ３とユースケース３との関係が解析され、その解析された関係情報に基づいて、更新部５６によって他のビューに対する定義内容の更新処理が行われる。これにより、ユースケース一覧画面６３のユースケース名称の欄にもユースケース３の名称が追加表示される。
【００９３】
以上のようにして要求仕様の記述内容が変更されると、構成要素間の関係をマトリクス表示するマトリクス表示ビュー６５の内容も更新して表示される。図１１に示す例では、この更新表示は最新ボタン６９をクリックしたときに行われるようになっている。なお、この最新ボタン６９を押さなくても自動的に内容を更新して表示するようにしても良い。
【００９４】
以上のように、第２の実施形態によれば、要求仕様を記述するための入力画面として複数のビューを用意し、任意のビューを用いて要求仕様を記述できるようにしたので、それぞれのオペレータ毎に書きやすいビューを用いて要求仕様の記述を行うことができる。しかも、１つのビューを用いて記述内容を変更すると、それに連動して他のビューの記述内容も適切に更新されるので、オペレータにとっての使い勝手を格段に向上させることができる。
【００９５】
さらに、本実施形態では、文章ベースだけでなく、図ベースによっても要求仕様を記述することができるようにしているので、例えば、最初は図ベースのビューを用いて視覚的に分かりやすい状態で要求仕様を記述していき、途中から文章ベースのビューに切り替えて詳細に記述していくといった使い方ができる。もちろん、最初に文章ベースで記述した要求仕様からそれに対応するユースケース図を自動的に生成し、以後は図ベースと文章ベースの所望のビューで修正していくことも可能である。つまり、図ベースの方が定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けることができる。
【００９６】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。
第３の実施形態は、要求仕様をユースケースの形態で記述する際に、ユースケースやアクタなどを構造的に記述できるようにしたものである。構造化されたユースケースやアクタの記述方法として、ここではＵＭＬ（Unified Modeling Language ）を利用する。
【００９７】
上記ＵＭＬにおいては、構成要素間の関係の種類として、利用（uses）、汎化（generalization）、拡張（extends ）の３つが定義されている。利用にはユースケース間の利用があり、汎化にはユースケース間およびアクタ間の汎化があり、拡張にはユースケース間の拡張がある。ここで言う利用、汎化、拡張は、ＵＭＬのバージョン1.1 における定義に基づいたものであるが、ＵＭＬのバージョン1.3 における定義に基づくものに置き換えることも可能である。
【００９８】
本実施形態では、ユースケース間の関係を定義する際、あるユースケース内の基本系列を構成する１個のイベントを他の１個のユースケースに対応させて構造化している点に特徴がある。このようにすることにより、ユースケースやアクタを構造化したときの詳細な関係を分かり易くすることができる。
【００９９】
ここで、利用とは、複数のユースケース間で共通に利用可能な共通サブユースケースがあるときに、あるユースケースからその共通サブユースケースを利用する関係を言う。汎化とは、元のユースケースや元のアクタに対して部分的な変更を加えて新たなユースケースや新たなアクタを作る関係を言う。なお、あるユースケースＡをベースに、それを継承して差分を記述して別のユースケースＢを定義した場合、ユースケースＡはユースケースＢを汎化したものであると言い、ユースケースＢはユースケースＡを特殊化したものであると言い、両者の関係を汎化関係という。また、拡張とは、基本的なイベントの流れを規定したユースケースにおいて、ある特定の条件を満たしたときに別の拡張ユースケースの処理を行う関係を言う。
【０１００】
図１２は、本実施形態によるユースケースの入力画面の例を示す図であり、基本系列を定義する部分を特にピックアップして示している。この図１２に示す基本系列の入力欄においては、図２の場合と同様に、そのユースケースで誰が何を行うか等の具体的な内容をイベント欄７１およびアクタ欄７２に記述する。このとき、特定のイベントにおいて共通サブユースケースを利用することがあれば、その利用する共通サブユースケースの名称を利用ユースケース（利用ＵＣ）の欄７３に記述する。
【０１０１】
図１２の例では、“ユースケース１”の基本系列において“イベント２”の中で利用する共通サブユースケースとして“ユースケース５”を定義している。これにより、“ユースケース１”と“ユースケース５”との間に利用（uses）の関係が張られる。
【０１０２】
また、図１２の入力画面には、利用ＵＣ作成ボタン７４、特殊化ボタン７５および拡張ボタン７６が設けられている。このうち、利用ＵＣ作成ボタン７４は、複数のイベント列を指定して共通サブユースケースを作成することを指示するためのボタンである。
【０１０３】
例えば、図１２に示す入力画面上で、共通サブユースケースに落とし込みたいイベント列を指定して利用ＵＣ作成ボタン７４をマウスでクリックすると、その指定したイベント列を要素とする共通サブユースケースの名称や概要（目的）の入力を促す画面が現れる。この画面で共通サブユースケースの名称や概要（目的）を入力してＯＫボタンを押すことにより、共通サブユースケースが作成される。
【０１０４】
図１３は、この共通サブユースケースを作成する際の動作を説明するための図である。図１３においては、ａ〜ｆを内容とするイベント列から成るユースケース▲１▼があったときに、ａ〜ｄの内容は複数のユースケースで利用する可能性があるためにこれを共通サブユースケースとして作成しようとする場合の例を示している。
【０１０５】
この場合、図１３（ａ）に示す元のユースケース▲１▼において、共通サブユースケースとすべきイベント列ａ〜ｄを指定して利用ＵＣ作成ボタン７４をクリックし、更に当該共通サブユースケースの名称として“ユースケース▲２▼”を入力するとともに、概要として“Ｘ”を入力すると、図１３（ｂ）に示すような共通サブユースケース▲２▼が作成される。また、図１３（ｃ）に示すように、元のユースケース▲１▼の４つのイベント列ａ〜ｄが１つのイベントＸ（共通サブユースケース▲２▼を利用したもの）に置き換えられたユースケース▲１▼′が自動的に作られる。
【０１０６】
このようにして共通サブユースケース▲２▼を作成した後は、ユースケース▲１▼′以外の他のユースケースからもこの共通サブユースケース▲２▼を利用することが可能となる。
このように共通サブユースケースを作成してこれを複数のユースケースで共通に利用できるようにすることにより、ユースケースの再利用を容易にすることができ、オペレータがユースケースを記述する際の作業負担を軽減することができる。
【０１０７】
また、特殊化ボタン７５は、あるユースケースと汎化関係にある他のユースケースを作成することを指示するためのボタンである。例えば、図１２に示す入力画面上で特殊化ボタン７５をクリックすると、そのとき表示されていたものと同内容のイベント列を有するユースケースが別の入力画面として現れる。ここで、所望の箇所を変更した上で、新たなユースケースの名称や概要（目的）を入力してＯＫボタンを押すことにより、元のユースケースと汎化関係にある別の特殊化されたユースケースが作成される。
【０１０８】
図１４は、この特殊化されたユースケースを作成する際の動作を説明するための図である。図１４（ａ）のようにａ〜ｅを内容とするイベント列から成るユースケース▲１▼があるときに、特殊化ボタン７５を押すと、図１４（ｂ）に示すように、ユースケース▲１▼のイベント列ａ〜ｅをそのまま反映した別のユースケースの入力画面が現れる。このとき、特殊化用のユースケースが新たに作られているが、この段階では、元のユースケースを特殊化したものであることを示す情報のみが新たな記憶領域に格納され、中身の情報は何も格納されていない状態である。
【０１０９】
次に、図１４（ｂ）に示す入力画面上で所望の箇所を変更する。図１４の例では、イベントｃの内容をイベントｘに変更している。さらに、特殊化用ユースケースの名称として“ユースケース▲２▼”を入力すると、図１４（ｃ）に示すように特殊化されたユースケース▲２▼が作成される。このとき、特殊化用ユースケースの記憶領域には、元のユースケース▲１▼から変更があった部分の差分データのみ、つまりイベントｘのデータのみが格納される。他の変更されていない部分の情報は、元のユースケース▲１▼が格納されている記憶領域からデータを読み出して画面上に表示している。
【０１１０】
様々なユースケースを記述していく際、異なるユースケースでも同内容の入力を繰り返し行うことが少なからずある。この場合において、従来は全てのユースケースについて最初から記述していたが、本実施形態によれば、一部のみが異なるユースケースを継承し、異なる部分の定義だけを記述すれば良いので、オペレータの作業量を格段に少なくすることができる。
【０１１１】
また、特殊化されたユースケースでは、その親のユースケースとの差分データだけを格納しているので、親のユースケースにおいて共通の部分に修正が行われたとしても、その修正内容は特殊化されたユースケースにも反映され、常に整合性を正しく維持することができる。したがって、全ての記述をオペレータの手作業で入力していた従来と比べて、修正漏れや入力の間違いを少なくすることができ、より正確な要求仕様を記述することができるようになる。
【０１１２】
また、拡張ボタン７６は、あるユースケースと拡張の関係にある他のユースケースを作成することを指示するためのボタンである。例えば、図１２に示す入力画面上で拡張ボタン７６をクリックすると、拡張ユースケースを記述するための別の入力画面が現れる。ここで、元のユースケースからの分岐条件と、その条件を満たした場合に実行するイベント列とを入力するとともに、元のユースケースから分岐する分岐場所と、拡張ユースケースの処理が終わった後に戻る元のユースケースの戻り場所とを入力することにより、元のユースケースと拡張の関係にある別のユースケースが作成される。
【０１１３】
図１５は、この拡張されたユースケースを作成する際の動作を説明するための図である。図１５（ａ）のようにａ〜ｅを内容とするイベント列から成るユースケース▲１▼があるときに、拡張ボタン７６を押すと、拡張ユースケースを記述するための別の入力画面が現れる。ここで、例えば、分岐条件の内容を含むイベント列ｘ〜ｚを入力するとともに、元のユースケース▲１▼の分岐場所としてイベントｃ、拡張ユースケースのイベント列ｘ〜ｚを実行した後に戻る元のユースケース▲１▼の戻り場所としてイベントｄを入力することにより、図１５（ｂ）に示すような拡張ユースケース▲２▼が作成される。
【０１１４】
なお、以上の例では、構造化されたユースケース等を文章ベースで記述する場合を例にとって説明したが、第２の実施形態と同様に、構造化されたユースケース等を図ベースで記述することも可能である。図１６は、本実施形態による表示画面の例を示す図である。
【０１１５】
すなわち、図１６に示すダイアグラム画面６４において構造化された関係を記述する場合には、汎化ボタン８１をクリックすることによってユースケース間あるいはアクタ間の汎化関係を追加することができ、利用ボタン８２をクリックすることによって、ユースケースと共通サブユースケースとの利用関係を追加することができる。また、拡張ボタン８３をクリックすることによって、ユースケース間の拡張関係を追加することができる。なお、これらの関係について詳細な内容を定義する際には、例えばダイアグラム画面６４上の該当するアイコンをマウスでクリックすることにより、文章ベースの入力画面を表示させる。
【０１１６】
図１７は、上述のようにユースケース等の構造化を行うことができるようにした第３の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。なお、この図１７において、図１０に示した符号と同一の符号を付したものは、同一の機能を有するものであるので、これについての詳細な説明は省略する。
【０１１７】
図１７に示す要求仕様記述支援装置では、図１０に示した構成に対して更に構造化指定部９１と第２の要求仕様格納部９２とが追加されている。構造化指定部９１は、第１の要求仕様格納部５３に格納されている要求仕様の情報に対して利用、汎化、拡張の何れかの関係を指定するものである。構造化指定部９１は、これら３つの関係の種類を指定するだけでなく、必要に応じて構造化を行う範囲も指定する。
【０１１８】
第２の要求仕様格納部９２は、第１の要求仕様格納部５３に格納されている元の要求仕様情報（ユースケースやアクタ）と利用、汎化あるいは拡張の関係を有する要求仕様情報を格納するものである。なお、ここでは第１の要求仕様格納部５３と第２の要求仕様格納部９２とを別に設けているが、同じ格納部に領域を分けて格納するようにしても良い。
【０１１９】
例えば、第１の要求仕様格納部５３に格納されているあるユースケースのイベント列の中から共通サブユースケースを作成しようとするときは、構造化指定部９１により利用関係を指定するとともに、作成対象とするイベント列の範囲を指定する。さらに、文章ベースの要求仕様記述部５１あるいは図ベースの要求仕様記述部５２を用いて必要な事項（当該共通サブユースケースの目的、事前条件、事後条件など）を記述することにより、共通サブユースケースに関する要求仕様の情報が第２の要求仕様格納部９２内に作られる。
【０１２０】
また、第１の要求仕様格納部５３に格納されているあるユースケースを特殊化して別のユースケースを作成しようとするときは、構造化指定部９１により汎化関係を指定する。このとき、第２の要求仕様格納部９２には、特殊化用のユースケースを格納するための領域が確保されるが、この段階では、元のユースケースを特殊化したものであることを示す情報のみがこの新たな記憶領域に格納される。
【０１２１】
さらに、文章ベースの要求仕様記述部５１あるいは図ベースの要求仕様記述部５２を用いて所望の箇所を修正するとともに、必要な事項（当該特殊化ユースケースの目的、事前条件、事後条件など）を記述することにより、特殊化されたユースケースに関する要求仕様の情報が第２の要求仕様格納部９２内に作られる。このとき第２の要求仕様格納部９２に格納される情報は、第１の要求仕様格納部５３に格納されている元のユースケースとの差分データのみである。
【０１２２】
また、第１の要求仕様格納部５３に格納されているあるユースケースを拡張して別のユースケースを作成しようとするときは、構造化指定部９１により拡張関係を指定する。さらに、文章ベースの要求仕様記述部５１あるいは図ベースの要求仕様記述部５２を用いて必要な事項（当該拡張ユースケースの目的、事前条件、拡張ユースケースの基本系列、事後条件など）を記述することにより、拡張ユースケースに関する要求仕様の情報が第２の要求仕様格納部９２内に作られる。
【０１２３】
表示制御部５４は、第１の要求仕様格納部５３および第２の要求仕様格納部９２に格納された各ビューに対応する要求仕様情報のうち、指定されたビューに対応する情報を選択的に表示部５５に表示させる制御を行う。このとき、表示制御部５４は、例えば汎化により構造化された要求仕様情報について、元の要求仕様情報との差分のみを表示したり、両者を合わせて展開したものを表示したりすることが可能である。
【０１２４】
以上のように、第３の実施形態によれば、ユースケースやアクタを利用、汎化、拡張の関係で構造化できるようにしたので、例えば利用関係を用いて共通サブユースケースを作成することにより、複数のユースケースからこの共通サブユースケースを利用することが可能となり、ユースケースの再利用を容易にすることができる。また、あるユースケースに含まれるイベント列の一部を抜き出して共通サブユースケースを作ると、その元のユースケース中で抜き出された部分を共通サブユースケースの記述に自動的に置き換えることができる。これにより、オペレータがユースケースを定義する際の作業負担を軽減することができる。
【０１２５】
また、例えば汎化関係を用いて別のユースケースや別のアクタを作成することにより、様々なユースケースを定義していく際、それらのユースケース間で共通の部分は繰り返し入力しなくても済み、異なる部分だけを入力していけば良くなる。これにより、オペレータの作業量を格段に少なくすることができる。このとき、異なる部分だけを表示して記述するのではなく、元のユースケースと同じ内容を入力画面に表示した上で必要な部分を修正していくことができるようにしているので、ユースケースの全体感をよく理解しながら異なる部分だけを記述していくことができる。
【０１２６】
また、特殊化されたユースケースでは、その元となったユースケースとの差分データだけを格納しているので、元のユースケースにおいて共通の部分に修正が行われたとしても、その修正内容は特殊化されたユースケースにも反映されることとなり、常に整合性を正しく維持することができる。したがって、修正漏れや入力ミスを少なくすることができ、より正確な要求仕様を記述することができるようになる。また、特殊化されたユースケースと元のユースケースとの差分だけを表示するビューや、両者を合わせて展開したものを表示するビューなど、必要に応じたビューを定義することもできる。
【０１２７】
また、例えば拡張関係を用いて別のユースケースを作成することにより、あるユースケース内の特定のイベントから他のユースケースへと条件分岐させることができる。このとき、１個のイベントと１個のユースケースとの間を関係付けているので、ユースケースを構造化したときの詳細な関係を分かり易くすることができる（これは利用関係により構造化したときも同じである）。
【０１２８】
また、本実施形態では、文章ベースだけでなく、図ベースによっても要求仕様を記述することができるようにしているので、構造化されている関係を一目で容易に理解することができる。また、図ベースの方が定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けることもできる。
【０１２９】
（本発明の他の実施形態）
なお、以上に説明した各実施形態の要求仕様記述支援装置は、コンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。記録媒体としては、ＣＤ−ＲＯＭ以外に、フロッピーディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。
【０１３０】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
【０１３１】
なお、上記に示した実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１３２】
【発明の効果】
本発明は上述したように、例えばユースケースの形態で記述された要求仕様モデルの構成要素間の関係を解析して、その解析された結果を例えば表示装置に出力するようにしたので、表示された構成要素間の関係を参照することによって、記述された要求仕様に漏れや矛盾等がないか否かのチェックを容易に行うことができる。これにより、必要に応じてそのチェック結果を要求仕様の記述にフィードバックすることにより、システムを開発する上で必要な要求仕様を正確に記述することができる。したがって、その後の設計段階や実装段階で手戻り作業が発生してしまう不都合を未然に防止することができ、従来に比べてシステムの開発コストを大幅に削減することができる。
【０１３３】
また、本発明のその他の特徴によれば、要求仕様をユースケースの形態で記述するための情報入力画面として、ユースケースを文章ベースで記述するビューと図ベースで記述するビューを含む複数のビューを用意し、何れかのビューを用いて要求仕様の記述が行われたときに、その記述内容を他のビューにも反映させるようにしたので、複数のビューの中からオペレータが書きやすいビューを用いて要求仕様の定義を行うことができる。したがって、図ベースの方が要求仕様の定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けることができ、オペレータにとってより使い勝手の良い環境を提供することができる。
【０１３４】
また、本発明のその他の特徴によれば、要求仕様モデルの各構成要素について、ある構成要素から他の構成要素を利用する利用関係、元の構成要素に対して部分的な変更を加えて新たな構成要素を作る汎化関係、ある構成要素において特定の条件を満たしたときに別の構成要素の処理を行う拡張関係の少なくとも１つを用いて各構成要素を構造化できるようにしたので、例えば利用関係を用いて共通構成要素を作成することにより、構成要素の再利用を容易にすることができる。
また、汎化関係を用いて別の構成要素を作成することにより、様々な構成要素間で共通の部分は繰り返し入力しなくても済み、オペレータの作業負荷を少なくすることができる。このとき、特殊化された構成要素は元の構成要素との差分だけをデータとして持つので、元の構成要素において行われた修正内容を、特殊化された構成要素にも特別な処理を行うことなく反映させることが可能となり、常に整合性を正しく維持することができる。したがって、修正漏れや入力ミスを少なくしてより正確な要求仕様を記述することができるようになる。
また、拡張関係を用いて別の構成要素を作成することにより、ある構成要素から他の構成要素へと条件分岐させることができる。
さらに、文章ベースだけでなく、図ベースによっても構造化された要求仕様を記述できるようにした場合には、図ベースのビューを用いることにより、構造化されている関係を一目で容易に理解することができる。逆に、詳細な内容を記述する場合には文章ベースのビューを用いることができる。つまり、図ベースの方が定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けて構造化された構成要素を定義することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【図２】第１の実施形態による要求仕様の入力画面の例を示す図である。
【図３】関係解析を行う構成要素を指定するための画面の一例を示す図である。
【図４】解析結果のマトリクス表示の例を示す図である。
【図５】解析結果のマトリクス表示の例を示す図である。
【図６】解析結果のマトリクス表示の例を示す図である。
【図７】図１の関係解析部が行う動作を示すフローチャートである。
【図８】関係解析を行う構成要素を指定するための他の画面例を示す図である。
【図９】各構成要素間の関係を表すために表示されるユースケース図の例を示す図である。
【図１０】本発明の第２の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【図１１】第２の実施形態による複数のビューを有する表示画面の例を示す図である。
【図１２】第３の実施形態によるユースケースの入力画面の例を示す図である。
【図１３】共通サブユースケースを作成する際の動作を説明するための図である。
【図１４】特殊化されたユースケースを作成する際の動作を説明するための図である。
【図１５】拡張されたユースケースを作成する際の動作を説明するための図である。
【図１６】第３の実施形態による複数のビューを有する表示画面の例を示す図である。
【図１７】第３の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【符号の説明】
１ 要求仕様記述部
２ 要求仕様格納部
３ 関係解析部
４ 解析指定部
５ 関係出力部
２１ ツリー構造表示画面
２２ａ ユースケース用タグ
２２ｂ ビジネスモデル用タグ
２３ ユースケース入力画面
３１ 構成要素抽出部
３２ 第１の解析部
３３ 解析結果格納部
３４ 第２の解析部
５１ 文章ベースの要求仕様記述部
５２ 図ベースの要求仕様記述部
５３ 要求仕様格納部
５４ 表示制御部
５５ 表示部
５６ 更新部
５７ 自動レイアウト生成部
５８ 図化範囲指定部
６１ ツリー構造表示画面
６２ 文章ベースのアクタ一覧画面
６３ 文章ベースのユースケース一覧画面
６４ 図ベースのダイアグラム画面
６５ マトリクス表示画面
６６ アクタボタン
６７ ユースケースボタン
６８ コミュニケーションボタン
６９ 最新ボタン
７１ イベント欄
７２ アクタ欄
７３ 利用ＵＣ欄
７４ 利用ＵＣ作成ボタン
７５ 特殊化ボタン
７６ 拡張ボタン
８１ 汎化ボタン
８２ 利用ボタン
８３ 拡張ボタン
９１ 構造化指定部
９２ 第２の要求仕様格納部
【発明の属する技術分野】
本発明は要求仕様記述支援装置およびその方法、記録媒体に関し、特に、ソフトウェア等のシステム開発で用いる要求仕様の記述を支援するための装置に用いて好適なものである。
【０００２】
【従来の技術】
一般に、コンピュータを利用したシステム開発は、その要求仕様の定義から基本設計、詳細設計などの過程を経て最終的にコーディングされ、必要に応じてデバッグされて完成となる。この中で、特に要求仕様の定義は、システム開発を行う上で非常に重要な意味を持つものである。すなわち、要求仕様の中で曖昧な記述や誤解を生じるような記述をしていると、その内容をもとに設計され作成されたシステムは、全く使えないものか、ユーザの全く期待していなかったものになってしまうことが多い。
【０００３】
また、要求仕様をきちんと記述していない場合、システム開発においてその要求定義の問題が発覚するのは、設計が終わったとき、あるいはコーディングを開始してからであることが多いが、この段階で間違いを直すのは簡単ではなく、莫大な開発コストがかかる。これに対して、最初の要求仕様をきちんと記述しておけば、その後で発生する手戻り作業を極力抑えることができる。したがって、要求仕様をきちんと記述しておくことは、極めて重要であると言える。
【０００４】
【発明が解決しようとする課題】
しかしながら、このように要求仕様は極めて重要であるにもかかわらず、従来これを正確に記述することができないことが多かった。
【０００５】
すなわち、従来は、システム開発の前段階において、現状システムと改善後のシステム、あるいは新しいシステムの内容などについて、システムが備える機能を中心として、人間が行う作業、データの発生や流れ、データの出力などを人間の言葉や図面を用いて記述していた。また、最近では、要求仕様を記述するのに種々の方法が用いられるようになってきており、その中の１つに、システムの機能ではなく用途に着目して記述を行うユースケースと呼ばれるものも登場してきている。
【０００６】
しかし、何れの方法によっても、その記述された内容からシステム設計に漏れや誤り等がないかどうかをチェックするのは、人手によっていた。例えば、要求仕様として記述された文章や図面そのものを人間が見て、そこからデータの発生、利用関係、出力等や、誰が何を入力してどんな作業を行うのかなどの色々なチェックをその人間の判断で行っていた。
【０００７】
ところが、これらのチェックは、人間が手作業で行うものなので、見落としや間違いなどが発生しやすい。また、コンピュータ等を利用してもある程度はチェックできるが、どのように行えばチェックが正確かつ容易になるかは、明確でなかった。チェックのミスや漏れがあると、結局は正しい要求仕様を記述することができず、その後の手戻り作業が発生してしまうことになり、多くの開発コストがかかってしまう原因となる。
【０００８】
本発明は、このような実情に鑑みて成されたものであり、記述された要求仕様のチェックを正確かつ容易に行えるようにすることにより、正確な要求仕様を記述することを支援できるようにした要求仕様記述支援装置およびその方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明の要求仕様記述支援装置は、システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析手段と、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力手段とを備えたことを特徴とする。
本発明の要求仕様記述支援方法は、システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、関係解析手段と、関係出力手段とを備えた要求仕様記述支援装置によって実行される要求仕様記述支援方法であって、上記関係解析手段が、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析ステップと、上記関係出力手段が、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力ステップとを備えたことを特徴とする。
本発明のコンピュータ読み取り可能な記録媒体は、コンピュータを、システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析手段と、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力手段として機能させるためのプログラムを記録したことを特徴とする。
【００２３】
本発明は上記技術手段より成るので、要求仕様モデルの各構成要素間の関係が解析されて出力されることとなり、その出力された構成要素間の関係をオペレータが参照することによって、本来定義すべき関係に漏れがないかどうかや、不必要な関係が定義されていないかどうかなどを確認することにより、要求仕様が適切に書かれているかどうかをチェックすることが可能となる。
【００２４】
また、本発明の他の特徴によれば、要求仕様を記述するための情報入力画面として用意された複数のビューの中から、オペレータが書きやすいビューを用いて要求仕様の記述を行うことが可能となり、１つのビューを用いて要求仕様の定義内容を変更すると、それに連動して他のビューの定義内容も適切に更新されることとなる。
【００２５】
また、本発明のその他の特徴によれば、例えば利用関係を用いて共通の構成要素を作成することにより、複数の構成要素からこの共通構成要素を利用することが可能となり、構成要素の再利用を容易にすることが可能となる。また、汎化関係を用いて別の構成要素を作成することにより、様々な構成要素について要求仕様を記述していく際に、それらの構成要素間で共通の部分は繰り返し入力しなくても済む。このとき、汎化された構成要素は元の構成要素との差分だけをデータとして持つので、元の構成要素において行われた修正内容を、汎化された構成要素にも特別な処理を行うことなく反映させることが可能となる。また、拡張関係を用いて別の構成要素を作成することにより、ある構成要素から他の構成要素へと条件分岐させることが可能となる。
【００２６】
【発明の実施の形態】
以下、本発明の一実施形態について図面を参照しながら説明する。
【００２７】
（第１の実施形態）
図１は、本発明の第１の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【００２８】
図１において、要求仕様記述部１は、本実施形態による要求仕様モデルの各構成要素が全て含まれるようにあらかじめ定められた所定のフォーマットに従って、要求仕様の定義を記述する。すなわち、要求仕様の入力フォーマットとして、上記要求仕様モデルの各構成要素を全て含んだ入力画面を用意し、ここに各種情報を入力していくことによって、要求仕様を記述する。本実施形態の場合、要求仕様モデルの各構成要素としては、ユースケース、アクタ、データ、条件、ビジネスルールの５つを含む。
【００２９】
ユースケースとは、開発するシステムが業務上どのように利用されるのかという点に着目して、システムの稼働時にオペレータが行う一連のアクション（イベント）等を、トランザクション毎に各構成要素が明確になるように自然言語で記述したものを言う。また、アクタは、それぞれのアクションを誰が行うかを示すもの、データは、各アクションの際にどんなデータを入出力するかを示すもの、条件は、各アクション時に満たすべき状態等を示すもの、ビジネスルールは、開発されたシステムによって業務を遂行する上で守るべきルールを示すものである。
【００３０】
図２は、本実施形態による要求仕様の入力画面の例を示す図である。図２において、ツリー構造表示画面２１は、あるシステムの開発プロジェクトについて定義した要求仕様モデルをツリー構造にて表示するための画面である。この画面２１の下方には、タグ２２ａ，２２ｂが設けられており、一方のタグ２２ａをクリックすると、図２に示されるようにユースケースの入力画面となり、もう一方のタグ２２ｂをクリックすると、図示しないビジネスルールの入力画面となる。
【００３１】
図２の例では、プログラミングの教育システムを開発するプロジェクトで要求仕様として定義すべき情報の例を示しており、上記ツリー構造表示画面２１内には、そのプロジェクトにおけるユースケースの利用関係とアクタの一覧とが示されている。すなわち、ここに示されるツリー構造としては、“プロジェクト”の下層に“ユースケース”と“アクタ”があり、上記“ユースケース”の下層に“外部”、“内部”および“情報システム”がある。
【００３２】
さらにここでは、ユースケース“外部”の中のユースケースの利用関係を特に示している。すなわち、ユースケース“外部”と書かれた階層の下の階層には、“演習問題の提供”、“評価”および“○○知識獲得”というユースケースがあり、上記“演習問題の提供”の下の階層には更に“事前準備”および“演習問題の公開”というユースケースがある。さらに、上記“演習問題の公開”の下の階層には更に“演習問題の実装”というユースケースがある。
【００３３】
このように、ある業務システムを作成する１つのプロジェクトに関する要求仕様は、システム上で行う個々の業務を単位として記述した複数の単位要求仕様から成り、ツリー構造表示画面２１内に示される“演習問題の提供”、“評価”、“○○知識獲得”、“事前準備”、“演習問題の公開”、“演習問題の実装”などの各ユースケースは、それぞれ１つの単位要求仕様に該当する。
【００３４】
ここで、例えばツリー構造表示画面２１内の任意のユースケースの部分をマウスでクリックすると、そのユースケースの入力画面２３がツリー構造表示画面２１の右側に表示される。図２の例では、“演習問題の実装”というユースケースの部分がクリックされたときの様子を示している。このユースケース入力画面２３では、ユースケース名の表示の後に、目的、事前条件、基本系列、事後条件およびデータの入力画面が表示される。
【００３５】
上記ユースケース入力画面２３内の目的の欄には、そのユースケースにおいてどんな業務を行うのかの大まかな内容を定義する。また、事前条件の欄には、その業務を行うために事前に行われていることが必要な条件を定義する。また、基本系列の欄には、そのユースケースで誰が何を行うか等の具体的な内容を定義する。ここでは、具体的な動作の内容を表すイベントと、それを誰が行うかを表すアクタと、それを行う際に利用する他のユースケースとを各動作毎に順番に記述していく。図２では、ツリー構造表示画面２１内から“箇所研修生”をドラッグしてきてアクタの欄に張り付けている状態を示している。
【００３６】
また、事後条件の欄には、そのユースケースで定義されている動作を行った後にどんな状態となるかを定義する。例えば、動作が成功に終わった場合と、失敗に終わった場合とに分けて、それぞれの場合にどういう状態となるかを定義する。また、データの欄には、そのユースケースでどんなデータを入出力するかについて定義する。なお、図２中には事後条件およびデータの入力画面は現れていないが、これらは画面を下にスクロールさせると見えてくる。
【００３７】
このように、本実施形態では、図面等とは異なり、誰もが同じように理解できる自然言語で各種の情報を入力していくことによって要求仕様を記述するようにしているので、開発するシステムの機能とそれを用いて行う業務との対応関係を明確にすることができ、食い違いの発生を極力少なくすることができる。その際、あらかじめ定められた入力項目に対して記述を行えば良いので、ユースケース等の記述がしやすく、簡単に入力することができる。また、図２に示すように、構成要素の記述をドラッグ＆ドロップ操作によって行うこともできるので、入力ミスを防止することもできる。
【００３８】
図１の要求仕様記述部１では、上記図２に示したフォーマット入力画面に基づいて、目的、条件、基本系列、データなどの各種情報を含んだユースケースを単位要求仕様毎に順次入力していくとともに、対応するビジネスルールを同じく単位要求仕様毎に順次入力していく。要求仕様格納部２は、このように入力された個々の要求仕様の情報を格納するためのものである。ここでは、定義された個々のユースケースおよびビジネスルール毎に要求仕様が格納される。
【００３９】
関係解析部３は、上述のように定められたフォーマットに従って記述された要求仕様中の各構成要素間の関係を解析するものであり、構成要素抽出部３１と、第１の解析部３２と、解析結果格納部３３と、第２の解析部３４とを備える。ここで、構成要素抽出部３１は、要求仕様格納部２に格納されている要求仕様の情報中から、要求仕様モデルの構成要素（ユースケース、アクタ、データ、条件、ビジネスルール）に相当する部分を個々の単位要求仕様毎に抽出する。
【００４０】
また、第１の解析部３２は、構成要素抽出部３１により抽出された各構成要素の情報を用いて、単一の単位要求仕様内に含まれる各構成要素間の関係を夫々解析し、その結果を解析結果格納部３３に個々の単位要求仕様毎に格納する。ここでは、要求仕様モデルを構成する５つの構成要素のうち、同じ構成要素間あるいは異なる２つの構成要素間の関係を、構成要素の組み合わせを複数選んで各々解析する。
【００４１】
すなわち、ここで解析する構成要素間の関係は、５つの構成要素の中の２つの関係、例えばユースケースとアクタとの関係（誰がそのユースケースを実行するか等）、ユースケースとデータとの関係（そのユースケースでどんなデータが入出力されるか等）などである。また、同じ構成要素間の関係、例えばユースケースと他のユースケースとの関係（あるユースケースで他のどのユースケースを利用するか等）も解析する。また、解析する関係の種類としては、利用関係と拡張関係とがある。
【００４２】
さらに、第２の解析部３４は、上記第１の解析部３２により各単位要求仕様毎に解析され解析結果格納部３３に格納されたそれぞれの解析結果を用いて、１つのプロジェクト内に含まれる複数の単位要求仕様間にまたがる各構成要素間の関係を更に解析する。この第２の解析部３４でも、上述した第１の解析部３２と同様に、５つの構成要素のうち、同じ構成要素間あるいは異なる２つの構成要素間の関係を、構成要素の組み合わせを複数選んで各々解析する。
【００４３】
ただし、ここでは５つの構成要素のうちどれを対象として関係の解析を実行するかは、解析指定部４を用いてオペレータが指定する。すなわち、第２の解析部３４は、解析結果格納部３３に格納されている個々の単位要求仕様毎の解析結果を用いて、指定された構成要素間の関係を全要求仕様モデルに渡って解析する。関係出力部５は、上記第２の解析部３４により解析された結果を、例えば表示装置に出力することにより画面上に表示する。
【００４４】
図３は、上記解析指定部４により関係解析を行う構成要素を指定するための画面の一例を示す図である。図３に示すように、本実施形態では、５つの構成要素を縦軸および横軸のそれぞれに配したマトリクス表示を用い、マトリクス上の各マスに解析指定用のボタン４１を設けている。この解析指定用ボタン４１は、全てのマスに設けられるのではなく、関係のあり得るところにだけ表示される。例えば、ユースケースとビジネスルールとの関係はあり得るが、データとビジネスルールとの関係はあり得ない。
【００４５】
何れかの解析指定用ボタン４１をクリックすると、図３に示されるような、利用関係と拡張関係との何れかを選択するための関係種類選択画面４２がポップアップ表示される。ここでオペレータが利用関係か拡張関係かの何れかを選択すると、第２の解析部３４により当該指定された構成要素間の関係が全要求仕様モデルに渡って解析される。そして、その解析結果が関係出力部５により画面表示される。本実施形態では、指定された構成要素間の関係について解析された結果をマトリクス表示する。
【００４６】
図４〜図６は、上記解析結果のマトリクス表示の例を示す図である。図４は、アクタとユースケースとの関係を示す図である。この図４に示すマトリクス表示において、“Ｐ”はそのユースケースにとって主たるアクタ（プライマリアクタ）であることを示し、“Ｓ”は副次的なアクタ（セカンダリアクタ）であることを示す。プライマリアクタは、図２のユースケース入力画面で、基本系列の一番最初の欄に入力されたアクタがなる。一方、基本系列の二番目以降の欄に入力されたアクタは、全てセカンダリアクタとなる。
【００４７】
オペレータは、このようなアクタとユースケースとの関係を参照することにより、各ユースケース毎にどのアクタが関連しているかを一目瞭然で分かるようになる。
【００４８】
また、図５および図６は、ユースケースとユースケースとの関係を示す図である。このうち図５では、ユースケース間の利用関係を“Ｕ”で示している。これを見ることにより、例えば「事前準備」のユースケースが「研修環境の説明」というユースケースを利用しているといったことが一目で分かる。また、図６は、ユースケース間の拡張関係を“Ｅ”で示している。例えば「実装演習の提供」というユースケースは、「チェック」というユースケースを拡張していることが分かり、「チェック」のユースケースを拡張しているものには、他に「受入検査」というユースケースがあることが分かる。
【００４９】
オペレータは、このようなユースケース間の関係を参照することにより、各ユースケース毎にどのユースケースを利用あるいは拡張しているのかを一目瞭然で分かるようになる。
なお、図には示していないが、要求仕様モデルの他の構成要素間の関係についても同様にしてマトリクス表示を見ることができる。
【００５０】
オペレータは、これらのマトリクス表示を見ることにより、本来定義すべき関係に漏れがないかどうかとか、不必要な関係が定義されていないかどうかなどを容易に確認することができ、ひいては、要求仕様が適切に書かれているかどうかを簡単にチェックすることができる。これによって要求仕様が適切に書かれていないことが分かれば、その時点で要求仕様を正しく記述し直すことができ、システムの設計終了後等における手戻り作業を未然に防ぐことができる。
【００５１】
図７は、図１の関係解析部３が行う動作を示すフローチャートである。図３において、まずステップＳ１で、図２の入力画面に従って定義された各単位要求仕様（各階層のユースケース）をカウントするためのカウント値ｉを“０”に初期化した後、ステップＳ２でそのカウント値ｉを１つ増やし、ステップＳ３に進む。ステップＳ３で関係解析部３内の構成要素抽出部３１は、要求仕様格納部２の中から、ある１つの単位要求仕様について記述された要求仕様情報を読み込む。
【００５２】
そして、ステップＳ４で、その読み込んだ要求仕様情報の中から、要求仕様モデルの５つの構成要素を判別して抽出する。ここでは、図２のユースケース入力画面２３内で構成要素の入力欄として明示された部分の情報を読み込むことによって、各構成要素の情報を簡単に抽出することができる。例えば、基本系列欄の中のアクタは誰であるかとか、利用しているユースケースには何があるか、あるいは事前条件の有無やそのユースケース内で入出力されるデータは何であるか等といった情報を抽出する。また、構成要素の入力欄以外に入力された内容を読んで解析することにより、各構成要素を判別して抽出するようにしても良い。
【００５３】
次に、ステップＳ５で第１の解析部３２は、上記ステップＳ２にて１つの単位要求仕様の中から抽出した５つの構成要素に対して、同じ構成要素間あるいは異なる２つの構成要素間の関係を順次解析する。すなわち、オブジェクトモデルのクラス図を作成していくイメージで、互いに関係のある構成要素間にリンクを順次張っていくことにより、１つの単位要求仕様内での構成要素間の関係をチェックする。そして、その解析結果を解析結果格納部３３に格納する。
【００５４】
次に、ステップＳ６に進み、ある１つのプロジェクトについて定義された全ての単位要求仕様について関係解析の処理が終了したかどうかを判断し、まだ残りがある場合は、ステップＳ２に戻って当該残りの単位要求仕様の関係解析を実行する。一方、定義された全ての単位要求仕様について、構成要素間の関係解析が終了した場合には、ステップＳ７に進み、解析指定部４によって関係解析を行う構成要素の指定が行われたかどうかを判断する。ここで、指定が行われた場合はステップＳ８に進み、第２の解析部３４は、当該指定された構成要素間の関係を全要求仕様モデルに渡って解析する。そして、その解析結果を関係出力部５に出力して、処理を終了する。
【００５５】
以上詳しく説明したように、本実施形態の要求仕様記述支援装置によれば、定められたフォーマットに従って記述された要求仕様モデルの構成要素間の関係を解析し、その解析結果を例えば表示装置に表示するようにしたので、その表示された構成要素間の関係に漏れや矛盾等がないかどうかを見ることによって、記述された要求仕様が正確に記述されているか否かのチェックを容易に行うことができる。例えば、ここで要求仕様の不備が発見された場合には、その不備を補充するように要求仕様を記述し直すことにより、システムを開発する上で必要な要求仕様を、最終的に矛盾や抜けがないように正確に記述することができる。これにより、その後の設計段階や実装段階で手戻り作業が発生してしまう不都合を抑制することができる。
【００５６】
また、要求仕様の記述はユースケースの形態により自然言語で行うので、要求仕様を記述する作業者の負担を軽減することができるとともに、作成された要求仕様を後で誰が見ても容易に理解できるものとすることができる。なお、構成要素間の関係が簡単に分かるので、現行プロセスの解析などにおいても有効に利用することができる。
【００５７】
なお、上記実施形態では、第１の解析部３２による単位要求仕様毎の関係解析処理までは自動的に行い、第２の解析部３４による全要求仕様モデルに渡る関係解析処理は、解析指定部４による指定が行われたときにはじめて行っていた。これに対し、第１の解析部３２および第２の解析部３４による関係解析処理をあらかじめ全て行ってその解析結果を格納しておき、その後オペレータから構成要素の指定が行われたときに、指定された構成要素間の関係を選択して出力するようにしても良い。また、第１の解析部３２による解析処理と第２の解析部３４による解析処理の双方とも、オペレータから指定されたときにのみ、当該指定された構成要素間の関係を解析して出力するようにしても良い。
【００５８】
また、上記実施形態では、要求仕様モデルの構成要素として、ユースケース、アクタ、データ、条件、ビジネスルールの５つをあげたが、これらは単なる一例であって、本発明はこれに限定されるものではない。また、各構成要素間の関係の解析の方法も、上述した第１の解析部３２および第２の解析部３４のように、まず単位要求仕様内での関係を解析した後で全体での関係を解析する方法には限定されない。
【００５９】
また、上記実施形態では、解析指定部４により関係解析を行う所望の構成要素を指定する際に、図３のような指定用画面を用いていたが、図２の左側に示したツリー構造表示画面２１から指定を行うようにすることも可能である。図８は、マウスカーソルを“外部”と書かれたアイコンのところに移動させ、マウスの例えば右ボタンを押した後、カーソルを移動して“アクタ”のアイコンを選択したときの状態を示す。この場合は、図４に示すようなユースケースとアクタとの相関マトリクスが表示されることになる。
【００６０】
また、上記実施形態では、構成要素間の関係の解析結果を図４〜図６のようにマトリクス表示するだけであったが、このマトリクス上において所望のマスをクリックしたときに、そのマスに該当する入力画面を表示させるようにしても良い。オペレータは、マトリクス表示を見て何らかの矛盾や定義漏れがあると判断した場合には、要求仕様の入力画面に戻って再び定義を行うことになるが、上述のようにすれば、対応する入力画面に直ちに飛んでいくことができるので、作業の操作性および効率性を向上させることができる。
【００６１】
また、上記実施形態では、各構成要素間の関係について解析された結果をマトリクス表示していたが、ユースケース図として表示するようにしても良い。図９は、表示されるユースケース図の例を示す図である。図９において、楕円で示した部分はそれぞれ単位要求仕様のユースケースを示し、人の形をした部分はアクタを示している。また、このユースケース図では利用関係および拡張関係を両方とも表示している。このようにすれば、各構成要素間の関係をイメージとして確認することができる。
【００６２】
また、上記実施形態では、構成要素間の関係を表すマトリクス表示を見てオペレータ自身が要求仕様の矛盾や漏れを判断していたが、あるべきルールをあらかじめ登録しておくことにより、矛盾や漏れを装置に自動的に行わせるようにすることも可能である。例えば、プライマリアクタもセカンダリアクタも存在しない場合や、データが重複して２回以上使われている場合、あるいはデータの参照場所と入力場所との対応がとれていない場合などの一般的にチェック可能な項目に関しては、装置が自動的にチェックを行い、ルール違反があった場合にはエラーメッセージを出力するようにすることが可能である。
【００６３】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
図１０は、第２の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。なお、この図１０において、図１に示した符号と同一の符号を付したものは、同一の機能を有するものであるので、これについての詳細な説明は省略する。
【００６４】
図１０において、文章ベースの要求仕様記述部５１は、要求仕様モデルの各構成要素（ユースケース、アクタ、データ、条件、ビジネスルール）が全て含まれるようにあらかじめ定められた所定のフォーマットに従って、要求仕様の定義を文章ベースで記述するものであり、図１に示した要求仕様記述部１とほぼ同様のものである。ただし、本実施形態による文章ベースの要求仕様記述部５１は、要求仕様を記述するための入力画面として複数のビューを有する点で、図１の要求仕様記述部１と異なる。なお、この入力画面は、ＣＲＴやＬＣＤなどの表示部５５上に表示されるものである。
【００６５】
上記文章ベースの要求仕様記述部５１が有する複数のビューの例としては、要求仕様を必須項目だけで簡易的に記述できるようにした画面や、表（テーブル）形式によって一覧として要求仕様を記述するようにした画面、あらかじめ設定した１つ１つの入力項目を埋めながら詳細に要求仕様を記述していく画面などが考えられる。
【００６６】
また、本実施形態では、文章ベースで要求仕様を記述する文章ベースの要求仕様記述部５１の他に、図ベースで要求仕様を記述できるようにした図ベースの要求仕様記述部５２も備えている。この図ベースの要求仕様記述部５２も、要求仕様を記述するための入力画面として複数のビューを有している。上記文章ベースの要求仕様記述部５１および図ベースの要求仕様記述部５２が持つビューは、表示制御部５４の制御により、表示部５５上に複数を同時に表示させることが可能である。
【００６７】
これら文章ベースの要求仕様記述部５１で記述された要求仕様の情報、および図ベースの要求仕様記述部５２で記述された要求仕様の情報は、要求仕様格納部５３に格納される。ここでは、各要求仕様記述部５１，５２が持つ個々のビューごとに、定義された要求仕様の情報が別に格納される。
【００６８】
表示制御部５４は、要求仕様格納部５３に格納された各ビューに対応する要求仕様情報のうち、指定されたビューに対応する情報を選択的に表示部５５に表示させる制御を行う。このとき、表示制御部５４は、図ベースの要求仕様記述部５２で定義された要求仕様情報を表示部５５に表示する場合には、ＧＵＩ（Graphical User Interface）等を用いて表した所定のアイコンによってアクタやユースケースを表示する。このアイコン等の表示位置に関する情報は、要求仕様格納部５３に格納されている。表示制御部５４はまた、関係出力部５から出力される関係情報を表示部５５に表示させる制御も行う。
【００６９】
更新部５６は、文章ベースの要求仕様記述部５１および図ベースの要求仕様記述部５２が有する複数のビューのうち、あるビューを用いて追加、削除あるいは変更された定義内容を他のビューにも反映させるように、要求仕様格納部５３に格納されている要求仕様情報を更新するものである。
【００７０】
すなわち、ある１つのビューを用いて要求仕様の定義に追加、削除あるいは変更の操作が行われると、そのビューに対応して要求仕様格納部５３内に格納されている要求仕様情報が変更される。関係解析部３では、この変更された要求仕様情報を解析して各構成要素間の関係情報を解析結果格納部３３に格納する。更新部５６は、このとき解析結果格納部３３に格納された関係情報に基づいて、上記要求仕様の変更等が実際に行われたビュー以外の他のビューに対応する要求仕様情報を更新し、全てのビューの要求仕様が互いに同じ内容となるようにする。
【００７１】
このように、要求仕様格納部５３に格納されている各ビューに対応する要求仕様情報の更新が行われる場合において、図ベースのビューを更新するときは、自動レイアウト生成部５７は、要求仕様格納部５３に格納されているアイコン等の表示位置に関する情報も更新し、アイコン同士が重ならないように画面レイアウトを自動的に調整する。
【００７２】
なお、ここでは、更新部５６は、要求仕様の変更等が実際に行われたビュー以外のビューに対して要求仕様情報の更新を行うようにしているが、処理をより簡素化するために、要求仕様の変更等が実際に行われたビューを含む全てのビューに対して要求仕様情報の更新を行うようにしても良い。この場合、実際に変更等が行われたビューに対して要求仕様の更新を行っても、同じ内容で上書きするだけなので、特に問題はない。
【００７３】
このようにして要求仕様格納部５３に格納されている各ビューに対応する要求仕様情報を更新すると、表示制御部５４は、更新された新たな内容に従って要求仕様情報を表示部５５に表示することになる。これにより、表示部５５に表示されている複数のビューのうち何れかのビューで要求仕様の内容を変更すると、そのとき表示部５５に表示されている他のビュー内の要求仕様の内容がそれに合わせて変更される。
【００７４】
図１１は、本実施形態による表示部５５の表示画面の例を示す図である。図１１において、ツリー構造表示画面６１は、図２に示したツリー構造表示画面２１と同様、あるシステムの開発プロジェクトについて定義した要求仕様モデルをツリー構造にて表示するための画面である。このツリー構造表示画面６１において、アクタやユースケースの追加、削除あるいは変更などを任意に行うことが可能である。
【００７５】
図１１の例では、要求仕様を記述するための入力画面（ビュー）として、３つのビュー６２〜６４を表示している。また、記述された要求仕様に基づき解析された各構成要素間の関係を表示するための画面として、１つのマトリクス表示ビュー６５も表示している。
【００７６】
要求仕様を記述するためのビューの１つ目は、アクタの一覧をテーブル形式にて表示するアクタ一覧画面６２であり、２つ目は、ユースケースの一覧をテーブル形式にて表示するユースケース一覧画面６３である。これらの画面６２，６３は、文章ベースの要求仕様記述部５１によって要求仕様を記述するための入力画面である。３つ目は、アクタやユースケースをＧＵＩなどの図形式で表示するダイアグラム画面６４である。これは、図ベースの要求仕様記述部５２によって要求仕様を記述するための入力画面である。
【００７７】
１つ目のアクタ一覧画面６２の欄では、アクタの名称と、各アクタの内容を表す概要と、各アクタと関係を有するユースケース（そのアクタが実行するユースケース）とを定義する。また、２つ目のユースケース一覧画面６３の欄では、ユースケースの名称と、各ユースケースにおいてどんな業務を行うのかの大まかな内容を表す目的と、各ユースケースと関係を有するアクタ（そのユースケースを実行するアクタ）とを定義する。
【００７８】
また、３つ目のダイアグラム画面６４では、上記アクタ一覧画面６２あるいはユースケース一覧画面６３において文章ベースで定義される内容と同様の内容（アクタの概要やユースケースの目的は除く）を図ベースで定義する。この図１１の例では、アクタは人間の形をしたアイコンで表され、ユースケースは楕円形のアイコンで表される。また、アクタとユースケースとの間の関係は、その間に引かれた線によって表される。
【００７９】
このダイアグラム画面６４において要求仕様を定義する際には、アクタボタン６６をクリックすることによって新たなアクタを追加することができ、ユースケースボタン６７をクリックすることによって新たなユースケースを追加することができる。また、コミュニケーションボタン６８をクリックすることによって、アクタとユースケースとの間の関係を追加することができる。
【００８０】
この図１１に示す画面において、例えば所望のユースケースの部分をマウスでクリックすると、図２に示したような詳細なユースケースの入力画面が表示され、より詳細な定義を行うことができるようになっている。
なお、この図１１では既に要求仕様の定義が入力された状態を示しているが、最初はどのビューも空欄である。
【００８１】
ここで、例えばアクタ１，２およびユースケース１，２の定義まで終了している段階で、更にアクタ一覧画面６２を用いてアクタ３およびユースケース３を追加する場合を例にとってその動作を説明する。
【００８２】
まず、アクタ一覧画面６２内のアクタ名称の欄にアクタ３を追加する。この時点では、入力画面６３，６４を含む他のビューに対応する要求仕様の記述内容の更新処理はまだ行われないが、ユースケース一覧画面６３では、上記アクタ一覧画面６２で新たに定義されたアクタ３を、何らかのユースケースを実行するアクタとして選択可能な状態になる。
【００８３】
次に、ユースケース一覧画面６３内のユースケース名称の欄にユースケース３を追加する。この時点でも、入力画面６２，６４を含む他のビューに対応する要求仕様の記述内容の更新処理はまだ行われないが、アクタ一覧画面６２では、上記ユースケース一覧画面６３で新たに定義されたユースケース３を、何れかのアクタが実行するユースケースとして選択可能な状態になる。
【００８４】
次に、ユースケース３を実行するアクタとして、ユースケース一覧画面６３内のアクタの欄にアクタ３を追加する。すると、関係解析部３によってこのアクタ３とユースケース３との関係が解析され、その解析された関係情報に基づいて、更新部５６によって他のビューに対する定義内容の更新処理が行われる。
【００８５】
これにより、ユースケース一覧画面６３と同時に表示されている他の入力画面６２，６４の定義内容が、ユースケース一覧画面６３で追加された定義内容と同様となるように更新されて表示される。すなわち、アクタ一覧画面６２では、ユースケースの欄にユースケース３が追加表示される。また、ダイアグラム画面６４では、アクタ３のアイコンとユースケース３のアイコンとがその間に線が引かれた状態で追加表示される。
【００８６】
なお、ここでは、ある文章ベースのビューにおいて要求仕様の記述が変更された場合に、他の文章ベースのビューに対応した要求仕様および図ベースのビューに対応した要求仕様の記述を更新する例を示したが、これとは逆に、ある図ベースのビューにおいて要求仕様の記述が変更された場合には、他の図ベースのビューに対応した要求仕様および文章ベースのビューに対応した要求仕様の記述が更新される。
【００８７】
また、ここでは、ある文章ベースのビューで要求仕様の記述が変更された場合に、図ベースのビューに対応した要求仕様の表示を自動的に更新する例を示したが、オペレータからの指示に応じて更新内容を表示するようにしても良い。この指示を行うための構成が、図１０に示した図化範囲指定部５８である。
【００８８】
すなわち、ユースケース一覧画面６３内でアクタ３とユースケース３を追加したときに、アクタ一覧画面６２内の表示がそれに対応して更新されることは上述の場合と同じであるが、このときダイアグラム画面６４には、アクタ３とユースケース３の追加内容はまだ表示しない。ここで、オペレータが図化範囲指定部５８を用いて、例えばアクタ一覧画面６２内でアクタ３とユースケース３の範囲を指定し、これを図化することを指示すると、そのとき初めてアクタ３のアイコンとユースケース３のアイコンとをその間に線が引かれた状態で追加表示する。
【００８９】
つまり、アクタあるいはユースケースの削除および図に表示されている部分への更新については、その削除内容や更新内容を図ベースのビューに即時に反映させても良いが、新たな追加分については、それをその図ベースのビューに加えて表示するのが適切かどうか不明なことが多いので、自動的な追加は行わず、図化範囲指定部５８による指定を待って行うようにする。これは、あるユースケース図は、要求仕様の全体ではなくその一部だけを表示している場合があるからである。したがって、全要素を表示するように指定されているビューであれば、他のビューでの追加内容を自動的に反映させることとしても問題ない。
【００９０】
また、上述の動作例では、最初にアクタ一覧画面６２内のアクタ名称の欄にアクタ３を追加した時点では他のビューに対する記述内容の更新処理は行わないようにしていたが、この時点でも直ちに関係解析部３によってアクタ３の関係を解析し、その結果を他のビューに反映させるようにしても良い。
【００９１】
この場合、アクタ３の関係を解析すると、アクタ３に関係するユースケースは存在しないという結果が得られる。更新部５６は、この解析結果に基づいて、他のビューに対する記述内容の更新処理を行うようにする。すなわち、ここではアクタ３に関係するユースケースの更新処理は行えないが、アクタに関する入力項目を持つビューに対してはそのアクタ３を追加する処理を行う。これにより、アクタ一覧画面６２内のアクタ名称の欄にアクタ３を追加した時点で、例えばユースケース一覧画面６３のアクタ一覧の欄にアクタ３の名称が追加表示される。
【００９２】
その後、アクタ一覧画面６２内のユースケースの欄にユースケース３を追加すると、関係解析部３によってこのアクタ３とユースケース３との関係が解析され、その解析された関係情報に基づいて、更新部５６によって他のビューに対する定義内容の更新処理が行われる。これにより、ユースケース一覧画面６３のユースケース名称の欄にもユースケース３の名称が追加表示される。
【００９３】
以上のようにして要求仕様の記述内容が変更されると、構成要素間の関係をマトリクス表示するマトリクス表示ビュー６５の内容も更新して表示される。図１１に示す例では、この更新表示は最新ボタン６９をクリックしたときに行われるようになっている。なお、この最新ボタン６９を押さなくても自動的に内容を更新して表示するようにしても良い。
【００９４】
以上のように、第２の実施形態によれば、要求仕様を記述するための入力画面として複数のビューを用意し、任意のビューを用いて要求仕様を記述できるようにしたので、それぞれのオペレータ毎に書きやすいビューを用いて要求仕様の記述を行うことができる。しかも、１つのビューを用いて記述内容を変更すると、それに連動して他のビューの記述内容も適切に更新されるので、オペレータにとっての使い勝手を格段に向上させることができる。
【００９５】
さらに、本実施形態では、文章ベースだけでなく、図ベースによっても要求仕様を記述することができるようにしているので、例えば、最初は図ベースのビューを用いて視覚的に分かりやすい状態で要求仕様を記述していき、途中から文章ベースのビューに切り替えて詳細に記述していくといった使い方ができる。もちろん、最初に文章ベースで記述した要求仕様からそれに対応するユースケース図を自動的に生成し、以後は図ベースと文章ベースの所望のビューで修正していくことも可能である。つまり、図ベースの方が定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けることができる。
【００９６】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。
第３の実施形態は、要求仕様をユースケースの形態で記述する際に、ユースケースやアクタなどを構造的に記述できるようにしたものである。構造化されたユースケースやアクタの記述方法として、ここではＵＭＬ（Unified Modeling Language ）を利用する。
【００９７】
上記ＵＭＬにおいては、構成要素間の関係の種類として、利用（uses）、汎化（generalization）、拡張（extends ）の３つが定義されている。利用にはユースケース間の利用があり、汎化にはユースケース間およびアクタ間の汎化があり、拡張にはユースケース間の拡張がある。ここで言う利用、汎化、拡張は、ＵＭＬのバージョン1.1 における定義に基づいたものであるが、ＵＭＬのバージョン1.3 における定義に基づくものに置き換えることも可能である。
【００９８】
本実施形態では、ユースケース間の関係を定義する際、あるユースケース内の基本系列を構成する１個のイベントを他の１個のユースケースに対応させて構造化している点に特徴がある。このようにすることにより、ユースケースやアクタを構造化したときの詳細な関係を分かり易くすることができる。
【００９９】
ここで、利用とは、複数のユースケース間で共通に利用可能な共通サブユースケースがあるときに、あるユースケースからその共通サブユースケースを利用する関係を言う。汎化とは、元のユースケースや元のアクタに対して部分的な変更を加えて新たなユースケースや新たなアクタを作る関係を言う。なお、あるユースケースＡをベースに、それを継承して差分を記述して別のユースケースＢを定義した場合、ユースケースＡはユースケースＢを汎化したものであると言い、ユースケースＢはユースケースＡを特殊化したものであると言い、両者の関係を汎化関係という。また、拡張とは、基本的なイベントの流れを規定したユースケースにおいて、ある特定の条件を満たしたときに別の拡張ユースケースの処理を行う関係を言う。
【０１００】
図１２は、本実施形態によるユースケースの入力画面の例を示す図であり、基本系列を定義する部分を特にピックアップして示している。この図１２に示す基本系列の入力欄においては、図２の場合と同様に、そのユースケースで誰が何を行うか等の具体的な内容をイベント欄７１およびアクタ欄７２に記述する。このとき、特定のイベントにおいて共通サブユースケースを利用することがあれば、その利用する共通サブユースケースの名称を利用ユースケース（利用ＵＣ）の欄７３に記述する。
【０１０１】
図１２の例では、“ユースケース１”の基本系列において“イベント２”の中で利用する共通サブユースケースとして“ユースケース５”を定義している。これにより、“ユースケース１”と“ユースケース５”との間に利用（uses）の関係が張られる。
【０１０２】
また、図１２の入力画面には、利用ＵＣ作成ボタン７４、特殊化ボタン７５および拡張ボタン７６が設けられている。このうち、利用ＵＣ作成ボタン７４は、複数のイベント列を指定して共通サブユースケースを作成することを指示するためのボタンである。
【０１０３】
例えば、図１２に示す入力画面上で、共通サブユースケースに落とし込みたいイベント列を指定して利用ＵＣ作成ボタン７４をマウスでクリックすると、その指定したイベント列を要素とする共通サブユースケースの名称や概要（目的）の入力を促す画面が現れる。この画面で共通サブユースケースの名称や概要（目的）を入力してＯＫボタンを押すことにより、共通サブユースケースが作成される。
【０１０４】
図１３は、この共通サブユースケースを作成する際の動作を説明するための図である。図１３においては、ａ〜ｆを内容とするイベント列から成るユースケース▲１▼があったときに、ａ〜ｄの内容は複数のユースケースで利用する可能性があるためにこれを共通サブユースケースとして作成しようとする場合の例を示している。
【０１０５】
この場合、図１３（ａ）に示す元のユースケース▲１▼において、共通サブユースケースとすべきイベント列ａ〜ｄを指定して利用ＵＣ作成ボタン７４をクリックし、更に当該共通サブユースケースの名称として“ユースケース▲２▼”を入力するとともに、概要として“Ｘ”を入力すると、図１３（ｂ）に示すような共通サブユースケース▲２▼が作成される。また、図１３（ｃ）に示すように、元のユースケース▲１▼の４つのイベント列ａ〜ｄが１つのイベントＸ（共通サブユースケース▲２▼を利用したもの）に置き換えられたユースケース▲１▼′が自動的に作られる。
【０１０６】
このようにして共通サブユースケース▲２▼を作成した後は、ユースケース▲１▼′以外の他のユースケースからもこの共通サブユースケース▲２▼を利用することが可能となる。
このように共通サブユースケースを作成してこれを複数のユースケースで共通に利用できるようにすることにより、ユースケースの再利用を容易にすることができ、オペレータがユースケースを記述する際の作業負担を軽減することができる。
【０１０７】
また、特殊化ボタン７５は、あるユースケースと汎化関係にある他のユースケースを作成することを指示するためのボタンである。例えば、図１２に示す入力画面上で特殊化ボタン７５をクリックすると、そのとき表示されていたものと同内容のイベント列を有するユースケースが別の入力画面として現れる。ここで、所望の箇所を変更した上で、新たなユースケースの名称や概要（目的）を入力してＯＫボタンを押すことにより、元のユースケースと汎化関係にある別の特殊化されたユースケースが作成される。
【０１０８】
図１４は、この特殊化されたユースケースを作成する際の動作を説明するための図である。図１４（ａ）のようにａ〜ｅを内容とするイベント列から成るユースケース▲１▼があるときに、特殊化ボタン７５を押すと、図１４（ｂ）に示すように、ユースケース▲１▼のイベント列ａ〜ｅをそのまま反映した別のユースケースの入力画面が現れる。このとき、特殊化用のユースケースが新たに作られているが、この段階では、元のユースケースを特殊化したものであることを示す情報のみが新たな記憶領域に格納され、中身の情報は何も格納されていない状態である。
【０１０９】
次に、図１４（ｂ）に示す入力画面上で所望の箇所を変更する。図１４の例では、イベントｃの内容をイベントｘに変更している。さらに、特殊化用ユースケースの名称として“ユースケース▲２▼”を入力すると、図１４（ｃ）に示すように特殊化されたユースケース▲２▼が作成される。このとき、特殊化用ユースケースの記憶領域には、元のユースケース▲１▼から変更があった部分の差分データのみ、つまりイベントｘのデータのみが格納される。他の変更されていない部分の情報は、元のユースケース▲１▼が格納されている記憶領域からデータを読み出して画面上に表示している。
【０１１０】
様々なユースケースを記述していく際、異なるユースケースでも同内容の入力を繰り返し行うことが少なからずある。この場合において、従来は全てのユースケースについて最初から記述していたが、本実施形態によれば、一部のみが異なるユースケースを継承し、異なる部分の定義だけを記述すれば良いので、オペレータの作業量を格段に少なくすることができる。
【０１１１】
また、特殊化されたユースケースでは、その親のユースケースとの差分データだけを格納しているので、親のユースケースにおいて共通の部分に修正が行われたとしても、その修正内容は特殊化されたユースケースにも反映され、常に整合性を正しく維持することができる。したがって、全ての記述をオペレータの手作業で入力していた従来と比べて、修正漏れや入力の間違いを少なくすることができ、より正確な要求仕様を記述することができるようになる。
【０１１２】
また、拡張ボタン７６は、あるユースケースと拡張の関係にある他のユースケースを作成することを指示するためのボタンである。例えば、図１２に示す入力画面上で拡張ボタン７６をクリックすると、拡張ユースケースを記述するための別の入力画面が現れる。ここで、元のユースケースからの分岐条件と、その条件を満たした場合に実行するイベント列とを入力するとともに、元のユースケースから分岐する分岐場所と、拡張ユースケースの処理が終わった後に戻る元のユースケースの戻り場所とを入力することにより、元のユースケースと拡張の関係にある別のユースケースが作成される。
【０１１３】
図１５は、この拡張されたユースケースを作成する際の動作を説明するための図である。図１５（ａ）のようにａ〜ｅを内容とするイベント列から成るユースケース▲１▼があるときに、拡張ボタン７６を押すと、拡張ユースケースを記述するための別の入力画面が現れる。ここで、例えば、分岐条件の内容を含むイベント列ｘ〜ｚを入力するとともに、元のユースケース▲１▼の分岐場所としてイベントｃ、拡張ユースケースのイベント列ｘ〜ｚを実行した後に戻る元のユースケース▲１▼の戻り場所としてイベントｄを入力することにより、図１５（ｂ）に示すような拡張ユースケース▲２▼が作成される。
【０１１４】
なお、以上の例では、構造化されたユースケース等を文章ベースで記述する場合を例にとって説明したが、第２の実施形態と同様に、構造化されたユースケース等を図ベースで記述することも可能である。図１６は、本実施形態による表示画面の例を示す図である。
【０１１５】
すなわち、図１６に示すダイアグラム画面６４において構造化された関係を記述する場合には、汎化ボタン８１をクリックすることによってユースケース間あるいはアクタ間の汎化関係を追加することができ、利用ボタン８２をクリックすることによって、ユースケースと共通サブユースケースとの利用関係を追加することができる。また、拡張ボタン８３をクリックすることによって、ユースケース間の拡張関係を追加することができる。なお、これらの関係について詳細な内容を定義する際には、例えばダイアグラム画面６４上の該当するアイコンをマウスでクリックすることにより、文章ベースの入力画面を表示させる。
【０１１６】
図１７は、上述のようにユースケース等の構造化を行うことができるようにした第３の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。なお、この図１７において、図１０に示した符号と同一の符号を付したものは、同一の機能を有するものであるので、これについての詳細な説明は省略する。
【０１１７】
図１７に示す要求仕様記述支援装置では、図１０に示した構成に対して更に構造化指定部９１と第２の要求仕様格納部９２とが追加されている。構造化指定部９１は、第１の要求仕様格納部５３に格納されている要求仕様の情報に対して利用、汎化、拡張の何れかの関係を指定するものである。構造化指定部９１は、これら３つの関係の種類を指定するだけでなく、必要に応じて構造化を行う範囲も指定する。
【０１１８】
第２の要求仕様格納部９２は、第１の要求仕様格納部５３に格納されている元の要求仕様情報（ユースケースやアクタ）と利用、汎化あるいは拡張の関係を有する要求仕様情報を格納するものである。なお、ここでは第１の要求仕様格納部５３と第２の要求仕様格納部９２とを別に設けているが、同じ格納部に領域を分けて格納するようにしても良い。
【０１１９】
例えば、第１の要求仕様格納部５３に格納されているあるユースケースのイベント列の中から共通サブユースケースを作成しようとするときは、構造化指定部９１により利用関係を指定するとともに、作成対象とするイベント列の範囲を指定する。さらに、文章ベースの要求仕様記述部５１あるいは図ベースの要求仕様記述部５２を用いて必要な事項（当該共通サブユースケースの目的、事前条件、事後条件など）を記述することにより、共通サブユースケースに関する要求仕様の情報が第２の要求仕様格納部９２内に作られる。
【０１２０】
また、第１の要求仕様格納部５３に格納されているあるユースケースを特殊化して別のユースケースを作成しようとするときは、構造化指定部９１により汎化関係を指定する。このとき、第２の要求仕様格納部９２には、特殊化用のユースケースを格納するための領域が確保されるが、この段階では、元のユースケースを特殊化したものであることを示す情報のみがこの新たな記憶領域に格納される。
【０１２１】
さらに、文章ベースの要求仕様記述部５１あるいは図ベースの要求仕様記述部５２を用いて所望の箇所を修正するとともに、必要な事項（当該特殊化ユースケースの目的、事前条件、事後条件など）を記述することにより、特殊化されたユースケースに関する要求仕様の情報が第２の要求仕様格納部９２内に作られる。このとき第２の要求仕様格納部９２に格納される情報は、第１の要求仕様格納部５３に格納されている元のユースケースとの差分データのみである。
【０１２２】
また、第１の要求仕様格納部５３に格納されているあるユースケースを拡張して別のユースケースを作成しようとするときは、構造化指定部９１により拡張関係を指定する。さらに、文章ベースの要求仕様記述部５１あるいは図ベースの要求仕様記述部５２を用いて必要な事項（当該拡張ユースケースの目的、事前条件、拡張ユースケースの基本系列、事後条件など）を記述することにより、拡張ユースケースに関する要求仕様の情報が第２の要求仕様格納部９２内に作られる。
【０１２３】
表示制御部５４は、第１の要求仕様格納部５３および第２の要求仕様格納部９２に格納された各ビューに対応する要求仕様情報のうち、指定されたビューに対応する情報を選択的に表示部５５に表示させる制御を行う。このとき、表示制御部５４は、例えば汎化により構造化された要求仕様情報について、元の要求仕様情報との差分のみを表示したり、両者を合わせて展開したものを表示したりすることが可能である。
【０１２４】
以上のように、第３の実施形態によれば、ユースケースやアクタを利用、汎化、拡張の関係で構造化できるようにしたので、例えば利用関係を用いて共通サブユースケースを作成することにより、複数のユースケースからこの共通サブユースケースを利用することが可能となり、ユースケースの再利用を容易にすることができる。また、あるユースケースに含まれるイベント列の一部を抜き出して共通サブユースケースを作ると、その元のユースケース中で抜き出された部分を共通サブユースケースの記述に自動的に置き換えることができる。これにより、オペレータがユースケースを定義する際の作業負担を軽減することができる。
【０１２５】
また、例えば汎化関係を用いて別のユースケースや別のアクタを作成することにより、様々なユースケースを定義していく際、それらのユースケース間で共通の部分は繰り返し入力しなくても済み、異なる部分だけを入力していけば良くなる。これにより、オペレータの作業量を格段に少なくすることができる。このとき、異なる部分だけを表示して記述するのではなく、元のユースケースと同じ内容を入力画面に表示した上で必要な部分を修正していくことができるようにしているので、ユースケースの全体感をよく理解しながら異なる部分だけを記述していくことができる。
【０１２６】
また、特殊化されたユースケースでは、その元となったユースケースとの差分データだけを格納しているので、元のユースケースにおいて共通の部分に修正が行われたとしても、その修正内容は特殊化されたユースケースにも反映されることとなり、常に整合性を正しく維持することができる。したがって、修正漏れや入力ミスを少なくすることができ、より正確な要求仕様を記述することができるようになる。また、特殊化されたユースケースと元のユースケースとの差分だけを表示するビューや、両者を合わせて展開したものを表示するビューなど、必要に応じたビューを定義することもできる。
【０１２７】
また、例えば拡張関係を用いて別のユースケースを作成することにより、あるユースケース内の特定のイベントから他のユースケースへと条件分岐させることができる。このとき、１個のイベントと１個のユースケースとの間を関係付けているので、ユースケースを構造化したときの詳細な関係を分かり易くすることができる（これは利用関係により構造化したときも同じである）。
【０１２８】
また、本実施形態では、文章ベースだけでなく、図ベースによっても要求仕様を記述することができるようにしているので、構造化されている関係を一目で容易に理解することができる。また、図ベースの方が定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けることもできる。
【０１２９】
（本発明の他の実施形態）
なお、以上に説明した各実施形態の要求仕様記述支援装置は、コンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。記録媒体としては、ＣＤ−ＲＯＭ以外に、フロッピーディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。
【０１３０】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
【０１３１】
なお、上記に示した実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１３２】
【発明の効果】
本発明は上述したように、例えばユースケースの形態で記述された要求仕様モデルの構成要素間の関係を解析して、その解析された結果を例えば表示装置に出力するようにしたので、表示された構成要素間の関係を参照することによって、記述された要求仕様に漏れや矛盾等がないか否かのチェックを容易に行うことができる。これにより、必要に応じてそのチェック結果を要求仕様の記述にフィードバックすることにより、システムを開発する上で必要な要求仕様を正確に記述することができる。したがって、その後の設計段階や実装段階で手戻り作業が発生してしまう不都合を未然に防止することができ、従来に比べてシステムの開発コストを大幅に削減することができる。
【０１３３】
また、本発明のその他の特徴によれば、要求仕様をユースケースの形態で記述するための情報入力画面として、ユースケースを文章ベースで記述するビューと図ベースで記述するビューを含む複数のビューを用意し、何れかのビューを用いて要求仕様の記述が行われたときに、その記述内容を他のビューにも反映させるようにしたので、複数のビューの中からオペレータが書きやすいビューを用いて要求仕様の定義を行うことができる。したがって、図ベースの方が要求仕様の定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けることができ、オペレータにとってより使い勝手の良い環境を提供することができる。
【０１３４】
また、本発明のその他の特徴によれば、要求仕様モデルの各構成要素について、ある構成要素から他の構成要素を利用する利用関係、元の構成要素に対して部分的な変更を加えて新たな構成要素を作る汎化関係、ある構成要素において特定の条件を満たしたときに別の構成要素の処理を行う拡張関係の少なくとも１つを用いて各構成要素を構造化できるようにしたので、例えば利用関係を用いて共通構成要素を作成することにより、構成要素の再利用を容易にすることができる。
また、汎化関係を用いて別の構成要素を作成することにより、様々な構成要素間で共通の部分は繰り返し入力しなくても済み、オペレータの作業負荷を少なくすることができる。このとき、特殊化された構成要素は元の構成要素との差分だけをデータとして持つので、元の構成要素において行われた修正内容を、特殊化された構成要素にも特別な処理を行うことなく反映させることが可能となり、常に整合性を正しく維持することができる。したがって、修正漏れや入力ミスを少なくしてより正確な要求仕様を記述することができるようになる。
また、拡張関係を用いて別の構成要素を作成することにより、ある構成要素から他の構成要素へと条件分岐させることができる。
さらに、文章ベースだけでなく、図ベースによっても構造化された要求仕様を記述できるようにした場合には、図ベースのビューを用いることにより、構造化されている関係を一目で容易に理解することができる。逆に、詳細な内容を記述する場合には文章ベースのビューを用いることができる。つまり、図ベースの方が定義しやすい部分と文章ベースの方が定義しやすい部分とで適宜ビューを切り替えて使い分けて構造化された構成要素を定義することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【図２】第１の実施形態による要求仕様の入力画面の例を示す図である。
【図３】関係解析を行う構成要素を指定するための画面の一例を示す図である。
【図４】解析結果のマトリクス表示の例を示す図である。
【図５】解析結果のマトリクス表示の例を示す図である。
【図６】解析結果のマトリクス表示の例を示す図である。
【図７】図１の関係解析部が行う動作を示すフローチャートである。
【図８】関係解析を行う構成要素を指定するための他の画面例を示す図である。
【図９】各構成要素間の関係を表すために表示されるユースケース図の例を示す図である。
【図１０】本発明の第２の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【図１１】第２の実施形態による複数のビューを有する表示画面の例を示す図である。
【図１２】第３の実施形態によるユースケースの入力画面の例を示す図である。
【図１３】共通サブユースケースを作成する際の動作を説明するための図である。
【図１４】特殊化されたユースケースを作成する際の動作を説明するための図である。
【図１５】拡張されたユースケースを作成する際の動作を説明するための図である。
【図１６】第３の実施形態による複数のビューを有する表示画面の例を示す図である。
【図１７】第３の実施形態による要求仕様記述支援装置の要素的特徴を表す機能構成ブロック図である。
【符号の説明】
１ 要求仕様記述部
２ 要求仕様格納部
３ 関係解析部
４ 解析指定部
５ 関係出力部
２１ ツリー構造表示画面
２２ａ ユースケース用タグ
２２ｂ ビジネスモデル用タグ
２３ ユースケース入力画面
３１ 構成要素抽出部
３２ 第１の解析部
３３ 解析結果格納部
３４ 第２の解析部
５１ 文章ベースの要求仕様記述部
５２ 図ベースの要求仕様記述部
５３ 要求仕様格納部
５４ 表示制御部
５５ 表示部
５６ 更新部
５７ 自動レイアウト生成部
５８ 図化範囲指定部
６１ ツリー構造表示画面
６２ 文章ベースのアクタ一覧画面
６３ 文章ベースのユースケース一覧画面
６４ 図ベースのダイアグラム画面
６５ マトリクス表示画面
６６ アクタボタン
６７ ユースケースボタン
６８ コミュニケーションボタン
６９ 最新ボタン
７１ イベント欄
７２ アクタ欄
７３ 利用ＵＣ欄
７４ 利用ＵＣ作成ボタン
７５ 特殊化ボタン
７６ 拡張ボタン
８１ 汎化ボタン
８２ 利用ボタン
８３ 拡張ボタン
９１ 構造化指定部
９２ 第２の要求仕様格納部
Claims (15)
- システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、
上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析手段と、
上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力手段とを備えたことを特徴とする要求仕様記述支援装置。 - 上記要求仕様を記述するための情報入力受付画面として、上記ユースケースを文章ベースで記述するビューおよび図ベースで記述するビューを含むビュー手段と、
上記ビュー手段に含まれるビューを介してユーザによる上記要求仕様の記述が行われたときに、その記述内容を他のビューに反映させるように情報の更新を行う情報更新手段とを備えたことを特徴とする請求項１に記載の要求仕様記述支援装置。 - 上記情報更新手段は、上記関係解析手段による解析結果に基づいて上記他のビューの情報の更新を行うことを特徴とする請求項２に記載の要求仕様記述支援装置。
- 上記関係解析手段は、個々の業務に対応する単一の単位要求仕様内に含まれる各構成要素間の関係を解析する第１の解析手段と、
上記第１の解析手段により各単位要求仕様毎に解析されたそれぞれの結果を用いて、複数の単位要求仕様間にまたがる各構成要素間の関係を更に解析する第２の解析手段とを備えたことを特徴とする請求項１乃至３の何れか１項に記載の要求仕様記述支援装置。 - 関係を解析する対象とする構成要素をユーザが指定するための指定手段を備え、
上記第２の解析手段あるいは、上記第１の解析手段および上記第２の解析手段の双方は、上記指定手段を介したユーザによる指定に応じて、指定された構成要素間の関係のみを解析することを特徴とする請求項４に記載の要求仕様記述支援装置。 - システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、関係解析手段と、関係出力手段とを備えた要求仕様記述支援装置によって実行される要求仕様記述支援方法であって、
上記関係解析手段が、上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析ステップと、
上記関係出力手段が、上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力ステップとを備えたことを特徴とする要求仕様記述支援方法。 - 上記要求仕様を記述するための情報入力受付画面として、上記ユースケースを文章ベースで記述するビューおよび図ベースで記述するビューを含む複数のビューを表示可能であり、
情報更新手段が、上記複数のビューのうち何れかのビューを介してユーザによる上記要求仕様の記述が行われたときに、その記述内容を他のビューに反映させるように情報の更新を行う情報更新ステップを更に有することを特徴とする請求項６に記載の要求仕様記述支援方法。 - 上記情報更新ステップは、上記関係解析ステップによる解析結果に基づいて上記他のビューの情報の更新を行うことを特徴とする請求項７に記載の要求仕様記述支援方法。
- 上記関係解析ステップは、第１の解析手段が、個々の業務に対応する単一の単位要求仕様内に含まれる各構成要素間の関係を解析する第１の解析ステップと、
第２の解析手段が、上記第１の解析ステップにより各単位要求仕様毎に解析されたそれぞれの結果を用いて、複数の単位要求仕様間にまたがる各構成要素間の関係を更に解析する第２の解析ステップとを有することを特徴とする請求項６乃至８の何れか１項に記載の要求仕様記述支援方法。 - 指定手段が、関係を解析する対象とする構成要素をユーザが指定するための指定ステップを更に有し、
上記第２の解析ステップあるいは、上記第１の解析ステップおよび上記第２の解析ステップの双方は、上記指定ステップを介したユーザによる指定に応じて、指定された構成要素間の関係のみを解析することを特徴とする請求項９に記載の要求仕様記述支援方法。 - コンピュータを、
システム化の対象となる業務の内容を定義するためのユースケースと上記業務に含まれるイベントと当該イベントを行うアクタと上記業務を行うために事前に行われていることが必要な条件と上記ユースケースにおいて入出力の対象となるデータとを構成要素として含む要求仕様の情報を記憶する記憶部であって、上記要求仕様に含まれる複数の上記ユースケースの各々に予め対応付けて、上記イベントと上記イベントに対応付けられた上記アクタと上記条件と上記データと当該ユースケースと利用関係又は拡張関係にあるユースケースとを要求仕様情報として記憶する記憶部と、
上記要求仕様情報に基づいて、上記要求仕様に含まれる上記構成要素を抽出し、抽出した上記構成要素について、同じ又は異なる種類の上記構成要素間の関係を順次チェックすることにより、上記構成要素間の関係を解析する関係解析手段と、
上記関係解析手段により解析された結果として、同じ又は異なる種類の上記構成要素間の関係を、マトリクス表示またはユースケース図として出力する関係出力手段として機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。 - 上記要求仕様を記述するための情報入力受付画面として、上記ユースケースを文章ベースで記述するビューおよび図ベースで記述するビューを含む複数のビューを表示可能であり、
上記複数のビューのうち何れかのビューを介してユーザによる上記要求仕様の記述が行われたときに、その記述内容を他のビューに反映させるように情報の更新を行う情報更新ステップを更にコンピュータに実行させるためのプログラムを記録した請求項１１に記載のコンピュータ読み取り可能な記録媒体。 - 上記情報更新ステップは、上記関係解析ステップによる解析結果に基づいて上記他のビューの情報の更新を行うことを特徴とするプログラムを記録した請求項１２に記載のコンピュータ読み取り可能な記録媒体。
- 上記関係解析ステップは、個々の業務に対応する単一の単位要求仕様内に含まれる各構成要素間の関係を解析する第１の解析ステップと、
上記第１の解析ステップにより各単位要求仕様毎に解析されたそれぞれの結果を用いて、複数の単位要求仕様間にまたがる各構成要素間の関係を更に解析する第２の解析ステップとを有することを特徴とするプログラムを記録した請求項１１乃至１３の何れか１項に記載のコンピュータ読み取り可能な記録媒体。 - 関係を解析する対象とする構成要素をユーザが指定するための指定ステップを更にコンピュータに実行させ、
上記第２の解析ステップあるいは、上記第１の解析ステップおよび上記第２の解析ステップの双方は、上記指定ステップを介したユーザによる指定に応じて、指定された構成要素間の関係のみを解析することを特徴とするプログラムを記録した請求項１４に記載のコンピュータ読み取り可能な記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000078552A JP4629183B2 (ja) | 1999-04-07 | 2000-03-21 | 要求仕様記述支援装置およびその方法、記録媒体 |
| US09/543,359 US8151242B1 (en) | 1999-04-06 | 2000-04-05 | Description support apparatus and method for requisition sheet, and recording medium |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9958099 | 1999-04-07 | ||
| JP11-99580 | 1999-04-07 | ||
| JP2000078552A JP4629183B2 (ja) | 1999-04-07 | 2000-03-21 | 要求仕様記述支援装置およびその方法、記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000353083A JP2000353083A (ja) | 2000-12-19 |
| JP4629183B2 true JP4629183B2 (ja) | 2011-02-09 |
Family
ID=26440702
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000078552A Expired - Fee Related JP4629183B2 (ja) | 1999-04-06 | 2000-03-21 | 要求仕様記述支援装置およびその方法、記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4629183B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4688580B2 (ja) * | 2005-06-15 | 2011-05-25 | 日本電信電話株式会社 | プログラム実行手順の整合性判定装置、その方法及びプログラム |
| JP4905119B2 (ja) * | 2006-12-26 | 2012-03-28 | 富士電機株式会社 | 仕様書作成支援装置および方法 |
| JP5108642B2 (ja) * | 2007-11-29 | 2012-12-26 | 株式会社日立製作所 | ユースケースシナリオ作成支援システム、ユースケースシナリオ作成支援方法、およびユースケースシナリオ作成支援プログラム |
| JP5099839B2 (ja) * | 2008-02-14 | 2012-12-19 | 三十四 日野 | バグレスソフトウェアシステム設計支援装置、方法及びプログラム |
| WO2010050042A1 (ja) * | 2008-10-31 | 2010-05-06 | 富士通株式会社 | ワークフロー編集プログラムおよびワークフロー編集装置 |
| JP5970292B2 (ja) * | 2012-08-21 | 2016-08-17 | 株式会社日立製作所 | ソフトウェア仕様開発支援方法及びソフトウェア仕様開発支援装置 |
| JP6847382B1 (ja) * | 2019-09-23 | 2021-03-24 | 株式会社デンソークリエイト | 設計支援ツール |
-
2000
- 2000-03-21 JP JP2000078552A patent/JP4629183B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000353083A (ja) | 2000-12-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2018236912B2 (en) | Managing and automatically linking data objects | |
| JP3136035B2 (ja) | データベースシステム用インターフェースのための自動レイアウト・ジェネレータ及びその生成方法 | |
| US9395958B2 (en) | Systems and methods for drag-and-drop data binding | |
| US7644370B2 (en) | Method of componentisation of a graphically defined formula | |
| US20090083697A1 (en) | Integration of User Interface Design and Model Driven Development | |
| EP1895407A1 (en) | HMI development support apparatus, HMI development support method and HMI development support program | |
| JP4629183B2 (ja) | 要求仕様記述支援装置およびその方法、記録媒体 | |
| JP3227066B2 (ja) | プログラム部品を用いたプログラム生成方法 | |
| KR102213815B1 (ko) | 앤서블을 위한 ｇｕｉ 시스템 | |
| JP3713466B2 (ja) | プログラム作成支援方法、プログラム作成支援プログラム及びプログラム作成支援装置 | |
| JP2004355326A (ja) | ソフトウェア開発支援プログラム、当該プログラムを記録した記録媒体及びソフトウェア開発支援システム | |
| Elouali et al. | A model-based approach for engineering multimodal mobile interactions | |
| JP4625155B2 (ja) | 要求仕様記述支援装置およびその方法、記録媒体 | |
| JPH11102293A (ja) | プログラム自動生成方法 | |
| US8151242B1 (en) | Description support apparatus and method for requisition sheet, and recording medium | |
| CN112181483A (zh) | 等离子体控制系统软件开发平台及方法 | |
| JP2001273125A (ja) | ソースプログラム自動生成方法およびシステム、ならびにそのプログラム記録媒体 | |
| JP2015210639A (ja) | アプリケーション開発システム、開発装置のデータ処理方法、およびプログラム | |
| CN115291929B (zh) | 用于人工智能教育图形化编程软件的编程块管理系统 | |
| JP2003241965A (ja) | プログラム作成支援方法、プログラム作成支援プログラム及びプログラム作成支援装置 | |
| Cardillo et al. | Visual OO Debugger (Folgearbeit) | |
| Loth | Enhancing ProMoEE and DyVProMo with Additional Features to Foster Empirical Studies in the Context of Process Models Comprehension | |
| Duong | Work Diary Thesis-Working as a software developer | |
| Gjesdal | A Modular Integrated Development Environment for Coloured Petri Net Models | |
| Härtull | Implementation of an Application for Analyzing and Visualizing Benchmark Results for Optimization Solvers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070315 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091210 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100518 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100715 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100810 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101005 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101026 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131119 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |