特許 7074330 検証装置、方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-05-16

(45)【発行日】2022-05-24

(54)【発明の名称】検証装置、方法、及びプログラム

(51)【国際特許分類】

   G06F 16/30 20190101AFI20220517BHJP

   G06F 40/279 20200101ALI20220517BHJP

   G06F 8/10 20180101ALI20220517BHJP

   G06F 11/36 20060101ALI20220517BHJP

【ＦＩ】

G06F16/30

G06F40/279

G06F8/10

G06F11/36 116

【請求項の数】 6

(21)【出願番号】P 2018088630

(22)【出願日】2018-05-02

(65)【公開番号】P2019194789

(43)【公開日】2019-11-07

【審査請求日】2021-04-26

(73)【特許権者】

【識別番号】501241645

【氏名又は名称】学校法人 工学院大学

(74)【代理人】

【識別番号】110001519

【氏名又は名称】特許業務法人太陽国際特許事務所

(72)【発明者】

【氏名】位野木 万里

【審査官】早川 学

(56)【参考文献】

【文献】特開２０１３－２３２０５８（ＪＰ，Ａ）

【文献】特開２００９－６４３３９（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

Ｇ０６Ｆ ４０／００－４０／５８

Ｇ０６Ｆ ８／１０

Ｇ０６Ｆ １１／３６

(57)【特許請求の範囲】

【請求項1】

情報システムを用いた業務に関するシナリオを含む前記情報システムの仕様書の網羅性を検証する検証装置であって、
前記仕様書の前記シナリオに含まれる各センテンスと、各センテンスに含まれる各設計要素の、設計要素の種類とを識別するセンテンス識別部と、
前記設計要素の種類ごとに、前記設計要素の種類について同一文脈でシナリオに出現すべき設計要素の集合からなる分類を格納した同一分類用語辞書を参照して前記センテンスごとに、前記センテンスに含まれる前記設計要素の各々が属する分類を付与する分類部と、
前記センテンスごとの、前記センテンスに含まれる各設計要素、設計要素の種類、前記付与された分類に基づいて、前記仕様書について、同一文脈でシナリオに出現すべき設計要素の集合の網羅性を検証する検証部と、
を含む検証装置。

【請求項2】

前記分類部は、前記センテンスごとに、前記センテンスに含まれる前記設計要素の各々が、前記設計要素の種類に応じて格納されるセンテンスグリッドを作成し、前記センテンスに含まれる前記設計要素の各々が属する分類を、前記センテンスグリッドに登録し、
前記検証部は、前記センテンスグリッドに基づいて、前記網羅性を検証する請求項１に記載の検証装置。

【請求項3】

前記分類部は、前記センテンスのペアについて、着目する前記設計要素の種類について、設計要素が異なり、かつ、分類が同一であり、着目する前記設計要素の種類以外について設計要素が一致する場合、前記センテンスのペアについて、前記設計要素の種類に対して同一のグループＩＤを各々付与するように、前記センテンスグリッドに対してセンテンスごと及び前記設計要素の種類ごとに前記グループＩＤを登録し、
前記検証部は、前記同一のグループＩＤの前記センテンスを前記シナリオにおいて同一の文脈のものであるとして、前記設計要素の種類ごと及び前記グループＩＤごとに、前記網羅性を検証する請求項２に記載の検証装置。

【請求項4】

前記検証部は、
前記設計要素の種類と前記グループＩＤとの組み合わせごとに、前記網羅性を表す第１スコアを算出する前処理部と、
前記組み合わせごとに算出した前記第１スコアに基づいて、前記分類ごとに、前記網羅性を表す第２スコアを算出する実行部と、
を含む請求項３に記載の検証装置。

【請求項5】

前記実行部は、更に、前記第２スコアが閾値以下であるか否かを判定する請求項４に記載の検証装置。

【請求項6】

コンピュータを、請求項１～請求項５のいずれか１項に記載の検証装置の各部として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、検証装置、方法、及びプログラムに係り、特に、情報システムの仕様を検証するための検証装置、方法、及びプログラムに関する。

【背景技術】

【0002】

情報システムの要求仕様書や基本設計書におけるシナリオや機能仕様の作成、検証、改善などの一連の開発作業において、高品質な仕様書の記述のために、仕様の記述状況と網羅度を自動検証する技術がある。自動検証によって、開発者及び開発の生産性と品質を向上させることができる。

【0003】

情報システム開発において、開発の範囲を明らかにし、発注者と開発者間で合意形成を行うための要求定義工程は極めて重要であり、要求定義工程の代表的な成果物である要求仕様書の高品質化が求められている。

【0004】

非特許文献１によれば、設計要素であるアクター、データ、画面、振る舞いは、開発するシステムの範囲を決める重要な要素とされている。要求仕様書は、情報システムの開発範囲を定義することが主たる目的となる。そのうち、情報システムを用いて、ステークホルダがどのように業務処理を実施するのかを示す業務処理仕様などの業務シナリオは、発注者と開発者間が情報システムの内容を合意形成するために用いられる、極めて重要な仕様である。業務処理仕様は、可読性を高めて共有しやすくするために業務ごとに表形式や業務フロー図などによりまとめられるが、各業務の説明部分、すなわち、アクター、入出力データ、利用画面、その際のシステムの振る舞いによるシナリオは、自然言語により記述される。

【0005】

要求仕様書に記述される業務処理仕様やシナリオは、自然言語で記述されることが多く、そのため、定義漏れや表記ゆれなどの不備が発生する。要求仕様書を十分に改善しないまま、基本設計以降に進む場合、仕様確認の手戻りが発生したり、要求された機能を備えたシステムに到達できないリスクが高まる。そのため、自然言語で記述された要求仕様書の一貫性検証を自動化するなどの技術開発と活用が推進されている。

