JP2003256205A - ソフトウェア設計要件抽出支援方法、ソフトウェア設計要件決定支援方法、ソフトウェア設計支援方法、およびプログラム - Google Patents

Abstract

(57)【要約】 【課題】 多様な非機能要求を設計の根拠として設計に
反映可能なソフトウェア設計要件抽出支援方法、および
抽出した設計要件を分類整理して採用すべき設計要件を
効率的に決定可能なソフトウェア設計要件決定支援方
法、を提供する。 【解決手段】 顧客等からの要求は、機能要求項目Ｄ１
１と非機能要求項目Ｄ１２とに分類して入力、記録され
る（Ｓ１１０）。機能要求項目とアーキテクチャ特性項
目Ｄａの各組み合わせについてリスク項目Ｄ２１を抽
出、記録し、各リスク項目について、全ての非機能要求
項目を個別に対比させ、可能性Ｄ２２、許容度Ｄ２３、
対策案Ｄ２４を抽出、記録する（Ｓ１２０）。対策案Ｄ
２４を分類整理して、現時点で重要な対策案Ｄ３１と重
要でない対策案Ｄ３２を抽出、記録し（Ｓ１３０）、重
要な対策案の関係Ｄ４を抽出、記録する（Ｓ１４０）。
関係に基づいて対策案の取捨選択を行い、採用すべき対
策案を決定する（Ｓ１５０）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェアのア
ーキテクチャ設計を行う場合に、機能要求だけでなく、
非機能要求も反映させるための手法に関するものであ
る。

【０００２】

【従来の技術】ソフトウェアのアーキテクチャの設計を
行う際、従来は、機能要求に焦点が当てられ、拡張性を
高くするなどの非機能要求は、それらをどこまで考慮す
るかが設計者のスキルに依存することが多く、必ずしも
設計に反映されるわけではなかった。ソフトウェアアー
キテクチャ設計時に、非機能要求をも反映させなけれ
ば、例えば、仕様変更やプラットフォーム変更などの外
的変動が発生した場合に、対応するのが困難なことが多
い。

【０００３】また、ＯＭＴ法（Ｊ．ランボー他著、羽生
田栄一監訳、オブジェクト指向方法論ＯＭＴモデル化と
設計、1992.7 ISBN4-8101-8527-3）などの、オブジェク
ト指向分析／設計技法も、クラスの抽出、クラス間の関
連の抽出などの、マクロなレベルでの作業項目を明示し
ている。しかしながら、従来のオブジェクト指向分析／
設計技法は、将来の外的変動が発生したときに対応しや
すい構成とするための作業項目を明示するものではない
ので、顧客の要求等が変動した場合には、要求を満足す
るソフトウェアを開発するコストが高くなる。

【０００４】

【発明が解決しようとする課題】現在の高度に複雑化し
たシステムでは、単に顧客の要求する機能だけを実現す
ればよいわけではない。その上、顧客の要求自体も曖昧
で、開発が進むにつれて、要求仕様が次第に明らかにな
るというケースも多い。このような、要求の変更などの
外的変動に対応できるようにするためには、発生した要
因が、ソフトウェアのどこの部分に影響を与えるか、ど
のように修正すべきかを、明確に追跡できるようにする
必要がある。

【０００５】そのためには、現状の設計が、「なぜその
ようになっているか」を明確に説明できる必要がある。
なぜなら、仕様変更に強くするには、予め仕様変更を想
定し、それを反映した設計でなければならず、このこと
が、「なぜそのような設計になっているか」という理由
になるからである。したがって、ソフトウェアの設計に
当たっては、様々な変動に対応できるように予め作り込
むことが必要であり、このことが、設計の根拠を重要視
しなければならない理由である。

【０００６】本発明は、以上のような従来技術の課題を
解決するために提案されたものであり、その目的は、外
的変動が発生した場合に、どの部分が影響するか、どの
ように直すべきかを明確化できるようにして、ソフトウ
ェア開発のトータルコストを下げ、また、顧客満足度の
高いソフトウェアを開発できるようにするための優れた
方法を提供することである。

【０００７】すなわち、本発明の第１の目的は、設計対
象ソフトウェアの構成と仕組みに関して作り込むべき設
計要件として、機能要求だけでなく非機能要求をも反映
させた設計要件を効率的に抽出可能とすることにより、
多様な非機能要求を設計の根拠として設計に反映可能な
ソフトウェア設計要件抽出支援方法を提供することであ
る。

【０００８】また、本発明の第２の目的は、機能要求お
よび非機能要求を反映させた設計要件を分類整理して重
要な設計要件のみに限定し、採用すべき設計要件を効率
的に決定可能なソフトウェア設計要件決定支援方法を提
供することである。また、本発明の第３の目的は、機能
要求および非機能要求を反映させた設計要件に基づい
て、多様な外的変動に対応可能なソフトウェアアーキテ
クチャを効率的に設計可能なソフトウェア設計支援方法
を提供することである。

【０００９】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、各機能要求項目についてソフトウェア設
計上で考慮すべき特性を個別に対比させることで機能要
求項目の実現に影響する事象を抽出し、各事象について
非機能要求項目を個別に対比させることで、機能要求だ
けでなく非機能要求をも反映させた設計要件を効率的に
抽出できるようにしたものである。

【００１０】なお、本発明において重要な用語の定義は
次の通りである。「設計要件」は、設計対象ソフトウェ
アの構成と仕組みに関して作り込むべき具体的な要件で
あり、それを実現するために、設計対象ソフトウェアの
具体的な構成と仕組みが決定付けられるような具体的な
内容を表現する情報である。例えば、処理Ａを行える仕
組みを設ける、情報Ｂを保持できる構成にする、部分Ｃ
を変更可能な構成にする、等の情報であるが、情報の表
現形式は何ら限定されない。

【００１１】「機能要求」は、設計されるソフトウェア
に要求される具体的な機能を意味しており、ソフトウェ
アエンジニアリングの分野で一般的に使用されている用
語である。「非機能要求」は、設計されるソフトウェア
に要求される具体的な機能以外の各種の要求を意味して
おり、例えば、性能要求、搭載対象の制約、再利用性、
拡張性、保守性、セキュリティ、使いやすさ、等の各種
の制約や条件を含む広い概念である。この「非機能要
求」もまた、ソフトウェアエンジニアリングの分野で一
般的に使用されている用語である。

【００１２】「ソフトウェア設計を行う上で考慮すべき
特性」は、ソフトウェア設計一般において考慮すべき各
種の特性を意味しており、例えば、ソフトウェアエンジ
ニアリングの分野で一般に定義されている、品質評価の
ための特性である「品質特性」をもとに再構成した、
「アーキテクチャ特性」などを利用できる。アーキテク
チャ特性には、「仕様の安定性」などのアーキテクチャ
特性項目が多数含まれているが、それぞれに、機能要求
項目の実現に影響する事象を誘発させるための質問を定
義している。「ソフトウェア設計を行う上で考慮すべき
特性」は、「アーキテクチャ特性項目」に限らず、定義
済みの他の各種の特性項目、あるいは開発者等が事前に
定義した特性項目なども含む広い概念である。

【００１３】「機能要求項目の実現に影響する事象」
は、対象としている機能要求項目の実現方法に影響を与
えるか、あるいは実現を困難にするような、何らかの事
象を意味しており、一般的にリスクと称される事象を含
むが、それ以外の各種の事象を含む広い概念である。
「ソフトウェアアーキテクチャ」は、ソフトウェアの全
体構造とそれぞれの部分を構成する構成要素間の関係を
表現する情報であり、ソフトウェア全体の設計方針とな
るものである。この「ソフトウェアアーキテクチャ」も
また、ソフトウェアエンジニアリングの分野で一般的に
使用されている用語である。

【００１４】請求項１の発明は、コンピュータを利用し
て、設計対象ソフトウェアの構成と仕組みに関して作り
込むべき設計要件の抽出を支援するソフトウェア設計要
件抽出支援方法において、入力支援ステップ、事象抽出
支援ステップ、設計要件抽出支援ステップ、を含むこと
を特徴としている。ここで、入力支援ステップは、設計
対象ソフトウェアの機能要求項目および非機能要求項目
の入力を支援するステップである。また、事象抽出支援
ステップは、各機能要求項目について、ソフトウェア設
計を行う上で考慮すべき特性として予め用意された特性
を個別に対比させ、対比結果に基づいて機能要求項目の
実現に影響する事象の抽出を支援するステップである。
そしてまた、設計要件抽出支援ステップは、抽出された
各事象について非機能要求項目を個別に対比させ、対比
結果に基づいて非機能要求項目を満足させる設計要件を
抽出するステップである。

【００１５】この方法によれば、各機能要求項目につい
てソフトウェア設計上で考慮すべき特性を個別に対比さ
せることにより、その対比結果に基づいて機能要求項目
の実現に影響する事象を抽出することができる。そし
て、抽出された各事象について非機能要求項目を個別に
対比させることにより、その対比結果に基づいて機能要
求だけでなく非機能要求をも反映させた設計要件を効率
的に抽出することができる。したがって、この方法によ
って得られた設計要件を採用することにより、多様な非
機能要求を設計の根拠として設計に反映させることがで
きる。

【００１６】請求項２の発明は、請求項１のソフトウェ
ア設計要件抽出支援方法において、入力支援ステップ
が、過去のデータに基づいて予め用意した機能要求項目
の候補および非機能要求項目の候補を提示して、設計者
に選択させるステップを含むことを特徴としている。こ
の方法によれば、過去のデータに基づいて予め用意した
候補の中で該当するものがあればそれを選択するだけで
機能要求項目および非機能要求項目を入力できるため、
候補が存在しない要求項目のみを作成するだけで、必要
な全ての要求項目を効率的に入力することができる。

【００１７】請求項３の発明は、請求項１または請求項
２のソフトウェア設計要件抽出支援方法において、事象
抽出支援ステップが、機能要求項目の実現に対する影響
度が予め設定された所定の基準値以上の事象を抽出する
ステップを含むことを特徴としている。この方法によれ
ば、候補として得られる事象の中から影響度が基準値以
上の事象のみを機械的に抽出し、影響度の低い事象を除
去することにより、抽出する事象の数を自動的に少なく
できるため、事象の抽出効率を高めると共に、後続作業
の効率を高めることができる。

【００１８】請求項４の発明は、請求項１乃至請求項３
のいずれかのソフトウェア設計要件抽出支援方法におい
て、設計要件抽出支援ステップが、非機能要求項目の満
足度が予め設定された所定の基準値以上の設計要件を抽
出するステップを含むことを特徴としている。この方法
によれば、候補として得られる設計要件の中から非機能
要求項目の満足度が基準値以上の設計要件のみを機械的
に抽出し、満足度の低い設計要件を除去することによ
り、抽出する設計要件の数を自動的に少なくできるた
め、設計要件の抽出効率を高めると共に、後続作業の効
率を高めることができる。

