KAOS (43) 衝突を管理する:体系だったプロセス (3.1.3-1)

要求内の衝突をより体系立てて扱うことができれば,よりよい結果を得ることができる.(p.90)

本項では,体系だった方法として,次の4つのステップが示されている.

重なり合っている要求文を見つける

重なり合いは,純粋に文の構成要素から見つけることができる 1.ここでは,単純な形態素解析だけできれば良いだろう.同じような名詞(句)があれば,最初の重なりの候補ということになる.

そこでの衝突を見つけ,記録する

見つける方法は,自由な方法・経験的方法・形式的方法・半形式的方法である.形式的方法と半形式的方法については,次章で詳細な説明がある.形式的方法は,なんらかの数学的なモデルに従った記述のこと.半形式的とは,一般的な図式言語に代表されるように,図式自体は明確な形式と意味を持っているが,その中に書かれる記述が自然言語であるような場合を指している.

このうち経験的方法では,「減らす(decrease)」と「増やす(increase)」という対立する語を見つけて,衝突がないかを確認する方法が示されている(図書館システムにおける「購読ジャーナル数を増やす」と「運用コストを減らす」.まったく違ったテーマだが,購読ジャーナル数を増やせば,単純には運用コストは増加するので,衝突していることになる).形式的方法については,この(かなり)先で示される.
記録に関しては,指標化するためのおもしろい方法が紹介されている(p.91)網羅的に文同士の間に衝突があるかないかを確認して,最終的に文書としての衝突数を知る方法である(ある程度サイズの問題はクリアできる方法だが,そのまま実務で使うのは難しいかもしれない).

衝突の解決策を作る

解決策を考えるというのは,知的な作業である.ここが,この項で一番おもしろい.しかし,次回の紹介としたい.

解決策を評価し,最も良いものを選ぶ

ここは,全くタイトルの通りである.

(nil)

Notes:

  1. Spanoudakis, G.; Finkelstein, A.; Till, D., Overlaps in requirements engineering. Automated Software Engineering 1999, 6 (2), 171-198.

KAOS (42) 不整合とうまくつきあう (3.1.2)

強い対立および弱い対立は,より一層(解決するのが)困難である.(p.89)

前回は,対立の種類分けであった.大きくは,「衝突(clash)」と「対立(conflict)」と訳し分けた2つのグループがある.対処もこの2つで異なる.

前者は,言葉の問題である.取り決めで済む場合も多く,解決は容易である.同一概念に異なる言葉を使っているのであれば統一する.そのときに,用語集にまとめる.異なる言葉をどうしても使う必要があれば,シノニム(同意語)として,用語集に記載する.

逆に,異なる概念に,同一の言葉を使っているのであれば,用語集にある言葉の定義に従って,適切に使い分ける.構造上の衝突は,単語定義よりは複雑だが,話し合えば解決は可能だろう.多くの場合,(官僚的でなければ)コトバの使い方に利害は絡まないからである.

複雑なのは,対立の場合である.

異なる利害関係者が,それぞれの立場から,要求を出している.単に,文言だけを調整しても解決しない.その要求の理由にさかのぼって,検討する必要がある.

また,非機能要求同士,或いは機能要求と非機能要求の間には,本質的な不整合があるという.以下が例である.

  • セキュリティを強化するためのパスワードに基づく認証を行う.このことは,しばしば,使用性の要求と衝突する
  • 守秘性とアカウンタビリティ(説明義務)は,衝突しやすい
  • システムのスループットに関する性能要求は,しばしば,安全性要求と衝突する
  • システムの保守性を増加させようとすると,開発コストの増大につながりやすい

上記の2番目に,最近出会った.

少し前に,都心のホテルの喫煙所にいたところ,ひとりの男性が大声で電話を掛けていた.手持ちぶさたであったし,聞くとはなしにきいていた(夜間静かな場所で,大声でしゃべっているのだから,聞きたくなくても聞こえてしまう).

それは,隠しておきたいって? QAの時間になったら,我々は奉仕者なんだから,全部の質問に答えないといけないんだ.

それが,国民の知る権利というもんだ.

そういうときの「答え方」をおしえてやる.

調査中の事案について,回答は控えさせて頂きます.

ふむ.うまく衝突回避している.

 (nil)

KAOS (41) 不整合のタイプ (3.1.1)

不整合が生じることが,規則からの逸脱という例外的な事象ではなく,それがルールである世界に住んでいる.そのことを,要求工学の実践者は,知る必要がある. (p.88)

3.1節は,不整合がテーマである.最初に不整合の規則があり,次にその扱い,最後に不整合の解決方法が記述されている.最後には,不整合と云うより一般的な問題解決手段にも利用できる(それも,とても有効な)アイデアが示される.従って,多少ゆっくりと進むことにする.

最初が,不整合の規則である.

用語の衝突

異なる文間で,異なった名前が,同じ概念を示している.

指示するものの衝突

異なる文間で,同じ名前が,異なった概念を示している.

構造的衝突

異なる文間で,異なった構造が,同一概念に対して与えられている.

これは少し分かりづらい.例としては,会議管理システムにおいて,都合の悪い日を,ある人は,日にちの列挙で与える.別の人は期間で与える.

強い対立

異なる文間で,論理的に偽となる.例としては,「参加者の予定は,他者に伝えてはいけない」と「会議開催者は,全ての参加者の予定を知っていることが望ましい」の関係.

弱い対立あるいは不一致

ある条件下で,異なる文が同時に成立しない.ここでの条件とは,境界条件である.例えば,図書館館員の立場から(必要とされるときに本がないと困るので)「借り手は,2週間以内に本を返却しなければならない」という要求を出す.一方借り手の立場からは,「借り手は,必要な期間本を借りたままにすることができる」という要求を出す.必要な期間が2週間以内であれば,両者は成立するが,それを超えると問題が生じることになる.

(nil)