【0006】

例えば、仕様書の文書チェックと一貫性検証の自動化に関する技術がある（例えば、特許文献１、特許文献２参照）。この技術における一貫性検証では、情報システムの要求仕様書を対象として、情報システムの利用者または対象情報システムと相互にやり取りをする他システムである「アクター」を対象にしている。情報システムの要求仕様書内において、利用者または他システムのアクター定義の内容と、同要求仕様書内の機能仕様に出現するアクター名の相互チェックを行い、アクター定義で定義されていないアクター名を未定義要素として自動指摘する。この技術では、自然言語で記述された仕様書の形態素解析を行い、名詞句の要素から、アクター名に付与される識別用語をあらかじめ決めておき、同識別用語の前後関係からアクター名を抽出し、抽出されたアクター名と、仕様書内のアクター定義の突合により一貫性のチェックを行う。

【0007】

前述の技術は、要求仕様書に記述された「アクター」にフォーカスされている。情報システムの要求仕様書には、アクターに加えて、画面、データ、振る舞いなどの設計要素も重要な開発対象である。これらの設計要素を対象として、発明者は、要求仕様の品質特性である「一貫性」に着目し、ベテラン技術者が経験的に得た検証知識を形式知化し、それら知識に基づき、自然言語で記述された要求仕様の一貫性検証支援ツールを実現し、既に運用しているものもある（例えば、非特許文献２～４参照）。

【0008】

なお、自然言語で記述された仕様書のテキストファイルから、各用語を品詞別に分解して抽出するプログラムとしては、形態素解析ツールが複数考案されている。代表的なものとしては、MeCabがあげられる。

【0009】

前述の先行技術は、開発者や発注者らにより記述された要求仕様書が妥当に記述されているかどうかを自動検証する技術である。要求仕様書の記述が不足していた場合のサポートとして、業務シナリオの自動生成ツールの考案をしている（例えば、非特許文献５参照）。この技術は、ある設計要素に対して、その派生形となる用語のバリエーションをあらかじめ定義しておき、仕様書内のセンテンスに対して、センテンスを構成する要素と、あらかじめ定義した同一分類用語辞書とを突合し、同一分類用語辞書に定義された要素と合致する要素があれば、同要素の同一分類（派生用語のバリエーション）を用いて、同要素をそのバリエーションで置き換えたセンテンスを自動生成する技術である。

【先行技術文献】

【特許文献】

【0010】

【文献】特開２０１３－２５４５０３号公報

【文献】特開２０１３－２３２０５８号公報

【非特許文献】

【0011】

【文献】独立行政法人情報処理推進機構，ソフトウェア・エンジニアリング・センター，機能要件の合意形成ガイド（https://www.ipa.go.jp/sec/softwareengineering/reports/20100331.html[2018年4月11日参照]）

【文献】位野木万里，近藤公久: 要求仕様の一貫性検証支援ツールの提案と適用評価, SEC journal49 号，独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センター，pp. 16-23, 2017．

【文献】位野木万里: 要求定義の高品質化のための要求仕様の整合性の検証知識の形式知化と一貫性検証支援ツールの開発, 独立行政法人情報処理推進機構, ソフトウェア工学分野の先導的研究支援事業, 2016.（http://www.ipa.go.jp/sec/rise/#01-9[2018年4月11日参照]）

【文献】位野木万里:シナリオの一貫性検証支援ツールの紹介,（http://www.ns.kogakuin.ac.jp/~wwa1076[2018年4月11日参照]）

【文献】位野木 万里，高橋 宏季，近藤 公久，情報システムの要求定義の効率化のための業務シナリオの自動生成ツールの提案，経営情報学会，2017年秋季全国研究発表大会予稿集，セッションID: D1-1

【発明の概要】

【発明が解決しようとする課題】

【0012】

大規模かつ長年にわたり保守拡張を繰り返してきた基幹系情報システムの場合、要求仕様書も既に過去の積み重ねで膨大な量が記述されていることが多い。そのような既存の要求仕様書が存在している情報システムに対して、法改正、組織変更、技術の進化などによって修正や拡張が行われる際、既存の要求仕様書を技術者が拡張することになる。この場合、初期の執筆者とは異なる技術者が拡張することが一般的である。加えて、要求仕様書の執筆者とは異なる開発者が、システム開発を行うことも一般的であり、要求仕様書は、第三者にとり、記述漏れや曖昧な記述のないように高品質化を図ることが重要である。

【0013】

ところで、仕様書の一貫性の検証については、既存技術（非特許文献２～４）の一貫性検証支援ツールを用いて検証の自動化が可能である。また、一般的な文書エディタやワープロソフトを用いれば、あらかじめ準備した曖昧さを誘発する表現のリストに基づいて、検索や置換機能により指摘や置き換えを行うことが可能である。

【0014】

情報システムの利用の目的の一つは情報の登録管理の効率化である。したがって、情報システムを通して、利用者は、管理対象の情報に対して、登録、検索、更新、削除などの一連の作業を行うことになる。また、利用者が、情報システムに情報を入力した場合、入力した情報の出力や加工等、一連の関連する動作を行うはずである。このように、情報システムへの操作に着目すると、情報の「入力」に関しては「出力」が、情報の「登録」に関しては、「検索」、「更新」、「削除」が、同一の文脈で想定されるシステムへの動作として、その機能仕様として定義すべき動作と考えられる。前述した、記述漏れのないシナリオとは、登録のシナリオがあれば、検索、更新、削除などの暗黙的に存在すべきシナリオについても網羅的に記述されていることである。これらの記述が一部でも省略されておれば、確認や指摘などの余分な手戻りの発生リスクが高まる。なお、システムの動作つまり振る舞い以外にも、システムの設計要素である、アクター、データ、画面、帳票なども、同一の文脈で想定される一連の設計要素用語が存在すると考えられる。例えば、データに着目すれば、起案書データと決裁書データは、対になる組合せであるし、入力画面、確認画面、確定画面の順番でデータ入力が完成するといったように、意味のある画面遷移である。

