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

Abstract

(57)【要約】 【課題】 記述された要求仕様のチェックを容易に行え
るようにすることにより、正確な要求仕様を記述するこ
とを支援できるようにする。 【解決手段】 例えばユースケースの形態で記述された
要求仕様モデルの構成要素間の関係を解析する関係解析
部３と、その解析された結果を例えば表示装置に出力す
る関係出力部５とを設けることにより、表示された構成
要素間の関係に漏れや矛盾等がないか否かをオペレータ
が見ることによって、要求仕様が正確に記述されている
か否かのチェックを容易に行うことができるようにす
る。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

【０００４】

【発明が解決しようとする課題】しかしながら、このよ
うに要求仕様は極めて重要であるにもかかわらず、従来
これを正確に記述することができないことが多かった。

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

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

【０００７】ところが、これらのチェックは、人間が手
作業で行うものなので、見落としや間違いなどが発生し
やすい。また、コンピュータ等を利用してもある程度は
チェックできるが、どのように行えばチェックが正確か
つ容易になるかは、明確でなかった。チェックのミスや
漏れがあると、結局は正しい要求仕様を記述することが
できず、その後の手戻り作業が発生してしまうことにな
り、多くの開発コストがかかってしまう原因となる。

【０００８】本発明は、このような実情に鑑みて成され
たものであり、記述された要求仕様のチェックを正確か
つ容易に行えるようにすることにより、正確な要求仕様
を記述することを支援できるようにした要求仕様記述支
援装置およびその方法を提供することを目的とする。

【０００９】

【課題を解決するための手段】本発明の要求仕様記述支
援装置は、記述された要求仕様のモデルを構成する所定
の構成要素間の関係を解析する関係解析手段と、上記関
係解析手段により解析された結果を出力する関係出力手
段とを備えたことを特徴とする。また、本発明の他の態
様では、要求仕様モデルの各構成要素が含まれるように
あらかじめ定められた所定のフォーマットに従って上記
要求仕様を記述する要求仕様記述手段を備えたことを特
徴とする。ここで、上記要求仕様記述手段は、例えば、
上記要求仕様をユースケースの形態で記述するようにな
されている。

【００１０】また、本発明の他の態様では、上記要求仕
様記述手段は、上記要求仕様をユースケースの形態で記
述するための情報入力画面として、上記ユースケースを
文章ベースで記述するビューおよび図ベースで記述する
ビューを含む複数のビューを有し、上記複数のビューの
うち何れかのビューを用いて上記要求仕様の記述が行わ
れたときに、その記述内容を他のビューに反映させるよ
うに情報の更新を行う情報更新手段を備えたことを特徴
とする。ここで、上記情報更新手段は、例えば、上記関
係解析手段による解析結果に基づいて上記他のビューの
情報の更新を行う。

【００１１】また、上記関係解析手段は、例えば、単一
の単位要求仕様内に含まれる各構成要素間の関係を解析
する第１の解析手段と、上記第１の解析手段により各単
位要求仕様毎に解析されたそれぞれの結果を用いて、複
数の単位要求仕様間にまたがる各構成要素間の関係を更
に解析する第２の解析手段とを備える。

【００１２】また、本発明のその他の態様では、関係を
解析する対象とする構成要素を指定するための指定手段
を備え、上記第２の解析手段あるいは、上記第１の解析
手段および上記第２の解析手段の双方は、上記指定手段
による指定に応じて、指定された構成要素間の関係のみ
を解析することを特徴とする。

【００１３】上記要求仕様モデルの構成要素には、シス
テム内でイベントを行うアクタ、取り扱うデータ、イベ
ントを行う際の条件が少なくとも含まれる。また、上記
関係出力手段は、２つの構成要素間の関係について解析
された結果をマトリクス表示するようにしても良いし、
各構成要素間の関係について解析された結果をユースケ
ース図として表示するようにしても良い。

【００１４】また、本発明のその他の態様では、上記要
求仕様モデルの各構成要素について、ある構成要素から
複数の構成要素間で共通に利用可能な共通構成要素を利
用する利用関係、元の構成要素に対して部分的な変更を
加えて新たな構成要素を作る汎化関係、ある構成要素に
おいて特定の条件を満たしたときに別の構成要素の処理
を行う拡張関係の少なくとも１つを用いて上記各構成要
素を構造化する構造化手段を備えたことを特徴とする。
例えば、上記要求仕様はユースケースの形態で記述する
ようになされており、上記利用関係および上記拡張関係
については、上記ユースケース内のイベントと他のユー
スケースとの関係を構造化する。

【００１５】また、本発明の要求仕様記述支援方法は、
要求仕様モデルの各構成要素が含まれるようにあらかじ
め定められた所定のフォーマットに従って、要求仕様を
記述する要求仕様記述ステップと、上記所定のフォーマ
ットに従って記述された要求仕様の各構成要素間の関係
を解析する関係解析ステップと、上記解析された結果を
出力する関係出力ステップとを有することを特徴とす
る。ここで、上記要求仕様記述ステップでは、上記要求
仕様をユースケースの形態で記述するようにしても良
い。

【００１６】また、本発明の他の態様では、上記要求仕
様記述ステップでは、上記要求仕様をユースケースの形
態で記述するための情報入力画面として、上記ユースケ
ースを文章ベースで記述するビューおよび図ベースで記
述するビューを含む複数のビューを表示可能であり、上
記複数のビューのうち何れかのビューを用いて上記要求
仕様の記述が行われたときに、その記述内容を他のビュ
ーに反映させるように情報の更新を行う情報更新ステッ
プを更に有することを特徴とする。ここで、上記情報更
新ステップにおける上記他のビューの情報の更新は、例
えば、上記関係解析ステップによる解析結果に基づいて
行う。

【００１７】また、上記関係解析ステップは、単一の単
位要求仕様内に含まれる各構成要素間の関係を解析する
第１の解析ステップと、上記第１の解析ステップで各単
位要求仕様毎に解析されたそれぞれの結果を用いて、複
数の単位要求仕様間にまたがる各構成要素間の関係を更
に解析する第２の解析ステップとを有しても良い。ま
た、上記関係解析ステップは、単一の単位要求仕様内に
含まれる各構成要素間の関係を解析する第１の解析ステ
ップと、上記要求仕様モデルの複数の構成要素のうち、
関係を解析する対象とする構成要素を指定する指定ステ
ップと、上記指定ステップで指定された構成要素を対象
として、上記第１の解析ステップで各単位要求仕様毎に
解析されたそれぞれの結果を用いて、複数の単位要求仕
様間にまたがる関係を更に解析する第２の解析ステップ
とを有しても良い。

【００１８】また、上記関係出力ステップでは、２つの
構成要素間の関係について解析された結果をマトリクス
表示するようにしても良いし、各構成要素間の関係につ
いて解析された結果をユースケース図として表示するよ
うにしても良い。

【００１９】また、本発明のその他の態様では、上記要
求仕様モデルの各構成要素について、ある構成要素から
複数の構成要素間で共通に利用可能な共通構成要素を利
用する利用関係、元の構成要素に対して部分的な変更を
加えて新たな構成要素を作る汎化関係、ある構成要素に
おいて特定の条件を満たしたときに別の構成要素の処理
を行う拡張関係の少なくとも１つを用いて上記各構成要
素を構造化する構造化ステップを更に有することを特徴
とする。例えば、上記要求仕様はユースケースの形態で
記述するようになされており、上記利用関係および上記
拡張関係については、上記ユースケース内のイベントと
他のユースケースとの関係を構造化する。

