要求仕様を記述する手法「USDM」って何？

皆さん、こんにちは。技術開発グループのn-ozawanです。
来週はハロウィンですね。ハロウィンと言えばカボチャのイメージが強いですが、元々の起源はカブだとか。カブの代用品としてカボチャが用いられ、気が付けばカボチャが定着したみたいですね。

本題です。
システムを開発していると、この仕様って何のためにあるの？とか、ユーザーはこの仕様で何を求めてるの？など、仕様の出所が分からないことがあります。この場合は有識者に質問することで解決するのですが、有識者へ質問する前に、要求と仕様の関係が整理された資料があると便利です。今回は、要求仕様を記述する手法として「USDM」を紹介します。

USDM

USDMは「Universal Specification Describing Manner」の略称で、要求仕様を正確に記述するための手法です。清水吉男氏が提唱し、SQuBOKなどの知識体系ガイドでも取り上げられています。

USDMは大きく「要求」と「仕様」で構成され、「要求」には「理由」と「説明」を記述します。以下はUSDMで記述された一例です。

要求はステークホルダがシステムに求めている事柄を、目的語と動詞を明確にして記載します。また、要求には、その要求が必要な理由や背景などがあります。各関係者との認識を共有し、認識のズレを防ぐために「理由」欄にそれらを記述します。もし補足事項や例示などがあれば「説明」欄に記述します。

仕様とは、そのシステムのあるべき姿であり、そのシステムが実現する事柄です。仕様の根拠は必ず要求にあります。ユーザーが求めていないことを勝手に仕様にすることはありません。上の画像でいうと、B列が「□」となっている行が仕様になります。

USDMの利点は要求と仕様の関係性が明らかになることにあります。ステークホルダからの要求がどのように仕様となるのか、また、その仕様の策定の根拠となる要求は何か、その理由は何か、などが一覧で追えるようになります。要求と仕様の関係性が明らかになることから、仕様漏れや、余計な仕様などの早期発見にも期待できます。

要求の範囲

要求は目的語と動詞で記述します。また、要求にはステークホルダが望む動作と、その条件が含まれています。USDMでは、要求の文中にある条件や動詞の「範囲」を重要視し、要求の表現を工夫するように記述します。例えば以下の要求があるとします。

印刷が出来ない状況が発生したときは担当者に知らせる。

上記の要求では、以下２点の範囲が曖昧です。

• 「印刷が出来ない状況」とは何か？
• 「知らせる」手段はなにか？

要求の範囲が広いと仕様漏れになりやすくなります。なので要求の範囲を狭め、より具体的に記述します。

印刷途中で用紙やトナーが不足すると分かった時点で、登録されている担当者へメールを送信する。

「印刷が出来ない状況」は「印刷途中で用紙やトナーが不足すると分かった時点」となり、「知らせる」は「メールを送信する」となりました。これにより要求はより具体性を持つことになります。

要求と仕様の階層構造

先ほども述べた通り、USDMの最大の利点は、要求と仕様の関係性が明らかになることです。USDMでは要求と仕様を階層構造で記述します。また、要求は「上位要求」と「下位要求」に分けられます。

要求は複数の要求に分割することが出来ます。例えば先ほどの要求を例にします。

印刷途中で用紙やトナーが不足すると分かった時点で、登録されている担当者へメールを送信する。

要求を分割するコツは「隠れた動詞を見つけること」です。一つの文章でも、複数の動詞が隠れています。例えば上記の要求であれば、用紙やトナーの不足を確認することと、メールを送信する、の２つになります。よって、上記の要求は以下の要求に分割することが可能です。

印刷途中で用紙やトナーが不足しているか確認する。

登録されている担当者へメールを送信する。

USDMでは、分割前の要求を「上位要求」、分割後の要求を「下位要求」として、階層構造で表現します。

仕様の抽出

要求を整理したら、要求から仕様を抽出します。USDMでは、仕様は要求に含まれる「動詞」もしくは「目的語」にある、としています。先ほどの要求を例にして説明します。

登録されている担当者へメールを送信する。

上記の要求であれば、動詞は「送信する」で、目的語は「メール」になります。メールを送信するにはメールアドレスが必要になります。メールアドレスは担当者の情報から取得すればよいでしょう。なので以下の仕様が抽出できます。

１．担当者マスタから担当者情報を取得する。
２．担当者情報からメールアドレスを取得する。
３．取得したメールアドレスへメールを送信する。

ざっと３つほど仕様が抽出されました。しかし、これだけでは不足していそうです。担当者マスタから担当者情報を取得する際、取得する条件は何でしょうか？全社員でしょうか？また、メールを送信する際、多数へ送信する場合はBCCで送信した方が良さそうです。

更に仕様を抽出するには、再度、要求とその要求の理由や背景を勘案して抽出していきます。分からなければステークホルダと検討の場を用意するのもいいでしょう。必要あれば要求そのものを見直すこともあり得ます。

おわりに

USDMについてざっくりと紹介しました。要求定義での記述手法としては非常に有効な方法かと思いますが、実際にやってみると意外と難しいです。私は仕様をプログラムでコーディングしてきた人間なので、要求や仕様を日本語化するのに慣れていないだけかもしれません。

USDMを提唱された清水吉男氏はいくつか書籍を販売しておりますので、興味ある方は是非読んでみてください。

ではまた。