【0015】

しかし、基幹系の大規模情報システムの要求仕様書において、長期間に渡り複数の開発者が追記や修正を繰り返してきたこと等が要因となり、暗黙的に補うことが可能な設計要素を含むシナリオは、記述が省略されている傾向にある。また、複数の開発者の記述の方針の違いによって、シナリオの網羅性にばらつきが生じていることもあり、各シナリオの網羅度を手作業で検証することは作業負荷が多大になり困難である。その結果、要求仕様書の高品質化の作業方針の立案が困難な状況にある。

【0016】

本発明は、上記問題点を解決するために成されたものであり、仕様書におけるシナリオについて、同一文脈でシナリオに出現すべき設計要素の網羅性を精度よく検証できる検証装置、方法、及びプログラムを提供することを目的とする。

【課題を解決するための手段】

【0017】

上記目的を達成するために、本発明に係る検証装置は、情報システムを用いた業務に関するシナリオを含む前記情報システムの仕様書の網羅性を検証する検証装置であって、
前記仕様書の前記シナリオに含まれる各センテンスと、各センテンスに含まれる各設計要素の、設計要素の種類とを識別するセンテンス識別部と、前記設計要素の種類ごとに、前記設計要素の種類について同一文脈でシナリオに出現すべき設計要素の集合からなる分類を格納した同一分類用語辞書を参照して前記センテンスごとに、前記センテンスに含まれる前記設計要素の各々が属する分類を付与する分類部と、前記センテンスごとの、前記センテンスに含まれる各設計要素、設計要素の種類、前記付与された分類に基づいて、前記仕様書について、同一文脈でシナリオに出現すべき設計要素の集合の網羅性を検証する検証部と、を含んで構成されている。

【0018】

本発明に係るプログラムは、コンピュータを、検証装置の各部として機能させるためのプログラムである。

【発明の効果】

【0019】

本発明の検証装置、方法、及びプログラムによれば、仕様書のシナリオに含まれる各センテンスと、各センテンスに含まれる各設計要素の、設計要素の種類とを識別し、設計要素の種類ごとに、設計要素の種類について同一文脈でシナリオに出現すべき設計要素の集合からなる分類を格納した同一分類用語辞書を参照してセンテンスごとに、センテンスに含まれる設計要素の各々が属する分類を付与し、センテンスごとの、センテンスに含まれる各設計要素、設計要素の種類、付与された分類に基づいて、仕様書について、同一文脈でシナリオに出現すべき設計要素の集合の網羅性を検証することにより、仕様書におけるシナリオについて、同一文脈でシナリオに出現すべき設計要素の網羅性を精度よく検証できる、という効果が得られる。

【図面の簡単な説明】

【0020】

【図1】本発明の実施の形態に係る検証装置の構成を示すブロック図である。

【図2】シナリオが記述された仕様書の一例を示す図である。

【図3】同一分類用語辞書の一例を示す図である。

【図4】センテンスグリッド化完了時のセンテンスグリッドワーキングメモリの状態の一例を示す図である。

【図5】出力される検証レポートの一例を示す図である。

【図6】本発明の実施の形態に係る検証装置における検証処理ルーチンを示すフローチャートである。

【図7】仕様データセットの一例を示す図である。

【図8】センテンスグリッド化処理ルーチンを示すフローチャートである。

【図9】センテンスグリッドの初期化の一例を示す図である。

【図10】センテンスグリッドにおける基本グリッドの生成の一例を示す図である。

【図11】センテンスグリッドにおける同一分類用語辞書との突合結果の一例を示す図である。

【図12】センテンスグリッドにおける同一分類用語辞書との突合結果の一例を示す図である。

【図13】センテンスグリッドにおける同一分類用語辞書との突合結果の一例を示す図である。

【図14】グループ化処理ルーチンを示すフローチャートである。

【図15】センテンスグリッドにおいて、Actorに関してグループＩＤを付与した一例を示す図である。

【図16】センテンスグリッドにおいて、Dataに関してグループＩＤを付与した一例を示す図である。

【図17】センテンスグリッドにおいて、Actionに関してグループＩＤを付与した一例を示す図である。

【図18】グループごとの個別網羅度の結果の一例を示す図である。

【図19】総合的な網羅度と検証結果の一例を示す図である。

【図20】検証レポートの一例を示す図である。

【発明を実施するための形態】

【0021】

以下、図面を参照して本発明の実施の形態を詳細に説明する。

【0022】

＜本発明の実施の形態に係る概要＞

【0023】

本発明の実施の形態における概要を説明する。

【0024】

情報システムの要求仕様書や基本設計書の開発生産性と品質を向上させるために、同要求仕様書や基本設計書中に記述される、業務処理記述などを自然言語で記述したシナリオを含む情報システムの機能仕様において、同仕様に出現する設計要素に着目する。設計要素の種類別かつ設計要素の用語名別に、同一文脈でシナリオ中に定義されるべき設計要素用語の集合を、同一分類用語辞書として蓄積しておき、同一分類用語辞書を用いて、シナリオの記述網羅性を自動検証する。

【0025】

また、自然言語で記述されたシナリオを自動検証するために、シナリオを構成するセンテンスから、利用者とシステムの一連の相互作用の最小単位を抽出し、上述した自動検証するためのデータ構造とその変換プログラムを定義する。

【0026】

同データ構造に対して、 同一分類用語辞書を用いて、シナリオの網羅度を算出するためのベテラン技術者の知識をルール化した同一分類検証ルールを用いて、同一分類の観点から仕様書の網羅性を判定する検証プログラムを実現する。