【００２０】また、本発明のコンピュータ読み取り可能
な記録媒体は、要求仕様モデルの各構成要素が含まれる
ようにあらかじめ定められた所定のフォーマットに従っ
て、要求仕様を記述する要求仕様記述手段と、定められ
た基準に従って記述された要求仕様の構成要素間の関係
を解析する関係解析手段と、上記関係解析手段により解
析された結果を出力する関係出力手段としてコンピュー
タを機能させるためのプログラムを記録したことを特徴
とする。

【００２１】また、本発明の他の態様では、要求仕様モ
デルの各構成要素が含まれるようにあらかじめ定められ
た所定のフォーマットを有する情報入力画面であって、
要求仕様を文章ベースのユースケースの形態で記述する
ビューおよび図ベースのユースケースの形態で記述する
ビューを含む複数のビューを有し、何れかのビューに従
って上記要求仕様を記述する要求仕様記述手段と、定め
られた基準に従って記述された要求仕様の構成要素間の
関係を解析する関係解析手段と、上記複数のビューのう
ち何れかのビューを用いて上記要求仕様の記述が行われ
たときに、上記関係解析手段による解析結果に基づい
て、上記要求仕様の記述内容を他のビューに反映させる
ように情報の更新を行う情報更新手段としてコンピュー
タを機能させるためのプログラムを記録したことを特徴
とする。

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

【００２３】本発明は上記技術手段より成るので、要求
仕様モデルの各構成要素間の関係が解析されて出力され
ることとなり、その出力された構成要素間の関係をオペ
レータが参照することによって、本来定義すべき関係に
漏れがないかどうかや、不必要な関係が定義されていな
いかどうかなどを確認することにより、要求仕様が適切
に書かれているかどうかをチェックすることが可能とな
る。

【００２４】また、本発明の他の特徴によれば、要求仕
様を記述するための情報入力画面として用意された複数
のビューの中から、オペレータが書きやすいビューを用
いて要求仕様の記述を行うことが可能となり、１つのビ
ューを用いて要求仕様の定義内容を変更すると、それに
連動して他のビューの定義内容も適切に更新されること
となる。

【００２５】また、本発明のその他の特徴によれば、例
えば利用関係を用いて共通の構成要素を作成することに
より、複数の構成要素からこの共通構成要素を利用する
ことが可能となり、構成要素の再利用を容易にすること
が可能となる。また、汎化関係を用いて別の構成要素を
作成することにより、様々な構成要素について要求仕様
を記述していく際に、それらの構成要素間で共通の部分
は繰り返し入力しなくても済む。このとき、汎化された
構成要素は元の構成要素との差分だけをデータとして持
つので、元の構成要素において行われた修正内容を、汎
化された構成要素にも特別な処理を行うことなく反映さ
せることが可能となる。また、拡張関係を用いて別の構
成要素を作成することにより、ある構成要素から他の構
成要素へと条件分岐させることが可能となる。

【００２６】

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

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

【００２８】図１において、要求仕様記述部１は、本実
施形態による要求仕様モデルの各構成要素が全て含まれ
るようにあらかじめ定められた所定のフォーマットに従
って、要求仕様の定義を記述する。すなわち、要求仕様
の入力フォーマットとして、上記要求仕様モデルの各構
成要素を全て含んだ入力画面を用意し、ここに各種情報
を入力していくことによって、要求仕様を記述する。本
実施形態の場合、要求仕様モデルの各構成要素として
は、ユースケース、アクタ、データ、条件、ビジネスル
ールの５つを含む。

【００２９】ユースケースとは、開発するシステムが業
務上どのように利用されるのかという点に着目して、シ
ステムの稼働時にオペレータが行う一連のアクション
（イベント）等を、トランザクション毎に各構成要素が
明確になるように自然言語で記述したものを言う。ま
た、アクタは、それぞれのアクションを誰が行うかを示
すもの、データは、各アクションの際にどんなデータを
入出力するかを示すもの、条件は、各アクション時に満
たすべき状態等を示すもの、ビジネスルールは、開発さ
れたシステムによって業務を遂行する上で守るべきルー
ルを示すものである。

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

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

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

【００３３】このように、ある業務システムを作成する
１つのプロジェクトに関する要求仕様は、システム上で
行う個々の業務を単位として記述した複数の単位要求仕
様から成り、ツリー構造表示画面２１内に示される“演
習問題の提供”、“評価”、“○○知識獲得”、“事前
準備”、“演習問題の公開”、“演習問題の実装”など
の各ユースケースは、それぞれ１つの単位要求仕様に該
当する。

【００３４】ここで、例えばツリー構造表示画面２１内
の任意のユースケースの部分をマウスでクリックする
と、そのユースケースの入力画面２３がツリー構造表示
画面２１の右側に表示される。図２の例では、“演習問
題の実装”というユースケースの部分がクリックされた
ときの様子を示している。このユースケース入力画面２
３では、ユースケース名の表示の後に、目的、事前条
件、基本系列、事後条件およびデータの入力画面が表示
される。

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

【００３６】また、事後条件の欄には、そのユースケー
スで定義されている動作を行った後にどんな状態となる
かを定義する。例えば、動作が成功に終わった場合と、
失敗に終わった場合とに分けて、それぞれの場合にどう
いう状態となるかを定義する。また、データの欄には、
そのユースケースでどんなデータを入出力するかについ
て定義する。なお、図２中には事後条件およびデータの
入力画面は現れていないが、これらは画面を下にスクロ
ールさせると見えてくる。

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

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

【００３９】関係解析部３は、上述のように定められた
フォーマットに従って記述された要求仕様中の各構成要
素間の関係を解析するものであり、構成要素抽出部３１
と、第１の解析部３２と、解析結果格納部３３と、第２
の解析部３４とを備える。ここで、構成要素抽出部３１
は、要求仕様格納部２に格納されている要求仕様の情報
中から、要求仕様モデルの構成要素（ユースケース、ア
クタ、データ、条件、ビジネスルール）に相当する部分
を個々の単位要求仕様毎に抽出する。

【００４０】また、第１の解析部３２は、構成要素抽出
部３１により抽出された各構成要素の情報を用いて、単
一の単位要求仕様内に含まれる各構成要素間の関係を夫
々解析し、その結果を解析結果格納部３３に個々の単位
要求仕様毎に格納する。ここでは、要求仕様モデルを構
成する５つの構成要素のうち、同じ構成要素間あるいは
異なる２つの構成要素間の関係を、構成要素の組み合わ
せを複数選んで各々解析する。

【００４１】すなわち、ここで解析する構成要素間の関
係は、５つの構成要素の中の２つの関係、例えばユース
ケースとアクタとの関係（誰がそのユースケースを実行
するか等）、ユースケースとデータとの関係（そのユー
スケースでどんなデータが入出力されるか等）などであ
る。また、同じ構成要素間の関係、例えばユースケース
と他のユースケースとの関係（あるユースケースで他の
どのユースケースを利用するか等）も解析する。また、
解析する関係の種類としては、利用関係と拡張関係とが
ある。

【００４２】さらに、第２の解析部３４は、上記第１の
解析部３２により各単位要求仕様毎に解析され解析結果
格納部３３に格納されたそれぞれの解析結果を用いて、
１つのプロジェクト内に含まれる複数の単位要求仕様間
にまたがる各構成要素間の関係を更に解析する。この第
２の解析部３４でも、上述した第１の解析部３２と同様
に、５つの構成要素のうち、同じ構成要素間あるいは異
なる２つの構成要素間の関係を、構成要素の組み合わせ
を複数選んで各々解析する。

