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

ホーム >  要求工学 >  2007年12月号 >  第38回：要求の曖昧さ 

前回、要求レビュについて解説した。そこで、要求の曖昧さをチェックすることが重要だとは述べたが、「複数の解釈ができることはないか？」というレビュ項目を示しただけで、要求レビュの具体的なやり方については説明しなかった。

今回は、要求仕様の曖昧さとは何か？それをどのようにして検出すればいいのか？について考えよう。

さて日常的な意味では、曖昧さというと、「ものごとがぼんやりしていて、何であるかはっきりしない様子」のことだろう。同じように、要求が明確に定義されていない（不明性）か、複数の意味に解釈できる（多義性）とき、要求が曖昧だと考えることができるだろう。

機能要求の構造と曖昧さ

そもそも曖昧さはどのようにして発生するのだろうか？

非機能要求については、本連載でもゴール指向要求工学などで定義する手法を何回か紹介しているので、ここでは機能要求の曖昧さについて考えていくことにする。

ソフトウェアの機能要求を、図1に示すように、「ある状況の下で何かのイベントを契機として、指定された動作を実行することにより、期待する結果を関係者（アクタ）にもたらす」ことだと考えてみる。

そうすると、機能要求における曖昧さを明らかにするためには、図1に示すような要求記述の構成要素と曖昧性との関係を考える必要があることが分かる。この場合、構成要素ごとの曖昧さと構成要素間の対応関係の曖昧さがあることにも注意しよう。

アクタ（関係者）

機能を誰のために提供するのかという問いに答えることは、それほど簡単なことではない。たとえばシステム開発ベンダは、情報システム部門からシステム開発を受注するとしても、開発した情報システムを実際に活用するのは、事業部門やその事業部門がサービスを提供する消費者であったりする。このような場合には、機能を利用するアクタから要求を抽出したり、アクタの行動を直接観察することはできないかもしれない。社内システムや、パートナー企業が明確な場合には、システムの利用者の意見を要求レビュの段階で早めに聞くことで対処できる。また、消費者増が予め特定できる場合には、そのような消費者の意見をまず聞くべきである。

しかし、そうでない場合にはアクタを明確に定義することはできないために、本質的な曖昧さが残ることになる。このような場合ではあっても、システムを継続的に進化させていくことができれば、運用情報に基づいてアクタの特性を分析することで、段階的にアクタを定義しなおしていくことができる可能性はある。このような本質的に曖昧さを含む要求については、曖昧さを制御する工夫を要求の中に予め組み込む必要があるだろう。

状況

機能がどのような状況で動作するかということを網羅的に考えることも、アクタを定義することと同じように、なかなか難しいことである。開発者は、機能がどんな場面で使われるかを知らないことが多い。また知る機会も少ない。しかし、それをいいことに開発者が自分の思い込みで機能要求を定義したのでは、開発した後で、こんな機能は使えないということになって、結局、大幅な手戻りが生じることになる。

状況で動作するのか、それとも特定の状況のときだけ動作するのかということも曖昧さの原因になる。このように、ある事柄の曖昧さは、その事柄に対して複数の解釈が対応する多義性に起因する。また、異なる言葉が同じ意味を持つ同意語の問題もある。

イベント

機能が動作する契機としてのイベントは正しく定義されているだろうか？機能の動作だけが正しくても、動作して欲しいときに動かなければ意味がない。

ある状況の下で、必要なイベントを定義できるだろうか？状況とイベントの関係を問うことが大切である。

イベントの解釈は一意に決められるだろうか？適用分野の知識がないと意味を理解できないことはないか？逆に技術的な用語でイベントを定義した場合には、顧客の立場で理解できないことになるのではないか？

イベントを発生するのは、システムの内部なのかそれとも、システムの外部からイベントが到着するのか？その形式はどうなっているのか？内容はどうか？

これらの点についても多義性が発生する可能性がある。

定期的なイベントの場合もあれば、リアルタイムなイベントや必要に応じてオンデマンドに発生するイベントもある。これらのイベントの特性を抽出しておかないと、設計段階で大幅な手戻りが発生することは明らかであろう。

入力

機能に対する入力は正しく定義されているだろうか？入力はどのように状況やイベントと関係しているだろうか？想定外の入力があるかもしれない。機能に関する入力の範囲を明らかにしておく必要がある。

動作

機能の動作の定義では、状況やイベントおよび入力に基づく動作条件、動作に対する制約、動作内容を明確に定義する必要がある。