【0027】

これらにより、自然言語で記述された要求仕様書のファイルを入力することで、その網羅度を自動的に算出する。

【0028】

＜本発明の実施の形態に係る検証装置の構成＞

【0029】

次に、本発明の実施の形態に係る検証装置の構成について説明する。図１に示すように、本発明の実施の形態に係る検証装置１００は、ＣＰＵと、ＲＡＭと、後述する検証処理ルーチンを実行するためのプログラムや各種データを記憶したＲＯＭと、を含むコンピュータで構成することが出来る。この検証装置１００は、機能的には図１に示すように演算部２０と、出力部５０とを備えている。

【0030】

入力部１０は、ユーザから入力された、分析または検証対象の電子化された、情報システムを用いた業務に関するシナリオを含む仕様書のドキュメントファイルを読み取りデータ前処理部２２に引き渡す。以下の説明ではドキュメントファイルは仕様書であることを前提に記述する。

【0031】

演算部２０は、データ前処理部２２と、仕様データセット２４と、センテンス識別部３０と、センテンスグリッドワーキングメモリ３２と、センテンスグリッド化部３４と、同一分類用語辞書３６と、同一分類検証ルール３８と、同一分類検証部４０とを含んで構成されている。

【0032】

データ前処理部２２は、入力部１０より入力された仕様書を、テキストファイルに変換し、形態素解析、設計要素の識別を行う。なお、データ前処理部２２の処理に関しては、既存技術を用いればよい（例えば、非特許文献２～４に記載の技術）。

【0033】

センテンス識別部３０は、データ前処理部２２で識別した内容を元に、仕様書のシナリオ中の各センテンスと、当該センテンスを構成する設計要素の用語の集合と、設計要素の種類とを識別し、仕様データセット２４に反映する。識別した結果をセンテンスグリッド化部３４に引き渡す。なお、センテンスグリッド化部３４に識別結果を引き渡すのではなく仕様データセット２４を参照させるようにしてもよい。

【0034】

仕様データセット２４は、データ前処理部２２によって識別された結果を格納するメモリ上のテンポラリーデータが格納される。仕様データセット２４には、シナリオ中に出現した、アクター、データ、画面、振る舞いの設計要素別の種類、設計要素の用語名、シナリオ中の出現箇所（何番目のセンテンスであるか）が格納される。

【0035】

センテンスグリッドワーキングメモリ３２は、仕様書のシナリオを構成するセンテンスと、当該センテンスを構成する設計要素用語とを構造化して格納するメモリであり、テンポラリーなデータ構造をメモリ上に展開する。

【0036】

センテンスグリッド化部３４は、センテンス識別部３０から引き渡された、センテンスと当該センテンスを構成する設計要素の用語の集合と設計要素の種類との識別結果を読み取り、各センテンスを構成する設計要素及び設計要素の分類に関する情報をセンテンスグリッドワーキングメモリ３２内の該当する各グリッドに格納（登録）する。
また、センテンスグリッド化部３４が、分類部の一例であり、ここでは、同一分類用語辞書３６を参照して、センテンスごとに、センテンスに含まれる設計要素の各々が属する分類を付与する。また、２つ以上のセンテンスの組み合わせについて、着目する設計要素の種類における設計要素が異なり、かつ、分類が同一であり、着目する設計要素の種類以外について設計要素が一致する場合、当該センテンスの組み合わせについて、着目する設計要素の種類に対して同一のグループＩＤを各々付与するように、センテンスグリッドに対してセンテンスごと及び設計要素の種類ごとにグループＩＤを登録する。

【0037】

同一分類用語辞書３６には、設計要素の種類ごとに、設計要素の種類について同一文脈でシナリオに出現すべき設計要素の集合からなる分類が格納されている。本実施の形態では、ある設計要素の種類について、同一文脈でシナリオに出現すべき設計要素の集合を、同一分類と定義する。ここで、仕様書のシナリオ中の設計要素を当該用語の派生形に置換しても、同様のシナリオが成り立つ場合、その派生形を含めた用語の集合を、同一文脈でシナリオに出現すべき設計要素の集合と定義する。同一分類用語辞書３６は、その同一分類となる用語の集合を、設計要素の種類別に記述した知識ベースの辞書である。同一分類用語辞書３６は、センテンスグリッド化部３４、同一分類検証部４０で参照される。

【0038】

同一分類検証ルール３８は、仕様書のシナリオの記述が同一分類の観点で網羅しているかどうかを検証するための手順をルール形式で記述したものである。同一分類検証ルール３８は、同一分類検証部４０の前処理部４２のルールとして、条件の判定のルールを定めると共に、実行部による実行を効率化するために、センテンスグリッドに記述されたシナリオのデータの加工、中間データの算出、閾値の設定等の事前の処理を行うためのルールを定めている。また、検証条件のルールとして、実行部４４による検証の閾値を定める。また、実行部４４のルールとして、条件に応じた検証結果の判定を記述する。例えば、検証条件のルールに定められた閾値の前後で、検証結果を問題有または無と判定するように記述する。同一分類検証部４０では、同一分類検証ルール３８のルールを適用して検証が実行される。

【0039】

同一分類検証部４０は、前処理部４２と、実行部４４とを含んで構成されている。
同一分類検証部４０は、センテンスグリッドワーキングメモリ３２に格納されたグリッド化されたシナリオ情報に対して、同一分類用語辞書３６、同一分類検証ルール３８を用いて、シナリオが同一分類の観点で網羅されているかどうかを検証する。同一分類検証部４０が、検証部の一例であり、ここでは、センテンスごとの、センテンスに含まれる各設計要素、設計要素の種類、付与された分類に基づいて、仕様書について、同一文脈でシナリオに出現すべき設計要素の集合の網羅性を検証する。