【００４３】ただし、ここでは５つの構成要素のうちど
れを対象として関係の解析を実行するかは、解析指定部
４を用いてオペレータが指定する。すなわち、第２の解
析部３４は、解析結果格納部３３に格納されている個々
の単位要求仕様毎の解析結果を用いて、指定された構成
要素間の関係を全要求仕様モデルに渡って解析する。関
係出力部５は、上記第２の解析部３４により解析された
結果を、例えば表示装置に出力することにより画面上に
表示する。

【００４４】図３は、上記解析指定部４により関係解析
を行う構成要素を指定するための画面の一例を示す図で
ある。図３に示すように、本実施形態では、５つの構成
要素を縦軸および横軸のそれぞれに配したマトリクス表
示を用い、マトリクス上の各マスに解析指定用のボタン
４１を設けている。この解析指定用ボタン４１は、全て
のマスに設けられるのではなく、関係のあり得るところ
にだけ表示される。例えば、ユースケースとビジネスル
ールとの関係はあり得るが、データとビジネスルールと
の関係はあり得ない。

【００４５】何れかの解析指定用ボタン４１をクリック
すると、図３に示されるような、利用関係と拡張関係と
の何れかを選択するための関係種類選択画面４２がポッ
プアップ表示される。ここでオペレータが利用関係か拡
張関係かの何れかを選択すると、第２の解析部３４によ
り当該指定された構成要素間の関係が全要求仕様モデル
に渡って解析される。そして、その解析結果が関係出力
部５により画面表示される。本実施形態では、指定され
た構成要素間の関係について解析された結果をマトリク
ス表示する。

【００４６】図４〜図６は、上記解析結果のマトリクス
表示の例を示す図である。図４は、アクタとユースケー
スとの関係を示す図である。この図４に示すマトリクス
表示において、“Ｐ”はそのユースケースにとって主た
るアクタ（プライマリアクタ）であることを示し、
“Ｓ”は副次的なアクタ（セカンダリアクタ）であるこ
とを示す。プライマリアクタは、図２のユースケース入
力画面で、基本系列の一番最初の欄に入力されたアクタ
がなる。一方、基本系列の二番目以降の欄に入力された
アクタは、全てセカンダリアクタとなる。

【００４７】オペレータは、このようなアクタとユース
ケースとの関係を参照することにより、各ユースケース
毎にどのアクタが関連しているかを一目瞭然で分かるよ
うになる。

【００４８】また、図５および図６は、ユースケースと
ユースケースとの関係を示す図である。このうち図５で
は、ユースケース間の利用関係を“Ｕ”で示している。
これを見ることにより、例えば「事前準備」のユースケ
ースが「研修環境の説明」というユースケースを利用し
ているといったことが一目で分かる。また、図６は、ユ
ースケース間の拡張関係を“Ｅ”で示している。例えば
「実装演習の提供」というユースケースは、「チェッ
ク」というユースケースを拡張していることが分かり、
「チェック」のユースケースを拡張しているものには、
他に「受入検査」というユースケースがあることが分か
る。

【００４９】オペレータは、このようなユースケース間
の関係を参照することにより、各ユースケース毎にどの
ユースケースを利用あるいは拡張しているのかを一目瞭
然で分かるようになる。なお、図には示していないが、
要求仕様モデルの他の構成要素間の関係についても同様
にしてマトリクス表示を見ることができる。

【００５０】オペレータは、これらのマトリクス表示を
見ることにより、本来定義すべき関係に漏れがないかど
うかとか、不必要な関係が定義されていないかどうかな
どを容易に確認することができ、ひいては、要求仕様が
適切に書かれているかどうかを簡単にチェックすること
ができる。これによって要求仕様が適切に書かれていな
いことが分かれば、その時点で要求仕様を正しく記述し
直すことができ、システムの設計終了後等における手戻
り作業を未然に防ぐことができる。

【００５１】図７は、図１の関係解析部３が行う動作を
示すフローチャートである。図３において、まずステッ
プＳ１で、図２の入力画面に従って定義された各単位要
求仕様（各階層のユースケース）をカウントするための
カウント値ｉを“０”に初期化した後、ステップＳ２で
そのカウント値ｉを１つ増やし、ステップＳ３に進む。
ステップＳ３で関係解析部３内の構成要素抽出部３１
は、要求仕様格納部２の中から、ある１つの単位要求仕
様について記述された要求仕様情報を読み込む。

【００５２】そして、ステップＳ４で、その読み込んだ
要求仕様情報の中から、要求仕様モデルの５つの構成要
素を判別して抽出する。ここでは、図２のユースケース
入力画面２３内で構成要素の入力欄として明示された部
分の情報を読み込むことによって、各構成要素の情報を
簡単に抽出することができる。例えば、基本系列欄の中
のアクタは誰であるかとか、利用しているユースケース
には何があるか、あるいは事前条件の有無やそのユース
ケース内で入出力されるデータは何であるか等といった
情報を抽出する。また、構成要素の入力欄以外に入力さ
れた内容を読んで解析することにより、各構成要素を判
別して抽出するようにしても良い。

【００５３】次に、ステップＳ５で第１の解析部３２
は、上記ステップＳ２にて１つの単位要求仕様の中から
抽出した５つの構成要素に対して、同じ構成要素間ある
いは異なる２つの構成要素間の関係を順次解析する。す
なわち、オブジェクトモデルのクラス図を作成していく
イメージで、互いに関係のある構成要素間にリンクを順
次張っていくことにより、１つの単位要求仕様内での構
成要素間の関係をチェックする。そして、その解析結果
を解析結果格納部３３に格納する。

【００５４】次に、ステップＳ６に進み、ある１つのプ
ロジェクトについて定義された全ての単位要求仕様につ
いて関係解析の処理が終了したかどうかを判断し、まだ
残りがある場合は、ステップＳ２に戻って当該残りの単
位要求仕様の関係解析を実行する。一方、定義された全
ての単位要求仕様について、構成要素間の関係解析が終
了した場合には、ステップＳ７に進み、解析指定部４に
よって関係解析を行う構成要素の指定が行われたかどう
かを判断する。ここで、指定が行われた場合はステップ
Ｓ８に進み、第２の解析部３４は、当該指定された構成
要素間の関係を全要求仕様モデルに渡って解析する。そ
して、その解析結果を関係出力部５に出力して、処理を
終了する。

【００５５】以上詳しく説明したように、本実施形態の
要求仕様記述支援装置によれば、定められたフォーマッ
トに従って記述された要求仕様モデルの構成要素間の関
係を解析し、その解析結果を例えば表示装置に表示する
ようにしたので、その表示された構成要素間の関係に漏
れや矛盾等がないかどうかを見ることによって、記述さ
れた要求仕様が正確に記述されているか否かのチェック
を容易に行うことができる。例えば、ここで要求仕様の
不備が発見された場合には、その不備を補充するように
要求仕様を記述し直すことにより、システムを開発する
上で必要な要求仕様を、最終的に矛盾や抜けがないよう
に正確に記述することができる。これにより、その後の
設計段階や実装段階で手戻り作業が発生してしまう不都
合を抑制することができる。

【００５６】また、要求仕様の記述はユースケースの形
態により自然言語で行うので、要求仕様を記述する作業
者の負担を軽減することができるとともに、作成された
要求仕様を後で誰が見ても容易に理解できるものとする
ことができる。なお、構成要素間の関係が簡単に分かる
ので、現行プロセスの解析などにおいても有効に利用す
ることができる。

