The Rational Edge

要件定義の考古学

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


2002/12/26

---

Dr Henry Jones, Sr.
インディ・ジョーンズ／最後の聖戦
Lucas Films, Ltd.（1989年）より

　要件定義はシステムの心臓部だ。システムの動作を明らかにするだけでなく、構築された背景をも、最終的に利益を享受するユーザーの頭の中に焼き付けてくれる。だが、これらの要件定義は、（1）簡略的もしくは局所的な開発メカニズムによって不十分な形で拾い出されたり、（2）デベロッパの頭やコードという不可解なものの中で拾い出されたりすることも多い。残念ながら、大半のソフトウェア開発企業にとっては、どちらのアプローチも、誤りとコスト増につながってしまう。

---

負の遺産

　多くの企業は、何年もの開発期間を費やし、自社の存続にとって欠かせないレガシーシステムを最低1つは抱えており、それに膨大な額の投資をしているものだ。しかし、一連の要件定義が欠損しているか、あるいは不完全か、はたまた不正確であるためか、そのようなシステムの大半は非常に脆弱であり、なおかつ保守費用を食い続ける金食い虫である。さらに、ソフトウェアの動作が明確に定義されていないことから、レガシーシステムを新システムに入れ替えることはほとんど不可能に近い。つまり、時代遅れで、現代のビジネス要求に合致する柔軟性を持たないシステムなのである。

　既存システムの安定性にどのような影響があるか予測できないため、新機能や新動作を付加すると問題が複雑化する。例えば、基礎がどうなっているのか分からない家に2階部分を増築するようなものだ。システムを構築したときの資料がないので、対応が手遅れにならない程度にどこまで構造が持ちこたえるのか、知る術はまったくない。レガシーシステムを置き換える、開発し直す、もしくは維持していく場合は、動作、状態、データエレメント、ビジネスルールなど、そのシステムの開発当初の原動力となったものを、さらに徹底的に理解する必要がある。それにはシステムの業務要件を見つけ出す必要があるのだ。

　この場合の明らかな情報源（システムを開発した人々）はおそらくすでに退社していることだろう。だが、コードという、「調査担当者」に残された信頼性の高い唯一の成果物の中に情報は埋もれて残っている。「失われた」要件定義の「成果物」を再発見する方法はあるのだ。そして、これを見つけ出すプロセスは、考古学の探検に似ている。調査地域を決定し、情報源に対してインタビューと調査を行い、手に入る品々を慎重に分類・整理し、あいまいなコメントを自分なりに解釈して、最終的にはソフトウェアの「沿革」をシステムの利害関係者に提示しなくてはならない。

　もちろん、このような作業には相当の覚悟がいる。すべての「探検」には、かなりのリスクやコストが付き物だ。拾い出すシステムのサイズや要件定義の現状によっては、最高3〜4人が数カ月間フルタイムで担当しなくてはならない。その費用は、安定した完全な要件定義のない場合の損失を考慮に入れて初めて正当化できるように思える。要件定義が完全に理解されていないと、企業はチャンスを失い、メンテナンスコストの増加、スケールメリット実現に向けたシステムの統合問題、そして社員の仕事に対する満足感の低下（システムの一部しか理解しない専門家は、ほかの部分の作業に携わる可能性が低くなる）に直面し、戦略的なプランニング能力が大幅に低下する可能性がある。「できていること」をしっかりと理解し直すしか、「これからできること」の実現に向けて組織が準備を進める方法はない。つまり、しっかりした要件定義がなくても企業が生き残ることは可能だが、成長および成功する力は非常に限られることになる。

　本稿ではレガシーシステムの要件定義を拾い出して、完全な要件定義を再構築するためのプロセスについて説明しながら、既存の成果物をはじめとする各種情報源から要件定義を「発掘」するテクニックをいくつか紹介していく。そして最後に、新たに発見した成果物をもっと高い確率で長期間維持できるような導入方法についても解説する。

