JP2007233905A - 要求仕様作成支援方法、そのプログラム及び要求仕様作成支援装置 - Google Patents

Abstract

【課題】 開発者が顧客との意思の疎通を図り、後戻り工数の発生を抑える。
【解決手段】 開示される要求仕様作成支援方法は、開発するシステムが果たすべき機能をＵＭＬを用いて表現するユースケース図を作成するステップＳＰ１と、開発するシステムが果たすべき基本機能の概要及び基本的な処理の流れを含むユースケース記述を作成するステップＳＰ２と、開発するシステムに要求される機能及び機能と、ユースケース図と、ユースケース記述とに基づいて、アクティビティ図又はシーケンス図を作成し、表示するステップＳＰ３と、表示されたアクティビティ図又はシーケンス図とともに、操作部の操作により入力された文字を表示するステップＳＰ４とを有している。
【選択図】 図２

Description

本発明は、例えば、ソフトウェア等のシステム開発で用いる要求仕様の作成を支援する要求仕様作成支援方法、そのプログラム及び要求仕様作成支援装置に関する。

従来、ソフトウェアを開発する際、顧客からの要求内容は、簡略化された文章（仕様書）で提示されていた。ソフトウェア開発者は、上記仕様書に記載された内容に基づいて、顧客の要求を分析し、機能分割を行うことにより、ソフトウェアを作成するための要求分析結果表や設計書を作成していた。上記設計書は、ソフトウェア開発者がソフトウェアを作成することを主眼として作成されているため、顧客は、上記設計書に記述された内容で自己が要求した内容がすべて含まれているか否か理解しにくい場合がある。

そのため、ソフトウェア開発者がソフトウェアを構成する１つの機能を作成する場合でも、顧客との意思の疎通が困難となるとともに、作成されたソフトウェアについて、顧客の要求を満たすために見直しや後戻りが多数発生することとなった。以上説明した事情から、顧客とソフトウェア開発者とが同じレベルでソフトウェアを構成する機能に関して容易に理解することができる表記法が要望されていた。

この点、近年、統一モデリング言語（ＵＭＬ：Unified Modeling Language）を利用したソフトウェア設計手法が検討され、以下に示すように、部分的に利用されている。ここで、ＵＭＬとは、オブジェクト指向のソフトウェア開発におけるプログラム設計図の統一的な表記法の１つである。

従来の要求仕様作成支援装置には、文章ベースの要求仕様記述部と、図ベースの要求仕様記述部と、関係解析部とを備えているものがある。文章ベースの要求仕様記述部は、要求仕様モデルの各構成要素（ユースケース、アクタなど）が全て含まれるように、要求仕様の定義を文章ベースで記述する。一方、図ベースの要求仕様記述部は、図ベース（ユースケース図）で要求仕様を記述する。関係解析部は、要求仕様モデルの構成要素間の関係を解析し、解析結果をユースケース図として表示する。（例えば、特許文献１参照。）以下、この技術を第１の従来例と呼ぶ。

また、従来のビジネスシステムの開発システムには、システム化基本アーキテクチャを決定した後、ビジネスをシステム化により実現するために、詳細化ルールを参照して、スコーピングモデルを詳細設計し、デザインモデルに変換するものがある。このとき生成されるデータの１つとしては、アクティビティ図がある（例えば、特許文献２参照。）。以下、この技術を第２の従来例と呼ぶ。

特開２０００−３５３０８３号公報（［００２８］，［００５５］，［００６１］，［００６３］，［００６４］，［００６６］，［００９５］、図９，図１０） 特開２００３−３３７６９７号公報（［００４８］，［００４９］、図１）

上記した第１及び第２の従来例は、いずれもＵＭＬを用いてはいるが、作成されたユースケース図やアクティビティ図を開発を依頼した顧客が参照することまでは想定していない。従って、ソフトウェア開発者と顧客との意思の疎通を図る、顧客の要求を満たすための見直しや後戻りの発生を抑えるという要望には十分に応えるものではない。
以上説明した不都合は、ソフトウェア以外のシステム開発においても同様に生じるおそれがある。