【００５７】なお、上記実施形態では、第１の解析部３
２による単位要求仕様毎の関係解析処理までは自動的に
行い、第２の解析部３４による全要求仕様モデルに渡る
関係解析処理は、解析指定部４による指定が行われたと
きにはじめて行っていた。これに対し、第１の解析部３
２および第２の解析部３４による関係解析処理をあらか
じめ全て行ってその解析結果を格納しておき、その後オ
ペレータから構成要素の指定が行われたときに、指定さ
れた構成要素間の関係を選択して出力するようにしても
良い。また、第１の解析部３２による解析処理と第２の
解析部３４による解析処理の双方とも、オペレータから
指定されたときにのみ、当該指定された構成要素間の関
係を解析して出力するようにしても良い。

【００５８】また、上記実施形態では、要求仕様モデル
の構成要素として、ユースケース、アクタ、データ、条
件、ビジネスルールの５つをあげたが、これらは単なる
一例であって、本発明はこれに限定されるものではな
い。また、各構成要素間の関係の解析の方法も、上述し
た第１の解析部３２および第２の解析部３４のように、
まず単位要求仕様内での関係を解析した後で全体での関
係を解析する方法には限定されない。

【００５９】また、上記実施形態では、解析指定部４に
より関係解析を行う所望の構成要素を指定する際に、図
３のような指定用画面を用いていたが、図２の左側に示
したツリー構造表示画面２１から指定を行うようにする
ことも可能である。図８は、マウスカーソルを“外部”
と書かれたアイコンのところに移動させ、マウスの例え
ば右ボタンを押した後、カーソルを移動して“アクタ”
のアイコンを選択したときの状態を示す。この場合は、
図４に示すようなユースケースとアクタとの相関マトリ
クスが表示されることになる。

【００６０】また、上記実施形態では、構成要素間の関
係の解析結果を図４〜図６のようにマトリクス表示する
だけであったが、このマトリクス上において所望のマス
をクリックしたときに、そのマスに該当する入力画面を
表示させるようにしても良い。オペレータは、マトリク
ス表示を見て何らかの矛盾や定義漏れがあると判断した
場合には、要求仕様の入力画面に戻って再び定義を行う
ことになるが、上述のようにすれば、対応する入力画面
に直ちに飛んでいくことができるので、作業の操作性お
よび効率性を向上させることができる。

【００６１】また、上記実施形態では、各構成要素間の
関係について解析された結果をマトリクス表示していた
が、ユースケース図として表示するようにしても良い。
図９は、表示されるユースケース図の例を示す図であ
る。図９において、楕円で示した部分はそれぞれ単位要
求仕様のユースケースを示し、人の形をした部分はアク
タを示している。また、このユースケース図では利用関
係および拡張関係を両方とも表示している。このように
すれば、各構成要素間の関係をイメージとして確認する
ことができる。

【００６２】また、上記実施形態では、構成要素間の関
係を表すマトリクス表示を見てオペレータ自身が要求仕
様の矛盾や漏れを判断していたが、あるべきルールをあ
らかじめ登録しておくことにより、矛盾や漏れを装置に
自動的に行わせるようにすることも可能である。例え
ば、プライマリアクタもセカンダリアクタも存在しない
場合や、データが重複して２回以上使われている場合、
あるいはデータの参照場所と入力場所との対応がとれて
いない場合などの一般的にチェック可能な項目に関して
は、装置が自動的にチェックを行い、ルール違反があっ
た場合にはエラーメッセージを出力するようにすること
が可能である。

【００６３】（第２の実施形態）次に、本発明の第２の
実施形態について説明する。図１０は、第２の実施形態
による要求仕様記述支援装置の要素的特徴を表す機能構
成ブロック図である。なお、この図１０において、図１
に示した符号と同一の符号を付したものは、同一の機能
を有するものであるので、これについての詳細な説明は
省略する。

【００６４】図１０において、文章ベースの要求仕様記
述部５１は、要求仕様モデルの各構成要素（ユースケー
ス、アクタ、データ、条件、ビジネスルール）が全て含
まれるようにあらかじめ定められた所定のフォーマット
に従って、要求仕様の定義を文章ベースで記述するもの
であり、図１に示した要求仕様記述部１とほぼ同様のも
のである。ただし、本実施形態による文章ベースの要求
仕様記述部５１は、要求仕様を記述するための入力画面
として複数のビューを有する点で、図１の要求仕様記述
部１と異なる。なお、この入力画面は、ＣＲＴやＬＣＤ
などの表示部５５上に表示されるものである。

【００６５】上記文章ベースの要求仕様記述部５１が有
する複数のビューの例としては、要求仕様を必須項目だ
けで簡易的に記述できるようにした画面や、表（テーブ
ル）形式によって一覧として要求仕様を記述するように
した画面、あらかじめ設定した１つ１つの入力項目を埋
めながら詳細に要求仕様を記述していく画面などが考え
られる。

【００６６】また、本実施形態では、文章ベースで要求
仕様を記述する文章ベースの要求仕様記述部５１の他
に、図ベースで要求仕様を記述できるようにした図ベー
スの要求仕様記述部５２も備えている。この図ベースの
要求仕様記述部５２も、要求仕様を記述するための入力
画面として複数のビューを有している。上記文章ベース
の要求仕様記述部５１および図ベースの要求仕様記述部
５２が持つビューは、表示制御部５４の制御により、表
示部５５上に複数を同時に表示させることが可能であ
る。

【００６７】これら文章ベースの要求仕様記述部５１で
記述された要求仕様の情報、および図ベースの要求仕様
記述部５２で記述された要求仕様の情報は、要求仕様格
納部５３に格納される。ここでは、各要求仕様記述部５
１，５２が持つ個々のビューごとに、定義された要求仕
様の情報が別に格納される。

【００６８】表示制御部５４は、要求仕様格納部５３に
格納された各ビューに対応する要求仕様情報のうち、指
定されたビューに対応する情報を選択的に表示部５５に
表示させる制御を行う。このとき、表示制御部５４は、
図ベースの要求仕様記述部５２で定義された要求仕様情
報を表示部５５に表示する場合には、ＧＵＩ（Graphica
l User Interface）等を用いて表した所定のアイコンに
よってアクタやユースケースを表示する。このアイコン
等の表示位置に関する情報は、要求仕様格納部５３に格
納されている。表示制御部５４はまた、関係出力部５か
ら出力される関係情報を表示部５５に表示させる制御も
行う。

【００６９】更新部５６は、文章ベースの要求仕様記述
部５１および図ベースの要求仕様記述部５２が有する複
数のビューのうち、あるビューを用いて追加、削除ある
いは変更された定義内容を他のビューにも反映させるよ
うに、要求仕様格納部５３に格納されている要求仕様情
報を更新するものである。

【００７０】すなわち、ある１つのビューを用いて要求
仕様の定義に追加、削除あるいは変更の操作が行われる
と、そのビューに対応して要求仕様格納部５３内に格納
されている要求仕様情報が変更される。関係解析部３で
は、この変更された要求仕様情報を解析して各構成要素
間の関係情報を解析結果格納部３３に格納する。更新部
５６は、このとき解析結果格納部３３に格納された関係
情報に基づいて、上記要求仕様の変更等が実際に行われ
たビュー以外の他のビューに対応する要求仕様情報を更
新し、全てのビューの要求仕様が互いに同じ内容となる
ようにする。

【００７１】このように、要求仕様格納部５３に格納さ
れている各ビューに対応する要求仕様情報の更新が行わ
れる場合において、図ベースのビューを更新するとき
は、自動レイアウト生成部５７は、要求仕様格納部５３
に格納されているアイコン等の表示位置に関する情報も
更新し、アイコン同士が重ならないように画面レイアウ
トを自動的に調整する。

【００７２】なお、ここでは、更新部５６は、要求仕様
の変更等が実際に行われたビュー以外のビューに対して
要求仕様情報の更新を行うようにしているが、処理をよ
り簡素化するために、要求仕様の変更等が実際に行われ
たビューを含む全てのビューに対して要求仕様情報の更
新を行うようにしても良い。この場合、実際に変更等が
行われたビューに対して要求仕様の更新を行っても、同
じ内容で上書きするだけなので、特に問題はない。