処理内容の記述では、まず入力や出力の構造とその要素の値についても多義性が生じる可能性がある。また、指示代名詞や条件節の係り受けの範囲を確認しておくことが重要だ。とくに、論理的な関係、時間的な関係、手順的な関係に対して複数の解釈ができることが多いので、十分な注意が必要である。

イベントとも関連するが、永続的な動作なのか、永続せず動作完了後は消滅する揮発的な動作なのかという区別も必要になる。

結果

結果の記述についても、範囲、内容についての曖昧さをなくす必要がある。どういう状況で、どのイベントおよび入力に対してどんな出力や結果を期待するのかを明確にする。また例外状況はどのように規定されているだろうか？もし期待に反する結果が出たときには、責任はどこにあるのか？ここでの問題は、期待と機能要求の差異である。

計算処理できることには限界がある。この問題に対処するためには、結果に関する定量的な達成条件を定義することである。もし達成条件を含めて機能要求に曖昧さがなく、それでも与えられた状況の下で期待した成果が出なかったとすれば、必要なことは結果に関する達成条件を変更することである。

アクタが想定外の結果に反応して、想定外の行動を重ねた場合にシステムは予期しない結果を生むことはないだろうか？このような状況と結果の複数の組み合わせについても、システムが予期しない結果を生まないことを確認することが大切である。

---

このように、機能要求をアクタ、状況、イベント、動作、結果というように構成要素に分類して理解しておくことで、これらの要素の内容を明確化できるだけでなく、相互関係を分析することができるようになり、それに基づいて機能要求の曖昧さを低減できるようになることが分かる。

要求の曖昧さの分類[1]

要求の曖昧さには、用語の曖昧さ、用語の指示・修飾関係の曖昧さ、ドメイン知識に起因する曖昧さ、要求の構成に関する曖昧さ、システム化の範囲や構成に起因する曖昧さなどがある。

用語

用語の曖昧さには次の２つがある。

• 一つの用語が複数の意味で用いられている
• 異なる状況で同じ単語が用いられるときに、単語の意味が異なる

指示範囲

用語の指示範囲の曖昧さについては以下がある。

• 「その」や「この」など指示代名詞の指示範囲
• 「すべての」「などの」などの副詞の指示範囲
• 「～し」や「かつ」「あるいは」「しかし」「そして」「また」などの接続詞の指示範囲
• 「～のとき」や「～でないとき」など条件節の指示範囲

ここまで書いて気づいたが、この説明の中で曖昧な「など」を記述してしまっている点については、ご容赦いただくことにしよう。

ドメイン知識

ドメイン知識の有無によって用語の解釈が変化する。ドメイン知識として、適用分野、システム分野、開発範囲がある。

• 適用分野の知識がないと、用語の意味が分からないので要求を具体化できない。
• システム分野の知識がないと、顧客には開発者が記述した要求の意味が理解できないので、妥当性を判断できない。
• 前述したように、あるイベントがシステムの外部から発生することなのか、内部で発声させないといけないのかで、開発範囲の誤解が生じることがある。

システム化

システム化の対象を明確に定義しようとする場合に、次のような曖昧さが生じる。

・類型とその個体との混乱

たとえば、分類名と個体名の関係がある。あなたが所有する自動車は、分類としての自動車一般ではなく、個体としての自動車である。しかし、自動車といっただけではどちらを指すかが曖昧である。

・プロセスとプロダクトの混乱

動的な処理で結果を提示する代わりに静的なデータとして記録しておき、それに基づいて同じ結果を提示することができる。つまり同じことをプロセスとして実現するかプロダクトとして実現するかを決めないといけない。また、プロセスとプロダクトの組合せも考えられるだろう。

・揮発性と永続性との混乱

プロセスやデータの生存期間の曖昧さを解消するために、永続的とするのか揮発的とするのかを決めておくことは大切である。

依存関係

要求間の依存関係を整理すると、図２に示すように次のようになる。

• 要求の重複
• 要求の矛盾
• 要求の詳細化の混乱
• 要求の必要条件の混乱
• 要求の制約条件の混乱

要求の重複と矛盾は類似する要求間の関係である。これに対して要求の詳細化、必要条件、制約条件との関係は、ある要求を具体化するための関係であるといえる。もし、これ以外の要求間の関係を追加するなら、手順関係、時間関係なども考えられないことはないが、必要条件と制約条件で代替できると思われる。

以上述べたような要求の曖昧さを発見するための質問例を表２に示す。この質問では、要求自身の曖昧さの質問に加えて、要求間の関係の曖昧さのための質問を用意している。