本発明は、上述した事情に鑑みてなされたものであり、上述のような課題を解決することができる要求仕様作成支援方法、そのプログラム及び要求仕様作成支援装置を提供することを目的とする。

上記課題を解決するために、請求項１記載の発明に係る要求仕様作成支援方法は、開発するシステムが果たすべき機能をＵＭＬを用いて表現するユースケース図を作成する第１のステップと、前記開発するシステムが果たすべき基本機能の概要及び基本的な処理の流れを含むユースケース記述を作成する第２のステップと、前記開発するシステムに要求される機能及び機能と、前記ユースケース図と、前記ユースケース記述とに基づいて、アクティビティ図又はシーケンス図を作成し、表示する第３のステップと、表示された前記アクティビティ図又はシーケンス図とともに、操作部の操作により入力された文字を表示する第４のステップとを有することを特徴としている。

また、請求項２記載の発明は、請求項１に記載の要求仕様作成支援方法に係り、前記第１のステップでは、前記開発するシステムが果たすべき機能について、前記ユースケース図に、基本的な機能から順次細分化して表現することを特徴としている。
また、請求項３記載の発明は、請求項１又は２に記載の要求仕様作成支援方法に係り、前記第４のステップでは、前記文字の入力の仕方について説明した案内を表示することを特徴としている。
また、請求項４記載の発明に係る要求仕様作成支援プログラムは、コンピュータに請求項１乃至３のいずれかに記載の機能を実現させることを特徴としている。

また、請求項５記載の発明に係る要求仕様作成支援装置は、表示部と、操作部と、前記操作部の操作により入力されるデータに基づいて、開発するシステムが果たすべき機能をＵＭＬを用いて表現するユースケース図を作成する第１の作成手段と、前記操作部の操作により入力されるデータに基づいて、前記開発するシステムが果たすべき基本機能の概要及び基本的な処理の流れを含むユースケース記述を作成する第２の作成手段と、前記操作部の操作により入力される前記開発するシステムに要求される機能及び機能と、前記ユースケース図と、前記ユースケース記述とに基づいて、アクティビティ図又はシーケンス図を作成し、前記表示部に表示する第３の作成手段と、前記表示部に表示された前記アクティビティ図又はシーケンス図とともに、前記操作部の操作により入力された文字を表示する第４の作成手段とを有することを特徴としている。

また、請求項６記載の発明は、請求項５に記載の要求仕様作成支援装置に係り、前記第１の作成手段は、前記開発するシステムが果たすべき機能について、前記ユースケース図に、基本的な機能から順次細分化して表現することを特徴としている。
また、請求項７記載の発明は、請求項５又は６に記載の要求仕様作成支援装置に係り、前記第４の作成手段は、前記文字の入力の仕方について説明した文を前記表示部に表示することを特徴としている。

本発明によれば、要求仕様を固める段階（設計の前段階）において、開発すべきシステムに対する顧客の要求をＵＭＬを用いてユースケース図、ユースケース記述及びアクティビティ図に図式化するとともに、アクティビティ図を用いて、要求される機能の洗い出し、要求される機能の不明点の明確化、顧客と開発者との考え方のレベルあわせ（意識あわせ）を行うことができる。これにより、開発者は、顧客との意思の疎通を図ることが可能となり、システム開発の前段階において、開発すべきシステムに対する顧客の要求をより明確かつより具体的にシステム開発に取り込むことができる。この結果、後戻りにかかる工数を抑えることができる。一方、顧客は、開発すべきシステムに対して、要求した機能が盛り込まれていることを直接確認することができるため、現在開発者が作成しているシステムへの不安を解消することができる。