【００１９】請求項５の発明は、コンピュータを利用し
て、設計対象ソフトウェアの機能要求項目および非機能
要求項目に基づいて設計対象ソフトウェアの構成と仕組
みに関して作り込むべき設計要件として得られた複数の
設計要件の分類整理、およびそれに基づく採用すべき１
つ以上の設計要件の決定を支援するソフトウェア設計要
件決定支援方法において、分類整理支援ステップ、関係
抽出支援ステップ、決定支援ステップ、を含むことを特
徴としている。

【００２０】ここで、分類整理支援ステップは、複数の
設計要件の重要度に応じた分類整理およびそれに基づく
重要な設計要件の抽出を支援するステップである。ま
た、関係抽出支援ステップは、抽出された重要な設計要
件の中から、１つの設計要件の採用が別の設計要件の採
用に影響を与える各種の関係を有する設計要件の各グル
ープの抽出を支援するステップである。そしてまた、決
定支援ステップは、所定の関係を有する設計要件の各グ
ループごとに設計要件の取捨選択を順次行わせ、採用す
べき設計要件の決定を支援するステップである。

【００２１】この方法によれば、機能要求および非機能
要求を反映させた複数の設計要件を分類整理して、相関
の高い複数の設計要件を上位の設計要件に統合する等の
作業を行い、機能要求項目群や現在の作業範囲、作業フ
ェーズ等の詳細度、具体度等によって決定される現時点
での重要性の高い設計要件を抽出することにより、設計
要件をより少ない数の重要な設計要件のみに限定するこ
とができる。そして、そのように限定された重要な設計
要件について、所定の関係を有する設計要件のグループ
ごとに設計要件の取捨選択を順次行うことにより、設計
要件の数を効率的に絞り込むことができる。したがっ
て、この方法によれば、機能要求および非機能要求を反
映させた設計要件を分類整理して重要な設計要件のみに
限定し、限定した設計要件を設計要件間の関係に基づい
てさらに効率的に絞り込むことができるため、採用すべ
き設計要件を効率的に決定することができる。

【００２２】請求項６の発明は、請求項５のソフトウェ
ア設計要件選択支援方法において、決定支援ステップ
が、相反要件選択ステップを含むことを特徴としてい
る。ここで、相反要件選択ステップは、１つの設計要件
を採用すると別の設計要件の採用が困難になるような相
反の関係を有する複数の設計要件が存在する場合に、そ
れらの設計要件について、相反の関係をなくすように現
時点での重要性に応じた取捨選択を行うステップであ
る。

【００２３】請求項７の発明は、請求項５または請求項
６のソフトウェア設計要件決定支援方法において、決定
支援ステップが、類似要件選択ステップを含むことを特
徴としている。ここで、類似要件選択ステップは、１つ
の設計要件を採用すると別の設計要件を採用したのと同
様になるような類似の関係を有する複数の設計要件が存
在する場合に、それらの設計要件について、現時点での
重要性に応じた取捨選択を行うステップである。

【００２４】これらの方法によれば、複数の設計要件が
相反の関係にある場合には、相反の関係をなくすような
取捨選択を行い、複数の設計要件が類似の関係にある場
合には数を少なくするような取捨選択を行うことができ
る。したがって、重要な設計要件として抽出された設計
要件について、設計要件間の関係と現時点での重要性に
応じて適切な取捨選択を順次行うことにより、設計要件
の数を適切かつ効率的に絞り込むことができるため、よ
り少ない数の最も重要な設計要件のみを、採用すべき設
計要件として容易に決定することができる。

【００２５】請求項８の発明は、請求項５乃至請求項７
のいずれかのソフトウェア設計要件決定支援方法におい
て、分類整理支援ステップが、各設計要件の現時点での
重要度が予め設定された所定の基準値以上の設計要件を
抽出するステップを含むことを特徴としている。この方
法によれば、機能要求および非機能要求に基づいて得ら
れた設計要件を分類整理した上で、現時点での重要度が
基準値以上の設計要件のみを機械的に抽出し、重要度が
比較的低い設計要件を除去することにより、抽出する設
計要件の数を自動的に少なくできるため、設計要件の抽
出効率を高めると共に、後続作業の効率を高めることが
できる。

【００２６】請求項９の発明は、コンピュータを利用し
て、設計対象ソフトウェアの機能要求項目および非機能
要求項目に基づいてソフトウェアアーキテクチャの設計
を支援するソフトウェア設計支援方法において、請求項
１の発明における入力支援ステップ、事象抽出支援ステ
ップ、設計要件抽出支援ステップと、請求項５の発明に
おける分類整理支援ステップ、関係抽出支援ステップ、
決定支援ステップに加えて、抽出統合支援ステップを含
むことを特徴としている。ここで、抽出統合ステップ
は、決定された採用すべき設計要件に基づいて、その全
ての設計要件を実現する構成と動作原理の抽出および統
合を支援するステップである。

【００２７】この方法によれば、請求項１、５の方法に
ついて上述した作用と同様の作用が得られることに加え
て、機能要求および非機能要求を反映させた設計要件に
基づいて、多様な外的変動に対応可能なソフトウェアア
ーキテクチャを効率的に設計することができる。

【００２８】なお、請求項１０〜１２の発明は、請求項
１、５、９の発明の方法をそれぞれプログラムの観点か
ら把握したものであり、各プログラムによれば、対応す
る各方法について上述した作用と同様の作用が得られ
る。

【００２９】

【発明の実施の形態】以下には、本発明の実施形態を図
面に沿って具体的に説明する。ただし、ここで記載する
実施形態は、本発明を何ら限定するものではなく、本発
明の一態様を例示するものにすぎない。

【００３０】本発明は、典型的には、コンピュータをソ
フトウェアで制御することにより実現される。この場合
のソフトウェアは、コンピュータのハードウェアを物理
的に活用することで本発明の作用効果を実現するもので
あり、また、従来技術を適用可能な部分には好適な従来
技術が適用される。さらに、本発明を実現するハードウ
ェアやソフトウェアの具体的な種類や構成、ソフトウェ
アで処理する範囲などは自由に変更可能であり、例え
ば、本発明を実現するプログラムは本発明の一態様であ
る。

【００３１】［１．ソフトウェア設計支援方法］図１
は、本発明を適用したソフトウェア設計支援方法の概要
をデータの流れと共に示すフローチャートである。この
図１に示すように、顧客、経営者、プロジェクトマネー
ジャ等のステークホルダからの要求は、設計者により、
機能要求項目Ｄ１１と非機能要求項目Ｄ１２とに分類し
て入力され、記録される（Ｓ１１０）。

【００３２】次に、リスク項目とそれに対する対策案の
抽出を行う（Ｓ１２０）。すなわち、記録された各機能
要求項目Ｄ１１について、予め用意されたアーキテクチ
ャ特性項目Ｄａを順次組み合わせて（Ｓ１２１）、各組
み合わせについてリスク項目Ｄ２１を抽出、記録し（Ｓ
１２２）、各リスク項目Ｄ２１について、全ての非機能
要求項目Ｄ１２を個別に対比させ、可能性Ｄ２２、許容
度Ｄ２３、対策案Ｄ２４を抽出、記録する（Ｓ１２
３）。

【００３３】ここで、「アーキテクチャ特性項目」と
は、ソフトウェアアーキテクチャ設計を行う上で考慮す
べき特性として一般に定義されている「品質特性」をも
とに再構成したもので、ソフトウェアアーキテクチャ設
計を行う上で考慮すべき特性項目を表している。また、
「リスク」とは、本発明における「機能要求項目の実現
に影響する事象」に含まれる概念であり、そのような事
象の中でも、特に、対象としている機能要求項目の実現
に、大きな影響を与えるか、あるいは実現を困難にする
と思われるような、より限定された何らかの事象を意味
している。

【００３４】また、「可能性」は、そのリスクが発生す
るのはどのような場合かについての情報であり、「許容
度」は、そのリスクをどこまで考慮すべきかについての
情報である。また、「対策案」は、本発明における「設
計要件」に含まれる概念であり、ここでは、そのリスク
が発生した場合の対応を容易にするために、どのような
構成、仕組み等を設ければよいかについての情報であ
る。そして、機能要求項目Ｄ１１とアーキテクチャ特性
項目Ｄａの全ての組み合わせについてステップＳ１２１
〜Ｓ１２３を行った時点で次のステップＳ１３０に進
む。

【００３５】ステップＳ１３０においては、記録された
対策案Ｄ２４を分類整理して、現時点で重要な対策案Ｄ
３１と現時点で重要でない対策案Ｄ３２を抽出、記録す
る。次に、記録された「重要な対策案」Ｄ３１につい
て、相反、類似、依存、独立、等の各種の関係のうち、
少なくとも、相反、類似、依存、等の、ある対策案を講
ずることが別の対策案を講ずることに何らかの影響を与
える関係を「重要な対策案の関係」Ｄ４として抽出、記
録する（Ｓ１４０）。

【００３６】ここで、「相反」は、ある対策案を講ずる
と、別の対策案を講ずるのが困難あるいは不可能にな
る、という関係である。また、「類似」は、ある対策案
を講ずると、別の対策案をも講じたことになる、という
関係である。また、「依存」は、ある対策案を講ずるた
めには、別の対策案を講ずることが条件となる、という
関係である。そしてまた、「独立」は、ある対策案を講
じても、別の対策案を講ずることに何ら影響を与えな
い、という関係である。

【００３７】続いて、記録された「重要な対策案の関
係」Ｄ４に基づいて、所定の関係を有する各グループご
とに対策案の取捨選択を行い、ソフトウェアアーキテク
チャ設計に採用すべき１つ以上の対策案を決定する（Ｓ
１５０）。そして、記録された「採用すべき対策案」Ｄ
５に基づいて、各対策案を実現するための構成と動作原
理を順次抽出し、統合することにより、ソフトウェアア
ーキテクチャＤ６を構築し、記録する（Ｓ１６０）。

【００３８】なお、ステップＳ１６０で記録されたソフ
トウェアアーキテクチャＤ６の構成要素群が、実装環境
に依存せずに、その詳細を検討できると判断された場合
（Ｓ１７０）には、それぞれの構成要素群を対象に、上
記ステップＳ１１０〜Ｓ１６０を繰り返す。以下には、
図１を参照しながら、ソフトウェア設計支援方法におけ
る個々のステップの詳細について順次説明する。

【００３９】［１−１．機能要求項目と非機能要求項目
の入力ステップ］機能要求項目と非機能要求項目の入力
ステップＳ１１０においては、設計者が、顧客、経営
者、プロジェクトマネージャ等のステークホルダから与
えられた要求の中から機能的な要求に属するものを抽
出、整理して機能要求項目とすると共に、それ以外のも
のを非機能要求項目として分類し、キーボード等の入力
操作部により入力操作を行うことにより、それらの機能
要求項目Ｄ１１および非機能要求項目Ｄ１２に関する情
報は、コンピュータに入力され、メモリ等の格納部に記
録される。