【0040】

（処理の具体例）
以下、入出力を含む検証装置１００の各処理部の具体的な処理について説明する。

【0041】

入力部１０は、図２に示すシナリオが記述された仕様書を受け付ける。また、同一分類用語辞書３６は、図３に示す内容であるとする。また、センテンスグリッド化部３４によるセンテンスグリッド化完了時のセンテンスグリッドワーキングメモリ３２のデータ構造の状態は図４に示す状態となる。このとき、出力部５０に出力される検証レポートは図５に示す内容となる。

【0042】

以下、センテンスグリッド化から検証レポートが生成されるまでの流れを詳細に示す。

【0043】

図６に、検証装置１００による仕様書の検証の実行から検証レポートを出力するまでの検証処理ルーチンの動作のフローチャートを示す。

【0044】

ステップＳ１００で、入力部１０において、図２に示すシナリオが記述された仕様書を受け付ける。

【0045】

ステップＳ１０２で、データ前処理部２２において、入力部１０より入力された図２の仕様書を、テキストファイルに変換し、形態素解析、設計要素の識別を行い、仕様データセット２４に蓄積する。図７に仕様データセット２４の例を示す。

【0046】

ステップＳ１０４で、センテンス識別部３０において、仕様データセット２４から、シナリオ中の各センテンスと、当該センテンスを構成する設計要素の用語の集合と、設計要素の種類とを識別する。識別した結果をセンテンスグリッド化部３４に引き渡す。以下、センテンスの識別の詳細について説明する。

【0047】

図７の仕様データセット２４のfile.txtファイルには、IDが１～４の４つのセンテンスが存在することが識別できる。例えば、IDが１のセンテンスは、「交付申請情報登録」である。これは、file.txtでは、１番目のセンテンスである。ここには、設計要素の種類としては、Actionだけが記述されており、それが、「交付申請情報登録」であることを示す。SentencePositionは仕様データセット２４上の位置である。IDが２のセンテンスは、「市町村が前年度実績額等を基に交付申請情報を登録する」である。これは、file.txtでは、２番目のセンテンスである。ここには、Screen以外の、Actor、Data、Actionの３つの設計要素の種類が登場する。それぞれ、Actorは、「市町村」、Dataは、「交付申請情報」、Actionは、「登録する」、である。IDが、３及び４についても、同様にセンテンスの内容を識別する。

【0048】

ステップＳ１０６で、センテンスグリッド化部３４において、センテンス識別部３０から引き渡された、センテンスと当該センテンスを構成する設計要素の用語の集合と設計要素の種類との識別結果を読み取り、各センテンスを構成する設計要素及び設計要素の分類に関する情報をセンテンスグリッドワーキングメモリ３２内の該当する各グリッドに格納する。センテンスグリッド化の処理の詳細については後述する。

【0049】

ステップＳ１０８で、同一分類検証部４０において、検証エンジン（図示省略）を実行して、センテンスグリッドワーキングメモリ３２に格納されたグリッド化されたシナリオ情報に対して、同一分類用語辞書３６、同一分類検証ルール３８を用いて、シナリオが同一分類の観点で網羅されているかどうかを検証し、検証結果を出力部５０に引き渡す。同一分類検証の処理の詳細については後述する。

【0050】

ステップＳ１１０で、出力部５０において、同一分類検証部４０から引き渡された検証結果を、検証レポートファイルとして加工して出力する。出力例については後述する。

【0051】

次に、ステップＳ１０６のセンテンスグリッド化部３４のセンテンスグリッド化処理ルーチンの詳細について図８のフローチャートを参照して説明する。

【0052】

ステップＳ２００で、センテンスと構成要素の読み込みを行う。センテンス識別部３０から引き渡された、センテンスと当該センテンスを構成する設計要素の用語の集合と設計要素の種類との識別結果を読み取り、センテンスグリッドワーキングメモリ３２上に展開する。仕様データセット２４について読み取った内容をメモリ上に展開する。また、メモリ上への展開の前に、図９に示すようにセンテンスグリッドの初期化を行う。

【0053】

ステップＳ２０２で、ステップＳ２００で読み込んだ全てのセンテンスに対する処理が終了したかを判定し、終了していればステップＳ２１６へ移行し、終了していなければステップＳ２０４へ移行する。

【0054】

ステップＳ２０４で、ステップＳ２００で読み込んだセンテンスのうち未選択のセンテンスを選択する。読み込んだセンテンス集合から（シナリオの記述順に）１つのセンテンスを特定して選択する。

【0055】

ステップＳ２０６で、ステップＳ２０４で選択したセンテンスから基本グリッドを生成する。選択したセンテンスを構成する設計要素を、センテンスグリッドの基本グリッド部分に格納する。図９に示す初期化されたセンテンスグリッドに対して、図１０に示すように基本グリッドを生成する。センテンスグリッドは基本グリッドと設計要素別のグリッドとに分けられる。例えば基本グリッドの項目について、Sec、SentencePosition、Actor、Data、Screen、Actionに要素を格納する。Secはセンテンスを区切るIDである。例えば２レコード目であれば、Sec「2」、SentencePosition「file.txt(2)」、Actor「市町村」、Data「交付申請情報」、Action「登録」と格納する。Screenの要素はないため格納しない。

【0056】

ステップＳ２０８で、選択したセンテンスについて、設計要素別の全グリッドをチェックしたかを判定し、チェックしていればステップＳ２０２に戻り、チェックしていなければステップＳ２１０へ移行する。なお、ここでいう全グリッドとはGroupIDを除くグリッドを指す。

【0057】

ステップＳ２１０で、選択中のセンテンスの設計要素別のグリッドのうち未選択の設計要素のグリッドを選択する。