また、本発明によれば、顧客と直接面談しながら、顧客が開発すべきシステムに要求する各機能の細部内容の調整を行うことも可能であるため、この顧客との検討時間を有効に利用することができる。
さらに、本発明によれば、国際標準化された表記言語であるＵＭＬを用いているため、作成されたユースケース図、ユースケース記述及びアクティビティ図から得られたデータについて、要求分析から設計、製造ひいては試験までの流れの中で、共通化、標準化を図ることができる。

以下、図面を参照して、本発明の実施の形態について説明する。本発明の実施の形態では、ソフトウェアの開発を依頼した顧客の要求を表現するために、上記したＵＭＬを用いる。特に、要求仕様を固める段階（設計の前段階）において、顧客の要求をＵＭＬを用いて図式化するとともに、要求される機能の洗い出し、要求される機能の不明点の明確化、顧客とソフトウェア開発者との考え方のレベルあわせ（意識あわせ）を目的として、ＵＭＬを用いる。これにより、開発すべきソフトウェアに対する顧客の要求をより明確にソフトウェア開発に取り込むことができる。

図１は、本発明の実施の形態に係る要求仕様作成支援装置１の概略構成を示すブロック図である。この要求仕様作成支援装置１は、制御部２と、操作部３と、表示部４と、通信制御部５と、記憶部６等を有するコンピュータ等の情報処理装置によって構成されている。制御部２は、ＣＰＵ（中央処理装置）等からなり、記憶部６に記憶されている要求仕様作成支援プログラム等の各種プログラムに基づいて、要求仕様作成支援処理等を実行し、要求仕様作成支援装置１の各部を制御する。

即ち、例えば、要求仕様作成支援プログラムが記憶部６から読み出されると、制御部２に読み込まれ、制御部２の動作を制御する。制御部２は、要求仕様作成支援プログラムが起動されると、要求仕様作成支援プログラムの制御により、要求仕様作成支援処理を実行するのである。なお、要求仕様作成支援処理については後述する。

操作部３は、文字キー、エンターキー、あるいはファンクションキー等からなるキーボードや、マウス、タッチパッド、あるいはペンデバイス等のポインティングデバイスなどを有する。表示部４は、ＣＲＴディスプレイ、液晶ディスプレイ（ＬＣＤ；Liquid Crystal Display）、エレクトロルミネセンス（ＥＬ：electroluminescence）ディスプレイ、あるいはプラズマディスプレイパネル（ＰＤＰ；Plasma Display Panel）等からなる。通信制御部５は、モデムやルータ等からなり、制御部２がこの通信制御部５及び図示せぬネットワークを介して外部の装置とデータ通信を行う。

記憶部６は、ＲＡＭやＲＯＭ、あるいはフラッシュメモリ等の半導体メモリ、ＦＤ（フレキシブルディスク）が装着されるＦＤドライブ、ＨＤ（ハード・ディスク）が装着されるＨＤドライブ、ＭＯ（光磁気）ディスクが装着されるＭＯディスクドライブ、あるいはＣＤ（コンパクト・ディスク）−ＲＯＭ、ＣＤ−Ｒ（Recordable）、ＣＤ−ＲＷ（Rewritable）や−ＲＯＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ等が装着されるＣＤ／ＤＶＤドライブ等からなる。

記憶部６は、上記した制御部２が実行すべき要求仕様作成支援プログラムその他の各種プログラムが予め記憶されているとともに、制御部２が上記した要求仕様作成支援プログラムその他の各種プログラムを実行する際に作業用として用いられる。尚、上記要求仕様作成支援プログラムは、アプリケーション・プログラムの１つとして記憶部６に予めインストールされているものとする。

次に、上記構成を有する要求仕様作成支援装置１が要求仕様作成支援処理を実行して、例えば、シミュレーション・ソフトウェアを開発する場合について、図２に示すフローチャートを参照して説明する。前提として、ソフトウェア開発者は、開発すべきシミュレーション・ソフトウェアに対して顧客が要求する機能・項目を記述した仕様書を入手しているものとする。