　ここから先は、失われた要件定義を追求する、恐れを知らぬ冒険者たちだけの世界だ。あなたたちには、なぞと血わき肉踊る冒険が待ち受けている。勇気と熱意のある方だけ読み進んでいただきたい。

探検の前に入念な準備をする

　慎重な要件定義考古学者なら、ソフトウェアの荒野へ探検に旅立つ前に、いくつかのスキルの習得と物資の調達が必要であることは、あらかじめ了解していると思う。

1. 「構造化要件定義」（*1）およびユースケースの要件定義分析に関する
   理論と実践を踏まえた基礎知識
   
   
2. 情報の調査／分類整理に関する経験
   
   
3. 小人数のエンジニアで構成された調査チームを率いた経験
   
   
4. 対象ビジネスの専門家が集まった小人数グループへの参加や支援経験
   
   
5. UMLモデリング（最低限でもユースケース図とアクティビティ図）の熟知
   
   
6. システムプログラミング言語の経験
   （必須ではないが、 「探検場所」の言語が使えることは必ず役に立つ）
   

　また、未知のものに遭遇するような場合は、適切な機器を自由に使えることも非常に有効なので、出発前に以下のものを入手しておくとよいかもしれない。

1. 発見したものを保管し、整理するための要件管理ツール
   （例：Rational RequisitePro*2）
   
   
2. システム情報をグラフィカルに表現するユースケース図、アクティビティ図、
   そして状態遷移図用のモデリングツール
   （例：Rational Rose*3）
   
   
3. コードの成果物を検査するために用いる特定のシステム言語に対応した
   コードエディタ／プロファイラ（例：TextPad*4）
   

　機器をそろえ、スキルを磨いたら、冒険に旅立つ準備は完了だ。

情報源の特定と「発掘現場」の調査

　驚いたことに、発掘が必要とされる要件定義が、拾い上げてすぐに利用できるよう無造作に放置されていることはまれだ。通常、これらは厳しく監視されたレガシーシステムや不可解な古い資料、そして「レガシーな社員」などの奥深くに埋もれている。私は、既存のソフトウェアシステムに関する情報源としては主に次の4つがあることに気付いている。

• 人
  
  
• 資料
  
  
• ソフトウェアのコード
  
  
• ソフトウェアのトラッキングレポート
  

　これらの情報源を取捨選択し、そのソフトウェアシステムを十分説明するようなものを回収するにはさまざまなテクニックが必要になる。もし企業が要件管理チームを擁していれば、彼らを中心に調査を開始するのが最適だ。通常、彼らは「ビジネスアナリスト」もしくは「要件定義エンジニア」などと呼ばれるが、製品／プロジェクト管理、マーケティング、あるいは営業の部署に所属するような人である場合もある。実際、システムの機能やパフォーマンスの決定に関与する組織の人間は、ソフトウェアシステムに対する当初のニーズを生み出した原動力を発見し、文書化できる優秀な情報源となる。Rational Unified Process（RUP）の中では、優れた設計のシステムに対するニーズは「利害関係者の要件定義」*5で最初に特定されている。

　文書化された資料は便利だが、情報源としては誤解を招くことがしばしばある。これは、資料の大半がきちんと保守されていないため、比較的短時間で現状に沿わなくなる傾向があるためだ。さらに、要件定義を整理しない企業の場合、関連資料を整理する可能性も低いため、一般的に情報源を見つけるのは非常に困難である。重要なシステム関連のドキュメントは、たいていローカルハードドライブかアクセスしにくい共有ドライブ上にある。しかしいったん集めてしまえば、これらの「歴史的文献」は、議論やさらなる調査に向けた素晴らしい第一歩となり得るだろう。

　もちろん、システムの動作に関する最も正確な情報源はソフトウェアコード自身だ。しかし、この情報源を活用するには特別なスキルを要する。調査担当者は特に、開発チームが利用する特定のプログラミング言語を前述のように1つ以上熟知していなくてはならない。その中にはメインフレームで使用されるアセンブリ言語からPCアプリケーション用のC++、Java、そしてVisual Basic、さらには一段と専門的なPerlやFortranといった言語までが含まれる。特定のプログラミング言語に堪能なことは、奥深く埋もれた要件定義（*6）の発見に役立つが、アプリケーションを実行してその動作を観察すれば、システムの機能特性に関する情報は同程度入手できる。

