JPH09190344A

JPH09190344A - 要求仕様補完装置

Info

Publication number: JPH09190344A
Application number: JP366496A
Authority: JP
Inventors: Tsuneki Haizuka; 凡樹灰塚
Original assignee: ATR TSUSHIN SYST KENKYUSHO KK
Current assignee: ATR TSUSHIN SYST KENKYUSHO KK
Priority date: 1996-01-12
Filing date: 1996-01-12
Publication date: 1997-07-22

Abstract

(57)【要約】【課題】３個以上の端末を対象とした通信サービスの
要求仕様を補完し得る要求仕様補完装置を提供する。【解決手段】開始状態と目標状態との間に欠落情報を
含む要求仕様を情報入力部２から入力すると、辞書検索
部４で辞書を検索し、開始状態と目標状態とを内部処理
形式に変換する。距離算出部９によって開始状態から目
標状態までの属性値の異なる数を数えて距離を算出し、
距離がゼロになるまで通常遷移部１０によって通常遷移
ルートを抽出するか、あるいは横滑り迂回部１２または
遠回り迂回部１３によって横滑りルートまたは遠回りル
ートを抽出し、欠落部情報を補完する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は要求仕様補完装置
に関し、特に、欠落情報を含む不完全なソフトウェア設
計情報を入力したとき、その欠落情報を補完できるよう
な要求仕様補完装置に関する。

【０００２】

【従来の技術および発明が解決しようとする課題】通信
ソフトウェアの開発において、種々の論文が発表されて
いる。その一例として、H. B. Reubenstein, et al.
“The Requirement Apprentice : AutomatedAssistance
for Requirements Acquisition” IEEE TRANSACTIONS
ON SOFTWAREENGINEERING, Vol.17, No.3, MARCH 1991お
よび N. A. M. Maiden & A. G. Sutcliffe“Requiremen
ts Critiquing Using Domain Abstractions ”PROCEEDI
NGSFIRST INTERNATIONAL CONFERENCE ON REQUIREMENTS
ENGINEERINGなどがある。これらの論文で発表されてい
る手法は、要求理解を非専門家と専門家の協調作業と考
えており、その協調作業の支援方法について研究を深め
ている。しかし、認知科学の面から、この手法を評価す
ると、専門家が介在しなければならない点は、要求者と
要求理解システムだけの構成に対して、完全な仕様を抽
出することを困難にしている面があり、専門家を必要と
しない手法の研究が未解決な課題となっている。

【０００３】また、既存のソフトウェア要求仕様やソフ
トウェア構造との類似性を判定して、再利用可能な要求
仕様を抽出し、情報の設定を１人で行ないつつ要求を獲
得する考えであり、既存のものにない要求仕様が入力さ
れた場合、新規な情報の定義が必要であることは検出で
きるが、基本的には自動的ではなく、人手で外部から情
報を取込まなければ要求理解ができない。さらに、欠落
情報を含む新規な通信サービスを状態遷移形式の要求仕
様として入力すると、システムとして正しい動作をする
ための規則に沿うように、欠落情報を補完することはで
きる。しかし、このような方法は２個の端末に着目して
おり、３個以上の端末を対象とした通信サービスの要求
仕様の補完については対処できないという欠点がある。

【０００４】それゆえに、この発明の主たる目的は、端
末数にかかわらずに既存の要求仕様にない新規な要求仕
様を対象として、欠落情報を自動的に補完して正しい要
求仕様とすることのできるような要求仕様補完装置を提
供することである。

【０００５】

【課題を解決するための手段】請求項１に係る発明は、
欠落情報を含む不完全なソフトウェア設計情報を入力し
たとき、欠落情報を補完する要求仕様補完装置であっ
て、開始状態と目標状態との間に欠落情報を含む要求仕
様情報を入力するための入力手段と、開始状態と目標状
態とを辞書を参照して内部処理形式に変換する内部処理
形式変換手段と、内部処理形式に変換された開始状態と
目標状態の属性値の異なる数を数えて距離を算出する距
離算出手段と、算出された距離がゼロになるまで開始状
態の属性値の定義を遷移させて欠落情報を補完する遷移
手段と、欠落情報が補完された開始状態から目標状態に
至るまでのルールを辞書を参照して内部形式から要求仕
様の形式に逆変換する逆変換手段とを備えて構成され
る。