ソフトウェア開発者は、まず、要求仕様作成支援装置１に電源を投入して、起動する（立ち上げる）。これにより、要求仕様作成支援装置１の制御部２がパスワードの入力を促す画面を表示部４に表示するので、ソフトウェア開発者は、操作部３を操作して、所定のパスワードを入力した後、ログイン（login）を指示する。

入力されたパスワードが正しければ、要求仕様作成支援装置１がアクセス可能な状態（ログイン）になるので、ソフトウェア開発者は、操作部３を操作して、上記要求仕様作成支援プログラムの起動を指示する。これにより、要求仕様作成支援装置１の制御部２は、上記要求仕様作成支援プログラムを起動する。

従って、ソフトウェア開発者は、予め入手したシミュレーション・ソフトウェアに関する仕様書に基づいて、操作部３を操作して、開発すべきソフトウェアが果たす機能を表現するユースケース図の作成を指示する（図２のステップＳＰ１）。このステップＳＰ１では、まず、ソフトウェアが果たす基本的な機能をユースケース図に表現した後、順次細分化していく。図３は、ユースケース図を含む表示の一例を示す図、図４は、図３に示す表示がノートパソコンからなる要求仕様作成支援装置１の表示部４に表示された例を示す図である。

図３及び図４に示す表示は、ツリー１１と、ユースケース図１２と、ログ１３とから構成されている。ツリー１１は、「ユースケースビュー」と「論理ビュー」とに大別されている。「ユースケース・ビュー」は、「アクタ」がソフトウェアにしてほしいこと又はソフトウェアが「アクタ」に提供しなくてはならない機能を記述したものである。ここで、「アクタ」とは、実際にソフトウェアと会話する相手のことであり、ソフトウェアを利用するユーザや開発されたソフトウェアと連帯する他のソフトウェアのことをいう。

一方、「論理ビュー」は、「ユースケース・ビュー」で抽出した機能をいかに実現するか、即ち、ソフトウェアの内部を記述したものである。この「論理ビュー」は、主に、ソフトウェア設計者とソフトウェア開発者のためのものであり、ソフトウェアの内部は静的な構造と動的な協調関係によって記述される。

「ユースケースビュー」は、さらに、「ビジネスユースケースモデル」と「ユースケースモデル」とに分類されている。「ビジネスユースケースモデル」は、ソフトウェアの機能の一覧をモデルで記述したものである。一方、「ユースケースモデル」は、顧客の当該ソフトウェアに対する要求を表現するモデルである。「ユースケースモデル」は、さらに、「アクタ」、「ユースケース」、「シミュレーションを制御」、「シミュレーション状況を記録」、「シミュレーション内の演算を実行」及び「シミュレーション状況を表示」に分類されている。

「ユースケース」は、開発対象のソフトウェアが業務上どのように利用されるのかという点に着目して、ソフトウェアの稼働時にアクタが行う一連のアクション（イベント）等を、一連のまとまりのある処理であるトランザクションごとに各構成要素が明確になるように自然言語で記述したものである。

一方、「論理ビュー」は、さらに、「ビジネスオブジェクトモデル」と「設計モデル」とに分類されている。このうち、「設計モデル」は、「レイヤ」、「プロセスビュー」及び「ユースケースの実現」に分類されている。「ビジネスオブジェクトモデル」は、ビジネスの実体の相互作用を表現したものである。ここで、ビジネスの実体とは、ビジネスのプロセスに現れる行為者やその行為者の生産物のことをいう。

また、図３及び図４において、ユースケース図１２は、システムの動的な構造を表すために記述する振る舞い図の一種であり、外部環境とシステムの機能との関係を記述するものである。このユースケース図１２において、楕円で示した部分はそれぞれ単位要求仕様のユースケースを示し、人の形をした部分はアクタであるオペレータを示している。ログ１３は、処理の内容をその処理した時刻とともに記録したものである。