【００７３】このようにして要求仕様格納部５３に格納
されている各ビューに対応する要求仕様情報を更新する
と、表示制御部５４は、更新された新たな内容に従って
要求仕様情報を表示部５５に表示することになる。これ
により、表示部５５に表示されている複数のビューのう
ち何れかのビューで要求仕様の内容を変更すると、その
とき表示部５５に表示されている他のビュー内の要求仕
様の内容がそれに合わせて変更される。

【００７４】図１１は、本実施形態による表示部５５の
表示画面の例を示す図である。図１１において、ツリー
構造表示画面６１は、図２に示したツリー構造表示画面
２１と同様、あるシステムの開発プロジェクトについて
定義した要求仕様モデルをツリー構造にて表示するため
の画面である。このツリー構造表示画面６１において、
アクタやユースケースの追加、削除あるいは変更などを
任意に行うことが可能である。

【００７５】図１１の例では、要求仕様を記述するため
の入力画面（ビュー）として、３つのビュー６２〜６４
を表示している。また、記述された要求仕様に基づき解
析された各構成要素間の関係を表示するための画面とし
て、１つのマトリクス表示ビュー６５も表示している。

【００７６】要求仕様を記述するためのビューの１つ目
は、アクタの一覧をテーブル形式にて表示するアクタ一
覧画面６２であり、２つ目は、ユースケースの一覧をテ
ーブル形式にて表示するユースケース一覧画面６３であ
る。これらの画面６２，６３は、文章ベースの要求仕様
記述部５１によって要求仕様を記述するための入力画面
である。３つ目は、アクタやユースケースをＧＵＩなど
の図形式で表示するダイアグラム画面６４である。これ
は、図ベースの要求仕様記述部５２によって要求仕様を
記述するための入力画面である。

【００７７】１つ目のアクタ一覧画面６２の欄では、ア
クタの名称と、各アクタの内容を表す概要と、各アクタ
と関係を有するユースケース（そのアクタが実行するユ
ースケース）とを定義する。また、２つ目のユースケー
ス一覧画面６３の欄では、ユースケースの名称と、各ユ
ースケースにおいてどんな業務を行うのかの大まかな内
容を表す目的と、各ユースケースと関係を有するアクタ
（そのユースケースを実行するアクタ）とを定義する。

【００７８】また、３つ目のダイアグラム画面６４で
は、上記アクタ一覧画面６２あるいはユースケース一覧
画面６３において文章ベースで定義される内容と同様の
内容（アクタの概要やユースケースの目的は除く）を図
ベースで定義する。この図１１の例では、アクタは人間
の形をしたアイコンで表され、ユースケースは楕円形の
アイコンで表される。また、アクタとユースケースとの
間の関係は、その間に引かれた線によって表される。

【００７９】このダイアグラム画面６４において要求仕
様を定義する際には、アクタボタン６６をクリックする
ことによって新たなアクタを追加することができ、ユー
スケースボタン６７をクリックすることによって新たな
ユースケースを追加することができる。また、コミュニ
ケーションボタン６８をクリックすることによって、ア
クタとユースケースとの間の関係を追加することができ
る。

【００８０】この図１１に示す画面において、例えば所
望のユースケースの部分をマウスでクリックすると、図
２に示したような詳細なユースケースの入力画面が表示
され、より詳細な定義を行うことができるようになって
いる。なお、この図１１では既に要求仕様の定義が入力
された状態を示しているが、最初はどのビューも空欄で
ある。

【００８１】ここで、例えばアクタ１，２およびユース
ケース１，２の定義まで終了している段階で、更にアク
タ一覧画面６２を用いてアクタ３およびユースケース３
を追加する場合を例にとってその動作を説明する。

【００８２】まず、アクタ一覧画面６２内のアクタ名称
の欄にアクタ３を追加する。この時点では、入力画面６
３，６４を含む他のビューに対応する要求仕様の記述内
容の更新処理はまだ行われないが、ユースケース一覧画
面６３では、上記アクタ一覧画面６２で新たに定義され
たアクタ３を、何らかのユースケースを実行するアクタ
として選択可能な状態になる。

【００８３】次に、ユースケース一覧画面６３内のユー
スケース名称の欄にユースケース３を追加する。この時
点でも、入力画面６２，６４を含む他のビューに対応す
る要求仕様の記述内容の更新処理はまだ行われないが、
アクタ一覧画面６２では、上記ユースケース一覧画面６
３で新たに定義されたユースケース３を、何れかのアク
タが実行するユースケースとして選択可能な状態にな
る。

【００８４】次に、ユースケース３を実行するアクタと
して、ユースケース一覧画面６３内のアクタの欄にアク
タ３を追加する。すると、関係解析部３によってこのア
クタ３とユースケース３との関係が解析され、その解析
された関係情報に基づいて、更新部５６によって他のビ
ューに対する定義内容の更新処理が行われる。

【００８５】これにより、ユースケース一覧画面６３と
同時に表示されている他の入力画面６２，６４の定義内
容が、ユースケース一覧画面６３で追加された定義内容
と同様となるように更新されて表示される。すなわち、
アクタ一覧画面６２では、ユースケースの欄にユースケ
ース３が追加表示される。また、ダイアグラム画面６４
では、アクタ３のアイコンとユースケース３のアイコン
とがその間に線が引かれた状態で追加表示される。

【００８６】なお、ここでは、ある文章ベースのビュー
において要求仕様の記述が変更された場合に、他の文章
ベースのビューに対応した要求仕様および図ベースのビ
ューに対応した要求仕様の記述を更新する例を示した
が、これとは逆に、ある図ベースのビューにおいて要求
仕様の記述が変更された場合には、他の図ベースのビュ
ーに対応した要求仕様および文章ベースのビューに対応
した要求仕様の記述が更新される。

【００８７】また、ここでは、ある文章ベースのビュー
で要求仕様の記述が変更された場合に、図ベースのビュ
ーに対応した要求仕様の表示を自動的に更新する例を示
したが、オペレータからの指示に応じて更新内容を表示
するようにしても良い。この指示を行うための構成が、
図１０に示した図化範囲指定部５８である。

【００８８】すなわち、ユースケース一覧画面６３内で
アクタ３とユースケース３を追加したときに、アクタ一
覧画面６２内の表示がそれに対応して更新されることは
上述の場合と同じであるが、このときダイアグラム画面
６４には、アクタ３とユースケース３の追加内容はまだ
表示しない。ここで、オペレータが図化範囲指定部５８
を用いて、例えばアクタ一覧画面６２内でアクタ３とユ
ースケース３の範囲を指定し、これを図化することを指
示すると、そのとき初めてアクタ３のアイコンとユース
ケース３のアイコンとをその間に線が引かれた状態で追
加表示する。

【００８９】つまり、アクタあるいはユースケースの削
除および図に表示されている部分への更新については、
その削除内容や更新内容を図ベースのビューに即時に反
映させても良いが、新たな追加分については、それをそ
の図ベースのビューに加えて表示するのが適切かどうか
不明なことが多いので、自動的な追加は行わず、図化範
囲指定部５８による指定を待って行うようにする。これ
は、あるユースケース図は、要求仕様の全体ではなくそ
の一部だけを表示している場合があるからである。した
がって、全要素を表示するように指定されているビュー
であれば、他のビューでの追加内容を自動的に反映させ
ることとしても問題ない。