【０００６】請求項２に係る発明では、請求項１の辞書
は要求仕様のルールを構成する状態とそのルールに対応
して内部処理形式種別ごとに記述されている。請求項３
に係る発明では、請求項１または２の要求仕様は、現在
の状態と次の状態と現在の状態から次の状態に遷移する
契機となるイベントとを含む複数のルールからなり、内
部形式は要求仕様における１つの状態が複数の属性の属
性値の集合に対応している。請求項４に係る発明では、
請求項１の遷移手段は、距離が縮まるような状態遷移ル
ートの抽出を行なう通常遷移ルート抽出手段と、状態遷
移ルートの抽出ができなかったとき、横滑り迂回ルート
または遠回り迂回ルートを抽出する迂回遷移ルート抽出
手段とを含む。

【０００７】請求項５に係る発明では、さらに開始状態
から目標状態に遷移する場合に、予め定める制約条件を
満たしているか否かを判別する制約条件判別手段と、制
約条件を満たしていないことが判別されたことに応じて
異常であることを知らせる異常通知手段を含む。請求項
６に係る発明では、さらに開始状態から目標状態に遷移
する過程において、必要な状態遷移を付加するための必
須条件付加手段を含む。

【０００８】

【発明の実施の形態】図１はこの発明の一実施形態を示
すブロック図であり、図２は要求仕様入出力情報のルー
ル構成を示す図であり、図３は要求仕様の構成を示す図
であり、図４は状態と内部処理形態の関係を示す図であ
る。まず、この発明の一実施形態の構成を説明する前
に、図２〜図４を参照して、入出力情報の形式について
説明する。要求仕様は状態遷移を記述するルールの集合
として記述され、図２に示すように、現状態とイベント
と次状態とからなり、イベントは現状態から次状態に遷
移する契機となる事象である。たとえば、電話端末機を
例にとると、現状態は受話器を取り上げる前の状態であ
り、イベントは受話器を取り上げる操作であり、次状態
は受話器を取り上げた後の呼出し音の発生である。

【０００９】要求仕様の構成は、図３に示すように、図
２に示したルールを複数組合せたものである。このよう
な要求仕様が入力されると、辞書により内部処理形式に
変換される。内部処理形式では、図４に示す点線で囲ま
れた複数の属性の属性値の集合が１つの状態となる。要
求仕様上の状態遷移の対象となるもの（たとえば電話端
末など）は、ルールによって１つあるいは２つの組合せ
で関係づけられる。属性の集合は、この組合せのタイプ
ごとに決定される。このタイプには、以下の３タイプが
ある。

【００１０】（ａ）タイプ１：対応する要求仕様上の
状態の引数が１つ。（ｂ）タイプ２：対応する要求仕様上の状態の引数が
２つでありかつ同一。（ｃ）タイプ３：対応する要求仕様上の状態の引数が
２つでありかつ異なる。次に、初期状態について説明する。特に、要求仕様上に
初期状態に関する指定がなければ、開始状態に現われな
いすべてのもの（たとえば電話端末など）について要求
仕様に示される最後の状態と同じ状態を持つと仮定され
る。同様に、目標状態に現われないすべてのものについ
て要求仕様に示される最初の状態と同じ状態を持つと仮
定し、初期状態が付加される。

【００１１】要求仕様上に初期状態に関する指定があれ
ば、開始状態，終了状態に現われないすべてのものにつ
いて、指定に従って初期状態が付加される。開始状態Ｐ１（Ａ，Ｂ），Ｐ２（Ｃ）目標状態Ｐ３（Ａ，Ｃ）最後の状態Ｐ４（Ｘ）最初の状態Ｐ５（Ｘ）初期状態を付加した開始状態Ｐ１（Ａ，Ｂ），Ｐ２
（Ｃ），Ｐ４（Ｂ）初期状態を付加した目標状態Ｐ３（Ｂ，Ｃ），Ｐ５
（Ａ），Ｐ５（Ｃ）なお、最後の状態Ｐ４（Ｘ）と最初の状態Ｐ５（Ｘ）は
電話端末では受話器を取り上げる前と受話器を置いた状
態で同じ状態（idle）となる。

【００１２】次に、辞書情報について説明する。辞書
は、要求仕様のルールを構成する状態と、各ルールに対
応する内部処理形式種別ごとに記述される。辞書上で実
際に可能な状態の和集合を作るとき、呼要素ごとの状態
定義に矛盾が生じるようなことは生じない。ここで呼要
素とは、電話機が通話できるときにとり得る組合せパタ
ーンを指す。たとえば、電話機Ａ，Ｂがある場合、組合
せパターンとして、Ａ，Ａ−Ａ，Ａ−Ｂ，Ｂ，Ｂ−Ｂ，
Ｂ−Ａの６つがある。ただし、未設定の項については、
他の内部形式の定義未設定以外の値設定がある場合は未
設定以外の値を有効とする。表１に要求仕様と内部形式
の対応関係を示す。