ただし、ユースケース図１２は、上記したように、あくまで開発すべきソフトウェアが果たす機能についてを表現するものであるから、各機能の概要等はユースケース記述によって表現される必要がある。そこで、ソフトウェア開発者は、作成されたユースケース図１２に基づいて、各ユースケース図の概要、ユースケース図の中では表現できない処理をユースケース記述として整理するために、操作部３を操作して、ユースケース記述の作成を指示する（図２のステップＳＰ２）。

図５は、ユースケース記述の一例を示す図、図６は、図５に示すユースケース記述を含む表示例がノートパソコンからなる要求仕様作成支援装置１の表示部４に表示された例を示す図である。ユースケース記述には、基本機能の概要、実行条件、基本的な処理の流れ、エラー時の処理、終了条件などが記載される。図５及び図６の例は、図３及び図４に示す「シミュレーション状況を表示」という「ユースケースモデル」に関するユースケース記述である。このユースケース記述は、（１）概要説明と、（２）事前条件（設定）と、（３）基本フローと、（４）代替フローと、（５）例外フローと、（６）事後条件と、（７）特殊要件とから構成されている。

次に、ソフトウェア開発者は、開発すべきシミュレーション・ソフトウェアに対して顧客が要求する機能・項目を記述した仕様書と、ステップＳＰ１で作成されたユースケース図と、ステップＳＰ２で作成されたユースケース記述とに基づいて、操作部３を操作して、一連の作業を構成するアクティビティ間の関係を記述するアクティビティ図の作成を指示する（図２のステップＳＰ３）。

図７は、アクティビティ図を含む表示の一例を示す図、図８は、図７に示す表示がノートパソコンからなる要求仕様作成支援装置１の表示部４に表示された例を示す図である。図７及び図８に示す表示は、ツリー２１と、アクティビティ図２２と、ログ２３とから構成されている。ツリー２１は、図３及び図４に示すツリー１１と同じものであり、「ユースケースビュー」の一部と「論理ビュー」の大部分が示されている。また、ログ２３も、図３及び図４に示すログ１３と同じものである。

図７及び図８に示すアクティビティ図２２には、図３及び図４に示すユースケース図１２の中に表現されているモデル（アクタ）と機能との間でどのような処理の流れとなるのかが表現されている。即ち、図７及び図８に示すアクティビティ図２２の例では、開発すべきシミュレーション・ソフトウェアにおいて、初期設定後、役割判定が行われ、表示部の役割と判定された場合には、表示部では、シミュレーション表示処理が行われることを示している。一方、シミュレーション（Sim）制御・記録部の役割と判定された場合には、シミュレーション（Sim）制御・記録部では、シミュレーション及びその記録処理が行われることを示している。また、運動計算部の役割と判定された場合には、運動計算部では、シミュレーションの運動計算処理が行われることを示している。

次に、ソフトウェア開発者又は顧客は、表示部４に表示された図７及び図８に示すアクティビティ図２２を参照して、顧客が要求する機能ごとの処理の流れに矛盾がないか、顧客が処理上必要する情報が抜けていないか、不足している部分がないか、処理の流れ（運用の流れ）に過不足はないかを確認する。この場合、ソフトウェア開発者又は顧客は、必要に応じて、操作部３を操作して、図７及び図８に示すアクティビティ図２２の中に、不明確な点について、コメント又は質問内容３１〜３３を追記する（図２のステップＳＰ４）。図９は、コメント又は質問内容３１〜３３の追記方法を説明するポップアップ３４が表示された図である。

図７〜図９において、コメント又は質問内容３１には、「Ｑ１．記録先は？、Ｑ２．記録先の空き容量の確認は行わないのか？、Ｑ３．エラー処理はここに記述しないのか？」と記載されている。コメント又は質問内容３２には、「Ｑ４．終了処理は各処理ともすべて共通化？、Ｑ５．ここで同期を取る理由は？」と記載されている。また、コメント又は質問内容３３には、「Ｑ６．イベントは計算処理からだけでよいか？、Ｑ７．逆の流れはないか？」と記載されている。さらに、図９に示すポップアップ３４には、「コメントや質問内容ほかを色分けし表示する。質問の場合は、設計を進める上での疑問点や記述されている内容の矛盾などを明確にする。」と記載されている。