【００９０】また、上述の動作例では、最初にアクタ一
覧画面６２内のアクタ名称の欄にアクタ３を追加した時
点では他のビューに対する記述内容の更新処理は行わな
いようにしていたが、この時点でも直ちに関係解析部３
によってアクタ３の関係を解析し、その結果を他のビュ
ーに反映させるようにしても良い。

【００９１】この場合、アクタ３の関係を解析すると、
アクタ３に関係するユースケースは存在しないという結
果が得られる。更新部５６は、この解析結果に基づい
て、他のビューに対する記述内容の更新処理を行うよう
にする。すなわち、ここではアクタ３に関係するユース
ケースの更新処理は行えないが、アクタに関する入力項
目を持つビューに対してはそのアクタ３を追加する処理
を行う。これにより、アクタ一覧画面６２内のアクタ名
称の欄にアクタ３を追加した時点で、例えばユースケー
ス一覧画面６３のアクタ一覧の欄にアクタ３の名称が追
加表示される。

【００９２】その後、アクタ一覧画面６２内のユースケ
ースの欄にユースケース３を追加すると、関係解析部３
によってこのアクタ３とユースケース３との関係が解析
され、その解析された関係情報に基づいて、更新部５６
によって他のビューに対する定義内容の更新処理が行わ
れる。これにより、ユースケース一覧画面６３のユース
ケース名称の欄にもユースケース３の名称が追加表示さ
れる。

【００９３】以上のようにして要求仕様の記述内容が変
更されると、構成要素間の関係をマトリクス表示するマ
トリクス表示ビュー６５の内容も更新して表示される。
図１１に示す例では、この更新表示は最新ボタン６９を
クリックしたときに行われるようになっている。なお、
この最新ボタン６９を押さなくても自動的に内容を更新
して表示するようにしても良い。

【００９４】以上のように、第２の実施形態によれば、
要求仕様を記述するための入力画面として複数のビュー
を用意し、任意のビューを用いて要求仕様を記述できる
ようにしたので、それぞれのオペレータ毎に書きやすい
ビューを用いて要求仕様の記述を行うことができる。し
かも、１つのビューを用いて記述内容を変更すると、そ
れに連動して他のビューの記述内容も適切に更新される
ので、オペレータにとっての使い勝手を格段に向上させ
ることができる。

【００９５】さらに、本実施形態では、文章ベースだけ
でなく、図ベースによっても要求仕様を記述することが
できるようにしているので、例えば、最初は図ベースの
ビューを用いて視覚的に分かりやすい状態で要求仕様を
記述していき、途中から文章ベースのビューに切り替え
て詳細に記述していくといった使い方ができる。もちろ
ん、最初に文章ベースで記述した要求仕様からそれに対
応するユースケース図を自動的に生成し、以後は図ベー
スと文章ベースの所望のビューで修正していくことも可
能である。つまり、図ベースの方が定義しやすい部分と
文章ベースの方が定義しやすい部分とで適宜ビューを切
り替えて使い分けることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１１４】なお、以上の例では、構造化されたユース
ケース等を文章ベースで記述する場合を例にとって説明
したが、第２の実施形態と同様に、構造化されたユース
ケース等を図ベースで記述することも可能である。図１
６は、本実施形態による表示画面の例を示す図である。

【０１１５】すなわち、図１６に示すダイアグラム画面
６４において構造化された関係を記述する場合には、汎
化ボタン８１をクリックすることによってユースケース
間あるいはアクタ間の汎化関係を追加することができ、
利用ボタン８２をクリックすることによって、ユースケ
ースと共通サブユースケースとの利用関係を追加するこ
とができる。また、拡張ボタン８３をクリックすること
によって、ユースケース間の拡張関係を追加することが
できる。なお、これらの関係について詳細な内容を定義
する際には、例えばダイアグラム画面６４上の該当する
アイコンをマウスでクリックすることにより、文章ベー
スの入力画面を表示させる。

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

【０１１７】図１７に示す要求仕様記述支援装置では、
図１０に示した構成に対して更に構造化指定部９１と第
２の要求仕様格納部９２とが追加されている。構造化指
定部９１は、第１の要求仕様格納部５３に格納されてい
る要求仕様の情報に対して利用、汎化、拡張の何れかの
関係を指定するものである。構造化指定部９１は、これ
ら３つの関係の種類を指定するだけでなく、必要に応じ
て構造化を行う範囲も指定する。

【０１１８】第２の要求仕様格納部９２は、第１の要求
仕様格納部５３に格納されている元の要求仕様情報（ユ
ースケースやアクタ）と利用、汎化あるいは拡張の関係
を有する要求仕様情報を格納するものである。なお、こ
こでは第１の要求仕様格納部５３と第２の要求仕様格納
部９２とを別に設けているが、同じ格納部に領域を分け
て格納するようにしても良い。

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

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

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

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

【０１２３】表示制御部５４は、第１の要求仕様格納部
５３および第２の要求仕様格納部９２に格納された各ビ
ューに対応する要求仕様情報のうち、指定されたビュー
に対応する情報を選択的に表示部５５に表示させる制御
を行う。このとき、表示制御部５４は、例えば汎化によ
り構造化された要求仕様情報について、元の要求仕様情
報との差分のみを表示したり、両者を合わせて展開した
ものを表示したりすることが可能である。

【０１２４】以上のように、第３の実施形態によれば、
ユースケースやアクタを利用、汎化、拡張の関係で構造
化できるようにしたので、例えば利用関係を用いて共通
サブユースケースを作成することにより、複数のユース
ケースからこの共通サブユースケースを利用することが
可能となり、ユースケースの再利用を容易にすることが
できる。また、あるユースケースに含まれるイベント列
の一部を抜き出して共通サブユースケースを作ると、そ
の元のユースケース中で抜き出された部分を共通サブユ
ースケースの記述に自動的に置き換えることができる。
これにより、オペレータがユースケースを定義する際の
作業負担を軽減することができる。

【０１２５】また、例えば汎化関係を用いて別のユース
ケースや別のアクタを作成することにより、様々なユー
スケースを定義していく際、それらのユースケース間で
共通の部分は繰り返し入力しなくても済み、異なる部分
だけを入力していけば良くなる。これにより、オペレー
タの作業量を格段に少なくすることができる。このと
き、異なる部分だけを表示して記述するのではなく、元
のユースケースと同じ内容を入力画面に表示した上で必
要な部分を修正していくことができるようにしているの
で、ユースケースの全体感をよく理解しながら異なる部
分だけを記述していくことができる。

【０１２６】また、特殊化されたユースケースでは、そ
の元となったユースケースとの差分データだけを格納し
ているので、元のユースケースにおいて共通の部分に修
正が行われたとしても、その修正内容は特殊化されたユ
ースケースにも反映されることとなり、常に整合性を正
しく維持することができる。したがって、修正漏れや入
力ミスを少なくすることができ、より正確な要求仕様を
記述することができるようになる。また、特殊化された
ユースケースと元のユースケースとの差分だけを表示す
るビューや、両者を合わせて展開したものを表示するビ
ューなど、必要に応じたビューを定義することもでき
る。

【０１２７】また、例えば拡張関係を用いて別のユース
ケースを作成することにより、あるユースケース内の特
定のイベントから他のユースケースへと条件分岐させる
ことができる。このとき、１個のイベントと１個のユー
スケースとの間を関係付けているので、ユースケースを
構造化したときの詳細な関係を分かり易くすることがで
きる（これは利用関係により構造化したときも同じであ
る）。

【０１２８】また、本実施形態では、文章ベースだけで
なく、図ベースによっても要求仕様を記述することがで
きるようにしているので、構造化されている関係を一目
で容易に理解することができる。また、図ベースの方が
定義しやすい部分と文章ベースの方が定義しやすい部分
とで適宜ビューを切り替えて使い分けることもできる。

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

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

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