【００１３】

【表１】

【００１４】次に、制約条件情報について説明する。制
約条件には以下の２つの条件がある。（１）属性値相互の排他性の記述。ここでは同時にと
り得ない属性値の組合せが記述される。ここで、属性値
相互とはたとえば２つの電話機が接続されていて通話で
きる状態になっている場合に受話器の状態としてとり得
る属性値が定まることをいう。排他性とは受話器をとっ
ているのが属性値であれば受話器を置いているのが排他
性である。

【００１５】（２）属性値と操作種別の間の排他性の
記述。ある属性が特定の属性値を持つ場合に、禁止すべ
き遷移操作種別が記述される。必須条件情報は、要求仕
様記述者の意図と無関係に、異常処理などのシステムと
して必須の仕様条件が記述される。次に、図１を参照し
て、全体の構成について説明する。全体制御部１は各処
理部への情報の授受，起動，終了後処理を行ない、各処
理部の異常があれば、強制的に処理を終了させる。情報
入力部２は対人，対装置の情報入力を担当し、対人入力
部では人に入力情報を容易に設定させるための入力画面
の表示や入力情報の候補を示す入力ガイダンスを行な
う。対装置入力部では他の装置からの入力を可能とする
インタフェースを提供する。

【００１６】欠落情報チェック部３は要求仕様が空き状
態から出発して他の状態に遷移し、最終的に空き状態に
至る状態遷移が記述されていることを利用しており、入
力された要求仕様を空き状態から出発して要求として入
力されたルールを適応することにより状態遷移させ、ど
のルールも適応できない状態を検出した場合、この状態
を開始状態とする。同様に、空き状態に戻ってくる状態
遷移ルートを逆に辿った場合の最終状態が空き状態でな
い場合を目標状態とする。この状態を図５に示す。

【００１７】辞書検索部４は入力情報を内部処理形式に
変換する場合、モデル状態変換部５を呼出し、内部処理
形式を出力情報形式に変換する場合に実状態変換部６を
呼出す。このような変換を行なうときに、変換先の情報
がない場合は、不足情報問合せ部７を呼出し、ユーザに
不足情報の設定を行なわせる。モデル状態変換部５は入
力情報を内部形式に変換するものであり、１つの入力情
報に対して複数の内部形式がある場合には、それぞれの
情報を変換し、それ以下の処理を続行する。実状態変換
部６は、内部処理形式を出力情報形式に変換するもので
あり、１つの内部処理形式に対して、複数の出力情報形
式がある場合は、それぞれの出力情報形式に変換し、情
報出力部１９を介してそれぞれの情報を表示し、ユーザ
に取捨選択を行なわせる。不足情報問合せ部７は入力情
報を内部形式に変換する場合、または内部処理形式を出
力情報形式に変換する場合に、何に変換するのか、辞書
上に情報がない場合は、辞書情報の入力画面を情報出力
部１９を介して表示し、ユーザに情報設定を行なわせ
る。

【００１８】抽象状態遷移部８は内部形式に変換された
開始状態と目標状態がそれぞれ属性の集合として表現す
る。その両者の属性の値が異なる数を数え上げたものを
距離と呼ぶ。この処理部では、基本的には抽象状態が遷
移することにより、距離が縮まるような状態遷移ルート
の抽出を行なう。しかし、一時的に、距離が大きくなる
ような状態遷移がないわけではないので、距離の縮まる
状態遷移ルートがない場合に、距離が一時的に大きくな
る状態遷移ルートの抽出を行なう。距離算出部９は内部
形式に変換された開始状態と目標状態の属性値の異なる
ものの数を数え上げ、距離を算出し、通常遷移部１０は
距離が縮まるような状態遷移ルートの抽出を行なう。そ
のようなルートがないときは、その旨を全体制御部１に
知らせる。

【００１９】迂回遷移部１１は距離が縮まるような状態
遷移ルートがないときに起動される。一時的に距離が大
きくなるような状態遷移がないわけではないので、距離
の縮まる状態遷移ルートがない場合に、距離が一時的に
大きくなる状態遷移ルートの抽出を行なう。横滑り迂回
部１２は、状態遷移しても距離は変化しないが、距離を
縮める状態遷移ルートに、その遷移により辿りつける場
合を横滑り迂回と呼ぶ。この横滑り迂回部１２は通常遷
移ができなくなったときに、最初に利用され、ルートの
抽出を行なう。横滑り迂回ルートがないときは、その旨
を全体制御部１に知らせる。