関係の曖昧さとして、関係の不明性、関係の多義性、関係の型の不明性を示した。ここで関係の型というのは、上述した、詳細化、必要条件、制約条件である。類似関係は、重複か矛盾であるから、解消されなくてはならない。

要求レビュ

要求仕様書の品質を向上するためには、要求の曖昧さを解消することが重要になる。実際には要求の記述を繰り返し洗練していくことが必要になる。レビュでどんな曖昧さが指摘できるかを示すために。次のような要求記述をレビュしてみよう。

【要求記述例】[2]

（R1）：WebサイトでPCショップ販売支援システムを提供している。このWebサイトに見積書作成機能を追加する。

（R2）：見積りの対象はPCのHW、SW、ネットワーク機器、サプライ商品とする。

（R3）：利用者が購入価格の見積りをシミュレートできる

（R4）：Webサイトの閲覧者は見積書の発行を依頼し、見積書を受取ることができる。

（R5）：販売担当者が介在しなくても見積書を閲覧者に送ることができる。

（R6）：見積書を発行する都度、見積書を発行した記録を残す。

（R7）：見積書の作成でキーボードからの入力を減らしたい。

（R8）：Topページで見積書作成へのリンクを張る。

【レビュ例】

たとえば、次のようにして記述上の曖昧さを摘出することができる。

R1：Webサイト、PCショップ販売支援システムと見積書作成機能の関係が曖昧である。

R2：PCとHW、SW、ネットワーク機器、サプライ商品の関係が曖昧である。また、見積もり対象として、PCは入るのか入らないのかも良く分からない。これらは指示範囲の曖昧さの例である。

R3：見積もりをシミュレートするための条件やシミュレートの結果は何か？が曖昧である。
たとえば、シミュレートするための入力は何かが不明である。利用者（R3）と閲覧者（R5）やWebサイトの閲覧者（R4）の関係が曖昧である。

R4：見積書と見積もりの関係が曖昧である。見積書をどのように受け取るのかが曖昧である。見積書の発行を依頼する契機が曖昧である。
また、「発行」「受け取る」「送る」という用語の間の関係が不明である。さらに、シミュレートした場合には、何かを送ることはないのだろうか？

R5：販売担当者が介在する状況とは何かが曖昧である。逆に介在しない状況とは何かも具体的ではない。販売担当者が利用する機能はあるのかないのかが曖昧である。

R6：「見積書を発行する都度」とは何か？具体的なイベントが特定されていない。
見積書について、シミュレート、作成、発行、送ることの相互関係が曖昧である。
見積もり書を発行した記録とは何かが曖昧である。

R7：キーボードからの入力を減らしたいとしているが、具体的な入力やイベントが明確ではない。

R8：リンクを張るのは誰なのかが曖昧である。
またシステムの動作プロセスとして実現するのか、それともリンク情報をシステムのコンテンツ（プロダクト）として埋め込んでおくのかが曖昧である。

要求の曖昧さの留意点

設計してみないと、トランザクション量、チェック、タイミングなどについては確定しにくいことも事実である。これらの内容を要求定義の段階で確定してしまうと、設計段階になって性能が出ないことが判明することなどにより、要求が変更される原因になってしまう。

このような設計依存の情報については、項目としては定義するが、その値は未定として設計段階で確定する方が手戻りが少なくなるだろう。

まとめ

今回は要求の曖昧さと要求レビュについて説明した。要求仕様の曖昧さについては古くから問題だとして指摘されてはいるが、前回も指摘したとおり、要求のモデリングに比べると要求の曖昧さの構造についてはまだ十分に分析されているとは思えない。良いモデリングによってこの問題を解消できるという考え方が強いのかもしれない。しかし、現実には強力なモデリング手法が現場レベルで浸透しているかといえば、どうもまだ疑わしいのではないか。だとすれば、より現実的なアプローチとして要求の曖昧さを低減する手法の開発が望まれる。

---

■参考文献

• [1] Kamsties, E., Berry, D.M., and Paech, B., “Detecting Ambiguities in Requirements Documents Using Inspections”, pp. 68--80 in Proceedings of the First Workshop on Inspection in Software Engineering （WISE’01）, 2001
• [2] 加藤潤三、佐伯元司。大西　淳、海谷治彦、山本修一郎、要求獲得におけるシソーラスの効果・効用について、電子情報通信学会、ソフトウェアサイエンス研究会、2006年8月