【００４０】［１−２．リスク項目とそれに対する対策
案等の抽出ステップ］図２は、リスク項目とそれに対す
る対策案等の抽出ステップＳ１２０（ステップＳ１２１
〜Ｓ１２４）の詳細をデータの流れと共に示すフローチ
ャートである。この図２に示すように、まず、入力ステ
ップＳ１１０で記録された機能要求項目Ｄ１１と予め用
意されたアーキテクチャ特性項目Ｄａから、１つの機能
要求項目Ｄ１１と１つのアーキテクチャ特性項目Ｄａか
らなる組み合わせを取り出す（Ｓ２０１）。このステッ
プＳ２０１は、図１のステップＳ１２１に相当する。

【００４１】そして、機能要求項目Ｄ１１とアーキテク
チャ特性項目Ｄａの組み合わせを、類似リスク検索の支
援表示と共に設計者に順次提示してリスク項目の入力支
援を行う（Ｓ２０２）。なお、本実施形態における各種
の入力支援は、基本的に、設計者に対して情報を画面表
示することで行われ、これに音声出力等が適宜組み合わ
せられるようになっている。設計者が検索要求の入力操
作を行うことで、類似リスクの検索要求が入力された場
合（Ｓ２０３のＹＥＳ）には、過去の作業データＤｂか
ら類似したリスクを検索、提示する（Ｓ２０４）。

【００４２】設計者が、提示された機能要求項目Ｄ１１
とアーキテクチャ特性項目Ｄａの組み合わせや過去の類
似データＤｂ等を参照しながら、リスクの検討を行って
リスク項目の作成やその確認等の入力操作を行った場合
（Ｓ２０５のＹＥＳ）には、そのリスク項目Ｄ２１に関
する情報は、コンピュータに入力され、メモリ等の格納
部に記録される（Ｓ２０６）。なお、これらのステップ
Ｓ２０２〜Ｓ２０６は、図１のステップＳ１２２に相当
する。

【００４３】続いて、記録されたリスク項目Ｄ２１を設
計者に提示して可能性、許容度、対策案の入力支援を行
う（Ｓ２０７）。この入力支援にあたってはまた、記録
された非機能要求項目を満足させる「対策案」を得るた
めに、設計者に対して、全ての非機能要求項目Ｄ１２を
示すリストが各リスク項目Ｄ２１と同時に提示される。
設計者が、提示されたリスク項目Ｄ２１と非機能要求項
目Ｄ１２を参照しながら、リスク項目Ｄ２１に対する可
能性Ｄ２２、許容度Ｄ２３、対策案Ｄ２４の検討を行っ
てそれらの情報の作成やその確認等の入力操作を行った
場合（Ｓ２０８のＹＥＳ）には、それらの情報は、コン
ピュータに入力され、メモリ等の格納部に記録される
（Ｓ２０９）。なお、これらのステップＳ２０７〜Ｓ２
０９は、図１のステップＳ１２３に相当する。

【００４４】そして、機能要求項目Ｄ１１とアーキテク
チャ特性項目Ｄａの各組み合わせを順次取り出し、各組
み合わせについてステップＳ２０２〜Ｓ２０９を繰り返
す。最終的に、全ての組み合わせについて上記のステッ
プＳ２０１〜Ｓ２０９を行った（Ｓ１２４のＮＯ、Ｓ２
１０のＮＯ）時点で、次のステップＳ１３０に進む。な
お、このようなリスク項目Ｄ２１とそれに対する対策案
Ｄ２４等の抽出ステップは、記録された非機能要求項目
Ｄ１２をブレイクダウンすることと、潜在的な非機能的
な要求を漏れなく抽出するために行うものであるため、
対策案Ｄ２４は、その詳細度、粒度にはあまり左右され
ることなく、広い視野で漏れなく抽出することが望まし
い。

【００４５】［１−３．対策案の分類整理、重要な対策
案の抽出ステップ］図３は、対策案の分類整理、重要な
対策案の抽出ステップＳ１３０の詳細をデータの流れと
共に示すフローチャートである。この図３に示すよう
に、まず、ステップＳ１２０で記録された全ての対策案
Ｄ２４のリストを設計者に提示して入力支援を行う（Ｓ
３０１）。設計者が、相関の高い複数の対策案の選択や
その確認等の入力操作を行うことで、統合の対象となる
複数の対策案Ｄ２４が指定された場合（Ｓ３０２のＹＥ
Ｓ）には、それらの複数の対策案Ｄ２４を統合対象グル
ープとして並べて提示し、対策案の記述を修正させるた
めの入力支援を行う（Ｓ３０３）。

【００４６】設計者が、提示された複数の対策案Ｄ２４
を参照しながら、統合対象グループに含まれる対策案の
全てを包括するような上位の対策案に統合する形で、対
策案の記述の修正やその確認等の入力操作を行った場合
（Ｓ３０４のＹＥＳ）には、元となったグループの複数
の対策案がリスト中で削除され、それらを包括する上位
の対策案に置き換えられる（Ｓ３０５）。

【００４７】相関の高い対策案Ｄ２４の統合が終了する
かあるいはそのような統合の対象となる複数の対策案Ｄ
２４が存在せず、統合が不要である場合（Ｓ３０６のＹ
ＥＳ）には、設計者は、対象の機能要求項目群の具体
度、現在の作業範囲、作業フェーズ等の詳細度や具体度
に適合する対策案の検討のみを行う。このような検討に
基づき、設計者が、現在のフェーズで考慮すべき対策案
としての選択やその確認等の入力操作を行った場合（Ｓ
３０７のＹＥＳ）には、設計者の選択結果に応じて、設
計者によって選択された対策案Ｄ２４は現時点で「重要
な対策案」Ｄ３１として、また、選択されなかった対策
案Ｄ２４は現時点で「重要でない対策案」Ｄ３２とし
て、メモリ等の格納部にそれぞれ記録される（Ｓ３０
８）。

【００４８】すなわち、設計者によって現在のフェーズ
で考慮すべき対策案として選択されなかった対策案につ
いては、実装する環境に依存した対策案、あるいは、対
象の機能要求項目群の具体度、現在の作業範囲、作業フ
ェーズ等の詳細度、具体度等と比べて、詳細度や具体度
が高い対策案、等については、現在のフェーズで考慮す
べきではない対策案である。したがって、これらの対策
案については、現時点で「重要でない対策案」Ｄ３２と
してグルーピングしておき、その対策案を考慮すべき時
点で抽出すればよい。

【００４９】［１−４．重要な対策案の関係抽出ステッ
プ］図４は、重要な対策案の関係抽出ステップＳ１４０
の詳細をデータの流れと共に示すフローチャートであ
る。この図４に示すように、まず、ステップＳ１３０で
記録された現時点で重要な対策案Ｄ３１の全てを示すリ
ストと共に、相反、類似、依存、等の関係を示すシンボ
ル等を示す選択画面を設計者に提示して入力支援を行う
（Ｓ４０１）。設計者が、相反の関係を有する複数の対
策案とその関係の選択やその確認等の入力操作を行うこ
とで、相反の関係を有する複数の対策案Ｄ３１が指定さ
れた場合（Ｓ４０２のＹＥＳ）には、それらの複数の対
策案Ｄ３１を、相反の関係を有する対策案のグループと
して提示して次の入力操作に備える（Ｓ４０３）。

【００５０】同様に、類似の関係を有する複数の対策案
Ｄ３１が指定された場合（Ｓ４０４のＹＥＳ）には、そ
れらの複数の対策案Ｄ３１を、類似の関係を有する対策
案のグループとして提示して次の入力操作に備える（Ｓ
４０５）。そしてまた、依存の関係を有する複数の対策
案Ｄ３１が、依存する側と依存される側を示す依存方向
と共に指定された場合（Ｓ４０６のＹＥＳ）には、それ
らの複数の対策案Ｄ３１を、依存の関係を有する対策案
のグループとして依存方向と共に提示して次の入力操作
に備える（Ｓ４０７）。

【００５１】そして、全ての対策案について、関係の明
確化が終了した時点（Ｓ４０８のＹＥＳ）で、相反、類
似、依存等の、重要な対策案の関係に関する情報は、
「重要な対策案の関係」Ｄ４として、メモリ等の格納部
に記録される（Ｓ４０９）。なお、このステップＳ１４
０は、ソフトウェアアーキテクチャ設計に、どのような
対策を講じていけばよいかを検討しやすくするために行
うものであるため、その観点から必要となる各種の関係
を抽出、記録する。

【００５２】［１−５．採用すべき対策案の決定ステッ
プ］図５は、採用すべき対策案の決定ステップＳ１５０
の詳細をデータの流れと共に示すフローチャートであ
る。この図５に示すように、まず、ステップＳ１４０で
記録された「重要な対策案の関係」Ｄ４に基づいて、相
反の関係を有する「重要な対策案」Ｄ３１の各グループ
を設計者に順次提示して入力支援を行う（Ｓ５０１）。

【００５３】設計者が、提示された対策案の各グループ
について、相反の関係を解消させるために採用しない対
策案の選択やその確認等の入力操作を行うことで、各グ
ループについて採用しない対策案Ｄ３１ａが指定された
場合（Ｓ５０２のＹＥＳ）には、その指定された対策案
Ｄ３１ａに基づいて、採用しない対策案を決定し、重要
な対策案Ｄ３１から削除する（Ｓ５０３）。

【００５４】すなわち、指定された対策案Ｄ３１ａを採
用しない対策案として決定すると共に、その指定された
対策案Ｄ３１ａと類似の関係を有する別の単数または複
数の対策案Ｄ３１ｂ、および指定された対策案に依存す
る別の単数または複数の対策案Ｄ３１ｃについても採用
しないものと決定し、これらの採用しない対策案Ｄ３１
ａ，Ｄ３１ｂ，Ｄ３１ｃを、重要な対策案Ｄ３１から削
除する。

【００５５】次に、削除されずに残った「重要な対策
案」Ｄ３１の中から、類似の関係を有する「重要な対策
案」Ｄ３１の各グループを設計者に順次提示して入力支
援を行う（Ｓ５０４）。設計者が、提示された対策案の
各グループについて、最も重要な対策案の選択やその確
認等の入力操作を行うことで、各グループで最も重要な
対策案Ｄ３１ｄが指定された場合（Ｓ５０５のＹＥＳ）
には、その指定された対策案Ｄ３１ｄを採用する対策案
として決定し、各グループの別の単数または複数の対策
案Ｄ３１ｅを、重要な対策案から削除する（Ｓ５０
６）。

【００５６】続いて、削除されずに残った「重要な対策
案」Ｄ３１の中から、依存の関係を有する「重要な対策
案」Ｄ３１の各グループを設計者に順次提示して入力支
援を行う（Ｓ５０７）。設計者が、提示された対策案の
各グループについて、採用する対策案の選択やその確認
等の入力操作を行うことで、各グループについて採用す
る対策案Ｄ３１ｆが指定された場合（Ｓ５０８のＹＥ
Ｓ）には、その指定された対策案Ｄ３１ｆに基づいて、
採用しない対策案を決定し、重要な対策案Ｄ３１から削
除する（Ｓ５０９）。