【００２０】図６は横滑り迂回の例を示す図である。図
６において属性Ｓｓ（ｓ_i，ｓ_j）の距離２を１に縮め
るときに、属性ｓ１，ｓ２への遷移が不可能な場合、属
性ｓ３に横滑りし、属性ｘ_jに迂回する。遠回り迂回部
１３は横滑り迂回部１２による横滑り迂回でも状態遷移
ルートが発見できない場合に起動され、距離が一時的に
大きくなっても、目標状態に状態遷移できるルートの抽
出を行なう。図７は遠回り迂回を説明するための図であ
る。図７において、属性Ｓｓの距離１を０に縮めると
き、属性Ｓｔに遷移が不可能な場合、一旦距離２の属性
ｓ_i，ｓ_jに迂回した後、距離１の属性ｘ_jに迂回し、
属性Ｓｔに遷移する。

【００２１】制約チェック部１４は抽象状態遷移上の属
性値相互の排他性や属性値と操作種別の間の排他性をチ
ェックし、必須条件付加部１５は要求仕様記述者には不
要でも、システムとして必要な状態遷移を抽象状態遷移
上で付加する。辞書入力部１６は要求仕様補完を実行す
る前に辞書登録を行なう事前登録と、要求仕様補完の実
行中の辞書情報の不足が検出されてその場で辞書情報を
追加する実行中登録とがある。事前登録は要求仕様補完
を実行する前に登録する場合に起動され、人に入力情報
を容易に設定させるための入力画面の表示や可能ならば
入力情報の候補を示す入力ガイダンスを行なう。実行中
登録は要求仕様補完の実行中に辞書情報の不足が検出さ
れて起動され、入力情報を容易に設定させるための入力
画面の表示や入力情報の候補を示す入力ガイダンスを行
なう。

【００２２】制約条件入力部１７は要求仕様補完を実行
する前に登録する場合に起動され、必須条件入力部１８
は要求仕様補完を実行する前に登録する場合に起動され
る。情報出力部１９は対人，対装置の情報出力を担当
し、対人入力に対しては人に入力情報を容易に設定させ
るための画面の表示や入力情報の候補を示す入力ガイダ
ンスを行ない、対装置入力では他の装置からの入力を可
能とするインタフェースを提供する。図９および図１０
はこの発明の実施形態の動作を説明するためのフローチ
ャートである。次に、図１〜図１０を参照して、この発
明の一実施形態の動作について説明する。まず、情報入
力部２から辞書情報を入力する。この辞書情報は前述の
ごとく要求仕様状態と内部形式とが対応づけられたもの
であり、具体例として表２に示す。

【００２３】

【表２】

【００２４】次に、制約条件が入力される。制約条件の
具体例として以下に〜を示す。 ♯<path-state （connected ），＄VALUE （origin
ating-address ）> 意味：パス接続状態で、発信側電話を他の電話に変え
る。 ♯<path-state （connected ），＄VALUE （termin
ating-address ）> 意味：パス接続状態で、受信側電話を他の電話に変え
る。 ♯<path-state （connected ），originating-addr
ess （＊））> 意味：パス接続状態で、発信側電話が不定である。

【００２５】 ♯<path-state （connected ），term
inating-address （＊））> originating-address （＊））> 意味：パス接続状態で、受信側電話が不定である。さらに、情報入力部２によって必須条件が入力される。
必須条件の一例を次に示す。＆＜条件：属性名，属性値，動作：属性名，操作種別＞例：＆＜条件：Ai,not（DEFAULT （Ai）），動作：Ai,
＄CLEAR （A ）>（Aiは発アドレスと着アドレス属性）この必須条件は、任意の状態でユーザの動作に起因する
切断動作が必要であることを意味している。

【００２６】要求仕様を情報入力部２から入力する。キ
ャッチホンを例にとると、開始状態がCalling （A,B
），目標状態がCW- Calling （A,C ）, Talk（A,B ）
であるとする。初期状態としてidle（X ）が定義されて
いる場合、入力状態を付加すると、Calling （A,B ）,
idle（C ）, 欠落情報，CW-Calling（A,C ）, Talk（A,
B）となる。欠落情報チェック部３は欠落情報のチェッ
クを行なう。上述の例では、Calling （A,B ），idle
（C ）とCW-Calling（A,C ）, Talk（A,B ）との間が欠
落情報であるので、欠落情報ありと判断し、要求仕様を
内部形式に変換する。内部形式に変換した一例を表３に
示す。