　（自動化の有無にかかわらず）もう1つの優れた情報源が社内のトラッキングシステムだが、これはシステムの「修正個所」として機能強化がロギングされていることから、システムの要件定義におけるデファクトレポジトリとなる場合が多い。幸運であれば、調査チームは「修正」が新機能であることを示す「ENH」や「Enhance」といった識別名でロギングされたレポートを作成することができる。だが、運が悪ければ、さらなる発掘調査が必要になってくる（古くなってしまった資料を発掘する際のヒントは以下を参照）。

　システムの要件調査のためには、情報源の特定に加えて「発掘現場」の状況も検討しなくてはならない。自分が知っている組織の文化、プレッシャー、ニーズに基づいて考え、社内の環境が自分にとって好意的なのか中立的なのかを判断する。もし組織が要件定義を拾い出すプロセスの改善ニーズを認識し、調査隊を歓迎してくれれば環境は好意的だ。環境が中立的なのは、現場の要件定義チームが「多忙」で、調査担当者の作業にはかかわれないものの、「時間があれば」協力を惜しまないような場合だ。「発掘と分類整理」のセクションで明らかなように、中立の環境では独自調査に大きく依存する必要が出てくる。

呪い

　考古学の話に呪いの話が出てこなくては面白くないだろう。ここでいう呪いとは、内容を知っている担当者は退社し、コードは不明瞭で、油断するとその中には袋小路やわながたくさん待ち受けているという、既存の要件定義関連そのものが、調査チームに誤解を与えたり、間違いを誘ったりする可能性があることを指す。最も神聖なソフトウェアデザインの安息の場を乱そうとする者には必ずや災いが降りかかるであろう！

　いうまでもないが、システム要件の発掘には用心が必要だ。一番良いのは、要件定義にかかわる利害関係者やユーザー、そのほかの見識のある個人と一緒に発見した機能を検証することだ。

　要件定義の中のギャップが要件定義自身よりも有効なこともある。例えば、機能を実現する部品が「あわてて」本番環境に導入された場合、それをサポートする要件定義が少なかったり、存在しないことも頻繁にある。さらに、本番環境への導入を急ぐほど企業にとって重要なものは、ソフトウェアの機能の中でも重要な部分である可能性が高い（*7）。この場合、欠けているものを探す手掛かりを突き止めるには、ソフトウェアの管理システムや個人へのインタビューに依存しなくてはならない。

　また、「デッドコード」と呼ばれるコードの中の実行されない部分に注意することも重要だ。コードの「生きている」ブロックと「死んでいる」ブロックを判断することは非常に難しいので、もはや機能していない部分のコードを判断するには優れたデバッグ／プロファイルツールが有効だろう。

「成果物」の発掘と分類整理

　要件定義の「成果物」の検索や整理を行う実際の仕組みはどうだろう？ インタビュー、作図、調査、そして既存の情報源から要件定義を拾い出すテクニックをそれぞれ考えてみたい。　

　中心となる調査担当者は、入手可能な資料を厳密に調べて興味のある情報を見つけ出すのに単独で作業を進める場合が多い。中立もしくは冷淡な環境では、そのようなスタイルの調査しかできないかもしれない。このような調査スタイルは、間違った仮説を導き出す可能性が高い。つまり、実際には全くインプリメントされなかったり、後で修正された要件定義を疑いもなく拾い出してしまう可能性があるのだ。従って、調査チームは「現場の人」とできる限り共同で作業を進めることが一番だ。表で詳述した作業の大半では、システムの専門家がいると仮定しているが、相当数の作業は、システムの実行者や専門家と話し合いの場を持つ前に着手することができる。やりくりのうまい調査担当者ならば、どの作業からでも既存のシステムをかなり理解できるようになる。系統的な調査テクニックを用いれば、ドキュメントが豊富にそろわないレガシーシステムでも、その秘密は明らかになっていく。これらの作業を、特定の順番どおりに着手する必要はないかもしれないが、私としては以下に示した順番が最も効果的だと感じている。