【００５７】すなわち、グループ内に指定された対策案
Ｄ３１ｆが依存する別の対策案Ｄ３１ｇがある場合に
は、最終的な依存先となる対策案まで辿る形で、対策案
Ｄ３１ｆが依存する全ての対策案Ｄ３１ｇを採用する対
策案として決定し、指定された対策案Ｄ３１ｆにさらに
依存するような別の対策案Ｄ３１ｈについては、重要な
対策案から削除する。

【００５８】最後に、削除されずに残った「重要な対策
案」Ｄ３１の中から、上記のような、相反、類似、依存
の関係を持たず、他の対策案から完全に独立している対
策案については、個々の対策案を設計者に個別に順次提
示して入力支援を行う（Ｓ５１０）。設計者が、提示さ
れた個々の対策案について、採用の有無やその確認等の
入力操作を行うことで、採用すると指定された対策案Ｄ
３１ｉについては（Ｓ５１１１のＹＥＳ）には、その指
定された対策案Ｄ３１ｉを採用する対策案として決定
し、採用しないと指定された対策案Ｄ３１ｊについて
は、その対策案Ｄ３１ｊを、重要な対策案から削除する
（Ｓ５１２）。

【００５９】そして、以上のような、相反、類似、依
存、独立の関係に基づく対策案の取捨選択が終了した時
点（Ｓ５１３のＹＥＳ）で、削除されずに残った「重要
な対策案」Ｄ３１は、「採用すべき対策案」Ｄ５とし
て、メモリ等の格納部に記録される（Ｓ５１４）。

【００６０】［１−６．対策案を実現する構成と動作原
理の抽出、統合ステップ］図６は、対策案を実現する構
成と動作原理の抽出、統合ステップＳ１６０の詳細をデ
ータの流れと共に示すフローチャートである。この図６
に示すように、まず、ステップＳ１５０で記録された
「採用すべき対策案」Ｄ５に基づいて、全ての「採用す
べき対策案」Ｄ５のリストを設計者に提示して、優先順
位を付けさせるための入力支援を行う（Ｓ６０１）。な
お、ここでは、「採用すべき対策案」Ｄ５として、ｎ個
の対策案Ｄ５１〜Ｄ５ｎが存在するものとする。

【００６１】設計者が、提示されたｎ個の対策案Ｄ５１
〜Ｄ５ｎについて、優先順の選択やその確認等の入力操
作を行うことで、ｎ個の対策案Ｄ５１〜Ｄ５ｎの優先順
位が指定された場合（Ｓ６０２のＹＥＳ）には、既存の
パターンや過去の作業データ等に対する情報検索の支援
表示と共に、その指定された優先順位に基づいて、対策
案Ｄ５１〜Ｄ５ｎを順次提示して、それを実現する構
成、動作原理を入力するための入力支援を行う（Ｓ６０
３）。設計者が、検索要求の入力操作を行うことで、既
存のパターンや過去の作業データの検索要求が入力され
た場合（Ｓ６０４のＹＥＳ）には、既存のアーキテクチ
ャパターンやデザインパターンＤｃ、過去の作業データ
Ｄｂ等の情報を検索、提示する（Ｓ６０５）。

【００６２】設計者が、提示された第１の対策案Ｄ５１
や、既存のパターンＤｃや過去の作業データＤｂ等の情
報を参照しながら、その対策案Ｄ５１を実現する構成、
動作原理を検討し、それらに関する情報の入力操作を行
った場合（Ｓ６０６のＹＥＳ）には、その構成、動作原
理Ｄ６１に関する情報が明確性を有するか否かが判定さ
れる（Ｓ６０７）。

【００６３】すなわち、構成、動作原理に関する情報に
おいて、各構成要素は、役割、責任範囲を明確に定義し
ている必要があるため、そのような明確性を判定して不
明確な場合（Ｓ６０７のＮＯ）には、再入力操作を促す
こと等が行われる。明確性を有する場合（Ｓ６０７のＹ
ＥＳ）には、その構成、動作原理Ｄ６１に関する情報
は、コンピュータに入力され、メモリ等の格納部に記録
される（Ｓ６０８）。なお、構成、動作原理に関する情
報は、ブロック構造図程度（マクロなレベル）でもよ
く、対象が狭い場合には、プログラム言語で設計者が経
験に基づいて作成してもよい。

【００６４】続いて、次の対策案Ｄ５２がある場合（Ｓ
６０９のＹＥＳ）には、その対策案Ｄ５２と情報検索の
支援表示を行うと共に、取得済みの構成、動作原理Ｄ６
１に関する情報を設計者に提示して入力支援を行い（Ｓ
６０３）、Ｓ６０４〜Ｓ６０７によって、その対策案Ｄ
５２を実現するための構成、動作原理Ｄ６２を取得し、
既存の構成、動作原理Ｄ６１に統合する（Ｓ６０８）。
このようにして、優先順位が最下位である第ｎ番目の対
策案Ｄ５ｎまで、同様の作業を行い、構成、動作原理を
統合していく。なお、統合が困難な場合には、その対策
案に対して別の構成、動作原理を抽出するか、最初の対
策案に戻って別の構成、動作原理を抽出するか、あるい
は任意の別のステップに戻ってやり直す等の作業が行わ
れる。

【００６５】そして、抽出、統合された構成、動作原理
が、全ての「採用すべき対策案」を反映した構成、動作
原理になった時点（Ｓ６１０のＹＥＳ）で、顧客の要求
等に応じて動作シナリオを導出し、その動作シナリオ
を、現時点の構成、動作原理上で、各構成要素の責任、
責任範囲から逸脱せず、動作原理から逸脱せずに、動作
させることができるか否かを検証する（Ｓ６１１）。こ
の結果、問題があると判断された場合（Ｓ６１１のＹＥ
Ｓ）に、これを回避する非機能要求項目を抽出できる場
合にはそれを加え、任意のステップからやり直す。そし
て、最終的に問題がないことが検証できた場合（Ｓ６１
１のＮＯ）には、現時点の構成、動作原理をソフトウェ
アアーキテクチャＤ６として記録する（Ｓ６１２）。

【００６６】［１−７．構成要素群に対する繰り返しス
テップの補足説明］以下には、ステップＳ１６０で記録
されたソフトウェアアーキテクチャの構成要素群を対象
とした上記ステップＳ１１０〜Ｓ１６０の繰り返しステ
ップについて補足説明する。まず、ステップＳ１１０の
機能要求項目Ｄ１１は、ステップＳ１６０で構築したソ
フトウェアアーキテクチャＤ６上で、対象の構成要素群
と関連する構成要素群に対して提供する機能要求項目と
なる。これらは、対象の構成要素群の役割、責任範囲
や、ステップＳ１２０で抽出した対策案Ｄ２４から、抽
出する。

【００６７】また、この繰り返し作業において、ステッ
プＳ１２０については、以前の繰り返し作業中の同じス
テップＳ１２０で抽出した対策案Ｄ２４や、ステップＳ
１３０において「現時点で重要でない対策案」としてグ
ルーピングされた対策案Ｄ３２を参考にする。そしてま
た、ステップＳ１６０については、以前の繰り返し作業
の同じステップＳ１６０で構築したソフトウェアアーキ
テクチャＤ６に統合していく。

【００６８】［２．ソフトウェア設計の具体例］以下に
は、上記のような本実施形態によるソフトウェア設計支
援方法を、会議室予約システムのソフトウェアアーキテ
クチャ設計に適用した具体例について説明する。

【００６９】［２−１．機能要求項目と非機能要求項目
の入力ステップ］ここでは、顧客からの要求として、次
のような要求１〜要求６が与えられたものとする。

【００７０】

【表１】（要求１）：オンラインで会議室の予約を行う
ためのシステム。利用者は、端末にログインして会議室
の予約、キャンセル、閲覧を行える。 （要求２）：予約する場合、利用者は、日付、時間帯、
会議室を指定する。端末には、予約できたか否かを表示
する。 （要求３）：キャンセルする場合、利用者は、その利用
者の予約を指定する。キャンセルは、予約を行った利用
者でなければ、キャンセルできないものとする。端末に
は、キャンセルできたか否かを表示する。 （要求４）：閲覧を行う場合、利用者は、会議室を指定
する。端末には、指定された会議室について、操作を行
った日から１ヶ月後までの予約状況を表示する。 （要求５）：端末の画面構成、操作仕様は任意である
が、直感的でわかりやすいユーザインタフェースとす
る。 （要求６）：複数の利用者が同時に、同じ時間、同じ会
議室の予約を行おうとしても、先着順で予約可、予約不
可が決まる。

【００７１】これらの要求１〜要求６に基づいて、機能
的な要求と非機能的な要求を抽出し、機能的な要求につ
いて、設計者がユースケース分析を行うことにより、機
能要求項目および非機能要求項目として、以下の各項目
を抽出し、入力操作する。その結果、これらの情報は、
コンピュータに入力され、メモリ等にデータとして記録
される（Ｓ１１０）。

【００７２】

【表２】（機能要求項目１）：予約を閲覧する （機能要求項目２）：予約する （機能要求項目３）：予約をキャンセルする （非機能要求項目１）：端末からの操作性 （非機能要求項目２）：同時利用の配慮 （非機能要求項目３）：拡張性を重視

【００７３】［２−２．リスク項目とそれに対する対策
案等の抽出ステップ］ここでは、一例として、機能要求
項目１「予約を閲覧する」と、アーキテクチャ特性項目
「仕様の安定性」の組み合わせで、リスク項目とそれに
対する対策案等を抽出する場合について説明する。

【００７４】まず、機能要求項目１「予約を閲覧する」
とアーキテクチャ特性項目「仕様の安定性」に定義され
ている質問であるところの、「機能拡張する可能性があ
るか」、「動作環境が変更される可能性はあるか」、と
いったリスクを伴う個々の状況との組み合わせが設計者
に対して画面表示される（Ｓ２０２）。この場合、類似
リスク検索の支援表示も行われる。これにより、設計者
は、必要に応じて類似リスクの検索要求を行い（Ｓ２０
３）、過去の作業データから類似したリスクを検索、表
示させる（Ｓ２０４）こともできるため、項目の組み合
わせやその類似リスク等の画面表示を同時に参照しなが
ら、リスクの検討を容易に行うことができる。

【００７５】この場合、会議室によっては備えている備
品もあり、それらの情報も表示できるようにするかもし
れない。あるいは、利用者の指示に応じて、表示する項
目数を加減することも考えられる。このような検討に基
づき、設計者は、例えば、次のリスク項目を抽出し、そ
の入力操作を行う（Ｓ２０５）。その結果、これらの情
報は、コンピュータに入力され、メモリ等にデータとし
て記録される（Ｓ２０６）。

【表３】（リスク項目１）：備品等、会議室に応じて表
示する情報が異なる （リスク項目２）：表示する情報が、利用者の希望に応
じて異なる

