Technical Information
要求仕様の曖昧さを理解し、ソフトウェアテストを組み立てる
株式会社ベリサーブ 東日本オートモーティブ事業部 事業部長 東 弘之
自然言語は思っているより曖昧です。当社ソフトウェアテストチームは、自然言語で記述された要求仕様書をテスト活動の入力情報として用いる場合が多くあり、多くの要求仕様の曖昧さと向き合ってきました。
本稿では日本品質管理学会誌にも投稿いたしました自著論文を一部引用させていただきながら、要求仕様の曖昧さや、それら曖昧さへの向き合い方をご紹介いたします。
１．要件定義にまつわる課題
JUAS（※1）の調査によると、プロジェクトの工期遅延の理由のうち55%が要件定義の問題であると言われています。その要因には、大きく2つが考えられます。
１．ユーザーからベンダーへ要件が正しく伝わらないこと
２．リスクの認識・合意が不十分であること
近年、短納期化やコストダウンを達成するための開発手法の一つとして、ソフトウェア開発の外部委託化が進み、開発工程ごとに、複数の組織を跨いで開発することが増えています。その結果、組織間に要求の認識齟齬が発生し、受入試験までのその齟齬に気づかず問題発覚が遅延するなどの問題が生まれるようになりました。このような問題へ対応するために、要求仕様書を非曖昧に作成し、要求を正しく伝える、要件を正しく理解していただくことが重要な課題となっております。
自然言語には曖昧さに気づくための言語学的な技術に限界があり、曖昧さを完全に排除することは困難です。しかし、自然言語の特徴を理解し、適切な対応をすることにより、曖昧さを減らす・曖昧さによる影響を下げることは十分可能です。
※1 JUAS（Japan Users Association of Information Systems）：一般社団法人 日本システム・ユーザー協会
２．要求仕様の曖昧さを知る
要求仕様を非曖昧に作成するためには、まず「曖昧要求仕様」とは何かを知る必要があります。要求仕様の曖昧さについてはさまざまな定義が存在しますが、本稿ではDaniel M.Berry とErik Kamsties による、書籍「ソフトウェア要求の全体像」（原題：Perspectives on Software
Requirements）2章における定義と分類（図1）をご紹介します。
【曖昧な要求仕様（Kamtiesによる定義）】
読み手の背景知識があるにも関わらず複数の解釈があるなら、曖昧な要求である。
本定義における「背景知識」とは、要求を解釈するために必要な知識のことを指し、要求文書、適用分野、システム分野、開発分野の4つからなります。これら背景知識が読み手に不足していた場合、要求仕様が全うでも複数の解釈が生まれてしまいます。書き手は、読み手の背景知識レベルの想定と対処を考慮に入れる必要があり、読み手は要求文章を正しく解釈するために必要な「背景知識」が何かを知り、理解する必要があります。
ここで、書籍「ソフトウェア要求の全体像」より曖昧さの例を紹介します。
自然言語の曖昧さの例
① The police shot the rioters with guns. （警官は暴徒たちを銃で撃った）
①の例では、言語学的な曖昧さを含んでいます。人によっては「銃で武装した暴徒たちを、警官は撃った」というように、この文章を捉えます。これは"with guns"が"shot"と"rioters"のどちらの修飾語句にもなり得るからです。これは図1の2-1「接続曖昧さ」の例となります。
② Sue is visiting her cousin.（スーは彼女のいとこを訪ねている）
③ He is tall.（彼は背が高い）
②、③の文章は共に不確定性と言われる曖昧さを含む文章で、②は一般性、③は漠然姓に分類されます。②の文章のcousin（いとこ）は、性別の判断はできないので一見曖昧だとも言えます。しかし、読み手、書き手にとって性別の判断情報が不要であるならば、満足な意思疎通を行えます。一方③のtall（高い）は、文化などにより異なります。プロバスケットボール選手にとって、身長180cmは高いとは言えません。漠然姓は読み手に取って解釈が異なりやすく、境界値ケースで多く現れます。
④ Shut off the pumps if the water level remains above 100 meters for more than 4 seconds.
（4秒より多く水位100メートルを上回ったなら、ポンプを止めろ。）
④の例は、ソフトウェア工学的曖昧さの例です。読み手の適用分野知識の有無により複数の解釈が生まれます。下記のように色々な解釈が可能ですが、多くの工学領域での標準的な解釈は、解釈3となります。タンク内の水が波打たない場合は全て同じ結果となり、実装が簡単な解釈4でも良いですが、波打った場合は危険な水位になる可能性があります。
解釈1：平均水位が100メーターを上回る
解釈2：中央値水位が100メーターを上回る
解釈3：二乗平方根水位が100メーターを上回る
解釈4：最小水位が100メーターを上回る
３．要求仕様の曖昧さ情報を活用する
自然言語の特徴から、自然言語で書かれた要求仕様の曖昧さを完全に排除することは不可能です。実際には、要求仕様曖昧さを排除することがコストや期間的に困難で、曖昧なまま進めるプロジェクトもあります。そこで、要求仕様の曖昧さ度合の情報をソフトウェアテスト工程に活かすことはできないか？と考え、次のような仮説を立て検証を行いました。日本品質管理学会誌に投稿した自著論文では、この仮説について考察を行っています（図2）。
この仮説が正しいかを、とあるプロジェクトで検証を行いました。その結果、曖昧さ度合いと欠陥密度の間に、相関があることを示す結果を得ることができました（図3）。
この関係性を用いることで、リスクベースドテストのインプットとしてより効果的な指標が得られます。すなわち、設計時の質問内容や質問領域を調査し、欠陥の多い領域を推定、テスト組織やテストの厚みを決めるときの参考にすることができます。ソフトウェアテストの見積・計画は、困難なことが多いのですが、要求仕様の曖昧さは、外部委託開発形態のプロジェクトで確認することのできる、数少ない欠陥予測の情報として活用が期待できます。
４．要求仕様の曖昧さを正す
曖昧さを活用する一方、曖昧さを減らす取り組みも、もちろん行っています（むしろ、こちらが王道です）。プロジェクトを成功に導くためには、上流成果物の品質を高めることが不可欠であり、近年、お客様（委託元企業）からのニーズも、テスト設計工程から、要求仕様の作成工程、プロセスづくりと、より上流工程からの品質づくりへと変化しています。図4は当社の品質向上のソリューション例となりますが、①、②の部分における取り組みが曖昧さ削減へ効果的な活動となります。
おわりに
本稿では自然言語を用いた要求仕様の曖昧さ、および当社で行っている曖昧さへの向き合い方を2つご紹介しました。何より重要なのは、自然言語は曖昧であることを知っていることです。曖昧さにはどのような種類があるか、要求仕様書を読むために（書くために）必要な背景知識は何か、などを知っておくことで、より正しく品質を理解できるようになると思います。本稿が、皆様のソフトウェア品質向上活動の一助になれば幸いです。
この記事をシェアする
