The Rational Edge

要件定義の考古学

by Benjamin A. Lieberman, Ph.D.
Senior Software Architect
Trip Network, Inc.


2002/12/26

---

付録：ユースケース変換のための構造化要件定義

---

　以下の文は、顧客サービスや自動サービス提供システムのために架空の通信会社が要求してきた大規模要件定義からの抜粋だ。これらの要件定義は行為者の特定や最初のユースケースの作成、システム用データディクショナリにおける最初の部分の抽出に使うことができる。

■「CUSTOMERPro顧客サービスシステム」システムの要件定義

サービスの提供と顧客サービス

1. PHONEMaster提供システムでヘッドセットを購入した顧客が特定の無料ダイヤルに電話をすれば、自動的にテレフォニーサービスに加入できるようにする
   
   
2. 顧客が特定の無料ダイヤルに電話をしたり、Webサイトにアクセスすれば、テレフォニーサービスを最大6カ月間休止することができる。Webのインターフェイスはユーザーにとって使いやすく直感的でなければならない
   
   
3. 特定の無料ダイヤルに電話をしたり、Webサイトにアクセスすれば、顧客はサービスを解約することができる
   
   
4. 顧客がアクセスをして自分のアカウント、サービスステータス、プリペイド通話時間の残りをチェックできるようインターネット機能をサポートする
   
   
5. システムはコールセンターが「CUSTOMERPro」システムに対する支払いを小切手、現金、クレジットカード、もしくは電子振り込みサービスで受けられるようにする。支払期限の過ぎた代金については通知を行い、2％の延滞手数料を課金するが、その顧客のアカウントがプレミアサービスであれば適用しない
   
   
6. コールセンターの担当者は上司の承認がなければ50ドル以下の返金しか扱えないようにする
   
   
7. コールセンターや顧客の操作はすべてロギングされ、監査のためにトラッキングできるようにする
   
   
8. Webのインターフェイスはユーザーにとって使いやすく直感的なものにする
   
   
9. コールセンターの担当者は全員が同じ情報にアクセスしたり、返金に応じたり、顧客アカウントにプリペイドの利用時間を追加できるようにする（上司による承認のない場合は特定の範囲内に限る）
   

要件定義からユースケースへの変換

　上述の「要件定義」は望まれるシステム（CUSTOMERPro）を説明するための文を集めたものだが、そこには明確なテーマも構想もない。一見したところ、1つは「サービス提供」用で、もう1つは「顧客サービス」用という明確に定義されたシステムが2つあるように思える。だが、「サービス提供」の部分を読むと、顧客という言葉が機能を説明するために頻繁に使用されていることは明らかだ。これは、実際には、機能が顧客サービスの一環であると考えられることを示唆している。そこで、ここでは図1のようにシステムの境界を定義することから作業を始める。

図1 システムの境界定義

　次にシステムの行為者を見てみよう。1、2、3、および4の文では「顧客」が出てくる。そして、コールセンターの担当者は5、6、7、9の文に出てくる。また、「PHONEMaster」というシステムは1の文に出てくる。そこで、われわれは図1を図2のように修正する。

図2 行為者の追加

　ここまできたら今度はユースケースを見ていき、それぞれに行為者を割り当てていくことができる。要件定義の1は顧客が電話サービスを開始するために、何らかの形の機能を提案しているが、2の文は上述のサービスを休止する機能を提案しており、3の文ではサービスの解約を用意している。さらに、別のシステム（PHONEMaster）との間で何らかのやりとりがあることも分かったが、このやりとりが「開始」時だけなのか「休止」や「解約」でも行われるのかが明確ではない。補足の要件定義で示唆されているのは、通常の電話を使ってアクセスできるシステムを開始するということだけだ（前述した1、2、および3の文を参照）。通常、私は図3に示すように、このような情報をユースケース図の要素に関する資料に直接入れている。

図3 補足した要件定義の捕捉

　これで、この要件定義のユースケースを図4のように拾い出すことができる。

図4 補足した要件定義のユースケース

　4の文は全部を組み合わせた要件定義文で、アカウント管理サービスと「プリペイド通話時間」と呼ばれるものの両方を扱う。この文にはインターネットベースのアクセスのための機能以外の要件定義も含まれている。5の文も複合要件定義で、受け付け可能な支払い方法（小切手、現金、クレジットカード、および電子振り込み）と、期限の過ぎた代金の支払い処理に必要な処理情報を組み合わせている。頭の切れる調査担当者ならば5の文の中に「顧客のアカウントがプレミアサービス」といった記述があることに気付くだろう。これは、顧客が会社に対して担う役割に関する何らかの情報を4の文に書かれたアカウント管理機能が持つようになることを示唆している（この情報は図中のユースケース資料の部分に組み入れることができる）。ここまできたユースケースモデルを図5に示す。

図5 ユースケースモデル

　6の文では、支払い受け付けのユースケースに金額や承認の条件付きで顧客のアカウントに返金を行うシナリオも加わることが示唆されている。

　7の文にはロギングという新機能が登場する。このほかに提案されているのが何らかの形のセキュリティだ（ユニークなIDを付けずにコールセンターの担当者を1人1人ロギングするのは困難だ）。そこで、ここに図6のような新たなユースケースが登場する。

図6 新たなユースケースを使ったモデル

　8の文が実際には必要条件ではなく、ごく一般的で測定もテストもできないユーザビリティに関する文であることに注意したい。

　9の文ではコールセンターの担当者が「同じ情報にアクセスできる」ことを提案しているが、どの情報を参照するのか（顧客アカウントか？）については明確ではない。また、ここでは返金と、（未定の制限と上司の承認を条件とした）顧客アカウントへの「プリペイド通話時間」の追加の機能が重ねて強調されている。

　これで、これらの文をすべてユースケースモデルへとトレースし、特定のユースケースに直接関連する機能以外の要件定義を拾い出すことができる。また、開始、休止、解約の間にある類似点を活用するよう電話サービスのユースケースを再度考慮することもできる（図7）。

図7 機能以外の要件定義を拾い出すユースケースモデル

　資料から拾い出したシナリオも図8のように拾い出すことができる。

図8 資料中のユースケースシナリオの捕捉

　明らかに、この分析からは回答よりも疑問の方が多く出てくる。このフォローアップとしては「プリペイド通話時間」機能の定義、無料通話インターフェイスの解明、「ヘッドセット」（1の文）の定義、ログに対するニーズやデータエレメントの照会などが考えられる。

監査追跡

• 変更日
  
  
• 変更内容（返金、プリペイド通話時間、顧客データ、支払額）
  
  
• 元情報
  
  
• 変更情報
  
  
• ユーザー識別子
  
  
• 承認インジケータ
  

　次のステップとしては、システムとのやりとりを説明するユーザーフローの作成（例：アクティビティ図）や、各ユースケースの代替／例外シナリオに関する詳細な説明なども考えられる。

　ここで例示されるように、システムに関する最低限の説明を用意するだけでも、調査プロセスとして情報を拾い出し、整理するための妥当なモデルを作成することが可能である。私はRational Roseを使って情報を作成および拾い出しているが、私がこれを通常のアプローチとしているのは、Rational Roseを使えば自分のモデルの拾い出しと整理が1ステップできてしまうためだ。そのほかの方法として、簡単な製図ツールと必要最小限のユースケース資料を用いてもっと簡単なアプローチも可能だ。重要なのは、解析アプローチを取ることでオリジナルの要件定義文までのトレースがいつでも可能なようにすることだ。

本記事は「The Rational Edge」に掲載された「Requirements Archaeology」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