【００７６】続いて、記録されたリスク項目１、リスク
項目２が、前述した非機能要求項目１〜非機能要求項目
３と共に設計者に対して画面表示され、リスク項目に対
する可能性、許容度、対策案の入力操作の支援が行われ
る（Ｓ２０７）。そのため、設計者は、リスク項目と非
機能要求項目を同時に参照しながら、可能性、許容度、
対策案の検討を容易に行うことができ、非機能要求項目
を反映させた対策案を効率的に抽出することができる。

【００７７】例えば、リスク項目１「備品など、会議室
に応じて表示する情報が異なる」について可能性を検討
すると、会議室に備えられている備品が異なることが一
般的と考えられるので、将来的に仕様変更が発生する可
能性が高い。また、許容度を検討すると、非機能要求項
目１「端末からの操作性」を考慮し、同様の仕様変更が
発生したときに、なるべく柔軟に対応できるように作り
込んでおくことが望ましいと考えられる。そしてまた、
対策案としては、会議室という概念クラスを設け、会議
室に関する情報や操作を隠蔽し、他から透過なアクセス
ができるようにする構成が有効であると考えられる。

【００７８】設計者は、以上のようなリスク項目の抽
出、およびそれに対する対策案等の検討を、機能要求項
目１〜機能要求項目３の各々と、各アーキテクチャ特性
項目との全ての組み合わせについて行うことにより、各
リスク項目に対する可能性、許容度、対策案を抽出し、
その入力操作を行う（Ｓ２０８）。その結果、これらの
情報は、コンピュータに入力され、メモリ等にデータと
して記録される（Ｓ２０９）。この例において、対策案
としては、例えば次のような対策案１〜対策案１５が記
録される。

【００７９】

【表４】（対策案１）：「会議室」という概念クラスを
設け、透過なアクセスができる構成にする （対策案２）：「処理依頼」という共通の処理を行える
仕組みを設ける （対策案３）：利用者の操作に関する部分を、他の部分
と完全に分離した構成にする （対策案４）：予約情報をＤＢＭＳで保持してもよいよ
うに、データの記録処理を抽象化する構成にする （対策案５）：ＯＳに依存する部分を分離する （対策案６）：予約情報等のデータをｅｘｐｏｒｔ可能
な仕組みを設ける （対策案７）：予約情報を多重化して保持できる構成に
する （対策案８）：検索アルゴリズム等を交換可能な構成に
する （対策案９）：従業員ＤＢ等の他のシステムとの連携を
考慮する （対策案１０）：複数の利用者が同時に予約しても整合
性が取れる仕組みを設ける （対策案１１）：データ保持部分をｐｌｕｇ−ｉｎのよ
うに変更可能な構成にする （対策案１２）：会議室や利用者情報を、ｉｍｐｏｒｔ
できるような仕組みを設 ける（対策案１３）：予約や取り消しの仕方を、利用者
が定義できるような仕組みを設ける （対策案１４）：データ検索部分やデータ保持部分を交
換可能な構成を設ける （対策案１５）：様々なユーザインタフェースを定義で
きるようにし、予約処理を透過に扱える構成にする

【００８０】［２−３．対策案の分類整理、重要な対策
案の抽出ステップ］ここでは、上記のように記録された
対策案１〜対策案１５を、ＫＪ法等の手法を用いて分類
整理する。すなわち、まず、対策案１〜対策案１５のリ
ストが設計者に対して画面表示される（Ｓ３０１）た
め、設計者は、現在の作業フェーズで重要な対策案と重
要でない対策案を容易に選択することができる（Ｓ３０
７）。また、重要な対策案のうち、現在のフェーズで重
要な対策案と重要でな相関の高い複数の対策案がある場
合には、それらを容易に選択することができる。設計者
により統合のそれらの対策案が指定される（Ｓ３０２）
と、指定された対策案は、統合対象グループとして並べ
て画面表示される（Ｓ３０３）ため、設計者は、複数の
対策案を同時に参照しながらそれらを包括するような上
位の対策案を容易に作成することができる。

【００８１】設計者によって上位の対策案が作成され、
それを元の対策案の代わりとすることが確認される（Ｓ
３０４）と、元の対策案は削除され、上位の対策案に置
き換えられる（Ｓ３０５）。このような統合作業によっ
て、対策案の数を少なくすることにより、後続の作業を
容易にすることができる。なお、この例において対象と
している作業範囲は、システム全体に関わる部分である
ので、粒度の細かい対策案は現在のフェーズでは考慮す
べきでない、すなわち重要でない対策案としてグルーピ
ングし、それ以外の対策案を、重要な対策案としてグル
ーピングすることになる。例えば、次のような「重要な
対策案１」〜「重要な対策案６」が記録される（Ｓ３０
８）。

【００８２】

【表５】（重要な対策案１）：ユーザインタフェースを
予約情報処理部分と分離する構成にする （重要な対策案２）：各プラットフォームで、ユーザイ
ンタフェースだけを書き直せばよいようにする （重要な対策案３）：予約や取り消し、閲覧の方法が変
更されてもよいように、「処理依頼」という共通の処理
の枠組みを作る （重要な対策案４）：複数の利用者が同時に処理を依頼
しても整合性が取れる仕組みを作る （重要な対策案５）：予約情報を多重化して保持してお
く （重要な対策案６）：システム内部で、データに対する
処理を抽象化する構成にする

【００８３】［２−４．重要な対策案の関係抽出ステッ
プ］ここでは、上記のように記録された「重要な対策案
１」〜「重要な対策案６」の間の関係を抽出する。すな
わち、これらの重要な対策案のリストと関係を表現する
シンボルを含む選択画面を設計者に対して画面表示する
（Ｓ４０１）ことにより、設計者は、相反、類似、依
存、独立、等の観点で対策案間の関係を容易に検討して
指定することができる（Ｓ４０２、Ｓ４０４、Ｓ４０
６）。設計者によって指定された対策案とその関係は、
図７に示すように、画面上でグラフィック画像として表
現させる（Ｓ４０３、Ｓ４０５、Ｓ４０７）ことによ
り、設計者は自らが指定した対策案間の関係を容易に把
握、確認することができる。グラフィック画像で表現さ
れた関係は、設計者によってその内容が確認された後、
「重要な対策案の関係」として記録される（Ｓ４０
９）。

【００８４】なお、図７においては、一例として、重要
な対策案を表示するボックスと関係を示すシンボルとし
ての接続線からなるグラフィック画像表現を示してい
る。すなわち、ボックス間を接続する双方向矢印付きの
直線は、各ボックスによって表現される対策案間に相反
の関係があることを示しており、ボックス間を接続する
矢印のない直線は、各ボックスによって表現される対策
案間に類似の関係があることを示している。また、ボッ
クス間を接続する線がない場合には、各ボックスによっ
て表現される対策案が互いに独立の関係であることを示
している。なお、ここでは、依存の関係は存在していな
いため、図示していないが、例えば、依存先に向けた単
方向矢印付きの直線で表現すること等が可能である。

【００８５】［２−５．採用すべき対策案の決定ステッ
プ］ここでは、記録された「重要な対策案の関係」に基
づいて、「重要な対策案１」〜「重要な対策案６」の中
から、採用すべき対策案を決定する。すなわち、図７に
示すようなグラフィック画像で所定の関係にある対策案
を画面表示する（Ｓ５０１、Ｓ５０４、Ｓ５０７、Ｓ５
１０）ことにより、設計者は、対象となる関係を有する
対策案を容易に対比することができるため、採用する対
策案または採用しない対策案を容易に指定する（Ｓ５０
２、Ｓ５０５、Ｓ５０８、Ｓ５１１）ことができる。

【００８６】図７の例においては、相反の関係を有する
対策案グループとして、まず、「複数の利用者が同時に
処理を依頼しても整合性が取れる仕組みを作る」と、
「予約情報を多重化して保持しておく」とを示す各ボッ
クスとその間を接続する双方向矢印付きの直線を表示す
る（Ｓ５０１）ことにより、設計者は、両方のボックス
を比較して、採用しない対策案を容易に指定することが
できる（Ｓ５０２）。この場合、例えば、コストと重要
度の観点から、「予約情報を多重化して保持しておく」
を採用しない対策案として指定されたものとする。その
結果、この対策案は重要な対策案のリストから削除され
る（Ｓ５０３）。

【００８７】次に、類似の関係を有する対策案グループ
として、図７に示す他の２組のボックスとその間を接続
する直線をそれぞれ表示する（Ｓ５０４）ことにより、
設計者は、線で接続された各グループのボックスを比較
して、各グループで最も重要な対策案を容易に指定する
ことができる（Ｓ５０５）。この場合、例えば、「シス
テム内部で、データに対する処理を抽象化する構成にす
る」と「予約や取り消し、閲覧の方法が変更されてもよ
いように、「処理依頼」という共通の処理の枠組みを作
る」のグループについては、後者が指定され、また、
「各プラットフォームで、ユーザインタフェースだけを
書き直せばよいようにする」と「ユーザインタフェース
を予約情報処理部分と分離する構成にする」についても
また、後者が指定されたものとする。その結果、指定さ
れなかった対策案は重要な対策案のリストから削除され
る（Ｓ５０６）。

【００８８】この例では、以上の作業だけで対策案の取
捨選択が終了する（Ｓ５１３）ため、削除されずに残っ
た３つの対策案が、次のように、「採用すべき対策案
１」〜「採用すべき対策案３」として記録される（Ｓ５
１４）。

【表６】（採用すべき対策案１）：複数の利用者が同時
に処理を依頼しても整合性が取れる仕組みを作る （採用すべき対策案２）：予約や取り消し、閲覧の方法
が変更されてもよいように、「処理依頼」という共通の
処理の枠組みを作る （採用すべき対策案３）：ユーザインタフェースを予約
情報処理部分と分離する構成にする

【００８９】［２−６．対策案を実現する構成と動作原
理の抽出、統合ステップ］ここでは、記録された「採用
すべき対策案」に基づいて、その対策案の全てを実現す
る構成と動作原理を抽出し、統合することにより、ソフ
トウェアアーキテクチャを構築する。すなわち、まず、
記録された「採用すべき対策案１」〜「採用すべき対策
案３」のリストを画面表示する（Ｓ６０１）ことによ
り、設計者は、対象となる対策案を容易に対比すること
ができるため、優先順位を容易に指定する（Ｓ６０２）
ことができる。この例では、例えば、次のような優先順
位が付けられる。

【００９０】

【表７】（採用すべき第１の対策案）：予約や取り消
し、閲覧の方法が変更されてもよいように、「処理依
頼」という共通の処理の枠組みを作る （採用すべき第２の対策案）：ユーザインタフェースを
予約情報処理部分と分離する構成にする （採用すべき第３の対策案）：複数の利用者が同時に処
理を依頼しても整合性が取れる仕組みを作る