【０１３２】

【発明の効果】本発明は上述したように、例えばユース
ケースの形態で記述された要求仕様モデルの構成要素間
の関係を解析して、その解析された結果を例えば表示装
置に出力するようにしたので、表示された構成要素間の
関係を参照することによって、記述された要求仕様に漏
れや矛盾等がないか否かのチェックを容易に行うことが
できる。これにより、必要に応じてそのチェック結果を
要求仕様の記述にフィードバックすることにより、シス
テムを開発する上で必要な要求仕様を正確に記述するこ
とができる。したがって、その後の設計段階や実装段階
で手戻り作業が発生してしまう不都合を未然に防止する
ことができ、従来に比べてシステムの開発コストを大幅
に削減することができる。

【０１３３】また、本発明のその他の特徴によれば、要
求仕様をユースケースの形態で記述するための情報入力
画面として、ユースケースを文章ベースで記述するビュ
ーと図ベースで記述するビューを含む複数のビューを用
意し、何れかのビューを用いて要求仕様の記述が行われ
たときに、その記述内容を他のビューにも反映させるよ
うにしたので、複数のビューの中からオペレータが書き
やすいビューを用いて要求仕様の定義を行うことができ
る。したがって、図ベースの方が要求仕様の定義しやす
い部分と文章ベースの方が定義しやすい部分とで適宜ビ
ューを切り替えて使い分けることができ、オペレータに
とってより使い勝手の良い環境を提供することができ
る。

【０１３４】また、本発明のその他の特徴によれば、要
求仕様モデルの各構成要素について、ある構成要素から
他の構成要素を利用する利用関係、元の構成要素に対し
て部分的な変更を加えて新たな構成要素を作る汎化関
係、ある構成要素において特定の条件を満たしたときに
別の構成要素の処理を行う拡張関係の少なくとも１つを
用いて各構成要素を構造化できるようにしたので、例え
ば利用関係を用いて共通構成要素を作成することによ
り、構成要素の再利用を容易にすることができる。ま
た、汎化関係を用いて別の構成要素を作成することによ
り、様々な構成要素間で共通の部分は繰り返し入力しな
くても済み、オペレータの作業負荷を少なくすることが
できる。このとき、特殊化された構成要素は元の構成要
素との差分だけをデータとして持つので、元の構成要素
において行われた修正内容を、特殊化された構成要素に
も特別な処理を行うことなく反映させることが可能とな
り、常に整合性を正しく維持することができる。したが
って、修正漏れや入力ミスを少なくしてより正確な要求
仕様を記述することができるようになる。また、拡張関
係を用いて別の構成要素を作成することにより、ある構
成要素から他の構成要素へと条件分岐させることができ
る。さらに、文章ベースだけでなく、図ベースによって
も構造化された要求仕様を記述できるようにした場合に
は、図ベースのビューを用いることにより、構造化され
ている関係を一目で容易に理解することができる。逆
に、詳細な内容を記述する場合には文章ベースのビュー
を用いることができる。つまり、図ベースの方が定義し
やすい部分と文章ベースの方が定義しやすい部分とで適
宜ビューを切り替えて使い分けて構造化された構成要素
を定義することができる。

【図面の簡単な説明】

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

【図２】第１の実施形態による要求仕様の入力画面の例
を示す図である。

【図３】関係解析を行う構成要素を指定するための画面
の一例を示す図である。

【図４】解析結果のマトリクス表示の例を示す図であ
る。

【図５】解析結果のマトリクス表示の例を示す図であ
る。

【図６】解析結果のマトリクス表示の例を示す図であ
る。

【図７】図１の関係解析部が行う動作を示すフローチャ
ートである。

【図８】関係解析を行う構成要素を指定するための他の
画面例を示す図である。

【図９】各構成要素間の関係を表すために表示されるユ
ースケース図の例を示す図である。

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

【図１１】第２の実施形態による複数のビューを有する
表示画面の例を示す図である。

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

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

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

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

【図１６】第３の実施形態による複数のビューを有する
表示画面の例を示す図である。

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

【符号の説明】

１ 要求仕様記述部 ２ 要求仕様格納部 ３ 関係解析部 ４ 解析指定部 ５ 関係出力部 ２１ ツリー構造表示画面 ２２ａ ユースケース用タグ ２２ｂ ビジネスモデル用タグ ２３ ユースケース入力画面 ３１ 構成要素抽出部 ３２ 第１の解析部 ３３ 解析結果格納部 ３４ 第２の解析部 ５１ 文章ベースの要求仕様記述部 ５２ 図ベースの要求仕様記述部 ５３ 要求仕様格納部 ５４ 表示制御部 ５５ 表示部 ５６ 更新部 ５７ 自動レイアウト生成部 ５８ 図化範囲指定部 ６１ ツリー構造表示画面 ６２ 文章ベースのアクタ一覧画面 ６３ 文章ベースのユースケース一覧画面 ６４ 図ベースのダイアグラム画面 ６５ マトリクス表示画面 ６６ アクタボタン ６７ ユースケースボタン ６８ コミュニケーションボタン ６９ 最新ボタン ７１ イベント欄 ７２ アクタ欄 ７３ 利用ＵＣ欄 ７４ 利用ＵＣ作成ボタン ７５ 特殊化ボタン ７６ 拡張ボタン ８１ 汎化ボタン ８２ 利用ボタン ８３ 拡張ボタン ９１ 構造化指定部 ９２ 第２の要求仕様格納部

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

Claims (25)

【特許請求の範囲】
1. 【請求項１】 記述された要求仕様のモデルを構成する
   所定の構成要素間の関係を解析する関係解析手段と、 上記関係解析手段により解析された結果を出力する関係
   出力手段とを備えたことを特徴とする要求仕様記述支援
   装置。
2. 【請求項２】 要求仕様モデルの各構成要素が含まれる
   ようにあらかじめ定められた所定のフォーマットに従っ
   て上記要求仕様を記述する要求仕様記述手段を備えたこ
   とを特徴とする請求項１に記載の要求仕様記述支援装
   置。
3. 【請求項３】 上記要求仕様記述手段は、上記要求仕様
   をユースケースの形態で記述するようになされているこ
   とを特徴とする請求項２に記載の要求仕様記述支援装
   置。
4. 【請求項４】 上記要求仕様記述手段は、上記要求仕様
   をユースケースの形態で記述するための情報入力画面と
   して、上記ユースケースを文章ベースで記述するビュー
   および図ベースで記述するビューを含む複数のビューを
   有し、 上記複数のビューのうち何れかのビューを用いて上記要
   求仕様の記述が行われたときに、その記述内容を他のビ
   ューに反映させるように情報の更新を行う情報更新手段
   を備えたことを特徴とする請求項３に記載の要求仕様記
   述支援装置。
5. 【請求項５】 上記情報更新手段は、上記関係解析手段
   による解析結果に基づいて上記他のビューの情報の更新
   を行うをことを特徴とする請求項４に記載の要求仕様記
   述支援装置。
6. 【請求項６】 上記関係解析手段は、単一の単位要求仕
   様内に含まれる各構成要素間の関係を解析する第１の解
   析手段と、 上記第１の解析手段により各単位要求仕様毎に解析され
   たそれぞれの結果を用いて、複数の単位要求仕様間にま
   たがる各構成要素間の関係を更に解析する第２の解析手
   段とを備えたことを特徴とする請求項１〜５の何れか１
   項に記載の要求仕様記述支援装置。
