いいかげんな要求仕様を自動的にチェックする．

論文

CSVとか，RDBとか，XMLとかいろんなデータの寄せ集めにおいて，データの整合性をチェックする仕組みを模索していたら，「いいかげんなデータの整合性をチェックする」手法ではなくて「いいかげんな要求仕様の整合性をチェックする」手法がひっかかった．

Handling non-canonical software requirements based on Annotated Predicate Calculus
Knowledge and Information Systems
http://www.springerlink.com/content/5351217j00qh3183/?p=6e574e8eb36d455db44d1c6ad3a1bc5c&pi=3

Annotated Predicate Calculus

なんか，普通の論理式P の後ろに :t とか :f とか :T ， :⊥ ， :fp ， :tp などをつけて

  • P:t Pは必ず真
  • P:f Pは必ず偽
  • P:T Pは矛盾する
  • P:⊥ Pかどうかわからん
  • P:tp Pは真になることがある
  • P:fp Pは偽になることがある

というアノテーションをつける論理計算らしい

例：
図書館システムの例

  • ほとんどの場合，本が予約されていたら，予約した人がその本を借りることになる
    • Reserve(User,Book):t => Borrow(User,Book):tp
  • 今のところ，利用者が延滞している場合に通知するかについては規定がない
    • Borrow(User,Book):t ^ Overdue(Book):t => Notify(User,Book):⊥

「わからん」というのを論理体系にもってくるのは面白いけど，役に立つのかな？

要求仕様とシナリオとテストケース

Annotated Predicate Calculus を評価実験するための枠組み

  • 要求仕様
  • シナリオ（＝"入力"と"期待する出力"：テストケース？）

が与えられた時に，要求仕様を「必要」「有用」「不要」に分類する．

サンプルシナリオ

これを使ってこんな要求仕様とシナリオを作ったらしい．

住宅の駐車場に車が入ってよいかどうかを判断するシステム

要求仕様：

1) 管理人が特別に許可した車は入ってよい
2) 管理人は業務用車輌は許可する
3) 普通，許可された車にはシステムによって自動的にガレージが割り当てられる
4) 普通，業務用車輌にはガレージが必要である

1) Authorized(V):t => Enter(V):t
2) Logistics(V):t => Authorized(V):t
3) Authrized(V):t => Garage(V):tp
4) Logistics(V):t => Garage(V):tp

シナリオ：

input: Logistics(ダンプカー):t
expected output: Garage(ダンプカー):tp

この場合， 1) は「不要」 4) は「有用」だが「必要」ではない（2と3があれば導けるから)

「だから，1と4は要求仕様から消してよい」....て書いてあるんだけど，車が入ってよいかどうか判断できなくなるけどいいのか？

他にも，車を割り当てたガレージに対して，

9)壊れたガレージは修理する必要がある
10)普通，耐用期限が過ぎたガレージは修理する必要がある

9) Distributed(G):t ^ Damaged(G):t -> Maintain(G):t
10) Distributed(G):t ^ Expired(G):t -> Maintain(G):tp
※ Distributed(G) : Gは車が割り当てられているガレージである

という要求仕様を追加して

「この要求仕様の欠点を洗い出すために，こういうテストケースを考えました」

input: not Distributed(G3) :t ^ Damaged(G3) :t
output: Maintain(G3): t

「でも，これだけからは Maintain(G3): ⊥ （G3は修理していいかどうか不明）
となって，テストに失敗します」

「ほら，こうやってシステム開発者にガレージの種類（Distributed(G)かどうか？）
をチェックさせることを思い出させるでしょ」
で評価の章がおわっている

....うーん，なんかさっぱり有用性がわからん．