NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第87回 要求文の曖昧さの摘出法国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 山本修一郎

国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授
(前NTTデータ フェロー システム科学研究所長)山本 修一郎

最近、システム開発文書品質研究会(ASDoQ)[1]に参加して、コラムを書きはじめた[2]。ASDoQでは、開発文書の曖昧さが議論されることが多い。要求文書に記述された要求品質を向上するためにも、曖昧さのない要求文を書くことが大切になる。そこで今回は、要求文書の曖昧さを摘出する方法を紹介したい[3]

要求文書の曖昧さには、記述された文に起因する曖昧さと、システム開発に起因する曖昧さが要求文に反映された結果として生じる曖昧さがある。この2種類の曖昧さを区別することが大切だと指摘されている[3]

文の曖昧性

文についての曖昧性には、表1に示すように、用語の類義性と多義性、修飾関係の多義性がある。

表1 曖昧用語のチェック方法

表1 曖昧用語のチェック方法

用語の類義性をなくすには、異なる単語で同じ意味を表現することがないか確認することが必要になる。また、用語の多義性をなくすには、ひとつの単語で異なる意味を表現することがないか確認することが必要になる。

ここで、多義性には同じ用語で、
①概念と実体
②プロセスとプロダクト
③変化する性質と変化しない性質
の両方を参照することがないか注意する。

概念と実体というのは、オブジェクト指向でいえば、クラスとインスタンスを同じ名詞で混用することである。たとえば自動車というとき、自動車一般なのか、特定の自動車なのかを区別する必要がある。

プロセスとプロダクトの混用の例として、代名詞によってプロセスが生成する生産物と、プロセスそのもののどちらを指示するか決められないことがある。

変化と不変では、対象物の変化する特性と変化しない特性の両方を同じ用語で指示しないように区別する必要がある。

修飾関係の多義性では、ある文の中で複数の参照関係を持つ可能性がないように注意する必要がある。たとえば、
「認証できるICカードと識別コードを入力する」
という文では、「認証できる(ICカードと識別コード)を入力する」のか、「(認証できるICカード)と(識別コード)を入力する」のかという2通りの解釈ができる。最初の解釈では、識別コードがICカードの中に記録されていて認証できる場合である。2番目の解釈では、認証できるICカードに加えて、外部から別の識別コードを入力する場合である。

システム開発に起因する曖昧性

システム開発では、要求文書の内容、適用領域の知識、システムと環境の相互作用、システムのアーキテクチャに起因する曖昧性が発生する可能性がある。

◆要求文書の曖昧性

要求文書に記述された事柄に基づいて、複数の解釈が発生する場合がある。この理由は、要求文の間に明示的な関係だけでなく、暗黙の関係があるからである。モデル図式などでは、記述されていないことは存在しないことになる。しかし、日本語で記述された要求文では、記述されていないことについては、読者が自由に補ってよいと考えがちである。そうすると、暗黙の関係が発生して読者によって解釈が異なる要求文が出てくることになる。また、記述されていることについても、要求文の間に明示的な複数の解釈関係が発生することもある。したがって、要求文に対する解釈規則を決めておくことが必要になる。

◆適用領域知識の曖昧性

適用領域知識のある読者なら一意に解釈できる要求文が、適用領域の知識がない読者には解釈できないために、勝手な解釈をしてしまうので曖昧性が発生することになる。

この問題に対処するためには、要求文で不足する適用領域知識を説明として補足する必要がある。

◆システムと環境の相互作用

システムと環境の相互作用については、図1を用いて説明する。ユーザーはシステムの外部環境から、システムを操作することにより、システムが動作する契機を与える。システムはこの契機に基づいて、ある条件の下で、システムが応答した結果をユーザーが確認する。環境側では、ユーザーが操作を確認する。ソリューション側では、システムが契機に基づいて応答する。要求では、環境側におけるユーザー操作と確認を記述する。

一方で要求仕様(あるいは要件)では、ソリューション側における、契機に対する応答を記述する。

このとき、システムと環境の相互作用に関する要求と要件の混乱や抜けが生じるために、要求文書の曖昧性が発生することになる。

たとえば要求として、操作ではなく契機を記述したり、確認ではなく応答を記述する可能性がある。

また、要件記述についての曖昧性の原因を分類すると表2のようになる。表2では、要件を<契機、応答、条件>からなる遷移単位ごとに分解して整理することができるという前提で分類している。要件が、このような遷移単位ごとに分解できる理由は、図1で説明したことから分かるだろう。

図1 システム環境

図1 システム環境


表2 曖昧性の観点

表2 曖昧性の観点

続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。

第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。