【００９１】このように優先順位が指定されると、設計
者に対して、その優先順位に応じて対策案が順次表示さ
れると共に、既存のパターンや過去の作業データ等に対
する情報検索の支援表示も行われる（Ｓ６０３）。これ
により、設計者は、必要に応じて既存のパターンや過去
の作業データの検索要求を行い（Ｓ６０４）、それらの
情報を検索、表示させる（Ｓ６０５）こともできるた
め、各対策案と既存のパターンや過去の作業データ等を
同時に参照しながら、その対策案を実現する構成や動作
原理を容易に検討することができる。この例では、各対
策案について、例えば、次のような検討が行われる。

【００９２】「採用すべき第１の対策案」については、
デザインパターンのＶｉｓｉｔｏｒパターン（Ｅ．ガン
マ 他著、本位田真一 他監訳、オブジェクト指向におけ
る再利用のためのデザインパターン改訂版、1999.11,IS
BN4-7973-1112-6）を適用することが有効と思われる。
依頼処理をＶｉｓｉｔｏｒとし、これがあらゆる依頼を
表現し、依頼に対する処理を隠蔽することで、利用者か
らのあらゆる依頼を、共通に扱えるようにできる。ま
た、これをオブジェクトとすることで、ネットワークを
介した予約処理も、透過に扱うことができる。

【００９３】「採用すべき第２の対策案」については、
ユーザインタフェースを司る部分を設け、これが上記依
頼処理に処理を委譲するという構成にすることで、実現
することができる。「採用すべき第３の対策案」につい
ては、複数の依頼処理が発生しても、実際に処理を開始
できる権限を与える部分が、システム全体で１つだけ存
在する構成にすることで対応できると考えられる。全て
の予約情報という１つのブロックを設け、これに依頼処
理が処理を開始する権限を与えられるようにすれば、十
分である。

【００９４】設計者が、このような各対策案についての
検討結果を統合した構成、動作原理の入力操作を行うこ
とにより、これらの構成、動作原理は、ソフトウェアア
ーキテクチャを構築する情報として、メモリ等に記録さ
れる（Ｓ６０３〜Ｓ６１０）。この例では、構築された
ソフトウェアアーキテクチャをＵＭＬで記述すると、図
８に示すようになる。また、ソフトウェアアーキテクチ
ャの構成要素である各クラスの役割の定義は、次のよう
になる。

【００９５】

【表８】（画面）：利用者からの操作を受け付け、その
結果を利用者に提示する役割がある。利用者の操作を反
映した処理依頼オブジェクトを生成し、処理を処理依頼
オブジェクトに委譲し、依頼結果を、画面を通して利用
者に提示する。 （処理依頼）：利用者の操作に応じた要求を保持し、そ
の要求に応じて、予約情報を操作する。 （予約情報）：会議室や利用者、予約等の情報を保持す
る。処理依頼オブジェクトだけが操作でき、また、処理
依頼オブジェクトへ操作の権利を与えることができる。

【００９６】このソフトウェアアーキテクチャで、前述
した機能要求項目や非機能要求項目を実現できることを
確認できるため、これを構築したソフトウェアアーキテ
クチャとして記録する（Ｓ６１１、Ｓ６１２）。なお、
この例では、３つの比較的シンプルな対策案だけを示し
ているため、構成、動作原理の統合も一度に可能である
が、実際には、多数の対策案が存在する場合がほとんど
であり、各対策案について、構成や動作原理の抽出や統
合が順次行われる。

【００９７】［２−７．本手法で構築されたソフトウェ
アアーキテクチャ］上記のステップで記録されたソフト
ウェアアーキテクチャは、３つの構成要素から構成され
ており、それぞれの構成要素について詳細化可能である
（Ｓ１７０）ため、各構成要素を対象に、ステップＳ１
１０〜Ｓ１６０を繰り返す。２回目の繰り返しステップ
において、機能要求項目は、上記のステップＳ１６０で
定義した役割を元に、改めて詳細を検討することにな
る。この例では、各構成要素について各ステップを繰り
返し、ソフトウェアアーキテクチャを統合することによ
り、最終的に、図９に示すソフトウェアアーキテクチャ
が得られる。このソフトウェアアーキテクチャの構成要
素である各クラスの役割の定義は、次のようになる。

【００９８】

【表９】（会議室）：会議室固有の情報を保持する。会
議室固有の情報とは、１つの会議室の、名前、場所、収
容人数、設備等である。 （利用者）：利用者固有の情報を保持する。利用者固有
の情報とは、名前、所属、役職等である。 （予約）：予約情報を保持する。予約情報とは、予約し
た会議室（会議室オブジェクト）と、予約者（利用者オ
ブジェクト）、予約日時である。 （日時）：日時情報を保持する。日時情報とは、特定の
日の特定の時間帯、毎週水曜日の特定の時間帯、等、日
時に関するあらゆる表現を可能とする。必ず、新たな予
約が発生すると共に、日時オブジェクトが作られる。こ
のオブジェクトによって、予約の、日時に関する情報を
表現する。 （依頼窓口）：依頼オブジェクトを受け付け、予約、会
議室、利用者、の各オブジェクトに対する操作権を決定
する。依頼窓口オブジェクトは、１システムに１つだけ
存在する。分散環境のための、代理窓口という役割も持
つ。依頼窓口オブジェクトが、予約オブジェクトを生成
したり、操作したりすることはない。 （依頼）：利用者からの依頼内容と、それに応じた処理
を表現するための抽象クラスである。依頼内容とは、会
議室の予約や取り消しに関する情報である。処理とは、
予約、会議室、利用者、の各オブジェクトの生成、変
更、削除、検索等である。この派生クラスに、具体的な
依頼とその処理手順を示したクラス群が存在する。 （依頼結果）：依頼によって行われた処理の結果を表現
するための抽象クラスである。結果とは、依頼の成功、
失敗や、その詳細等である。依頼結果オブジェクトは、
それが利用者にどのように提示されるかは知らない。こ
の派生クラスに、具体的な依頼結果を表現したクラス群
が存在する。 （画面）：利用者からの操作を受け付け、その結果を利
用者に提示する。利用者の操作に応じて、適切な依頼オ
ブジェクトを生成し、これを依頼窓口オブジェクトに渡
す。依頼結果オブジェクトを受け取り、その内容を利用
者に画面を通して提示する。

【００９９】この本手法により構築されたソフトウェア
アーキテクチャ上で、典型的な処理の流れは、次のよう
になる。 （１）画面オブジェクトは、利用者の要求を受け付け、
その内容に見合った依頼オブジェクトを生成し、これを
依頼窓口オブジェクトに渡す。 （２）依頼窓口オブジェクトは、受け取った依頼オブジ
ェクトに、予約、会議室、利用者、の各オブジェクトに
対するアクセス権を与えると共に、これらのオブジェク
トへの操作を委譲する。 （３）依頼オブジェクトは、自身が保持する依頼内容に
したがって、予約、会議室、利用者、の各オブジェクト
を操作し、その結果として、適切な依頼結果オブジェク
トを生成する。 （４）依頼結果オブジェクトは、依頼窓口オブジェクト
を経由して、画面オブジェクトに渡し、画面オブジェク
トは、依頼結果オブジェクトが保持する情報にしたがっ
て、利用者に結果を提示する。

【０１００】［２−８．従来手法で構築されたソフトウ
ェアアーキテクチャ］ここでは、本手法と比較するため
に、顧客からの上記の要求１〜要求６に対して、従来手
法でソフトウェアアーキテクチャを構築した場合につい
て、説明する。まず、予約については、日時、時間帯、
会議室を指定して行う仕様となっており、また、閲覧
は、会議室を指定して行う仕様となっている。したがっ
て、「特定の会議室」に、「予約した利用者」と、「日
付と時間帯」に関する情報を付加して記録すれば十分で
ある。

【０１０１】キャンセルは、利用者の予約を指定する仕
様なので、上記の情報が特定できれば十分である。ま
た、実際の依頼処理は、予約、キャンセル、閲覧で、そ
れぞれが具体的に行う処理を仕様として定めることがで
きる。したがって、従来手法によれば、図１０に示すよ
うなソフトウェアアーキテクチャで、顧客要求を満足す
ることができる。この従来手法で構築されたソフトウェ
アアーキテクチャの各クラスの定義は、次のようにな
る。

【０１０２】

【表１０】（会議室）：会議室固有の情報を保持する。
会議室固有の情報とは、１つの会議室の、名前、場所、
収容人数、設備等である。この会議室に対する予約リス
トを保持する。 （利用者）：利用者固有の情報を保持する。利用者固有
の情報とは、名前、所属、役職等である。 （予約）：予約情報を保持する。予約情報とは、予約し
た会議室（会議室オブジェクト）と、予約者（利用者オ
ブジェクト）、予約日時である。 （依頼窓口）：依頼内容を受け付け、予約、会議室、利
用者、の各オブジェクトに対する操作を行う。操作と
は、予約、会議室、利用者、の各オブジェクトの生成、
変更、削除、検索等である。依頼窓口オブジェクトは、
１システムに１つだけ存在する。分散環境のための、代
理窓口という役割も持つ。 （画面）：利用者からの操作を受け付け、その結果を利
用者に提示する。利用者の操作に応じて、その内容を依
頼窓口オブジェクトに渡す。依頼結果の内容を受け取
り、その内容を画面を通して利用者に提示する。

【０１０３】この従来手法により構築されたソフトウェ
アアーキテクチャ上で、典型的な処理の流れは、次のよ
うになる。 （１）画面オブジェクトは、利用者の操作を受け付け、
その内容を依頼窓口オブジェクトに渡す。 （２）依頼窓口オブジェクトは、予約、会議室、利用
者、の各オブジェクトに対するアクセス権を調整し、受
け取った内容にしたがって、これらのオブジェクトを操
作する。 （３）依頼窓口オブジェクトは、依頼結果の内容を画面
オブジェクトに渡し、画面オブジェクトは、受け取った
依頼結果の内容にしたがって、利用者に結果を提示す
る。

【０１０４】［２−９．本手法と従来手法で構築された
ソフトウェアアーキテクチャの比較］以下には、本手法
によって構築された図９のソフトウェアアーキテクチャ
と、従来手法によって構築された図１０のソフトウェア
アーキテクチャにおいて、仕様変更が発生した場合の対
応について具体的に比較する。ここでは、一例として、
「この先３ヶ月間、毎週水曜日の１３時〜１５時、場所
はどこでもよいから予約する」等の、複雑な処理を行え
るようにする仕様変更が発生した場合を想定する。

【０１０５】まず、本手法で構築したソフトウェアアー
キテクチャの場合、次のように容易に対応することがで
きる。 （１）依頼の仕方が追加、変更されるのであるから、そ
れを表現するクラス、つまり、依頼、依頼結果の抽象ク
ラスの派生クラスの追加、変更を行えばよいことが、容
易に導き出される。 （２）実際の追加、変更も、日時オブジェクトを予約ご
とに作っているので、必要に応じて日時クラスの変更、
あるいは派生クラスの追加、を行うことで、依頼クラス
の追加、変更にも容易に対応できる。 （３）各クラスの変更は、他のクラスに影響を与えな
い。 （４）画面クラスの変更は、依頼処理と分離してあるの
で、他との影響を考慮することなく、独立して修正する
ことができる。

