(57)【要約】【課題】ステークホルダ要求の変更に伴う機能要求に付随する品質要求の変更に関連したアーキテクチャ上の見直し箇所を導出するサービスシステムの設計支援システムを提供する。【解決手段】サービスシステムの設計支援システムに、設計対象サービスシステムのステークホルダ要求について、機能要求と、品質特性情報の特性ごとの区分の品質特性と に分けて登録を受け付ける要求分離手段と、アーキテクチャ情報を参照して、登録された機能要求に紐付け可能な品質特性の実現に寄与する、各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、機能要求に関して変更可能な品質特性の関連付けを保持し、登録された品質特性を設定可能な他の品質特性に変更された際に、品質充足条件を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、アーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段を設ける。【選択図】図１
2019015995.tif 000002
【特許請求の範囲】
【請求項１】
サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて登録を受け付ける要求分離手段と、
サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記要求分離手段で登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段、
を具備することを特徴とするサービスシステムの設計支援システム。
【請求項２】
前記変更支援情報導出手段は、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更後の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の追加設計箇所を導出する、
ことを特徴とする請求項１に記載のサービスシステムの設計支援システム。
【請求項３】
前記要求分離手段は、設計対象の前記サービスシステムに対して入力されるステークホルダ要求の登録について、機能要求毎に、個々の機能要求に対応付けて品質特性の登録を受け付け、
前記変更支援情報導出手段は、個々の機能要求に関して関連付けられているある品質特性を設定可能な他の品質特性に変更された際に、変更された前記ある品質要求の属性に関して、全部の機能要求の変更前の品質特性の実現に用いられていた箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の差異を導出処理する
ことを特徴とする請求項１又は２に記載のサービスシステムの設計支援システム。
【請求項４】
前記変更支援情報導出手段で導出された変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能上の差異をモデル図内に認知可能に出力する修正属性候補出力手段を具備し、
該修正属性候補出力手段は、前記サービスシステムに対して入力された機能要求が複数あった場合のアーキテクチャ上の構成要素の機能上の差異の重複箇所を可視的に認知可能に出力する
ことを特徴とする請求項１ないし３の何れか一項に記載のサービスシステムの設計支援システム。
【請求項５】
前記変更支援情報導出手段は、
前記機能要求に関して 設計変更に伴い変更可能な品質特性を受け付ける設定可能品質特性定義手段と、
前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を、前記設定可能品質特性定義手段で受け付けた設定可能な他の品質特性に変更する入力を受け付ける要求変更手段と、
前記要求変更手段で変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前後の品質要求の実現に寄与していた機能の組み合わせを識別して、変更前後のサービスシステムに関連するアーキテクチャ上の各構成要素の機能の差異が現れる情報を変更支援情報として生成する影響分析手段と、
前記変更支援情報を参照して、前記影響分析手段で抽出された属性をアーキテクチャ情報に反映させてモデル図として出力する修正属性候補出力手段と
から構成されていることを特徴とする請求項１ないし４の何れか一項に記載のサービスシステムの設計支援システム。
【請求項６】
前記アーキテクチャ情報は、各構成要素が持つ機能のうち、各構成要素の特定の接続関係においてサービスシステムの設計上のパラメータとなる接続情報を含み、
前記要求品質充足条件登録手段は、ユーザから登録される前記機能要求に紐付け可能な品質特性の実現に寄与する各構成要素が持つ機能の組み合わせと共に、その構成要素間の接続関係を含めて品質充足条件を記録し、
前記変更支援情報導出手段は、機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、品質特性の変更に関して、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせとその接続関係の一覧を参照して、各構成要素の接続関係の充足条件上の不足箇所及び／又は余分箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の接続関係の差異を導出処理する
ことを特徴とする請求項１ないし５の何れか一項に記載のサービスシステムの設計支援システム。
【請求項７】
前記アーキテクチャ情報の入力をモデルベースで受け付けるアーキテクチャ情報定義手段を更に備えることを特徴とする請求項１ないし６の何れか一項に記載のサービスシステムの設計支援システム。
【請求項８】
前記アーキテクチャ情報定義手段は、設計するサービスシステムを提供するクラウド環境の提供可能な構成要素及び機能に対応させた、モデルベースの構成要素 及び 各構成要素単位で発揮する機能をアーキテクチャ情報として受け付け、
前記変更支援情報導出手段は、変更された品質特性について、変更前後のクラウドベースサービスシステムに関連するアーキテクチャ上の差異を、クラウド環境の構成要素及び機能に対応させて導出する
ことを特徴とする請求項７記載のサービスシステムの設計支援システム。
【請求項９】
設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、予め準備されているサービスシステムの品質を示す特性の一覧を示す品質特性情報に登録されている特性ごとの区分で品質特性と に分けて受け付け、
予め準備されている前記設計対象サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、登録された前記機能要求に紐付け可能な品質特性の実現に寄与する前記アーキテクチャ情報に属性として含まれている各構成要素が持つ機能の組み合わせを品質充足条件として受け付け、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを予め保持すると共に、受け付けた機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する
ことを特徴とする情報処理システムによるサービスシステムの設計支援方法。
【請求項１０】
情報処理システムのプロセッサを、
サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて登録を受け付ける要求分離手段と、
前記設計対象サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記要求分離手段で登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段、
として、動作させることを特徴とするサービスシステムの設計支援用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムに関し、サービスシステムに対するステークホルダ要求を満足する設計解の導出を支援するための技術に関する。
【背景技術】
【０００２】
ＩＴ（Information Technology）サービスシステム（以降「システム」と称する）の開発は、顧客や開発者・保守担当者などの様々なステークホルダの要求を満たすように、システムアーキテクチャを設計する。ここでのシステムアーキテクチャは、システムを構成するコンピュータ機器の構成／構造や人員の配置、運用ポリシーなどを示す。
【０００３】
ＩＴサービスシステムに対するステークホルダの要求は、一般に、機能要求と非機能要求に分類される。機能要求は、システムによって提供される機能（システムの挙動）に関する要求を表す。非機能要求は、機能以外の全般に関する要求を表し、性能や可用性・使いやすさ・セキュリティといったシステムの品質に対する要求 および 技術的・ビジネス的な理由などによって生じる設計上の制約であることが多い。
【０００４】
非機能要求、特に品質に対する要求は、システムを構成するデバイスやソフトウェア、Ｗｅｂ（World Wide Web）製品などの単体要素の機能を組み合わせるだけでなく、それらの要素を過不足なく適切に組み合わせることで満足される。このため、システムの設計者は、システムを実際に構築・導入する前の設計段階で、非機能要求をきちんと満たされているか検証することに高い能力を要求される。
【０００５】
また、システムの使用条件や外部システムとの連携などの要因によって、満たすべき非機能要求の種類や非機能要求の優先順位が変化する。このため、システム設計者は、システムが使用される環境や今後の動向などについても熟慮した上で、適切なアーキテクチャを設計する必要がある。
【０００６】
現状、一般的には、非機能要求と構築するアーキテクチャの関係性は、要件定義書や各種設計文書などの仕様書に明示化されていない。このため、システム設計者は、多くの場合、要件定義書や各種設計文書の中に暗黙的に含まれている非機能要求を、経験や慣習に基づいて読み解いて設計に反映させる。この結果、アーキテクチャ設計解の導出は、個々の開発担当者（システム設計者）の属人的な影響を受けている。
【０００７】
コンピュータシステムのアーキテクチャ設計に関連する技術としては、特許文献１や特許文献２が挙げられる。
【０００８】
特許文献１には、非機能要求の実現に関するリスク項目とその対策案を、機能要求およびアーキテクチャ特性を考慮しながら抽出し、その結果をシステム設計者に提示するソフトウェア設計要件抽出支援方法が記載されている。このソフトウェア設計要件抽出支援方法では、機能要求だけでなく非機能要求についても設計の根拠として反映させ、要求仕様の変更に柔軟に対応できるようにシステム設計者を支援する。
【０００９】
特許文献２には、ソフトウェア開発の成果物（例えば、要求記述文書や設計モデル、プログラムコード）の変更に伴って、その変更の影響を受ける他の成果物を識別して、システム設計者に通知する開発支援装置が開示されている。この開発支援装置は、開発プロセスの各段階で作成される成果物の対応関係を定義したタグ情報を保持して、ある成果物の修正によって影響を受ける他の成果物を、修正された成果物を起点にタグ情報を辿って遡って識別することで、ソフトウェア開発の支援を行う。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許第３８８７５７１号公報
【特許文献２】特開２００７−１２２１３５号公報
【非特許文献】
【００１１】
【非特許文献１】ＩＰＡ，「非機能要求グレード」，２０１０（2015年10月現在、http://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.htmlからアクセス可能）
【非特許文献２】Anthony J. Lattanze（著），橘高 陸夫 他（訳），「アーキテクチャ中心設計手法」，翔泳社，２０１１
【発明の概要】
【発明が解決しようとする課題】
【００１２】
上記したように、現状、非機能要求と構築するアーキテクチャの関係性は、要件定義書や各種設計文書などの仕様書に明示化されていない。このため、システム設計者は、多くの場合、要件定義書や各種設計文書の中に暗黙的に含まれている非機能要求を、経験や慣習に基づいて読み解いて設計に反映させる。
【００１３】
例えば、既存のアーキテクチャ情報を複数の案件で再利用する際に、システムの使用環境の違いによって変更すべき箇所を見極めることに、個々の設計者の能力が発揮される。また、例えば、非機能要求に合致しない既存のアーキテクチャ情報を流用してシステムを構築・導入しようとした場合、設計者の並々ならぬ能力が必要になる。また、非機能要求に合致しないアーキテクチャでシステムを構築してしまった場合、重大な障害やインシデントが引き起こされる可能性がある。これのことを解消する一つの手法に、個々の設計者の属人的な影響を弱めて、アーキテクチャ設計解を導出する手法が望まれる。
【００１４】
また、非機能要求と構築するアーキテクチャの関係性とを踏まえたアーキテクチャ設計手法について、例示した特許文献１や特許文献２では解決できない。
【００１５】
例えば、特許文献１の手法では、抽出できたリスク項目とその対策案を参酌して、ソフトウェアアーキテクチャを設計するプロセスや仕様変更に伴って具体的にどの部分のアーキテクチャを変更すべきかの最終的な判断は、属人的に設計者によって行われる。
【００１６】
また、特許文献２の手法では、要求記述文書に対する修正によって影響を受ける設計モデルや文書自体をトレースして設計者に通知できるものの、その修正の影響が具体的にアーキテクチャのどの部分に生じることを知ることができない。
【００１７】
ステークホルダ要求から識別される非機能要求は、システムの構成要素（例えばコンピュータ、サーバ、クラウドリソース、ネットワークデバイス）の各種機能を組み合わせることで実現される。このような、アーキテクチャ内に横断的に影響を与える品質に係る非機能要求が変更された場合に、アーキテクチャの全体的な見直しが必要となる。
【００１８】
発明者は、アーキテクチャ横断的な影響を生じるステークホルダからの品質要求の変更について、アーキテクチャ内で見直す必要がある設計箇所を自動的に判別する手法を検討する。
【００１９】
このことで、例えば、機能要求が共通であるものの システムの使用環境の違いによって求められる品質レベルが異なるような案件に対して、既存のアーキテクチャ情報の再利用を促進することが期待できる。また、アーキテクチャ情報を流用したシステム設計において、ステークホルダ要求に不適合である結果を事後的に発見するリスクを軽減することが期待できる。
【００２０】
本発明は、上記背景に鑑みて成されたものであり、ステークホルダ要求の変更に伴って機能要求に付随する品質要求を変更した際に、見直す必要があるアーキテクチャ設計箇所を自動的に判別するサービスシステムの設計支援システム、方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明の一実施形態に係るサービスシステムの設計支援システムは、サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて登録を受け付ける要求分離手段と、サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記要求分離手段で登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段を具備することを特徴とする。
【００２２】
本発明の一実施形態に係るサービスシステムの設計支援方法は、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、予め準備されているサービスシステムの品質を示す特性の一覧を示す品質特性情報に登録されている特性ごとの区分で品質特性と に分けて受け付け、予め準備されている前記設計対象サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、登録された前記機能要求に紐付け可能な品質特性の実現に寄与する前記アーキテクチャ情報に属性として含まれている各構成要素が持つ機能の組み合わせを品質充足条件として受け付け、前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを予め保持すると共に、受け付けた機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出することを特徴とする。
【００２３】
本発明の一実施形態に係るサービスシステムの設計支援用プログラムは、情報処理システムのプロセッサを、サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて登録を受け付ける要求分離手段と、前記設計対象サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記要求分離手段で登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段として、動作させることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、ステークホルダ要求の変更に伴って機能要求に付随する品質要求を変更した際に、見直す必要があるアーキテクチャ設計箇所を自動的に判別するサービスシステムの設計支援システム、方法、及びプログラムを提供できる。
【図面の簡単な説明】
【００２５】
【図１】本発明の一実施形態に係るサービスシステムの設計支援システム１を示すブロック図である。
【図２】設計支援システム１の動作例を示すフローチャートである。
【図３】本発明に係る一構成例の設計支援システム２を示すブロック図である。
【図４】（ａ）は品質特性情報の例、（ｂ）はアーキテクチャ情報の例を示す説明図である。
【図５】一構成例の設計支援システム２で用いる品質充足条件一覧を可視的に例示した説明図である。
【図６】変更支援情報生成プロセスを例示するフローチャートである。
【図７】変更支援情報生成プロセスを例示する別のフローチャートである。
【図８】（ａ）はモデル図を用いて追加設計箇所見直し箇所を示した表示画面構築例、（ｂ）はモデル図を用いて見直し箇所を示した表示画面構築例を示した表示画面構築例を示した説明図である。
【図９】モデル図を用いて追加設計箇所及び見直し箇所を示した表示画面構築例を示した説明図である。
【発明を実施するための形態】
【００２６】
［実施形態］ 
本発明の実施形態を図面を参照して説明する。なお、以下の説明のステークホルダは、サービスシステムを直接的に利用するユーザ以外にも、間接的に利用するユーザも含む。ステークホルダを例示すれば、直接的にサービスを享受するコンシューマーユーザが挙げられる。また、システムを用いる顧客企業の業務部門や経営層、システムの運用保守を担当する企業の情報システム部門、システムの設計開発を担うＩＣＴ（Information and Communication Technology）ベンダー自身などが含まれる。ステークホルダ要求は、これら様々な立場のステークホルダからサービスシステムに対してベンダーが受け付ける要望・要求である。
【００２７】
図１は、本発明の一実施形態に係るサービスシステムの設計支援システム１を示すブロック図である。 
図示するように、設計支援システム１は、要求分離部１０と、要求品質充足条件登録部２０と、変更支援情報導出部３０を備える。また、設計支援システム１は、品質特性情報やアーキテクチャ情報にアクセス可能に構築される。図１では、設計支援システム１内に、品質特性情報やアーキテクチャ情報を保持する内部データベースを用いる例を図示している。無論、各種情報は外部データベースでアーキテクチャ情報などを管理することとしてもよい。
【００２８】
品質特性情報は、サービスシステムによって提供される各種機能の品質レベルを測る指標となり得る品質特性（例えば、可用性、性能、セキュリティなど）を分類した一覧である。品質特性情報は、例えば、国際規格（ＩＳＯ９１２６）で定められた品質特性モデルや、非機能要求グレード表（非特許文献１）のメトリクス、アーキテクチャ中心設計手法（非特許文献２）で用いられている品質特性の分類などに従うことが望ましい。品質特性情報は、設計者間で共用することが望ましい。品質特性情報を複数の設計者が共用することで、属人性を弱められる。設計支援システム１は、ユーザから、品質特性情報に含まれる品質特性の区分で、機能要求に関連付く品質要求を満たすための設計対象サービスシステムのアーキテクチャに要求する品質の設定を受け付ける。
【００２９】
アーキテクチャ情報は、設計対象サービスシステムを構成する各構成要素（コンピュータ機器（サーバ、ストレージ、ネットワークスイッチなど）や人的リソースなど）とその接続関係とをモデル化した情報である。アーキテクチャ情報にはまた、構成要素間の接続関係における設計上のパラメータとなる各構成要素が持つ機能単体を有効な属性として、各々の構成要素に紐付けられている。
【００３０】
要求分離部１０は、登録されている品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求とその機能要求に紐付ける品質特性に分けられてユーザから登録を受け付ける。この際、要求分離部１０は、機能要求の品質要求を、品質特性情報に登録されている品質特性の区分でユーザから受け付ける。要求分離部１０は、機能要求に紐付ける品質特性情報の一覧（選択肢）をユーザに提示可能に構成することが望ましい。なお、後述する一構成例では具体的なステークホルダ要求を例示して説明する。要求分離部１０は、ステークホルダ要求の登録について、機能要求が複数あった場合、機能要求毎に、個々の機能要求に対応付けて品質特性の登録を受け付けることが望ましい。
【００３１】
ここではステークホルダ要求を入力するユーザはサービスシステムの設計者を想定するが、顧客自身や関係者自身などにステークホルダ要求を分離且つ区分して入力させてもよい。この場合でも、品質特性を顧客などに品質特性情報の一覧内から選択されることで、ステークホルダ要求と設計するサービスシステムの齟齬を予防できる。
【００３２】
なお、本実施形態では、ステークホルダ要求に含まれる非機能要求は、品質要求と、開発対象のプロジェクトごとに指定される制約に分解されるものとする。この制約については、設計を行う時点での技術レベルやビジネスの状況、法規制などに応じて、変更前後のシステムで共通的（固定）であるとし、本実施形態では情報処理に含めない。他方で、制約もアーキテクチャと共に設計者に提示可能に構成することが望ましい。
【００３３】
要求品質充足条件登録部２０は、アーキテクチャ情報に登録されている各構成要素の個々の属性を選択肢として、ユーザから要求分離部１０で登録された機能要求に紐付け可能な各品質特性の品質充足条件を満たす属性（機能）の組み合わせについてユーザから登録可能に構成される。また、機能要求が複数あった場合、要求品質充足条件登録部２０は、機能要求毎に対応付けられている各品質特性の品質充足条件を満たす属性（機能）の組み合わせについて登録を受け付ける。要求品質充足条件登録部２０は、入力された各品質充足条件を保持して管理する。また、要求品質充足条件登録部２０は、ユーザから登録される機能要求に紐付け可能な品質特性の実現に寄与する各構成要素が持つ機能の組み合わせと共に、その構成要素間の接続関係を含めて品質充足条件を記録することとしてもよい。この品質充足条件は、アーキテクチャ情報と紐付けてデータベース化することが望ましい。
【００３４】
また、要求品質充足条件登録部２０は、アーキテクチャ情報に含まれる各構成要素と各構成要素が持つ属性と各構成要素の接続関係とを、ユーザにモデル図の画像を介して提示可能に構成することが望ましい。また、要求品質充足条件登録部２０は、アーキテクチャ情報に含まれる各構成要素と各構成要素が持つ属性と各構成要素の接続関係とを、テーブル情報若しくはテーブル情報とモデル図で提示可能に構成することとしてもよい。 
このように、ユーザによる個々の品質特性の品質充足条件の登録は、要求分離部１０で登録された機能要求に紐付け可能な品質特性毎に、サービスシステムの構成（アーキテクチャ）に付与する各品質特性を得るための各構成要素の属性が所要数選択されて、紐付けられる。
【００３５】
変更支援情報導出部３０は、要求分離部１０に登録された機能要求に関して、設計変更などに伴い変更可能な品質特性の関連付けを保持する。この機能要求と品質特性の関連付けは、ステークホルダ要求に含まれる機能要求毎に保持することが望ましい。また、変更支援情報導出部３０は、指定可能な品質要求の選択肢に従ってユーザから要求分離部１０で登録された機能要求に関連付けられている品質特性を他の品質特性に変える変更を受け付け可能に構成される。 
この変更可能な品質特性は、要求品質充足条件登録部２０で登録される要求品質充足条件と対応付く。すなわち、設計支援システム１は、ユーザから登録された機能要求に関連付け可能な品質特性の選択肢を保持して、ユーザからその変更を受け付け可能に構成されている。また、設計支援システム１は、この選択肢となる各品質特性について、要求品質充足条件を準備して保持する。
【００３６】
変更支援情報導出部３０は、機能要求に紐付く品質特性がユーザによって変更された際に、品質充足条件を参照して、機能要求及び変更後の品質特性を満たすためのアーキテクチャ内の各構成要素に付与する機能の設計箇所を導出処理する。この導出処理では、変更前の品質要求の実現に寄与していた機能の組み合わせを品質充足条件から探索して、識別した機能上の差異を変更支援情報に纏め上げる。この変更支援情報には、品質特性の変更に伴う各構成要素の持つ個々の機能の差異がアーキテクチャ横断的に現れる。
【００３７】
変更支援情報導出部３０は、導出した変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能上の差異を、アーキテクチャ情報をモデル図として出力した描写に認知可能に関連付けて出力する修正属性候補出力部を設けてもよい。また、この修正属性候補出力部は、サービスシステムに対して入力された機能要求が複数あった場合のアーキテクチャ内の機能上の差異の重複箇所を可視的に強調して出力可能に構成することが望ましい。
【００３８】
また、変更支援情報導出部３０は、機能要求に関して関連付けられている品質特性を設定可能な他の品質特性に変更された際に、品質特性の変更に関して、品質充足条件として登録されている各構成要素が持つ機能の組み合わせとその接続関係の一覧を参照して、各構成要素の接続関係の品質充足条件上の不足箇所と余分箇所を識別して変更支援情報に含めることが望ましい。
【００３９】
この変更支援情報は、ステークホルダ要求の変更に伴い見直す必要があるアーキテクチャ設計箇所（機能の見直し箇所、追加設計箇所）として、ユーザや本設計支援システムと連携する設計システムに通知される。
【００４０】
このことで、サービスシステムの設計支援システム１は、入力されたステークホルダ要求の変更に伴って機能要求に付随する品質要求が変化した場合に、ユーザから入力される機能要求と品質特性に基づいて、見直す必要があるアーキテクチャ上の設計箇所を自動的に判定することが可能になる。 
例えばあるステークホルダ要求によってサービスシステムに付与するある品質特性を変更や追加した際に、その変更に伴い見直す必要がある設計箇所が多岐に影響する場合でも、この自動判定により、多数の設計変更箇所が容易に認知可能になる。特に、アーキテクチャ内で余分となる機能を導出できる点について、認知できる点が利便性に富む。 
よって、システムの使用環境などが異なる複数の案件に対して、既存のアーキテクチャ設計情報を再利用しやすくなるとともに、要求との不適合リスクが軽減される。
【００４１】
なお、上記実施形態で、アーキテクチャ情報は、既にデータベースに登録されていることとして説明した。このアーキテクチャ情報は、設計変更時に、ユーザが入力することとしてもよい。このため、設計支援システム１は、アーキテクチャ情報の入力を受け付けるアーキテクチャ情報定義部を設けることが望ましい。このアーキテクチャ情報定義部は、アーキテクチャ情報の入力をモデルベースで受け付け得るように構築することが望ましい。
【００４２】
また、アーキテクチャ情報定義部は、アーキテクチャを画く部品として、設計するサービスシステムを提供するクラウド環境の利用可能な構成要素及び機能に対応させるように構成されてもよい。このことで、クラウドリソースを用いるクラウドベースサービスシステムの設計変更に伴う各構成要素の機能やリソース量の過不足などがより具体的に理解し易くなる。
【００４３】
次に、設計支援システム１の動作例を説明する。変更支援情報を生成するプロセスは、適宜各ステップを往き来しながら進めてもよく、図示したフローに限定されることはない。例えば、データベースが充実するまで、ステークホルダ要求の取得時や、ステークホルダ要求の変更時、サービスシステムの品質見直し時など、サービスシステムのアーキテクチャを非機能要求に基づいて見直す際に、不足する情報を補いながら運用すればよい。以下のプロセスを実行することで、システムの品質特性変更に横断的に影響を受ける各構成要素及びその各機能を変更支援情報から読み解け得るようになる。
【００４４】
図２は、設計支援システム１の動作例を示すフローチャートである。
【００４５】
まず、設計支援システム１は、データベースへの品質特性情報とアーキテクチャ情報の登録を受け付ける（Ｓ１０１）。アーキテクチャ情報は、既のアーキテクチャ情報をデータベース内から選択すればよく、またこの時点で入力することとしても構わない。
【００４６】
次に、設計支援システム１は、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、その機能要求に紐付ける品質特性とを分けられて受け付ける（Ｓ１０２）。この品質要求の種別は、データベースに準備されている品質特性情報に登録されている特性の区分から選択される。
【００４７】
次に、設計支援システム１は、登録された機能要求に紐付け可能な各品質要求の実現に寄与するアーキテクチャ情報の個々の構成要素の属性（機能）の組み合わせを品質充足条件として受け付ける（Ｓ１０３）。
【００４８】
上記Ｓ１０１からＳ１０３の準備工程は、過去の設計情報（品質充足条件の登録）を利用することで省力化が図れ、また個々の設計者の属人的な影響を弱めることができる。
【００４９】
次に、設計支援システム１は、受け付けた機能要求に関して関連付けられている品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、品質充足条件（各構成要素が持つ機能の組み合わせ）の一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能的差異を変更支援情報として導出処理する（Ｓ１０４）。
【００５０】
最後に、設計支援システム１は、導出した変更支援情報の内容をユーザに提示する（Ｓ１０５）。
【００５１】
このＳ１０４及びＳ１０５の変更支援工程は、ステークホルダ要求（品質要求）の変更を受けた際に、アーキテクチャ（構成要素及び接続関係）を共通に、適宜その影響を受けるアーキテクチャ上の１ないし複数の設計箇所（構成要素及びその機能）を導き出せる。
【００５２】
以上のように、本実施形態によれば、システム構成要素の機能を組み合わせることで実現される、アーキテクチャ横断的なステークホルダ要求について、要求が変更された場合に見直す必要があるアーキテクチャ設計箇所を自動的に判別して設計者に提示可能になる。
【００５３】
この判別成果を有効利用することで、例えば既存のアーキテクチャ設計情報の再利用を促進するとともに、ステークホルダ要求と新規のアーキテクチャの不適合リスクを軽減できる。
【００５４】
［構成例］ 
次に、一構成例を示して本発明を説明する。
【００５５】
図３は、本発明に係る一構成例を示したサービスシステムの設計支援システム２である。本設計支援システム２は、既存のサービスシステムの設計システムと同一のコンピュータ上で既存の設計システムと並列して動作する形態を想定している。
【００５６】
図示するように、本構成例の設計支援システム２は、要求分離部１０と、要求品質充足条件登録部２０と、変更支援情報導出部３０と、アーキテクチャ情報定義部４０を含み構成されている。また、変更支援情報導出部３０は、設定可能品質特性定義部３１と、要求変更部３２と、影響分析部３３と、修正属性候補出力部３４を具備する。入力を受けた各種情報や生成した情報は、適宜に関連付けて内部／外部データベースに保存するように構成すればよい。なお、データベースには、サービスシステムによって提供される各種機能の品質レベルの指標となる特性の一覧（品質特性情報（図４（ａ）に例示））を予め格納している。
【００５７】
要求分離部１０は、設計対象サービスシステムに対するステークホルダ要求の入力を受け付けて記憶する。また、要求分離部１０は、サービスシステムの設計者に、品質特性情報に含まれる区分で品質特性の選択肢を提示し、ステークホルダ要求を、システムの挙動に対する要求を表す機能要求と共に、その機能要求に付随する品質特性の選択を受け付ける。
【００５８】
以下ではステークホルダ要求として、ある企業内で使用される情報システムの設計請負時の例を説明に用いる。この例では、ネットワーク接続されたサーバ内に会議資料を保存し、会議の参加者間で共有できる仕組みを有する社内情報システムの構築を考える。ここで、システムベンダは、顧客からステークホルダ要求として、「保存された会議資料を、複雑な手順を踏まず容易に閲覧できること」という要求が与えられたとする。 
このステークホルダ要求は、「会議資料を閲覧する」という機能（「会議資料を参加者のＰＣ画面上に表示する」というシステムの挙動）に関する要求と、「容易に」という品質に関する要求で構成されている。このため、このシステムの機能要求に紐付ける品質要求は「容易に」であり、品質特性として設計者によって品質特性情報の「使用性」が入力インタフェース上で選択され、設計支援システム２に登録される。
【００５９】
アーキテクチャ情報定義部４０は、設計対象サービスシステムを構成する構成要素とその接続関係、各構成要素が持つ属性（単体で提供可能な機能）などの設計情報を受け付け、モデル化してアーキテクチャ情報としてデータベースに記録可能に構成されている。
【００６０】
このアーキテクチャ情報は、例えば図４（ｂ）に示すように、既存の各種モデリング言語と同様に、属性を持つ構成要素（図中のロードバランサなど）の有無（有効／無効）と、各構成要素の接続関係とを用いて表現してもよい。この各構成要素には、単体で提供可能な機能を示す属性（例えば、ロードバランサは負荷分散など、共有ＤＢサーバは簡易ファイル共有など）が付与される。図中では、代表的な属性のみを記載している。
【００６１】
また、設計情報を受け付ける際も、既存の各種モデリング言語と同様に描けるように、部品と成り得る構成要素を予め統一して準備しておくことが望ましい。このことで入力の省力化や属人的な影響の低減が図れる。また、個々の構成要素を可視的に紐付け可能にアーキテクチャ情報の入力インタフェースを作ることで利便性に富む設計支援システムを提供できる。
【００６２】
属性の種類は、各構成要素が単体で持つ機能のうち、ある接続関係において設計パラメータとなり得るものをアーキテクチャ情報内に定義する（ユーザが登録可能にする）。 
例えば、共有ＤＢサーバは、メールサーバと同様、指定された日時に自動的に保存データをバックアップする機能（自動バックアップ機能）を持たせられる。しかし、本アーキテクチャでは、共有ＤＢサーバにバックアップ先となる構成要素（他のストレージサーバなど）が接続されていないため、この共有サーバに対して「自動バックアップ」という属性が有効化されない。このように、個々の構成要素の接続状態に基づいて各構成要素の付与する属性の種類を決める。 
この登録用の入力インタフェースは、予め構成要素となるモデル図の部品に使用可能な属性（機能）を付与しておき、構成要素間の接続関係で使用不能な属性を削除（グレーアウト）するように構成してもよい。
【００６３】
図４（ｂ）に示したアーキテクチャ情報では、共有ＤＢサーバの属性（機能）として、簡易ファイル共有機能を有効に働かせることが表現されている。この簡易ファイル共有機能によって、共有ＤＢサーバは、ネットワーク上の複数の任意のユーザ間でフォルダやファイルを共有できる仕組みを提供できる。また、認証サーバは、「シングルサインオン」属性を有する。
【００６４】
この共有ＤＢサーバの機能により、特定のファイルに誰でもアクセス可能にできるため、ステークホルダ要求の品質要求として受け付ける「会議参加者同士でのファイル共有の容易化」の一部を実現できる。同様に、認証サーバの機能により、一度の認証で様々な対象にアクセス可能にできるため、ステークホルダ要求の品質要求として受け付ける「会議参加者同士でのファイル共有の容易化」の一部を実現できる。
【００６５】
この二つの構成要素を接続して用いることで、サービスシステムは、共有ＤＢサーバの簡易ファイル共有機能と認証サーバのシングルサインオン機能を連携させて動作させ得る。
【００６６】
簡易ファイル共有機能と認証サーバのシングルサインオン機能を用いることで、ステークホルダ要求の品質要求として受け付ける「会議参加者同士でのファイル共有の容易化」を実現できる。
【００６７】
このように、単体の構成要素が持つ機能を組み合わせることで実現できる要求以外にも、各構成要素を適切に接続することも必要とするステークホルダ要求にも対応できる。
【００６８】
この仕組みによって、サービスシステム全体として適切なアーキテクチャを取ることで実現されるステークホルダ要求と、サービスシステムのアーキテクチャ情報を対応付けることが可能になる。
【００６９】
要求品質充足条件登録部２０は、設定可能な品質特性の実現に寄与する属性の組み合わせ（品質従属条件情報）を、設計者に定義させる。既に品質従属条件がデータベースに登録されていれば、その品質従属条件情報を用いればよい。要求品質充足条件登録部２０は、品質従属条件情報に含ませる属性の組み合わせを、アーキテクチャ情報を示した画面上で個々の構成要素の属性を選択可能な入力インタフェースを有することで、省力化が図れる。この入力インタフェースを有することで、ユーザは、品質従属条件を満たす組み合わせを構成要素の接続関係を参照しながら選択でき、誤りが起きにくい。また、過去に登録された品質従属条件を画面上で参照する際にも、アーキテクチャ構造や、品質特性の担保を視覚的に理解し易い。
【００７０】
例えば、図４（ｂ）のアーキテクチャ情報における「使用性」に関する品質特性は、共有ＤＢサーバの簡易ファイル共有機能と認証サーバのシングルサインオン機能によって実現できる。よって、「使用性」という品質特性に対して、ユーザは、共有ＤＢサーバの「簡易ファイル共有」属性と認証サーバの「シングルサインオン」属性との組み合わせを選択する。
【００７１】
品質充足条件情報は、例えば図５に示すようなテーブル情報として定義できる。この例では、機能要求毎に、品質充足条件を別々のテーブル情報で定義しているが、一まとめのテーブル情報に形成しても良いし、他のデータベース形態を採用してもよい。なお、定義された品質充足条件は、データベースに保存して共用化を図ることが望ましい。
【００７２】
変更支援情報導出部３０は、設定可能品質特性定義部３１と、要求変更部３２と、影響分析部３３と、修正属性候補出力部３４を具備する。
【００７３】
設定可能品質特性定義部３１は、ユーザであるサービスシステムの設計者に品質特性情報に含まれる選択肢に従って、要求分離部１０で分離されて登録された機能要求に対して付随させることができる品質特性を定義させる。 
例えば、「複数のユーザが会議資料を同時に閲覧する」という機能要求に対して、「使用性」に関する品質要求の他にも、「同時に複数のユーザが会議資料にアクセスした場合でも高速に」、「認証された特定ユーザのみが」、「全社の集中休暇期間を除く任意の時間帯に」などの品質に関わる要求を追加できる。これらの品質要求を受けたならば、図４（ａ）の品質特性情報の、「性能」、「セキュリティ」、「可用性」に関する品質特性を機能要求に紐づければよい。 
他方、上記の機能要求は、システム導入後の運用コストや保守しやすさなどとは関連しないため、「運用保守性」という品質特性とは紐付けない。
【００７４】
要求変更部３２は、サービスシステムの設計者から、任意の機能要求に付随する品質特性の変更入力を受け付ける。この要求変更部３２の入力インタフェースは、選択された機能要求に紐づく設定可能品質特性（設定可能品質特性定義部３１で定義）に含まれる品質特性の品質要求に変更可能に構成する。
【００７５】
例えば、図４（ｂ）のアーキテクチャ情報によって構築されたサービスシステムについて、「外出先から会議資料を閲覧するために、社外のネットワークからもアクセスされるような使用環境を想定」した場合、機能要求に付随して定義されていた「使用性」よりも優先させるべき品質特性として、「保存された会議資料を、会議参加者（正確に認証されたユーザ）のみが閲覧できること」という、品質特性情報に含まれる「セキュリティ性」に関する品質特性に変更される。
【００７６】
影響分析部３３は、機能要求毎に、品質充足条件一覧から、要求変更部３２において変更前の品質特性の実現に寄与する属性の組み合わせ（変更前品質充足条件）を抽出し、必要に応じて変更後の品質特性の実現に寄与する属性の組み合わせ（変更後品質充足条件）を抽出し、影響を受ける機能（構成要素の属性）を判定する。影響分析部３３は、例えば図６や図７に例示するフローチャートように、変更支援情報生成プロセスを実行すればよい。
【００７７】
例えば、図７のフロー例では、「会議資料を閲覧する」という機能要求１に付随する品質要求が「セキュリティ性」に関するものに変更された場合、変更前に機能要求に付随していた品質特性「使用性」の実現に寄与していた二つの属性（「簡易ファイル共有」と「シングルサインオン」）が品質充足条件（図５参照）から抽出される。同様に変更後の「セキュリティ性」の実現に寄与する二つの属性（「暗号化」と「ユーザ認証」）が品質充足条件（図５参照）から抽出される。そして、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能的差異を変更支援情報として導出する。
【００７８】
修正属性候補出力部３４は、変更支援情報を参照して、影響分析部３３で抽出された構成要素や属性を設計者に可視的にモデル図でアーキテクチャ情報を用いて提示する。
【００７９】
修正属性候補出力部３４は、複数の機能要求を取り扱う際に、変更されたある品質要求の属性に関して、全部の機能要求の変更前の品質要求の実現に用いられていた箇所を識別して、変更後のアーキテクチャ設計箇所を判別して提示する。この際、特に気を付ける必要が生じ得るアーキテクチャの差異の重複箇所を可視的に強調して提示することとしてもよい。
【００８０】
図８及び図９は、ユーザに提示するモデル図を用いた表示画面構築例を示した説明図である。図８（ａ）には、図４に示したアーキテクチャについて、ある機能要求に付与する品質特性を“可用性”から“セキュリティ性”に変更したした際に、変更支援情報に含まれる追加設計箇所を示した画面描写が示されている。同様に、図８（ｂ）には、図４に示したアーキテクチャについて、ある機能要求に付与する品質特性を“可用性”から“セキュリティ性”に変更したした際に、変更支援情報に含まれる見直し箇所を示した画面描写が示されている。同様に、図９には、図４に示したアーキテクチャについて、ある機能要求に付与する品質特性を“可用性”から“セキュリティ性”に変更したした際に、変更支援情報に含まれる設計箇所及びステークホルダ要求を示した画面描写が示されている。
【００８１】
図９に示すように、ステークホルダ要求、機能要求、品質要求もサービスシステムのアーキテクチャと共に提示可能にすることが望ましい。また、ステークホルダ要求に関連する制約もサービスシステムのアーキテクチャと共に提示することとしてもよい。
【００８２】
以上説明したように、本発明を適用したサービスシステムの設計支援システムは、ステークホルダ要求の変更に伴って機能要求に付随する品質要求を変更した際に、見直す必要があるアーキテクチャ設計箇所を自動的に判別することが可能にできる。
【００８３】
尚、設計支援システムの各部は、コンピュータシステムのハードウェアとソフトウェアの組み合わせを用いて実現すればよい。このコンピュータシステムは、所望形態に合わせた、１ないし複数のプロセッサー、メモリー、入力部、出力部、及びバスを含む。また、このコンピュータシステムの形態では、各部は、上記メモリーに設計支援用プログラムが展開され、このプログラムに基づいて１ないし複数のプロセッサー等のハードウェアを実行命令群やコード群で動作させることによって、実現すればよい。この際、必要に応じて、このプログラムは、オペーレティングシステムや、マイクロプログラム、ドライバなどのソフトウェアが提供する機能と協働して、各部を実現することとしてもよい。
【００８４】
メモリーに展開されるプログラムデータは、プロセッサーを１ないし複数の上述した各部として動作させる実行命令群やコード群、テーブルファイル、コンテンツデータなどを適宜含む。
【００８５】
また、このコンピュータシステムは、必ずしも一つの装置として構築される必要はなく、複数のサーバ／コンピュータ／仮想マシンなどが組み合わさって、所謂、シンクライアントや、分散コンピューティング、クラウドコンピューティングで構築されてもよい。また、コンピュータシステムの一部／全ての各部をハードウェアやファームウェア（例えば、一ないし複数のLSI：Large-Scale Integration，FPGA：Field Programmable Gate Array，電子素子の組み合わせ）で置換することとしてもよい。同様に、各部の一部のみをハードウェアやファームウェアで置換することとしてもよい。
【００８６】
また、このプログラムは、記録媒体に非一時的に記録されて頒布されても良い。当該記録媒体に記録されたプログラムは、有線、無線、又は記録媒体そのものを介してメモリーに読込まれ、プロセッサー等を動作させる。
【００８７】
尚、本明細書では、記録媒体には、類似するタームの記憶媒体やメモリー装置、ストレージ装置なども含むこととする。この記録媒体を例示すれば、オプティカルディスクや磁気ディスク、半導体メモリー装置、ハードディスク装置、テープメディアなどが挙げられる。また、記録媒体は、不揮発性であることが望ましい。また、記録媒体は、揮発性モジュール（例えばRAM：Random Access Memory）と不揮発性モジュール（例えばROM：Read Only Memory）の組み合わせを用いることとしてもよい。
【００８８】
上記形態を別の表現で説明すれば、設計支援システムとして動作させるプロセッサを、メモリーに展開された設計支援用プログラムに基づき、要求分離手段、要求品質充足条件登録手段、変更支援情報導出手段、設定可能品質特性定義手段、要求変更手段、影響分析手段、修正属性候補出力手段として動作させることで、その結果、設計支援システムを実現できる。
【００８９】
同様に、上記形態を更に別の表現で説明すれば、記録媒体は、メモリーに展開されて情報処理リソースで動作する設計支援用プログラムを含み、情報処理リソースに上記準備工程と変更支援工程を適時実行させることで、設計支援システムを構築できる。
【００９０】
なお、実施形態及び／又は構成例を例示して本発明を説明した。しかし、本発明の具体的な構成は前述の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の変更があってもこの発明に含まれる。例えば、上述した実施形態及び／又は実施例のブロック構成の分離併合、手順の入れ替えなどの変更は本発明の趣旨および説明される機能を満たせば自由であり、上記説明が本発明を限定するものではない。
【００９１】
また、上記の実施形態の一部又は全部は、以下のようにも記載されうる。尚、以下の付記は本発明をなんら限定するものではない。 
［付記１］
サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて登録を受け付ける要求分離手段と、
サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記要求分離手段で登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段、
を具備することを特徴とするサービスシステムの設計支援システム。
【００９２】
［付記２］
前記変更支援情報導出手段は、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更後の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の追加設計箇所を導出する、
ことを特徴とする上記付記記載のサービスシステムの設計支援システム。
【００９３】
［付記３］
前記要求分離手段は、設計対象の前記サービスシステムに対して入力されるステークホルダ要求の登録について、機能要求毎に、個々の機能要求に対応付けて品質特性の登録を受け付け、
前記変更支援情報導出手段は、個々の機能要求に関して関連付けられているある品質特性を設定可能な他の品質特性に変更された際に、変更された前記ある品質要求の属性に関して、全部の機能要求の変更前の品質特性の実現に用いられていた箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の差異を導出処理する
ことを特徴とする上記付記記載のサービスシステムの設計支援システム。
【００９４】
［付記４］
前記変更支援情報導出手段で導出された変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能上の差異をモデル図内に認知可能に出力する修正属性候補出力手段を具備し、
該修正属性候補出力手段は、前記サービスシステムに対して入力された機能要求が複数あった場合のアーキテクチャ上の構成要素の機能上の差異の重複箇所を可視的に認知可能に出力する
ことを特徴とする上記付記記載のサービスシステムの設計支援システム。
【００９５】
［付記５］
前記変更支援情報導出手段は、
前記機能要求に関して 設計変更に伴い変更可能な品質特性を受け付ける設定可能品質特性定義手段と、
前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を、前記設定可能品質特性定義手段で受け付けた設定可能な他の品質特性に変更する入力を受け付ける要求変更手段と、
前記要求変更手段で変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前後の品質要求の実現に寄与していた機能の組み合わせを識別して、変更前後のサービスシステムに関連するアーキテクチャ上の各構成要素の機能の差異が現れる情報を変更支援情報として生成する影響分析手段と、
前記変更支援情報を参照して、前記影響分析手段で抽出された属性をアーキテクチャ情報に反映させてモデル図として出力する修正属性候補出力手段と
から構成されていることを特徴とする上記付記記載に記載のサービスシステムの設計支援システム。
【００９６】
［付記６］
前記アーキテクチャ情報は、各構成要素が持つ機能のうち、各構成要素の特定の接続関係においてサービスシステムの設計上のパラメータとなる接続情報を含み、
前記要求品質充足条件登録手段は、ユーザから登録される前記機能要求に紐付け可能な品質特性の実現に寄与する各構成要素が持つ機能の組み合わせと共に、その構成要素間の接続関係を含めて品質充足条件を記録し、
前記変更支援情報導出手段は、機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、品質特性の変更に関して、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせとその接続関係の一覧を参照して、各構成要素の接続関係の充足条件上の不足箇所及び／又は余分箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の接続関係の差異を導出処理する
ことを特徴とする上記付記記載のサービスシステムの設計支援システム。
【００９７】
［付記７］
前記アーキテクチャ情報の入力をモデルベースで受け付けるアーキテクチャ情報定義手段を更に備えることを特徴とする上記付記記載のサービスシステムの設計支援システム。
【００９８】
［付記８］
前記アーキテクチャ情報定義手段は、設計するサービスシステムを提供するクラウド環境の提供可能な構成要素及び機能に対応させた、モデルベースの構成要素 及び 各構成要素単位で発揮する機能をアーキテクチャ情報として受け付け、
前記変更支援情報導出手段は、変更された品質特性について、変更前後のクラウドベースサービスシステムに関連するアーキテクチャ上の差異を、クラウド環境の構成要素及び機能に対応させて導出する
ことを特徴とする上記付記記載のサービスシステムの設計支援システム。
【００９９】
［付記９］
コンピュータシステムの入力部から、サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて機能要求毎に登録を受け付ける第１の入力インタフェースと、
データベースに記録されている、サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記第１の入力インタフェースで登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を前記入力部から機能要求毎に受け付ける第２の入力インタフェースと、
前記コンピュータシステムのプロセッシングリソースによって、前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記前記第１の入力インタフェースで登録された個々の機能要求に関して関連付けられているある品質特性を設定可能な他の品質特性に変更された際に、変更された前記ある品質特性について、前記第２の入力インタフェースで登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 全部の機能要求の変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出して、前記コンピュータシステムの出力部から出力可能に構成された出力インタフェース
を具備することを特徴とするサービスシステムの設計支援システム。
【０１００】
［付記１０］
前記アーキテクチャ情報を、前記入力部を介してモデルベースで受け付ける第３の入力インタフェースを備え、
前記第３の入力インタフェースは、設計するサービスシステムを提供するクラウド環境の提供可能な構成要素及び機能に対応させた、モデルベースの構成要素 及び 各構成要素単位で発揮する機能を前記アーキテクチャ情報として受け付け、前記データベースに記録する
ことを特徴とする上記付記記載のサービスシステムの設計支援システム。
【０１０１】
［付記１１］
設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、予め準備されているサービスシステムの品質を示す特性の一覧を示す品質特性情報に登録されている特性ごとの区分で品質特性と に分けて受け付け、
予め準備されている前記設計対象サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、登録された前記機能要求に紐付け可能な品質特性の実現に寄与する前記アーキテクチャ情報に属性として含まれている各構成要素が持つ機能の組み合わせを品質充足条件として受け付け、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを予め保持すると共に、受け付けた機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する
ことを特徴とする情報処理システムによるサービスシステムの設計支援方法。
【０１０２】
［付記１２］
前記情報処理システムは、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更後の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の追加設計箇所を導出する
ことを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０３】
［付記１３］
前記情報処理システムは、
設計対象の前記サービスシステムに対して入力されるステークホルダ要求の登録について、機能要求毎に、個々の機能要求に対応付けて品質特性の登録を受け付け、
個々の機能要求に関して関連付けられているある品質特性を設定可能な他の品質特性に変更された際に、変更された前記ある品質要求の属性に関して、全部の機能要求の変更前の品質特性の実現に用いられていた箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の差異を導出処理する
ことを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０４】
［付記１４］
前記情報処理システムは、
導出した変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能上の差異をモデル図内に認知可能に出力する
ことを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０５】
［付記１５］
前記情報処理システムは、
前記サービスシステムに対して入力された機能要求が複数あった場合、アーキテクチャ上の構成要素の機能上の差異の重複箇所を可視的に認知可能に出力する
ことを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０６】
［付記１６］
前記アーキテクチャ情報は、各構成要素が持つ機能のうち、各構成要素の特定の接続関係においてサービスシステムの設計上のパラメータとなる接続情報を含み、
前記情報処理システムは、
ユーザから登録される前記機能要求に紐付け可能な品質特性の実現に寄与する各構成要素が持つ機能の組み合わせと共に、その構成要素間の接続関係を含めて品質充足条件を記録し、
機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、品質特性の変更に関して、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせとその接続関係の一覧を参照して、各構成要素の接続関係の充足条件上の不足箇所及び／又は余分箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の接続関係の差異を導出処理する
ことを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０７】
［付記１７］
前記情報処理システムは、前記アーキテクチャ情報の入力を入力部を介してモデルベースで受け付けることを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０８】
［付記１８］
前記情報処理システムは、
設計するサービスシステムを提供するクラウド環境の提供可能な構成要素及び機能に対応させた、モデルベースの構成要素 及び 各構成要素単位で発揮する機能をアーキテクチャ情報として受け付け、
変更された品質特性について、変更前後のクラウドベースサービスシステムに関連するアーキテクチャ上の差異を、クラウド環境の構成要素及び機能に対応させて導出する
ことを特徴とする上記付記記載のサービスシステムの設計支援方法。
【０１０９】
［付記１９］
情報処理システムのプロセッサを、
サービスシステムの品質を示す特性の一覧を示す品質特性情報を参照して、設計対象サービスシステムに対して入力されているステークホルダ要求について、機能要求と、前記品質特性情報に登録されている特性ごとの区分で品質特性と に分けて登録を受け付ける要求分離手段と、
前記設計対象サービスシステムの各構成要素の接続関係と 各構成要素単位で発揮する機能を示す属性 とを含むアーキテクチャ情報を参照して、前記要求分離手段で登録された前記機能要求に紐付け可能な品質特性の実現に寄与する、前記アーキテクチャ情報に属性として含まれる各構成要素が持つ機能の組み合わせの登録を受け付ける要求品質充足条件登録手段と、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の見直し箇所を導出する変更支援情報導出手段、
として、動作させることを特徴とするサービスシステムの設計支援用プログラム。
【０１１０】
［付記２０］
前記変更支援情報導出手段を、
前記機能要求に関して 設計変更に伴い変更可能な品質特性の関連付けを保持すると共に、前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更後の品質要求の実現に寄与していた機能の組み合わせを識別し、前記機能要求及び変更後の品質特性を満たすアーキテクチャ内の機能の追加設計箇所を導出する
ように動作させることを特徴とする上記付記記載のサービスシステムの設計支援用プログラム。
【０１１１】
［付記２１］
前記要求分離手段が、設計対象の前記サービスシステムに対して入力されるステークホルダ要求の登録について、機能要求毎に、個々の機能要求に対応付けて品質特性の登録を受け付け、
前記変更支援情報導出手段が、個々の機能要求に関して関連付けられているある品質特性を設定可能な他の品質特性に変更された際に、変更された前記ある品質要求の属性に関して、全部の機能要求の変更前の品質特性の実現に用いられていた箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の差異を導出処理する
ように動作させることを特徴とする上記付記記載のサービスシステムの設計支援用プログラム。
【０１１２】
［付記２２］
前記プロセッサを、
前記変更支援情報導出手段で導出された変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の機能上の差異をモデル図内に認知可能に出力する修正属性候補出力手段として動作させ、
該修正属性候補出力手段を、前記サービスシステムに対して入力された機能要求が複数あった場合のアーキテクチャ上の構成要素の機能上の差異の重複箇所を可視的に認知可能に出力する
ように動作させることを特徴とする上記付記記載のサービスシステムの設計支援用プログラム。
【０１１３】
［付記２３］
前記プロセッサを、
前記変更支援情報導出手段として、
前記機能要求に関して 設計変更に伴い変更可能な品質特性を受け付ける設定可能品質特性定義手段と、
前記要求分離手段で登録された機能要求に関して関連付けられている前記品質特性を、前記設定可能品質特性定義手段で受け付けた設定可能な他の品質特性に変更する入力を受け付ける要求変更手段と、
前記要求変更手段で変更された品質特性について、前記要求品質充足条件登録手段で登録されている各構成要素が持つ機能の組み合わせの一覧を参照して 変更前後の品質要求の実現に寄与していた機能の組み合わせを識別して、変更前後のサービスシステムに関連するアーキテクチャ上の各構成要素の機能の差異が現れる情報を変更支援情報として生成する影響分析手段と、
前記変更支援情報を参照して、前記影響分析手段で抽出された属性をアーキテクチャ情報に反映させてモデル図として出力する修正属性候補出力手段
として、動作させることを特徴とする上記付記記載に記載のサービスシステムの設計支援用プログラム。
【０１１４】
［付記２４］
前記アーキテクチャ情報は、各構成要素が持つ機能のうち、各構成要素の特定の接続関係においてサービスシステムの設計上のパラメータとなる接続情報を含み、
前記要求品質充足条件登録手段が、ユーザから登録される前記機能要求に紐付け可能な品質特性の実現に寄与する各構成要素が持つ機能の組み合わせと共に、その構成要素間の接続関係を含めて品質充足条件を記録し、
前記変更支援情報導出手段が、機能要求に関して関連付けられている前記品質特性を設定可能な他の品質特性に変更された際に、品質特性の変更に関して、前記品質充足条件として登録されている各構成要素が持つ機能の組み合わせとその接続関係の一覧を参照して、各構成要素の接続関係の充足条件上の不足箇所及び／又は余分箇所を識別して、変更前後のサービスシステムに関連するアーキテクチャ上の構成要素の接続関係の差異を導出処理する
ように動作させることを特徴とする上記付記記載のサービスシステムの設計支援用プログラム。
【０１１５】
［付記２５］
前記プロセッサを、前記アーキテクチャ情報の入力をモデルベースで受け付けるアーキテクチャ情報定義手段として動作させることを特徴とする上記付記記載のサービスシステムの設計支援用プログラム。
【０１１６】
［付記２６］
前記アーキテクチャ情報定義手段が、設計するサービスシステムを提供するクラウド環境の提供可能な構成要素及び機能に対応させた、モデルベースの構成要素 及び 各構成要素単位で発揮する機能をアーキテクチャ情報として受け付け、
前記変更支援情報導出手段が、変更された品質特性について、変更前後のクラウドベースサービスシステムに関連するアーキテクチャ上の差異を、クラウド環境の構成要素及び機能に対応させて導出する
ように動作させることを特徴とする上記付記記載のサービスシステムの設計支援用プログラム。
【０１１７】
［付記２７］
上記付記に記載したサービスシステムの設計支援用プログラムを記録した記録媒体。
【符号の説明】
【０１１８】
１，２  設計支援システム（コンピュータシステム）
１０    要求分離部（要求分離手段）
２０    要求品質充足条件登録部（要求品質充足条件登録手段）
３０    変更支援情報導出部（変更支援情報導出手段）
３１    設定可能品質特性定義部（設定可能品質特性定義手段）
３２    要求変更部（要求変更手段）
３３    影響分析部（影響分析手段）
３４    修正属性候補出力部（修正属性候補出力手段）
【図１】
2019015995.tif 000003
【図２】
2019015995.tif 000004
【図３】
2019015995.tif 000005
【図４】
2019015995.tif 000006
【図５】
2019015995.tif 000007
【図６】
2019015995.tif 000008
【図７】
2019015995.tif 000009
【図８】
2019015995.tif 000010
【図９】
2019015995.tif 000011