要件定義の考古学：The Rational Edge（2/2 ページ）

[Benjamin A. Lieberman, Ph.D.（Senior Software Architect Trip Network, Inc.），＠IT]

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

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

■「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ステップできてしまうためだ。そのほかの方法として、簡単な製図ツールと必要最小限のユースケース資料を用いてもっと簡単なアプローチも可能だ。重要なのは、解析アプローチを取ることでオリジナルの要件定義文までのトレースがいつでも可能なようにすることだ。

著者プロフィール

Benjamin A. Lieberman, Ph.D.

Senior Software Architect

Trip Network, Inc.

【参考文献】

・Alistair Cockburn著、「Goals and Use Cases」（Journal of Object-Oriented Design、1997年9月号、35〜40ページ）

・E.F.J Ecklund、L.M.L Delcambre、M.J Freiling共著、『Change Cases: Use Cases that Identify Future Requirements』（1996年OOPSLA刊）

・ Ivar Jacobson、Grady Booch、Jim Rumbaugh共著、『The Unified Software Development Process』（1999年Addison-Wesley刊）

・ Philippe Kruchten著、『The Rational Unified Process: An Introduction』第2版（2000年Addison-Wesley刊）

・ Ben Lieberman著、「UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior」（The Rational Edge、2001年4月号）

・ Tom Rowlett著、「Building an Object Process Around Use Cases」（Journal of Object-Oriented Design、1998年3/4月号、53〜58ページ）

【注釈】

（*1）構造化要件定義という言葉は「システムは〜であること」といった古典的な宣言形式を指す。

（*2）http://www.rational.com/reqpro参照。

（*3）http://www.rational.com/参照。

（*4）http://www.textpad.com参照。

（*5）Philippe Kruchten著、『The Rational Unified Process: An Introduction』第2版（2000年Addison-Wesley刊）およびIvar Jacobson、Grady Booch、James Rumbaugh共著、『The Unified Software Development Process』（1999年Addison-Wesley刊）参照。

（*6）「埋もれた」という言葉を使うのは、コードベースにしか存在しない要件定義を指すためだ。これは、特定のデベロッパとクライアントが直接コミュニケーションを取り、機能が検査を受けずに直接コードベースに挿入された結果であることが多い。

（*7）潜在的に非常に重要な要件を示すインジケータとして、資料の「不足」を使うのは、肺炎を聴診器で見つけ出すという伝統的な手法と同じだという指摘があった。深刻な問題のある可能性が高い場合、呼吸は全く聞こえないのだ。

（*8）Ben Lieberman著、「UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior」（The Rational Edge、2001年4月号）参照。

（*9）http://www.rational.com/products/clearquest/index.jsp参照。

（*10）インタビューによって要件定義を聞き出すための詳細な情報は、Dean Leffingwell、Don Widrig、Edward Yourdon共著の『Managing Software Requirements: A Unified Approach』（2000年Addison-Wesley刊の491ページを参照）。

（*11）要請された機能は、顧客の要望に基づく。要件定義は機能要件定義の大半を描写すべくユースケースシナリオとして拾い出すことができる。補足資料は定義に用語、機能以外の要件定義、例、およびインプリメンテーションの制限（例：サードパーティのインターフェイス）に有用だ。

（*12）以下の参考リストとRational Edgeの記事を参照。

「Ending Requirements Chaos」

http://www.therationaledge.com/content/aug_02/m_endingChaos_sa.jsp

「Features, Use Cases, Requirements, Oh My!」

http://www.therationaledge.com/content/dec_00/t_usecase.html

「Iteration-Specific Requirements」

http://www.therationaledge.com/content/mar_01/t_iteration_mt.html

（*13）Software Engineering Body of Knowledge（SWEBOK）

http://www.swebok.org/

---

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

---

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）