手法	作業	説明
独自調査	資料の検査	あまり正確でも完全でもないにしろ、大半の組織には何らかの資料がある。この情報にできる限り多く目を通し、詳しく調べ、「候補となる」要件定義を特定し、これを要件管理ツールの中に記録したい。例外処理（エラー関連）には特に注意すること。たいていのデベロッパはまず望まれる機能から着手し、エラー処理は（対応したとしても）後回しにしてしまう。従って、システムの例外条件や処理は通常、開発の最終段階に回され、資料は最も不足する場合が多いのである
独自調査	システム機能モデリング	次に、アプリケーション自身の発掘作業を行う。既存のシステム機能を素早く拾い出すためにアクティビティ図（*8）（「ウルトラフローチャート」）を使う。自分がエンドユーザーであるかのようにアプリケーションを駆使（ユーザーインターフェイス経由でデータを入力し、コマンドラインからアカウントを作成、検索を実行するなど）して作成する。この作業は、1人もしくはシステムの専門家（テストチームのメンバーなど）と一緒に行う。専門家がアプリケーションを利用し、自分は別のノートPCを使ってユーザーの作業記録を取ったり、図式化を行ったりする。機能の大半については、手元に用意した資料の中に、対応する要件定義がない場合が多い
独自調査	欠陥トラッキング検査	「Rational ClearQuest」（*9）などのトラッキングツールを使って、機能領域ごとに整理されているであろうトラッキングレポートを検査する。また、特定の機能領域に対応するバグレポートも作成する。「修正」の形でシステムの強化が行われている場合も多いので、現状に沿わない要件定義資料では拾い出せない。これらの要件定義を正しく識別するには、文書化された機能要件定義とのクロスリファレンスが必要になるので、最初にドキュメントを調査したい。開発スタッフが「試行錯誤」によるアプローチを採用する場合は、1つの機能に対する変更を時系列で記録する問題報告が次々に出てくる可能性が高い
独自調査	コードトレーシング	たとえ、コード用の言語を熟知していなくとも、問題と関連付けられたプログラマのコメント（例：「2001年1月3日に1403のバグを修正」）がコードベースに埋め込まれている場合が多いので、その部分のコードを調査すること。前述のシステム機能モデリングでは、シミュレーションや再現が難しい例外条件を検知する方法が、予想される動作だけなのかを報告するようプログラマに依頼しておく
インタビュー	個人インタビュー	1対1でインタビューを行い、事前にシステム関連資料を調査してシステム専門家が話し合いを始めるに当たっての情報を提供する。 ・資料の検証と、相違部分の解消や誤情報のアップデートを、その分野の専門家（SME）に依頼する。システムファンクションフロー向けに作成され、システムの中であまり明確になっていない部分（特にシステムの例外処理）を浮き彫りにしてくれるアクティビティ図を使用する ・ほかにも、SMEに一通りアプリケーションを使用してもらい、システムの各部分がいつ、どのように構築されたかコメントしてもらいたい。通常、そこそこ複雑なソフトウェアシステム（*10）をカバーするにはSMEと何度もインタビューを繰り返す必要がある
インタビュー	グループセッション	個人インタビューを拡張したものであり、アップデートされた資料や所見を調査するには最適だ。調査担当者が自分たちの作業について発表し、情報に対する建設的な調査に役立てる。資料の中のコメントは、ノートPCにプロジェクタを接続して表示して拾い出す。要件定義のかなりの部分が見つかり、文書化されるまで、このアプローチは取っておく
短期ワークショップ（再発見促進）	小グループセッション	再発見ワークショップには次の2つの目的がある。 ・要件定義を拾い出し、システムの動作に最も近いものから直接ユースケース図の中にドキュメント化していく ・一連の適切なユースケース／補足仕様として要件定義を拾い出してプレゼンテーションを行い、保守のための優れたテクニックをチームに教えていく
表：要件定義の調査テクニック