【０１０６】これに対して、従来手法で構築したソフト
ウェアアーキテクチャの場合、次のように、仕様変更へ
の対応が困難である。 （１）依頼に関する操作を、依頼窓口クラスが単独で全
て担っているので、依頼窓口クラスの内部を大幅に変更
する必要がある。 （２）仕様変更の大きさにより、依頼窓口クラスの変更
が大がかりになったり、依頼窓口のインタフェースにも
影響を与えることが考えられる。したがって、画面クラ
スにも大きな変更を行う必要性が生じる。 （３）日時を、予約クラスの内部属性としているので、
場合によっては予約クラスにも影響が及ぶことになる。

【０１０７】［３．実施形態の効果］以上のように、本
実施形態の手法によって構築したソフトウェアアーキテ
クチャは、仕様変更に対応しやすいだけでなく、潜在的
な顧客の要求も引き出した上でソフトウェアアーキテク
チャを構築することができるので、ソフトウェア開発の
トータルコストを下げ、顧客満足度の高いソフトウェア
を開発できるようにすることができる。また、本手法に
おける特徴的な各ステップの効果は次の通りである。

【０１０８】まず、リスク項目とそれに対する対策案等
の抽出ステップの効果は次の通りである。すなわち、各
機能要求項目についてアーキテクチャ特性項目を個別に
対比させることにより、その対比結果に基づいて機能要
求項目の実現に大きく影響するかあるいは実現を困難に
するリスク項目を抽出することができる。特に、過去の
作業データ等の検索、提示も行うことにより、過去のデ
ータを利用してリスク項目をより容易に抽出することが
できる。そして、抽出された各リスク項目について非機
能要求項目を個別に対比させることにより、その対比結
果に基づいて機能要求だけでなく非機能要求をも反映さ
せた対策案を効率的に抽出することができる。したがっ
て、このステップによって得られた対策案を採用するこ
とにより、多様な非機能要求を設計の根拠として設計に
反映させることができる。

【０１０９】次に、対策案の分類整理、重要な対策案の
抽出ステップにおいては、機能要求および非機能要求を
反映させた複数の対策案を分類整理して、相関の高い複
数の対策案を上位の対策案に統合する等の作業を行い、
機能要求項目群や現在の作業範囲、作業フェーズ等の詳
細度、具体度等によって決定される現時点での重要性の
高い対策案を抽出している。したがって、このステップ
によれば、後続するステップにおいて対象とする対策案
を、より少ない数の重要な対策案のみに限定することが
できる。

【０１１０】また、重要な対策案の関係抽出ステップに
よれば、重要な対策案の相反、類似、依存、独立の各関
係を順次抽出することができるため、対策案の採用に影
響する全ての関係を効率的に抽出することができる。特
に、対策案とその関係をグラフィック画像として表示す
ることにより、関係の把握、確認を容易に行うことがで
き、作業効率をさらに高めることができる。

【０１１１】そしてまた、採用すべき対策案の決定ステ
ップにおいては、所定の関係を有する対策案のグループ
ごとに対策案の取捨選択を順次行うことにより、対策案
の数を効率的に絞り込むことができる。この場合にも、
関係抽出ステップと同様に、対策案とその関係をグラフ
ィック画像として表示することにより、対策案の関係の
把握やそれに基づく対策案の取捨選択を容易に行うこと
ができる。このステップにおいては、最初に、相反の関
係をなくすような取捨選択を行うことにより、相反の関
係にある一方の対策案を除去すると共に、その対策案と
類似の関係にある対策案や依存する対策案を機械的に削
除することができる上、さらに、残った対策案の中か
ら、類似や依存の関係に応じて、適切な取捨選択を行い
ながら、対策案の数を大幅に少なくすることができる。
したがって、採用すべき対策案の決定効率を高めると共
に、後続作業の効率を高めることができる。

【０１１２】また、対策案を実現する構成と動作原理の
抽出、統合ステップにおいては、機能要求および非機能
要求を反映させた、絞り込まれた数の「採用すべき対策
案」を、その優先順に提示することにより、効率的に構
成と動作原理を抽出、統合して、効率的にソフトウェア
アーキテクチャを構築することができる。特に、既存の
パターンや過去の作業データ等の検索、提示も行うこと
により、それらの情報を利用して、構成と動作原理の抽
出をより容易に行うことができる。

【０１１３】さらに、構築したソフトウェアアーキテク
チャの構成要素が、実装環境に依存せずにその詳細を検
討できるような場合には、各構成要素を対象に、一連の
ステップを繰り返すことにより、詳細度をより高めたソ
フトウェアアーキテクチャを効率的に構築することがで
きる。

【０１１４】［４．他の実施形態］なお、本発明は、前
述した実施形態に限定されるものではなく、本発明の範
囲内で他にも多種多様な形態が実施可能である。

【０１１５】［４−１．既存のデータの自動提示、候補
としての利用］例えば、前記実施形態において、リスク
項目を抽出する際には、検索要求に応じて過去の作業デ
ータから類似したリスクを検索し、提示するようにした
が、検索要求なしに自動的に提示したり、あるいは、提
示した既存のリスク項目を候補としてリスク項目を選択
させたりすること等も可能である。この場合には、設計
者は、既存のリスク項目にないリスク項目のみを作成す
ればよいため、リスク項目の抽出効率を大幅に向上する
ことができる。

【０１１６】また、対策案を実現する構成と動作原理の
抽出の際における既存のパターンや過去の作業データに
ついても同様にそれらの情報を自動提示したり、候補と
して選択させたりすることにより、構成と動作原理の抽
出効率を大幅に向上することができる。さらに、このよ
うな、既存のデータの自動提示やそれを候補として選択
させる等の支援表示を行う手法は、リスク項目に対する
対策案を抽出する際にも同様に適用可能であり、同様の
効果が得られるものである。

【０１１７】そしてまた、機能要求項目や非機能要求項
目を入力する際にも、過去のデータに基づいて予め用意
した機能要求項目の候補や非機能要求項目の候補を提示
して、設計者に選択させることも可能である。この場合
にも、候補が存在しない要求項目を作成するだけで、顧
客等の要求に応じた全ての要求項目を効率的に入力する
ことができる。

【０１１８】［４−２．予め用意した基準値による数の
削減］一方、前記実施形態においては、設計者が作成し
た全てのリスク項目をそのまま記録して、各リスク項目
に対する対策案等を抽出するようにしたが、過去の作業
データ等を利用して、リスク項目による機能要求項目の
実現に対する影響度に関する基準値を予め設定し、その
基準値以上のリスク項目を抽出すること等も可能であ
る。

【０１１９】例えば、候補として得られたリスク項目の
影響度に応じて、影響度が極めて高いものを「影響度
Ａ」、それ以外のものを「影響度Ｂ」として、影響度Ａ
のリスク項目のみを機械的に抽出し、影響度Ｂのリスク
項目を除去することにより、記録するリスク項目の数を
自動的に少なくできる。その結果、リスク項目の抽出効
率を高めると共に、後続作業の効率を高めることができ
る。また、変形例として、「影響度Ｂ」のリスク項目に
ついては、自動的に削除せずに、そのリストを一旦設計
者に提示して残すリスク項目を選択させるようにしても
よい。

【０１２０】同様に、対策案についても、過去の作業デ
ータ等を利用して、非機能要求項目の満足度に関する基
準値を予め設定し、その基準値以上の対策案を抽出する
こと等が可能である。この場合には、候補として得られ
た対策案の中から、非機能要求項目の満足度が基準値以
上の対策案のみを機械的に抽出し、満足度の低い対策案
を除去することにより、抽出する対策案の数を自動的に
少なくできる。その結果、対策案の抽出効率を高めると
共に、後続作業の効率を高めることができる。また、変
形例として、満足度の低い対策案については、自動的に
削除せずに、そのリストを一旦設計者に提示して残す対
策案を選択させるようにしてもよい。

【０１２１】また、抽出された対策案の中から、現時点
で重要な対策案を決定する際にも、同様に、過去の作業
データ等を利用して、対策案の現時点での重要度に関す
る基準値を作業フェーズ等に応じて予め設定し、その基
準値以上の対策案を重要な対策案として抽出すること等
が可能である。この場合には、機能要求および非機能要
求に基づいて得られた対策案の中から、現時点での重要
度が基準値以上の対策案のみを機械的に抽出し、重要度
が比較的低い対策案を除去することにより、抽出する重
要な対策案の数を自動的に少なくできる。

【０１２２】この場合、特に、相反や類似等の所定の関
係を有する対策案の各グループごとにグループ内の各対
策案の現時点での重要度を比較し、重要度の高低に応じ
て取捨選択を行うことにより、設計要件の数を自動的に
さらに少なくできる。その結果、重要な対策案の抽出効
率を高めると共に、後続作業の効率を高めることができ
る。また、変形例として、重要度が比較的対策案につい
ては、自動的に削除せずに、そのリストを一旦設計者に
提示し、重要な対策案として残す対策案を選択させるよ
うにしてもよい。

【０１２３】［４−３．自動化の推進］なお、上述した
ような各種の基準値による評価対象となる「リスク項目
による機能要求項目の実現に対する影響度」、「対策案
による非機能要求項目の満足度」、「現時点での対策案
の重要度」、等は、リスク項目や対策案の作成時に設計
者によって段階評価値等を与えることが考えられる。あ
るいはまた、過去の作業データ等に基づいて、それらの
影響度、満足度、影響度等を表現する値を算出するため
のアルゴリズムを作成して、自動的に求めること等も考
えられる。

【０１２４】同様に、前記実施形態において、設計者に
よる検討対象として記載した各部分は、関連する各種の
データと、各種の統計手法や解析手法等とを有機的に組
み合わせることにより、コンピュータによる対象の自動
判定や自動抽出を行うことが可能である。そのような自
動化を進めることにより、機能要求項目と非機能要求項
目の自動的な分類、入力、リスク項目等の事象とそれに
対する対策案等の設計要件の自動抽出、重要な対策案の
自動選択とその関係の自動抽出、採用すべき対策案の自
動決定、採用すべき対策案を満足するソフトウェアアー
キテクチャの自動構築、等が可能となる。したがって、
本発明の手法は、最終的には、顧客等からの要求を入力
しただけで、機能要求および非機能要求を反映させた設
計要件を自動的に抽出し、そのような設計要件を満足す
るソフトウェアアーキテクチャを自動的に構築できるよ
うにするものである。

【０１２５】