【００２７】

【表３】

【００２８】表３における開始状態と目標状態とを比較
すると、呼要素Ｃ，Ａ−Ｂ，Ａ−Ｃ，Ｂ−Ａ，Ｃ−Ａの
アンダーライン部分の属性値を書き換える必要がある。
不足情報問合せ部７は辞書の中に不足情報があるか否か
を判別する。不足情報があればユーザに問合せをし、距
離算出部９は距離を算出する。表３に示した例では、属
性値の異なる数を数えれば６となるので、距離が６であ
ると判断する。全体制御部１は距離がゼロか否かを判別
し、ゼロでなければ通常遷移部１０が通常遷移ルートを
抽出する。すなわち、横滑り迂回ルートや遠回り迂回ル
ートを通ることなく距離を縮めることのできるルートを
抽出する。この通常遷移ルート抽出では、表４に示すよ
うに、開始状態から次状態１のルートの抽出が行なわれ
る。

【００２９】

【表４】

【００３０】表４では呼要素Ａ−Ｂ，Ｂ−Ｃが主属性操
作＄VALUE （pathstate ），connectをpathstate がini
tial を選び属性値が変更される。ここでいう操作は、
主属性操作と従属性操作から構成される。主属性操作
は、呼要素に対して無条件に成立する操作であり、従属
性操作は主属性操作の結果生じた特定の状態に対して成
立する操作である。もし、通常ルートを抽出できなけれ
ば、迂回遷移部１１が横滑り迂回部１２または遠回り迂
回部１３によって横滑り迂回ルートまたは遠回り迂回ル
ートを抽出する。

【００３１】いずれかのルートで抽出が行なわれると、
制約条件チェック部１４が前述の制約条件をチェックす
る。このチェックでは、開始状態から状態１に移る場合
に、前述の制約条件〜を満たしているかをチェック
する。たとえば、通信サービスにおいてあってはならな
い状態があればルート抽出は失敗になり、処理結果異常
を通知する。このようにしてルート抽出が行なわれる
と、必須条件付加部１５は必須条件を付加する。この必
須条件は、前述のごとくユーザが任意に通信を切断でき
るという条件である。そして、再び距離算出部９が距離
を算出する。表４では２つの属性値が目標値に変換され
たので、距離は４になる。そして、再び距離がゼロであ
るか否かが判別され、ゼロでないことから再び通常遷移
ルートが抽出される。この通常遷移ルートが抽出された
ことによって、表４の次状態１が表５の状態１として状
態２に変換される。

【００３２】

【表５】

【００３３】この場合、呼要素Ｃの属性値がinitial か
らtoneに変換され、距離が３になる。この動作を繰り返
すことによって、最終的に表６に示すように状態２が目
標状態となる。

【００３４】

【表６】

【００３５】表６の目標状態を表２の辞書に基づいて逆
変換すると、次のようになる。したがって、初期状態に
比べて欠落情報を補完できていることがわかる。 Calling （A,B ）, idle（C ） offhook （B ）:Talk
（A,B ）. Talk（A,B ）, idle（C ） offhook （C ）:Talk
（A,B ）. dial-tone（C ）. dial-tone （C ）, Talk（A,B ）dial（C,A ） :CW-Ca
lling （C,A ）, Talk（A,B ）なお、必須条件を付加したことによって新たに要求が付
加されて分岐する必要性が生じた場合、分岐して分岐し
たルートの処理を行なう。この場合は、その分岐したル
ートの距離算出が行なわれ、それ以降の処理は前述の説
明と同じである。

【００３６】前述の説明では、キャッチホンの一例を示
したが、次に三者通話による例について説明する。ま
ず、開始状態をHold（A,B ），Calling （A,C ）とし、
目標状態をTalk（A,B ）, Talk（C,A ）, Talk（C,A ）
とし、開始状態と目標状態との間の欠落情報があるもの
とする。そして、初期状態としてidle（X ）が定義され
ていても、入力状態を付加する対象がないものとする。
このような開始状態と目標状態の要求仕様を内部形式に
変換すると、表７に示すようになる。

【００３７】

【表７】

【００３８】表７において、開始状態と目標状態の属性
値の異なる数を数えると６となるため、距離が６とな
る。そして、前述の説明と同様にして、表７の開始状態
が表８に示す状態１に変換され、距離が４となる。