「成果物」の発掘と分類整理

　要件定義を拾い出したら、次は解析と変換が待っている。多くの要件定義は何らかの形の機能分解テクニックを使うことで拾い出すことができる。この一般的なテクニックは問題の領域を扱いやすい範囲へと分割するのに便利だが、誤用されてインプリメンテーションの詳細を示すことが多く、1つの文が単独ではシステム機能に関するまとまった「説明」にならないため、解釈が非常に難しい。さらに一般的なのは、要件定義をかなり抽象的な作業概要（例：「システムは直感的かつユーザーフレンドリーであること」）として拾い出すことだ。その結果、もっと理解可能な「内容の濃い」フォーマット（例、ユースケース）へと変換してくれる一般的な見解を見いだす必要がある。いうまでもないが、この作業を実行するには詳細に至るまで、相当な注意とシステムの変遷に関する要素の全貌を知るための指標となるロゼッタストーンのようなもの（業務ビジョンのドキュメントなど）が必要となる。

機能要件定義の拾い出し　ユーザーに対する要求が高いシステムの要件定義は、その大部分が機能要件定義で占められている。これらの要件定義を解釈する際は通常、トップダウン式のアプローチを取ることが望ましい。ただ、従来の構造分解式のアプローチも、依然としてかなり人気が高いので、例にはこの方式を採用する（構造宣言からユースケースフロー、補足仕様までの解釈すべての例については付録を参照）。構造宣言文を解釈する際は、ユーザーによる操作を求める要件定義である「システムは以下を提示する」あるいは「システムは以下を表示する」といったフレーズを探すとよい。「システムは以下を実行する」などで始まる要件定義は、システム処理のステップを示している可能性が高い。その一方で、「システムは60秒以内に応答しなくてはならない」などという制限のある要件定義は、補足仕様である確率が高い。分解は本質的に階層的であるため、この構造は機能の最初の分離点を示すために利用できる。例えば、要件定義の階層が「株式購入と照合」とされる場合は、これが「株式購入」と「アカウント照合」に関連する一連のユースケースを示すかもしれない。従って、同様の機能を集めた主要グループもしくは文書階層自身の構造から最初のユースケース調査までを素早く立ち上げることができる。これによって文書のファンクションフローまで究明するフレームワークが実現するのだ。

データの詳説　データの説明は資料やコードのあちこちに散在していることが多く、その多くには要件定義文にとって不要なインプリメンテーションの詳細まで含まれている。一般的に、データベーステーブルから作成したデータディクショナリが、要件定義資料の中に置かれている場合にこのようなことが発生する。プライマリ／外部キーのインプリメンテーションやデータタイプの詳細は要件定義の説明には含めない。その代わり、データエレメントとこれらのエレメントに含まれる可能性のある値の制限との関係を要件定義は記述しなくてはならない。例えば、付録のユースケースから次のようなユーザーの作業監査追跡を抜き出す。

監査追跡

• 変更日時
  
  
• 変更イベント（返金、プリペイド通話時間、顧客データ、支払い）
  
  
• 元情報
  
  
• 変更情報
  
  
• ユーザー識別子（名字＋名前＋ユーザーID）
  
  
• 監督者承認指示（イエス／ノー）
  

　このアプローチでは、ビジネス分野の専門家には難なく理解できる抽象化レベルでデータエレメントを記述している。彼らは設計関係のドキュメントに適したインプリメンテーションの詳細に惑わされることなくデータの関係を理解することができる。

ビジネスルールの解析　システムのビジネスルールはユーザビリティ、信頼性、パフォーマンス、そしてスケーラビリティ（URPS）と関連する。これらのタイプの要件定義は一般的に資料全体に散らばっており、機能以外の次のような要件セットに整理し直す必要がある。

• データ検証ルール
  
  
• 処理およびパフォーマンスの制限
  
  
• 例外処理
  
  
• 外部システムインターフェイス
  
  
• セキュリティ
  

