Hatena::ブログ(Diary)

たまゆら雑記 このページをアンテナに追加 RSSフィード Twitter

2011-04-03

要求仕様定義ガイドラインを読む

はじめに

 USDMに関する記事をインターネット上で検索すると、「要求仕様定義ガイドライン」 に触れた記事がヒットします。ただし、内容について書かれたものは少ないようです。

 そこで、どんな内容なのかUSDMとの関連に絞って書こうと思います。


USDMとガイドラインの関係

 ガイドライン執筆の動機として、要求仕様書の品質が良くないため、ユーザ企業として何とかしたい。何を書けばよいのかは分かっているが、いかに書くかはよく分からない。どのような要求仕様書を書けばよいのか模索しているとき、清水吉男さんが提唱しているUSDMに出会い、USDMをベースにガイドラインを作ったということです。


なぜUSDMを採用したのか

 JUASがUSDMを採用した理由として次のようなものが挙げられています。

1.システム要求を二段階で記述すること。

2.下位要求の基準があること。

3.要求の下に仕様を記述することにより、仕様を漏れなく抽出できること。

4.理由を記述すること。

5.思いついた方式を記述する欄が用意されていること。

 この理由は、USDMの特徴そのものと言えます。USDMの特徴=採用理由なのですから、他の選択肢は無かったと言えます。そもそもUSDMがきっかけでプロジェクトが立ち上がった訳ですから、そうなるもの仕方が無いのかも知れません。


USDMに足りないもの


優先順位

 USDMの要求には優先順位が付けられていません。ガイドラインでは 業務上の優先度を表現できるように、USDMのテンプレートを変更するように言っています。優先度は三段階で表現します。

優先度1:必須機能

優先度2:重要機能

優先度3:あると良い機能


抜け漏れ、ダブり、矛盾の発見法

 機能×機能のQFDを用いて、要求の抜け漏れ、ダブり、矛盾を見つけられるとしています。機能と機能が矛盾する場合、交差するセルに×を、ダブりがある場合には交差するセルに△を記述するようにします。


要求の記述レベルについて

 USDMでは上位要求、下位要求、仕様で表現しますが、書き方によっては詳細な記述を表現することが可能になります。そこで、ガイドラインでは、入出力仕様とデータ加工仕様に関しては要求仕様書に記述するのではなく、入出力定義書に記述することを推奨しています。

 各社の開発プロセスでは、入出力定義書を外部設計の段階で記述するように書かれていることも多いと思いますが、ガイドラインでは要求仕様と並行して書くことを推奨しています。


要求仕様書とUSDMの関係

 ガイドラインでは、要求仕様書とUSDMはイコールではありません。要求仕様書の一章をUSDM表記で書くこと推奨しているのです。ガイドラインに載っている要求仕様書のプロトタイプを次に示します。

  1. はじめに
    1. 目的
    2. 範囲
    3. 専門用語、頭文字語、略語の定義
    4. 参照
    5. 概要
  2. 全体の記述
    1. 製品についての考え方
    2. 製品の機能
    3. ユーザの特性
    4. 制約
    5. 前提
    6. 先送りされる要求事項
  3. 要求と仕様

付録

索引

 IEEE830の要求仕様書を参考にしており、「要求と仕様」にUSDM表記を当てはめています。

 さて、上記プロトタイプをみると、疑問に思うことがいくつかあります。

 USDMに足りないところでQFDを用いるように言っていますが、上記プロトタイプには入っていません。

 エンタープライズ系システム開発の要求仕様書のプロトタイプにもかかわらず、「製品の機能」と書かれています。どうにも腑に落ちません。ガイドラインでは、この製品の機能、制約、前提に業務要求を記述するように言っています。そうであるなら、「製品の機能」ではなく「業務要求」とすれば良いはずです。僕はなぜ変えていないのか分かっていません。

 また、この表現では、業務要求とシステム要求の関係が分かりません。システム要求と仕様のトレーサビリティを重視しているにもかかわらず、ユーザ企業にとって重要だと思われる業務要求とシステム要求の関係を記すところが無いのも疑問に思うところです。


図書管理システム要求仕様書へのUSDM適用による有効性評価

 図書管理システムの要求仕様書として、ユースケース記述、画面遷移、ER図(T字形ER)、プロトタイプ、USDMを記述しています。

 上記に書かれている要求仕様書のプロトタイプと異なるので、JUAS主催のセミナーで質問したところ、「書いた人が違うから」という回答をもらいました。このような種類のガイドラインは、章ごとに担当を割り当てて記述することが多いので、仕方が無いところがありますが、ガイドラインとして一貫性を持たせてもらいたかったと思います。

 要求仕様書を書きながら、USDM表記について得られた知見として、仕様の必要性を伝えることができ、仕様のトレースが可能になることを挙げています。ただし、機能の記述方法、機能の区分、機能の抽象化はベテランと未熟者との間で差が大きくでき、ばらつきができたということです。USDM表記を採用すると、要求記述のばらつきが少なくなることを期待している人もいるようですが、実証実験の結果をみると、スキルによって異なることが分かります。


まとめ

 章ごとに担当者が異なるため、本ガイドラインを最初から読むと混乱します。ある章では大切だと書かれていることが、他の章では無視されています。ですから、自分が関心を持つところを読むのが良いでしょう。

 ユーザ企業が要求仕様書についてどのように思っているのかを知るには良いガイドラインだと思います。(例えば、新規、訂正、取消、追加の話など。具体的な話を知りたい人は是非ともガイドラインを手に取ってください)

 しかし、組込み系システムへの適用事例が多いUSDMを、エンタープライズ系システムの要求仕様書にどのように適用すればよいのかというヒントを得たいと思うのであれば、不満を持つかもしれません。ユースケース記述からUSDM表記に落とす方法を採用していますが、それは清水吉男さんの書籍にも書かれていることなので、特に新しい知見を得られるものではありません。

 僕が今までこのガイドラインについて触れていなかったのは、USDMについて書くべき内容が無かったからです。しかし、幾人かの方から問い合わせがあったので、この記事を書きました。