【発明の効果】以上説明したように、本発明によれば、
各機能要求項目についてソフトウェア設計上で考慮すべ
き特性を個別に対比させることで機能要求項目の実現に
影響する事象を抽出し、各事象について非機能要求項目
を個別に対比させることで、機能要求だけでなく非機能
要求をも反映させた設計要件を効率的に抽出できるよう
にしたことにより、多様な非機能要求を設計の根拠とし
て設計に反映可能なソフトウェア設計要件抽出支援方法
を提供することができる。

【０１２６】また、本発明によれば、機能要求および非
機能要求を反映させた設計要件を分類整理して重要な設
計要件のみに限定し、採用すべき設計要件を効率的に決
定可能なソフトウェア設計要件決定支援方法、および、
機能要求および非機能要求を反映させた設計要件に基づ
いて、多様な外的変動に対応可能なソフトウェアアーキ
テクチャを効率的に設計可能なソフトウェア設計支援方
法、を提供することができる。

【図面の簡単な説明】

【図１】本発明を適用したソフトウェア設計支援方法の
概要をデータの流れと共に示すフローチャート。

【図２】図１に示す方法において、リスク項目とそれに
対する対策案等の抽出ステップの詳細をデータの流れと
共に示すフローチャート。

【図３】図１に示す方法において、対策案の分類整理、
重要な対策案の抽出ステップの詳細をデータの流れと共
に示すフローチャート。

【図４】図１に示す方法において、重要な対策案の関係
抽出ステップの詳細をデータの流れと共に示すフローチ
ャート。

【図５】図１に示す方法において、採用すべき対策案の
決定ステップの詳細をデータの流れと共に示すフローチ
ャート。

【図６】図１に示す方法において、対策案を実現する構
成と動作原理の抽出、統合ステップの詳細をデータの流
れと共に示すフローチャート。

【図７】図１に示す方法によって抽出された重要な対策
案の関係の一例を示すデータ表示図。

【図８】図１に示す方法によって構築されたソフトウェ
アアーキテクチャの一例を示す構造図。

【図９】図８に示すソフトウェアアーキテクチャの詳細
度をさらに高めたソフトウェアアーキテクチャの一例を
示す構造図。

【図１０】従来手法によって構築されたソフトウェアア
ーキテクチャの一例を示す構造図。

フロントページの続き (72)発明者 今井 健男 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 加藤 泰志 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 西岡 竜大 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 藤巻 昇 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 深谷 哲司 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B076 DD01 EC07

Claims (12)

【特許請求の範囲】
1. 【請求項１】 コンピュータを利用して、設計対象ソフ
   トウェアの構成と仕組みに関して作り込むべき設計要件
   の抽出を支援するソフトウェア設計要件抽出支援方法に
   おいて、 前記設計対象ソフトウェアの機能要求項目および非機能
   要求項目の入力を支援する入力支援ステップと、 各機能要求項目について、ソフトウェア設計を行う上で
   考慮すべき特性として予め用意された特性を個別に対比
   させ、対比結果に基づいて機能要求項目の実現に影響す
   る事象の抽出を支援する事象抽出支援ステップと、 抽出された各事象について非機能要求項目を個別に対比
   させ、対比結果に基づいて非機能要求項目を満足させる
   前記設計要件の抽出を支援する設計要件抽出支援ステッ
   プと、を含むことを特徴とするソフトウェア設計要件抽
   出支援方法。
2. 【請求項２】 前記入力支援ステップは、過去のデータ
   に基づいて予め用意した機能要求項目の候補および非機
   能要求項目の候補を提示して、設計者に選択させるステ
   ップを含む、ことを特徴とする請求項１に記載のソフト
   ウェア設計要件抽出支援方法。
3. 【請求項３】 前記事象抽出支援ステップは、機能要求
   項目の実現に対する影響度が予め設定された所定の基準
   値以上の事象を抽出するステップを含む、ことを特徴と
   する請求項１または請求項２に記載のソフトウェア設計
   要件抽出支援方法。
4. 【請求項４】 前記設計要件抽出支援ステップは、非機
   能要求項目の満足度が予め設定された所定の基準値以上
   の設計要件を抽出するステップを含む、ことを特徴とす
   る請求項１乃至請求項３のいずれかに記載のソフトウェ
   ア設計要件抽出支援方法。
5. 【請求項５】 コンピュータを利用して、設計対象ソフ
   トウェアの機能要求項目および非機能要求項目に基づい
   て設計対象ソフトウェアの構成と仕組みに関して作り込
   むべき設計要件として得られた複数の設計要件の分類整
   理、およびそれに基づく採用すべき１つ以上の設計要件
   の決定を支援するソフトウェア設計要件決定支援方法に
   おいて、 前記複数の設計要件の重要度に応じた分類整理およびそ
   れに基づく重要な設計要件の抽出を支援する分類整理支
   援ステップと、 抽出された重要な設計要件の中から、１つの設計要件の
   採用が別の設計要件の採用に影響を与える各種の関係を
   有する設計要件の各グループの抽出を支援する関係抽出
   支援ステップと、 所定の関係を有する設計要件の各グループごとに設計要
   件の取捨選択を順次行わせ、採用すべき設計要件の決定
   を支援する決定支援ステップと、を含むことを特徴とす
   るソフトウェア設計要件決定支援方法。
6. 【請求項６】 前記決定支援ステップは、 １つの設計要件を採用すると別の設計要件の採用が困難
   になるような相反の関係を有する複数の設計要件が存在
   する場合に、それらの設計要件について、相反の関係を
   なくすように現時点での重要性に応じた取捨選択を行う
   相反要件選択ステップを含む、ことを特徴とする請求項
   ５に記載のソフトウェア設計要件決定支援方法。
7. 【請求項７】 前記決定支援ステップは、 １つの設計要件を採用すると別の設計要件を採用したの
   と同様になるような類似の関係を有する複数の設計要件
   が存在する場合に、それらの設計要件について、現時点
   での重要性に応じた取捨選択を行う類似要件選択ステッ
   プを含む、ことを特徴とする請求項５または請求項６に
   記載のソフトウェア設計要件決定支援方法。
8. 【請求項８】 前記分類整理支援ステップは、各設計要
   件の現時点での重要度が予め設定された所定の基準値以
   上の設計要件を抽出するステップを含む、ことを特徴と
   する請求項５乃至請求項７のいずれかに記載のソフトウ
   ェア設計要件決定支援方法。
9. 【請求項９】 コンピュータを利用して、設計対象ソフ
   トウェアの機能要求項目および非機能要求項目に基づく
   ソフトウェアアーキテクチャの設計を支援するソフトウ
   ェア設計支援方法において、 前記設計対象ソフトウェアの機能要求項目および非機能
   要求項目の入力を支援する入力支援ステップと、 各機能要求項目について、ソフトウェア設計を行う上で
   考慮すべき特性として予め用意された特性を個別に対比
   させ、対比結果に基づいて機能要求項目の実現に影響す
   る事象の抽出を支援する事象抽出支援ステップと、 抽出された各事象について非機能要求項目を個別に対比
   させ、対比結果に基づいて非機能要求項目を満足させる
   前記設計要件の抽出を支援する設計要件抽出支援ステッ
   プと、 前記複数の設計要件の重要度に応じた分類整理およびそ
   れに基づく重要な設計要件の抽出を支援する分類整理支
   援ステップと、 抽出された重要な設計要件の中から、１つの設計要件の
   採用が別の設計要件の採用に影響を与える各種の関係を
   有する設計要件の各グループの抽出を支援する関係抽出
   支援ステップと、 所定の関係を有する設計要件の各グループごとに設計要
   件の取捨選択を順次行わせ、採用すべき設計要件の決定
   を支援する決定支援ステップと、 決定された採用すべき設計要件に基づいて、その全ての
   設計要件を実現する構成と動作原理の抽出および統合を
   支援する抽出統合支援ステップと、を含むことを特徴と
   するソフトウェア設計支援方法。
10. 【請求項１０】 コンピュータを利用して、設計対象ソ
    フトウェアの構成と仕組みに関して作り込むべき設計要
    件の抽出を支援するためのプログラムにおいて、 前記設計対象ソフトウェアの機能要求項目および非機能
    要求項目の入力を支援する入力支援機能と、 各機能要求項目について、ソフトウェア設計を行う上で
    考慮すべき特性として予め用意された特性を個別に対比
    させ、対比結果に基づいて機能要求項目の実現に影響す
    る事象の抽出を支援する事象抽出支援機能と、 抽出された各事象について非機能要求項目を個別に対比
    させ、対比結果に基づいて非機能要求項目を満足させる
    前記設計要件の抽出を支援する設計要件抽出支援機能
    と、をコンピュータに実現させることを特徴とするプロ
    グラム。
11. 【請求項１１】 コンピュータを利用して、設計対象ソ
    フトウェアの機能要求項目および非機能要求項目に基づ
    いて設計対象ソフトウェアの構成と仕組みに関して作り
    込むべき設計要件として得られた複数の設計要件の分類
    整理、およびそれに基づく採用すべき１つ以上の設計要
    件の決定を支援するためのプログラムにおいて、 前記複数の設計要件の重要度に応じた分類整理およびそ
    れに基づく重要な設計要件の抽出を支援する分類整理支
    援機能と、 抽出された重要な設計要件の中から、１つの設計要件の
    採用が別の設計要件の採用に影響を与える各種の関係を
    有する設計要件の各グループの抽出を支援する関係抽出
    支援機能と、 所定の関係を有する設計要件の各グループごとに設計要
    件の取捨選択を順次行わせ、採用すべき設計要件の決定
    を支援する決定支援機能と、をコンピュータに実現させ
    ることを特徴とするプログラム。
12. 【請求項１２】 コンピュータを利用して、設計対象ソ
    フトウェアの機能要求項目および非機能要求項目に基づ
    くソフトウェアアーキテクチャの設計を支援するための
    プログラムにおいて、 前記設計対象ソフトウェアの機能要求項目および非機能
    要求項目の入力を支援する入力支援機能と、 各機能要求項目について、ソフトウェア設計を行う上で
    考慮すべき特性として予め用意された特性を個別に対比
    させ、対比結果に基づいて機能要求項目の実現に影響す
    る事象の抽出を支援する事象抽出支援機能と、 抽出された各事象について非機能要求項目を個別に対比
    させ、対比結果に基づいて非機能要求項目を満足させる
    前記設計要件の抽出を支援する設計要件抽出支援機能
    と、 前記複数の設計要件の重要度に応じた分類整理およびそ
    れに基づく重要な設計要件の抽出を支援する分類整理支
    援機能と、 抽出された重要な設計要件の中から、１つの設計要件の
    採用が別の設計要件の採用に影響を与える各種の関係を
    有する設計要件の各グループの抽出を支援する関係抽出
    支援機能と、 所定の関係を有する設計要件の各グループごとに設計要
    件の取捨選択を順次行わせ、採用すべき設計要件の決定
    を支援する決定支援機能と、 決定された採用すべき設計要件に基づいて、その全ての
    設計要件を実現する構成と動作原理の抽出および統合を
    支援する抽出統合支援機能と、をコンピュータに実現さ
    せることを特徴とするプログラム。