【0058】

ステップＳ２１２で、ステップＳ２１０で選択したグリッドの用語が、同一分類用語辞書３６と合致する用語かを判定する。同一分類用語辞書３６に合致する用語が定義されていれば、ステップＳ２１４へ進む。同一分類用語辞書３６に合致する用語が定義されていなければ、ステップＳ２０８に戻る。

【0059】

ステップＳ２１４で、合致した同一分類用語辞書３６のＩＤと用語を抽出し、センテンスグリッドの当該設計要素において、同一分類用語辞書３６と合致する辞書の情報をセンテンスグリッドの該当部分に格納する。その後ステップＳ２０８に戻り、他の設計要素に対するセンテンスグリッドのチェックを行う。

【0060】

ここで、同一分類用語辞書３６と各センテンスの設計要素の突合について説明する。同一分類用語辞書３６の例は図３に示したものである。１番目の設計要素の種類である「Actor」から、基本グリッドに格納されたセンテンスに出現する設計要素を突き合わせる。図１０のSecが２のセンテンスは、Actorとして、「市町村」が出現している。これは、同一分類用語辞書３６の設計要素の種類Actorの１番目の分類の要素として出現している。図１０のIDが３及び４の要素も同様である。図１１は、同一分類用語辞書３６との突合結果を示したものである。センテンスが２～４に対して、Actorの用語に出現した用語「市町村」が、同一分類用語辞書３６の、設計要素の種類Actorの１番目の分類の要素で、「市町村」が合致したこと、またその「市町村」は同一分類用語辞書３６のActorの１番目の分類の中では、１番目の要素のポジションであることを示している。なお、説明の便宜のため、Actorの用語に着目して全てのセンテンスの突合結果について説明したが、処理上は選択したセンテンスごと突合が行われる。

【0061】

図１２及び図１３は、図１０で示した設計要素の種類：Actorに関する同一分類用語辞書３６との突合の処理を、設計要素の種類：Data及びActionについて実施した結果を示している。なお、図１１～１３の事例の場合、設計要素の種類：Screenについては、センテンス上に出現しなかったため、突合処理の結果は空白になっている。

【0062】

ステップＳ２１６で、全てのセンテンスの各々の設計要素別のグリッドごとに、グループＩＤ（以下、グループＩＤまたはGroupIDと記載する）を付与して、センテンスグリッド化処理ルーチンを終了する。

【0063】

次に、ステップＳ２１６のグループ化処理ルーチンの詳細について図１４のフローチャートを参照して説明する。

【0064】

ステップＳ３００で、全てのセンテンスに対する処理が終了したかを判定し、終了していればグループ化処理ルーチンを終了し、終了していなければステップＳ３０２へ移行する。

【0065】

ステップＳ３０２で、グループ化処理で未選択のセンテンスを選択する。読み込んだセンテンス集合から、シナリオの記述順に１つのセンテンスを特定して選択する。

【0066】

ステップＳ３０４で、全ての設計要素をチェックしたかを判定し、チェックしていればステップＳ３００に戻り、チェックしていなければステップＳ３０６へ移行する。

【0067】

ステップＳ３０６で、未選択の設計要素を選択し、同一分類用語辞書３６を参照して、当該設計要素と同一分類となる設計要素を含むセンテンスを抽出する。ここで抽出したセンテンスは、同じグループＩＤを付与する候補となる。

【0068】

ステップＳ３０８で、ステップＳ３０６で抽出した全センテンスをチェックしたかを判定し、抽出した全センテンスをチェックしていればステップＳ３０４に戻り、抽出した全センテンスをチェックしていなければステップＳ３０９へ移行する。

【0069】

ステップＳ３０９で、ステップＳ３０６で抽出した全センテンスから未選択のセンテンスを選択する。

【0070】

ステップＳ３１０で、ステップＳ３０９で選択したセンテンスの上記同一分類となる設計要素に対してグループＩＤの設定がされていないかを判定する。グループＩＤが設定されていなければステップＳ３１２へ移行し、グループＩＤが設定されていればステップＳ３０８に戻る。

【0071】

ステップＳ３１２で、抽出したセンテンスの当該設計要素以外の設計要素の値が全て一致するセンテンス集合を抽出する。ステップＳ３０６で抽出したセンテンス全体のうち、上記同一分類となる設計要素に対してグループＩＤが付与されていないセンテンス集合から、ステップＳ３０６で選択している設計要素（同一分類用語辞書３６を参照して格納した当該設計要素の値）以外の設計要素の値が全て一致するセンテンスを抽出する。ステップＳ３０９で選択したセンテンスにおいて、着目している設計要素以外の設計要素の値が全て一致するセンテンスが自分自身以外に存在しない場合でも、その１センテンスを抽出する。

【0072】

ステップＳ３１４で、ステップＳ３１２で抽出されたセンテンス集合に対して、当該センテンス集合における上記同一分類となる設計要素の各々に対して、同一グループＩＤを定める。グループＩＤは、当該センテンス集合の設計要素に対しては一意に定める。また、ステップＳ３０６で抽出したセンテンスのうち、ステップＳ３１２の条件に合致するセンテンスが、１センテンスのみであっても、センテンスが１つだけのグループとしてグループＩＤを付与する。

【0073】

ここで、グループ化の具体例について説明する。

【0074】

設計要素の種類「Actor」に着目したグループ化の具体例を以下に示す。

【0075】