このように、図７及び図８に示すアクティビティ図２２には、図３及び図４に示すユースケース図１２の中に表現されているモデル（アクタ）と機能との間でどのような処理の流れとなるのかが表現されている。従って、ステップＳＰ４の要素仕様検討処理では、ソフトウェア開発者は、アクティビティ図２２に表現されているモデル（アクタ）と機能との間における処理の流れの中において、必要な情報は何か、どのタイミングで当該処理を行うのかなどについて、確認することができる。

一方、顧客は、ステップＳＰ４の要素仕様検討処理では、自己が要求する機能がどのような計算式でどのような情報に基づいて処理されているか、その処理がシステム運用上に妥当な処理か否かについて確認することができる。また、ソフトウェア開発者及び顧客は、相互に不明確な点について、ポップアップ３４による案内に従って、アクティビティ図２２の中に、コメント又は質問内容３１〜３３として追記することができる。これにより、ソフトウェア開発者及び顧客は、相互に情報交換することが可能となり、異なる視点で要素仕様を検討することができる。

以上説明した要素仕様検討処理を行った以降は、ソフトウェア開発者は、クラス設計やコンポーネント設計などを進める際に、上記ステップＳＰ１〜ＳＰ３の処理で作成されたユースケース図、ユースケース記述及びアクティビティ図から得られるデータを利用することができる。また、当該ソフトウェア開発者、当該顧客の他、他のソフトウェア開発者や他の顧客が以上説明した要求仕様作成支援プログラムと同様の要求仕様作成支援プログラムを用いることにより、上記ステップＳＰ１〜ＳＰ３の処理で作成されたユースケース図、ユースケース記述及びアクティビティ図から得られたデータの共有化を図ることができる。

このように、本発明の実施の形態１によれば、要求仕様を固める段階（設計の前段階）において、開発すべきソフトウェアに対する顧客の要求をＵＭＬを用いてユースケース図、ユースケース記述及びアクティビティ図に図式化するとともに、アクティビティ図を用いて、要求される機能の洗い出し、要求される機能の不明点の明確化、顧客とソフトウェア開発者との考え方のレベルあわせ（意識あわせ）を行っている。これにより、ソフトウェア開発者は、顧客との意思の疎通を図ることが可能となり、ソフトウェア開発の前段階において、開発すべきソフトウェアに対する顧客の要求をより明確かつより具体的にソフトウェア開発に取り込むことができる。この結果、後戻りにかかる工数を抑えることができる。一方、顧客は、開発すべきソフトウェアに対して、要求した機能が盛り込まれていることを直接確認することができるため、現在ソフトウェア開発者が作成しているソフトウェアへの不安を解消することができる。

また、本発明の実施の形態１によれば、要求仕様記述支援装置１において要求仕様作成支援プログラムを起動することにより、顧客と直接面談しながら、顧客が開発すべきソフトウェアに要求する各機能の細部内容の調整を行うことも可能であるため、この顧客との検討時間を有効に利用することができる。さらに、本発明の実施の形態１によれば、国際標準化された表記言語であるＵＭＬを用いているため、作成されたユースケース図、ユースケース記述及びアクティビティ図から得られたデータについて、要求分析から設計、製造ひいては試験までの流れの中で、共通化、標準化を図ることができる。

以上、本発明の実施の形態について図面を参照して詳述してきたが、具体的な構成はこの実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計の変更等があっても本発明に含まれる。
例えば、上述の実施の形態では、要求仕様を検討する際に、アクティビティ図を用いる例を示したが、これに限定されず、オブジェクト間のメッセージの送受信関係を時系列で記述するシーケンス図を用いても良い。