【００３９】

【表８】

【００４０】さらに、通常遷移ルートにより、表９に示
すように、状態１が状態２に変換される。

【００４１】

【表９】

【００４２】さらに、通常遷移ルートにより、表１０に
示すように、状態２が目標状態に変換される。

【００４３】

【表１０】

【００４４】そして、目標状態を辞書に基づいて逆変換
すると次のような要求仕様が生成される。 Calling （A,C ）, cond:Hold （A,B ）offhook （C
）:Talk （A,C ）. Talk（A,C ）,Hold （A,B ） flash （A ）
:Talk （A,B ）, Talk（B,C ）, Talk（C,A ）.

【００４５】

【発明の効果】以上のように、この発明によれば、欠落
情報を含む不完全なソフトウェア設計情報を入力したと
き、要求仕様であるソフトウェア設計情報中の３個以上
の端末の状態を２個以下のものの状態の組合せで表現
し、これらの状態を遷移させることによってイベントの
定義を行なって欠落情報を補完することができる。

【図面の簡単な説明】

【図１】この発明の一実施形態を示すブロック図であ
る。

【図２】要求仕様入出力情報のルール構成を示す図であ
る。

【図３】要求仕様の構成を示す図である。

【図４】状態と内部処理形式の関係を示す図である。

【図５】欠落情報を含む要求仕様を説明するための図で
ある。

【図６】横滑り迂回の例を説明するための図である。

【図７】遠回り迂回の例を説明するための図である。

【図８】この発明の一実施形態の処理フローチャートを
示す図である。

【図９】この発明の一実施形態の処理フローチャートを
示す図である。

【符号の説明】

１全体制御部２情報入力部３欠落情報チェック部４辞書検索部５モデル状態変換部６実状態変換部７不足情報問合せ部８抽象状態遷移部９距離算出部１０通常遷移部１１迂回遷移部１２横滑り迂回部１３遠回り迂回部１４制約条件チェック部１５必須条件付加部１６辞書入力部１７制約辞書入力部１８必須条件入力部１９情報出力部

Claims

【特許請求の範囲】

【請求項１】欠落情報を含む不完全なソフトウェア設
計情報を入力したとき、前記欠落情報を補完する要求仕
様補完装置であって、開始状態と目標状態との間に欠落情報を含む要求仕様情
報を入力するための入力手段、前記開始状態と前記目標状態とを辞書を参照して内部処
理形式に変換する内部処理形式変換手段、前記内部処理形式に変換された開始状態と目標状態の属
性値の異なる数を数えて距離を算出する距離算出手段、前記距離算出手段によって算出される距離がゼロになる
まで、前記開始状態の属性値の定義を遷移させて前記欠
落情報を補完する遷移手段、および前記遷移手段によっ
て欠落情報が補完された開始状態から目標状態に至るま
でのルールを前記辞書を参照して内部形式から要求仕様
の形式に逆変換する逆変換手段を備えた、要求仕様補完
装置。
【請求項２】前記辞書は、前記要求仕様のルールを構
成する状態と、そのルールに対応して内部処理形式種別
ごとに記述されていることを特徴とする、請求項１の要
求仕様補完装置。
【請求項３】前記要求仕様は、現在の状態と、次の状
態と、前記現在の状態から次の状態に遷移する契機とな
るイベントとを含む複数のルールからなり、前記内部形式は、前記要求仕様における１つの状態が複
数の属性の属性値の集合に対応していることを特徴とす
る、請求項１または２の要求仕様補完装置。
【請求項４】前記遷移手段は、前記距離が縮まるような状態遷移ルートの抽出を行なう
通常遷移ルート抽出手段と、前記通常遷移ルート抽出手段によって状態遷移ルートの
抽出ができなかったとき、横滑り迂回ルートまたは遠回
り迂回ルートを抽出する迂回遷移ルート抽出手段とを含
む、請求項１の要求仕様補完装置。
【請求項５】さらに、前記開始状態から前記目標状態
に遷移する場合に、予め定める制約条件を満たしている
か否かを判別する制約条件判別手段と、前記制約条件判別手段によって前記制約条件を満たして
いないことが判別されたことに応じて異常であることを
知らせる異常通知手段を含む、請求項１の要求仕様補完
装置。
【請求項６】さらに、前記開始状態から前記目標状態
に遷移する過程において、必要な状態遷移を付加するた
めの必須条件付加手段を含む、請求項１の要求仕様補完
装置。