図１３のSecが２のセンテンスにおいて、設計要素の種類：Actorの値は、「市町村」で同一分類用語辞書３６では、分類を識別するDicIDが１で、WordPositionは１である。センテンスグリッドにおいて、DicIDが一致するセンテンスを抽出する。ここでは、Secが３と４が抽出結果にあたる。これらのセンテンスで、注目している、設計要素の種類：Actor以外の設計要素を比較する。Data、Screen、Actionを比較して、Actor以外の設計要素が完全に一致するセンテンスは互いに存在しない。したがって、これらは全て異なるグループ、すなわち、異なる文脈で記述しているセンテンスであるとみなし、ActorのGroupIDとして、異なるもの（例えば、１、２、３）をそれぞれに付与する。設計要素の種類：Actorに関してグループＩＤを付与した例が図１５である。

【0076】

設計要素の種類「Data」に着目したグループ化の具体例を以下に示す。

【0077】

センテンスグリッドにおいて、DicIDが一致するセンテンスを抽出する。ここでは、Secが2と4が抽出結果にあたる。これらのセンテンスで、注目している、設計要素の種類：Data以外の設計要素を比較する。Actor、Screen、Actionを比較して、Data以外の設計要素が完全に一致するセンテンスは互いに存在しない。したがって、これらは全て異なるグループ、すなわち、異なる文脈で記述しているセンテンスであるとみなし、DataのGroupIDとして、異なるもの(例えば、１、２）をそれぞれに付与する。設計要素の種類：Dataに関してグループＩＤを付与した例が図１６である。

【0078】

設計要素の種類「Screen」については、同一分類用語辞と合致する設計要素は存在しないので、グループＩＤ付与の処理は実施されない。

【0079】

設計要素の種類「Action」に着目したグループ化の具体例を以下に示す。

【0080】

センテンスグリッドにおいて、分類を識別するDicIDが一致するセンテンスを抽出する。ここでは、Secが２と４が抽出結果にあたる。これらのセンテンスで、注目している、設計要素の種類：Action以外の設計要素を比較する。Actor、Data、Screenを比較すると、Action以外の要素が完全に一致する。したがって、これらは同一グループ、すなわち、同一文脈で記述しているセンテンスであるとみなし、ActionのGroupIDとして、同一のもの（例えば、１）をそれぞれに付与する。

【0081】

続いて、センテンスグリッドのグループＩＤが付与されていない残りのセンテンスについても処理を続ける。グループＩＤが付与されていない残りのセンテンスとして、Secが3のセンテンスが存在する。比較する対象はここでは存在しないので、これに前述のグループＩＤとは異なるＩＤ（例えば、２）を付与する。設計要素の種類：Actionに関してグループＩＤを付与した例が図１７である。

【0082】

以上がセンテンスグリッド化の処理の詳細である。

【0083】

次に、ステップＳ１０８の同一分類検証部４０の処理の詳細について説明する。

【0084】

同一分類検証部４０の処理は、仕様書に含まれるシナリオの中の同一文脈で出現する設計要素が、同一分類用語辞書３６に記述された同一分類に属する設計要素の集合をどの程度網羅しているかをチェックすることに相当する。網羅度１００％（ここでは網羅度１）が同一分類検証で目指す指標になる。

【0085】

同一分類検証ルール３８は、算出された同一分類用語辞書３６に対する網羅度を用いて、仕様の妥当性についての判定ルールを記述する。

【0086】

同一分類検証ルールの仕様の例を示す。例えば、同一分類検証部４０の前処理部４２について、「グループごとに網羅度を算出する。同一分類用語辞書３６の分類ごとに網羅度を算出する。設計要素の種類別に網羅度の閾値Sを設定してもよい。」とルールを定める。また、閾値Sは0.4と定められている。また、同一分類検証部４０の実行部４４について、「分類ごとの網羅度が閾値S未満となる分類については問題有と判定する。」とルールを定める。

【0087】

同一分類検証ルール３８を用いて、同一分類検証を実施する手順の例を以下に示す。

【0088】

４つの設計要素の種類（Actor、Data、Screen、Action）の各々について以下の処理を繰り返す。

【0089】

（１）１つの設計要素の種類に着目する
（２）全てのグループＩＤをチェックするまで繰り返す
（２－１）同一グループＩＤのSentence Positionを抽出する
（２－２）当該同一グループＩＤが付与され、かつ、該当する分類の用語と用語数（A）を同一分類用語辞書３６から抽出する
（２－３）該当する分類の用語のうち、当該同一グループＩＤが付与された設計要素と一致する用語（カバーしている用語）と用語数(B)を抽出する
（２－４）該当する分類の用語のうち、当該同一グループＩＤが付与された設計要素と一致しない用語（カバーしていない用語）を抽出する
（２－５）網羅率Cを算出する（C=B/Aで算出）
（２－６）全ての分類についてチェックするまで繰り返す
（２－６－１）対象とする分類についての全グループＩＤの網羅率Ｃを合算する（X=ΣC，Y件あるとする）
（２－６－２）網羅率の平均を求める（Z=X/Y）
（２－６－３）同一分類検証ルール３８を適用して、Zがあらかじめ定めた閾値S以下であれば対象とする分類の網羅度に問題ありと判定する

【0090】

図１７のグループＩＤを付与したセンテンスグリッドを対象に、上述した同一分類検証ルール３８を用いて検証した結果は次のようになる。

【0091】

同一分類検証は、前処理部４２による、同一分類用語辞書３６の記載項目とシナリオ別、すなわちグループＩＤ別の網羅度となる個別網羅度の算出と、実行部４４による、個別網羅度の結果を踏まえた同一分類用語辞書３６の分類別の総合的な網羅度の算出及び判定とがある。

【0092】

前者の前処理部４２の個別網羅度の算出では、設計要素の種類：Actor、Data、Screen、Actionに対してそれぞれ、グループは３件、２件、０件、２件、合計７件が形成されている。したがって、前者の個別網羅度の算出では、これら７件のグループに対する検証結果が導出されることになる。設計要素の種類とグループとの組み合わせによりグループが形成される。

【0093】

ActorのグループＩＤが１の場合は、file.txtの２つ目のシナリオが該当し、「市町村、市、町、村」の４つの同一分類用語辞書３６の用語のうち、「市町村」だけが登場しているため、網羅度は０．２５となる。

【0094】

７つのグループの個別網羅度の結果を図１８に示す。

【0095】

図１８の１件（１行分）の検証結果は、カンマ区切りにより、<Sec>、<Dictionary(ID)>、<Sentences>、<Coverage>、<Covered Terms>、<Uncovered Terms>の項目で記述される。１行が１つのグループに対応している。

【0096】

<Sec>は、検証結果の識別子を示す。ここでは、１から始まる連番としている。<Dictionary(ID)>は、該当する同一分類用語辞書３６の設計要素の分類のＩＤである。<Sentences>は、検証対象となるシナリオが記述されたファイル名とシナリオＩＤである。<Coverage>は、当該グループと分類との組み合わせに対する網羅度である。<Covered Terms>は、<Dictionary(ID)>が示す同一分類用語辞書３６の分類に属する設計要素の集合のうち、本グループが網羅する設計要素である。<Uncovered Terms>は、<Dictionary(ID)>が示す同一分類用語辞書３６の分類に属する設計要素の集合のうち、本グループが網羅していない設計要素である。なお、グループに対する網羅度が第１スコアの一例である。

【0097】

後者の実行部４４では、同一分類検証ルール３８に基づく網羅率を用いて、同一分類用語辞書３６の分類ごとの総合的な網羅度と検証結果を出力する。総合的な網羅度と検証結果を図１９に示す。

【0098】

検証結果は、同一分類用語辞書３６の４つの分類ごとの結果となる。上述した個別網羅度と、同一分類検証ルールに基づき、問題の有無が判定される。

【0099】

各検証結果（一行分）は、カンマ区切りにより<Sec>、<Dictionary(ID)>、<Coverage>、<Result>で構成する。

【0100】

<Sec>は、検証結果の識別子を示す。ここでは、１から始まる連番としている。<Dictionary(ID)>は、該当する同一分類用語辞書３６の用語のＩＤである。<Coverage>は、<Dictionary(ID)>が示す同一分類用語辞書３６の分類に対する網羅度である。<Result>は、上記網羅度に対する検証判定結果であり、同一分類検証ルール３８に基づき出力される。ここでの例では、問題有か問題無で判定される。なお、同一分類用語辞書３６の分類に対する網羅度が第２スコアの一例である。

【0101】

ここでは、平均網羅度の閾値を０.４と設定しているので、Actor（1）は問題有と判定されるが、それ以外の分類は問題無と判定される。

【0102】

最後に出力部５０から出力する検証レポートについて説明する。出力部５０において、同一分類検証部４０から引き渡された検証結果を、検証レポートファイルとして加工して出力する。

【0103】

上述の例から出力される検証レポートの例を図２０に示す。ここでは、「個別網羅度」、「総合検証結果」のタイトルと、各検証結果の記述項目名を加えた形に加工して、出力している。

【0104】

以上説明したように、本発明の実施の形態に係る検証装置は、仕様書のシナリオに含まれる各センテンスと、各センテンスに含まれる各設計要素の、設計要素の種類とを識別し、設計要素の種類ごとに、設計要素の種類について同一文脈でシナリオに出現すべき設計要素の集合からなる分類を格納した同一分類用語辞書を参照してセンテンスごとに、センテンスに含まれる設計要素の各々が属する分類を付与し、センテンスごとの、センテンスに含まれる各設計要素、設計要素の種類、付与された分類に基づいて、仕様書について、同一文脈でシナリオに出現すべき設計要素の集合の網羅性を検証することにより、仕様書におけるシナリオについて、同一文脈でシナリオに出現すべき設計要素の網羅性を精度よく検証できる。

【0105】

本発明の実施の形態の手法によれば、情報システムを利活用するシーンにおいて、情報システムを用いた業務に関するシナリオ中に定義されるべき、アクター、データ、画面、振る舞い等の設計要素用語の集合は、本来ベテラン技術者の暗黙知に相当する知識であるが、それらが同一分類用語辞書として形式知化されるため、技術者間の知識継承に有効である。

【0106】

また、従来は要求仕様書の検証はベテラン技術者が目視によりチェックをしており、数十ページから数百ページにわたる要求仕様書を多大な工数をかけて検証する必要があったが、本発明により検証を自動化することにより、作業の効率化が図れる。

【0107】

また、本発明の実施の形態の手法により、既存の要求仕様書の網羅性の観点からの仕様の品質度合いを効率的に把握可能となり、初級の技術者が大規模情報システムの保守拡張に取り組む場合でも、当該要求仕様書の問題点や不十分な点を事前に把握しやすくなる。これにより、現状の要求仕様書の網羅度の度合いに応じて、要求仕様書の改善の作業の見積りも容易になり、計画的に要求仕様書の改善に取り組める。

【0108】

また、改善され高品質化された要求仕様書に基づいた情報システムの開発により、仕様確認の手戻りの発生や、不十分な機能の実現による使われないシステムの構築の防止が期待できる。更に、発注者組織において高品質な情報システムが導入されることにより、業務の効率化への貢献が期待できる。

【0109】

なお、本発明は、上述した実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。

【符号の説明】

【0110】

２０ 演算部
２２ データ前処理部
２４ 仕様データセット
３０ センテンス識別部
３２ センテンスグリッドワーキングメモリ
３４ センテンスグリッド化部
３６ 同一分類用語辞書
３８ 同一分類検証ルール
４０ 同一分類検証部
４２ 前処理部
４４ 実行部
５０ 出力部
１００ 検証装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】