　これらの要件定義があるべき当然の場所がシステム補足仕様の中だ。これらは、特定のユースケースと直接関連付けることも、システム全体のグローバルな要件定義として作成することもできる。

システム成果物の維持・管理方法を教えることも仕事だ

　当初の要件定義が発見され、再現されたら、その情報を保存および提示するための何らかの手法が必要になる。ソフトウェア考古学者の役目はシステムが「出土」して終わりではない。関与したチームのメンバーに、システム成果物の維持・管理方法を教えることも仕事なのだ。その価値を持続させるためには、要件定義は正確かつ最新で体裁が良くなくてはならない。

　要件定義は、適切な整理ツールを利用することで最適な維持ができる。比較的低価格のものも含め、その候補には優れたものが多数ある。このツールには最低でも要求仕様、要件定義（ユースケースシナリオを含む）、そして補足資料（例：用語集*11）を記録する機能が必要とされる。要件定義の管理については優れた論文や書籍が数多く存在している（*12）。ユースケースモデル、アクティビティ図、そしてデータディクショナリ情報など、発見され、作成された成果物はすべて、このようなドキュメント管理システムを使って維持管理しなくてはならない。

　要件定義の成果物を確実に保守するためには、要件管理に関する継続的なトレーニングと開発のためのプロセスを確立する必要がある。これには、業界カンファレンスへの参加、新人および現社員の指導を目的としたコンサルタント／トレーナーの招聘（へい）、さらなるトレーニングや経験を積む社員に対する報奨（ほうしょう）などが考えられる。執筆時点では、要件定義エンジニアを認定するもので業界全体に受け入れられたものは1つもないが、そのために利用できる基礎知識体系の確立が試みられているところだ（*13）。

　要件定義考古学者にとって最大の危険の1つが、そもそも作業のやり直しを余儀なくさせたものと同じ問題に「逆戻り」する可能性だ。注意しなくてはならないのは、不的確なスケジュールによるプレッシャー、経験豊かな社員から未熟な社員への引き継ぎ、予算の削減、ビジネス（そして、それに伴うソフトウェア機能）の急激な拡張、認識の低下（例：「うまく動作しているからもう気にするのはやめよう」）などがある。このような落とし穴にはまり、大変な努力の末に得たものを台無しにしないためには、継続的な用心を怠ってはならない。

これで終わり？

　要件定義を拾い出すためのプロセスは、ソフトウェアコードをメンテナンスするプロセスと全く変わらないと私は思っている。健全なシステムには、定期的な再検討や構造改革が必要であり、システムの要件定義は、顧客やエンドユーザーの本当のニーズを確実に満たすよう、継続的に調べ直し、修正を加えなくてはならない。見落とされることが多いものの、要件定義は企業の重要な資産の代表だ。いい換えれば、要件定義は収益に直結するのだ。正しいシステムの要件定義とソフトウェア製品の売り上げは直接の関係がある。これらの関係は次のようにすれば分かりやすいかもしれない。

正しい要件定義→正しいシステム

正しいシステム→顧客による手形の発行

顧客による手形の発行→売り上げ

　残念ながら、自分のチームが、見たことのないレガシーシステムを担当している場合は、システムのアップグレードや統合を進める前に、十中八九はシステムの業務要件を拾い出し直さなくてはならなくなる。システムの要件定義を再発見する作業を考古学の一種として考えるのは楽しいことだが、この作業が必要なのは、企業があまりにも頻繁に上述したシンプルな関係の理解に失敗するためだというのが、悲しいかな、真実なのだ。再発見のプロセスは難しく、時にはコストもかかる。しかし、この作業は、最終的には必ず報われる。作業チームがシステムの原動力（動作、各種状態、データエレメント、ビジネスルール）をいったん理解してしまえば、システムをもっとうまく動作させる方法や、やりがいのある難しいプロジェクトでシステムを強化する方法を理解できるようになる。

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

　

---

【参考文献】
・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」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