7. 【請求項７】 関係を解析する対象とする構成要素を指
   定するための指定手段を備え、 上記第２の解析手段あるいは、上記第１の解析手段およ
   び上記第２の解析手段の双方は、上記指定手段による指
   定に応じて、指定された構成要素間の関係のみを解析す
   ることを特徴とする請求項６に記載の要求仕様記述支援
   装置。
8. 【請求項８】 上記要求仕様モデルの構成要素には、シ
   ステム内でイベントを行うアクタ、取り扱うデータ、イ
   ベントを行う際の条件を少なくとも含むことを特徴とす
   る請求項１〜７の何れか１項に記載の要求仕様記述支援
   装置。
9. 【請求項９】 上記関係出力手段は、２つの構成要素間
   の関係について解析された結果をマトリクス表示するこ
   とを特徴とする請求項１〜８の何れか１項に記載の要求
   仕様記述支援装置。
10. 【請求項１０】 上記関係出力手段は、各構成要素間の
    関係について解析された結果をユースケース図として表
    示することを特徴とする請求項１〜８の何れか１項に記
    載の要求仕様記述支援装置。
11. 【請求項１１】 上記要求仕様モデルの各構成要素につ
    いて、ある構成要素から他の構成要素を利用する利用関
    係、元の構成要素に対して部分的な変更を加えて新たな
    構成要素を作る汎化関係、ある構成要素において特定の
    条件を満たしたときに別の構成要素の処理を行う拡張関
    係の少なくとも１つを用いて上記各構成要素を構造化す
    る構造化手段を備えたことを特徴とする請求項１〜１０
    の何れか１項に記載の要求仕様記述支援装置。
12. 【請求項１２】 上記要求仕様はユースケースの形態で
    記述するようになされており、上記利用関係および上記
    拡張関係については、上記ユースケース内のイベントと
    他のユースケースとの関係を構造化することを特徴とす
    る請求項１１に記載の要求仕様記述支援装置。
13. 【請求項１３】 要求仕様モデルの各構成要素が含まれ
    るようにあらかじめ定められた所定のフォーマットに従
    って、要求仕様を記述する要求仕様記述ステップと、 上記所定のフォーマットに従って記述された要求仕様の
    各構成要素間の関係を解析する関係解析ステップと、 上記解析された結果を出力する関係出力ステップとを有
    することを特徴とする要求仕様記述支援方法。
14. 【請求項１４】 上記要求仕様記述ステップでは、上記
    要求仕様をユースケースの形態で記述することを特徴と
    する請求項１２に記載の要求仕様記述支援方法。
15. 【請求項１５】 上記要求仕様記述ステップでは、上記
    要求仕様をユースケースの形態で記述するための情報入
    力画面として、上記ユースケースを文章ベースで記述す
    るビューおよび図ベースで記述するビューを含む複数の
    ビューを表示可能であり、 上記複数のビューのうち何れかのビューを用いて上記要
    求仕様の記述が行われたときに、その記述内容を他のビ
    ューに反映させるように情報の更新を行う情報更新ステ
    ップを更に有することを特徴とする請求項１４に記載の
    要求仕様記述支援方法。
16. 【請求項１６】 上記情報更新ステップにおける上記他
    のビューの情報の更新は、上記関係解析ステップによる
    解析結果に基づいて行うをことを特徴とする請求項１５
    に記載の要求仕様記述支援方法。
17. 【請求項１７】 上記関係解析ステップは、単一の単位
    要求仕様内に含まれる各構成要素間の関係を解析する第
    １の解析ステップと、 上記第１の解析ステップで各単位要求仕様毎に解析され
    たそれぞれの結果を用いて、複数の単位要求仕様間にま
    たがる各構成要素間の関係を更に解析する第２の解析ス
    テップとを有することを特徴とする請求項１３〜１６の
    何れか１項に記載の要求仕様記述支援方法。
18. 【請求項１８】 上記関係解析ステップは、単一の単位
    要求仕様内に含まれる各構成要素間の関係を解析する第
    １の解析ステップと、 上記要求仕様モデルの複数の構成要素のうち、関係を解
    析する対象とする構成要素を指定する指定ステップと、 上記指定ステップで指定された構成要素を対象として、
    上記第１の解析ステップで各単位要求仕様毎に解析され
    たそれぞれの結果を用いて、複数の単位要求仕様間にま
    たがる関係を更に解析する第２の解析ステップとを有す
    ることを特徴とする請求項１３〜１６の何れか１項に記
    載の要求仕様記述支援方法。
19. 【請求項１９】 上記関係出力ステップでは、２つの構
    成要素間の関係について解析された結果をマトリクス表
    示することを特徴とする請求項１３〜１８の何れか１項
    に記載の要求仕様記述支援方法。
20. 【請求項２０】 上記関係出力ステップでは、各構成要
    素間の関係について解析された結果をユースケース図と
    して表示することを特徴とする請求項１３〜１８の何れ
    か１項に記載の要求仕様記述支援方法。
21. 【請求項２１】 上記要求仕様モデルの各構成要素につ
    いて、ある構成要素から他の構成要素を利用する利用関
    係、元の構成要素に対して部分的な変更を加えて新たな
    構成要素を作る汎化関係、ある構成要素において特定の
    条件を満たしたときに別の構成要素の処理を行う拡張関
    係の少なくとも１つを用いて上記各構成要素を構造化す
    る構造化ステップを更に有することを特徴とする請求項
    １３〜２０の何れか１項に記載の要求仕様記述支援方
    法。
22. 【請求項２２】 上記要求仕様はユースケースの形態で
    記述するようになされており、上記利用関係および上記
    拡張関係については、上記ユースケース内のイベントと
    他のユースケースとの関係を構造化することを特徴とす
    る請求項２１に記載の要求仕様記述支援方法。
23. 【請求項２３】 要求仕様モデルの各構成要素が含まれ
    るようにあらかじめ定められた所定のフォーマットに従
    って、要求仕様を記述する要求仕様記述手段と、 定められた基準に従って記述された要求仕様の構成要素
    間の関係を解析する関係解析手段と、 上記関係解析手段により解析された結果を出力する関係
    出力手段としてコンピュータを機能させるためのプログ
    ラムを記録したことを特徴とするコンピュータ読み取り
    可能な記録媒体。
24. 【請求項２４】 要求仕様モデルの各構成要素が含まれ
    るようにあらかじめ定められた所定のフォーマットを有
    する情報入力画面であって、要求仕様を文章ベースのユ
    ースケースの形態で記述するビューおよび図ベースのユ
    ースケースの形態で記述するビューを含む複数のビュー
    を有し、何れかのビューに従って上記要求仕様を記述す
    る要求仕様記述手段と、 上記要求仕様記述手段により記述された要求仕様の構成
    要素間の関係を解析する関係解析手段と、 上記複数のビューのうち何れかのビューを用いて上記要
    求仕様の記述が行われたときに、上記関係解析手段によ
    る解析結果に基づいて、上記要求仕様の記述内容を他の
    ビューに反映させるように情報の更新を行う情報更新手
    段としてコンピュータを機能させるためのプログラムを
    記録したことを特徴とするコンピュータ読み取り可能な
    記録媒体。
25. 【請求項２５】 上記要求仕様モデルの各構成要素につ
    いて、ある構成要素から他の構成要素を利用する利用関
    係、元の構成要素に対して部分的な変更を加えて新たな
    構成要素を作る汎化関係、ある構成要素において特定の
    条件を満たしたときに別の構成要素の処理を行う拡張関
    係の少なくとも１つを用いて上記各構成要素を構造化す
    る構造化手段としての機能を更にコンピュータに実現さ
    せるためのプログラムを記録したことを特徴とする請求
    項２３または２４に記載のコンピュータ読み取り可能な
    記録媒体。