また、上述の実施の形態では、本発明をシミュレーション・ソフトウェアの開発に適用する例を示したが、これに限定されず、本発明は、通信インターフェイスを有するソフトウェアや組み込み用信号処理モジュールを用いたソフトウェアの開発にも適用することができる。
また、上述の実施の形態では、本発明をソフトウェアの開発に適用する例を示したが、これに限定されず、本発明は、ソフトウェア以外のシステムの開発にも適用することができる。

本発明の実施の形態に係る要求仕様作成支援装置の概略構成を示すブロック図である。 図１に示す要求仕様作成支援装置が実行する要求仕様作成支援処理を説明するためのフローチャートである。 ユースケース図を含む表示の一例を示す図である。 図３に示す表示が要求仕様作成支援装置の表示部に表示された例を示す図である。 ユースケース記述の一例を示す図である。 図５に示すユースケース記述を含む表示例が要求仕様作成支援装置の表示部に表示された例を示す図である。 アクティビティ図を含む表示の一例を示す図である。 図７に示す表示が要求仕様作成支援装置の表示部に表示された例を示す図である。 要素仕様検討処理におけるコメント又は質問内容の追記方法を説明するポップアップが表示された図である。

符号の説明

１ 要求仕様作成支援装置
２ 制御部（第１〜第４の作成手段）
３ 操作部
４ 表示部
５ 通信制御部
６ 記憶部
１１，２１ ツリー
１２ ユースケース図
１３，２３ ログ
２２ アクティビティ図
３１〜３３ コメント又は質問内容
３４ ポップアップ

Claims (7)

1. 開発するシステムが果たすべき機能をＵＭＬを用いて表現するユースケース図を作成する第１のステップと、
   前記開発するシステムが果たすべき基本機能の概要及び基本的な処理の流れを含むユースケース記述を作成する第２のステップと、
   前記開発するシステムに要求される機能及び機能と、前記ユースケース図と、前記ユースケース記述とに基づいて、アクティビティ図又はシーケンス図を作成し、表示する第３のステップと、
   表示された前記アクティビティ図又はシーケンス図とともに、操作部の操作により入力された文字を表示する第４のステップと
   を有することを特徴とする要求仕様作成支援方法。
2. 前記第１のステップでは、前記開発するシステムが果たすべき機能について、前記ユースケース図に、基本的な機能から順次細分化して表現することを特徴とする請求項１に記載の要求仕様作成支援方法。
3. 前記第４のステップでは、前記文字の入力の仕方について説明した案内を表示することを特徴とする請求項１又は２に記載の要求仕様作成支援方法。
4. コンピュータに請求項１乃至３のいずれかに記載の機能を実現させるための要求仕様作成支援プログラム。
5. 表示部と、
   操作部と、
   前記操作部の操作により入力されるデータに基づいて、開発するシステムが果たすべき機能をＵＭＬを用いて表現するユースケース図を作成する第１の作成手段と、
   前記操作部の操作により入力されるデータに基づいて、前記開発するシステムが果たすべき基本機能の概要及び基本的な処理の流れを含むユースケース記述を作成する第２の作成手段と、
   前記操作部の操作により入力される前記開発するシステムに要求される機能及び機能と、前記ユースケース図と、前記ユースケース記述とに基づいて、アクティビティ図又はシーケンス図を作成し、前記表示部に表示する第３の作成手段と、
   前記表示部に表示された前記アクティビティ図又はシーケンス図とともに、前記操作部の操作により入力された文字を表示する第４の作成手段と
   を有することを特徴とする要求仕様作成支援装置。
6. 前記第１の作成手段は、前記開発するシステムが果たすべき機能について、前記ユースケース図に、基本的な機能から順次細分化して表現することを特徴とする請求項５に記載の要求仕様作成支援装置。
7. 前記第４の作成手段は、前記文字の入力の仕方について説明した文を前記表示部に表示することを特徴とする請求項５又は６に記載の要求仕様作成支援装置。

Images