要求とは？
|
要求工学はソフトウェア開発における要求仕様化プロセスを工学的に定式化する技術として注目を集めている。今年は第12回の要求工学国際会議（International Conference on Requirements Engineering,ICRE）が日本の京都で９月６日から11日まで立命館大学の衣笠キャンパスで開催される[１]。本稿では、要求工学の概要と要求工学の本質的な要素を明らかにするとともに、要求工学の価値について述べる。最後に要求工学の課題を紹介する。 多要求工学（ Requirements Engineering）は新しい技術ではなく1970年代から議論されている。ソフトウェア危機が1960年代に認識されたときに、ソフトウェア開発プロジェクトが失敗する主要な原因が要求の欠陥にあると報告されている[２]。 開発したソフトウェアが納入され変更することなく使われたとき、開発プロジェクトは成功したといえるだろう。ソフトウェア開発プロジェクトが失敗するのはこの逆で、次のような場合が考えられる。 c）要求仕様を満足するソフトウェアを開発したが、変化した顧客の目標に対してソフトウェアを修正できなかった d）要求仕様を満足するソフトウェアを開発し、変化した顧客の目標に対してソフトウェアを修正する必要があった これらの問題を解決するためには、ソフトウェア開発の上流で可能な限り完全に顧客要求を確定しておくことが重要になる。c）d）については、予めソフトウェアが使用されたときの状況を想定することにより、要求変化を考慮した要求仕様を作成する必要があることを示している。実際にはソフトウェアを使って見ないと分からない要求もあるので、継続的なソフトウェア進化の中で要求仕様の成長を考える必要があるだろう。 このようにソフトウェアの要求仕様は、だれでも自然に記述できるものではなく、系統的な手法により、抽出した要求仕様を継続的に検証して更新していく必要がある。つまりアドホックな要求仕様作成ではなく、定式化された要求仕様の作成方式が必要だということで要求工学の重要性が認識されたのである[３]。要求工学の目的は、要求を分析し文書化することに関する科学および原理を解明することにより要求分析を効率化しソフトウェア開発を成功させることであるといえよう。 要求工学は、ユーザ要求を仕様化するプロセスである。作成された仕様がシステム開発の設計、製造、試験工程をガイドする。 要求工学は要求の系統的な処理を表す。ソフトウェア要求は要求工学プロセスから生じる生産物である。 要求工学は、コンピュータシステムに関する要求の集合を、発見、文書化、保守することに関するすべての活動を対象とする。要求工学では系統的で反復可能な技術を用いてシステム要求が完全、無矛盾、実際的であることを確認する。 問題分析時に相互作用的で協調的なプロセスにより要求を生成すること、観察結果を種々の表現形式により文書化すること、取得された理解の精度を検討すること、これらをシステム的に行うプロセスのことをいう。 要求工学はソフトウェアシステムに関する実世界のゴール、機能、制約を扱うソフトウェア工学の分野である。要求工学では、これらとソフトウェアの振る舞いに関する正確な要求仕様との関係や、時間ならびに関連するソフトウェアに関してこれらの要因がどのように進化していくかについても扱う。 このように要求工学の定義には、ソフトウェア要求仕様を作成するプロセス（定義１〜定義４）とソフトウェア工学研究の分野（定義５）との2つがある。以下ではまず要求工学プロセスを構成する要素について紹介する。次いで要求工学の主要な研究課題を概観しよう。 SWEBOKでは、要求工学プロセスを、要求の抽出、要求分析と折衝、要求の仕様化、要求の妥当性確認と要求管理から構成している。これらの活動では、まず非公式に提示された要求が合意された要求になり、その要求が仕様書として文書化され、さらに妥当性が確認されるという過程がスパイラルモデルで反復的に繰り返される。 ステークホルダ（システムの利害関係者：経営者、発注者、ユーザ、運用者など）、文書、業務知識（ドメイン知識）市場調査などからシステム要求を見つける。このプロセスは要求の発見や獲得などとも呼ばれる。要求抽出では、インタビュー、シナリオ分析、プロトタイピング、打合せ、ユーザ行動の観察などの手法を用いる。 要求分析では、異なるステークホルダから抽出した要求間の競合を解決し、システム化の範囲を明確化する。このため要求分析では、適切なモデルを用いて要求の構成要素間の関係を理解する。このような要求のモデルには、データフロー、制御フロー、イベント、ユーザインタフェース、オブジェクトなどがある。要求を具体化する過程で、ソフトウェアのアーキテクチャを考慮して、どのコンポーネントが要求に対して責任を持つかということを検討する場合がある。つまりシステムをどのようなアーキテクチャに基づいてコンポーネントに分割し、要求をどのコンポーネントに割り当てるかを考える。 要求の折衝では、ステークホルダ間、機能と制約間などで発生する要求間の競合を解決する。このためには競合解決のためのトレードオフについて合意を形成しておく必要がある。 合意された要求についてすべてのステークホルダが理解できるように文書化する。したがって対象業務の用語を用いて記述する必要がある。また開発者が設計や製造で参照できるように定式化されたモデルで要求を適切な詳細さで文書化することも必要である。 要求の一貫性と完全性をソフトウェアの設計や製造を始める前に検証しておく必要がある。要求仕様書のレビュ、プロトタイピング、モデルを用いた形式的な検証などの手法がある。 要求管理ではソフトウェア開発の全工程で次のようにして要求を管理する。まず合意された要求を識別し、要求の内容を管理する。また指定された要求に対する変更を管理する。さらに要求間の関係や要求とソフトウェア開発に関する他の文書との関係を管理する。 ここで、従来の要件定義[９]や要求分析[10]と呼ばれていたソフトウェア開発の上流工程と、要求工学との主な違いをまとめておくと次の２点であろう。 要求工学ではスパイラルモデルにより反復的に要求の仕様が成長していくと考える。このためソフトウェア開発の全工程にわたって要求を管理することの重要性が認識された。これに対して、従来の要件定義ではウォータフォールモデルにより、要求仕様を上流工程で確定してから、下流工程に進む開発工程を想定していた。 1980年代までは、要求仕様ではシステムの実現方法（How）ではなくシステムの目的（What）を記述するべきであると考えられていた。たとえば文献[10]では「要求分析とは、利用者のニーズを明らかにして、システムやソフトウェアに対する外部特性を記述するプロセスである」と述べている。しかし、1990年代に入って、C/Sやインターネット、コンポーネント、Webサービスなどの新しいソフトウェア技術の登場により、アーキテクチャを前提にして要求仕様を記述するようになってきている。SWEBOKでも、すでに述べたように要求工学プロセスでアーキテクチャ設計を考慮している。 要求工学がソフトウェア開発にもたらす作用には、次のような受容性と完全性の向上という２つの方向がある。 発注者の目的に適した要求仕様を記述することで、納入後も継続的に使用できるソフトウェアを提供できソフトウェアの受容性が向上する。 このような要求仕様を満足するソフトウェアを開発することでソフトウェアの完全性を向上できる。 また要求工学の価値をソフトウェアの開発工程ごとに考えてみると次のようになる。ソフトウェア開発の工程には分析、設計、製造、試験、保守がある。分析工程では系統的な要求工学手法を用いることにより完全性の高い要求仕様を作成できる。設計工程では、設計したソフトウェアの構成要素が要求仕様を満足することを検証することにより設計の妥当性を保証できる。製造工程では、コードの必要性を対応する設計の根拠となる要求を追跡することで確認できるだけでなく、コード変更の波及効果も分析できる。試験工程では試験仕様を要求仕様に基づいて作成することにより、信頼性の高い試験を実施できる。またソフトウェアの誤りを修正するために必要なコストの相対比は、要求分析：設計：製造：試験：保守で１：５：10：50：200であるといわれている[11]。 この理由は下流工程に行くほど、誤りの検出が困難になるだけでなく、手戻りがより多く発生するためである。したがってできるだけ要求工学プロセスの段階で誤りを発見することが望ましい。 本稿では、要求工学の必要性と概要ならびに研究課題を紹介した。要求工学はこれまで約30年にわたって発展してきた。今後もこれらの課題にたいして精力的な技術開発が進んでいくことだろう。 |
[ 86] 要求工学の概要（要求工学：第1回）
[引用サイト] http://www.bcm.co.jp/site/2004/2004Oct/04-youkyuu-kougaku-10/04-youkyuu-kougaku-10.htm
|
前回「いまさら聞けない要求管理の基本」は、要求についてかなり漠然とした定義のみに触れましたが、今回はもう少し詳細に要求というものを見てみましょう。そもそも何を記述すればシステムの要求を完全に書いたことになるのか、ということから見ていきたいと思います。 システムを定義する詳細な要求を、RUPでは“ソフトウェア要求（Software Requirements）”と呼んでいます。つまり、ソフトウェア要求を完全に記述すれば、システムの要求（仕様）を完全に記述したことになります。 ソフトウェア要求の定義は、システムをブラックボックスとする視点から、ユーザーやデバイスあるいは別のシステムのために、システムが遂行する能力／状態を記述したもの、となります。つまり、ソフトウェア要求を記述しようと思ったら、システムを外部から見た状態で（システムの中はどうなっているか分からない）、そのシステムが何を行うかを完全に記述する、ことを考えてみるのです。 システムを完全に記述するためには、図1の5つのカテゴリに着目する必要があります。図の中の項目を定義していくことによって、ソフトウェア要求一式を決定することができます。 ここまで、ソフトウェア要求とは、外部の視点から見て、システムが何をしなければいけないかを開発者に伝えるもので、システムの入出力、機能、機能以外の属性、設計上の制約という側面から定義されることを説明しました。システムが何をしてくれるか（What）、を決めますが、システムがどのようにそれを実現するか（How）は決めないということが大切です。 また、ソフトウェア要求に含めるべきでない情報には気を付けなければなりません。設計や実装についての情報、システムのテスト方法についての情報、プロジェクト管理に関する情報などは、ソフトウェア要求に含めないようにします（図2）。 特に、設計や実装についての情報は、気付かないうちに入ってしまうので、十分に気を付ける必要があります。設計やアーキテクチャについての情報を要求に含めてしまうと、その情報に制限されて、アプリケーションにとって最適な設計方法を選択できなくなってしまいます。ただし、あらかじめシステムの内部的なことが決められている場合があります。例えば、組織が持つライセンス上の問題で、データベースとしてDB2を使用することが決められているケースがあります。その場合は、“設計上の制約（Design 大切なことは、設計上の制約はできるだけ少なくすることです。そうすることで、開発者は、最小限の制約に縛られるのみで、必要な機能を実装し指定された性能や信頼性を達成するシステムを設計することが可能になります。 ソフトウェア要求に関してここまで見てきましたが、ソフトウェア要求と一言でいってもさまざまな種類の要求があることはお分かりだと思います。特に次のように3つに分類することができます。 また、図3のようにFunctionality（機能）、Usability（使いやすさ）、Reliability（信頼性）、Performance（性能）、Supportability（サポートのしやすさ）、の頭文字を取ってFURPS+の形で分類することも一般的に行われます。FURPS+の最後の+は、FURPSに含まれない設計上の制約を示しています。このFURPS+は、上の3つの分類でいうと、Fは機能要求、URPSが機能外要求、+が設計上の制約にそれぞれ相当することはお分かりだと思います。 このような形に分類することにより、要求を引き出す際や、要求に対する理解を評価する際のチェックリストとなり、漏れや不完全さを防ぐことができます。 前節まで、 “ソフトウェア要求”とは、システムを詳細レベルで定義した要求であり、ブラックボックス的視点からシステムの能力を記述した要求、として見てきました。また、ソフトウェア要求は、FURPS+の形に分類できることも見ました。しかし、顧客に満足してもらえるシステムを開発するには、ソフトウェア要求だけではなく、利害関係者（Stakeholder： プロジェクトと何らかの利害関係を持つ人、特にシステムのユーザーは重要な利害関係者に挙げられます）のニーズをとらえることが重要です。 要求管理を効率的に行うために、詳細レベルの要求である “ソフトウェア要求”以外も要求としてとらえることが経験上有効であることが知られています。つまり、要求という言葉の対象を、システムの詳細定義である“ソフトウェア要求”だけでなく、利害関係者の“ニーズ(Needs)”にも拡大しているのです。そしてもう1つ、ソフトウェア要求より抽象レベルの高い要求として、“基本要件(Features)”も要求としてとらえます。ちょっとややこしいですが、 “要求タイプ” という概念を導入し、そのタイプの1つが“ニーズ”であり“基本要件”であり、“ソフトウェア要求”というわけです。基本要件は、ソフトウェア要求と比べて抽象度が高く記述されるため、基本要件を用いれば、システム全体を容易に把握でき、開発範囲を管理が楽になります。 そうしますと、図4のように、ニーズ、基本要件、ソフトウェア要求と3段のピラミッド状に要求を要求タイプごとに体系化して記述することができます。受注管理を効率化する業務用アプリケーションを例にとりあげて、それぞれの要求タイプ別にサンプル要求が書くと図5のようになります。要求タイプごとのイメージをつかんで頂けると思います。 【ニーズ】 利害関係者の望むものをシステム（ソリューション）に依存しないかたちで表現したもの 【基本要件】 システムが外部に提供するサービスを表現したもの。これらは、1つ以上の利害関係者のニーズをサポートしている 【ソフトウェア要求】 開発者が設計、実装、検証できる程度まで詳細に記述された要求。これらは、1つ以上の基本要件をサポートしている 図4 要求のピラミッド（ニーズ、基本要件、ソフトウェア要求）と各要求タイプの定義 在庫確認機能：システムを用いると、受注担当者は、商品カテゴリ、もしくは、商品名、メーカ名、商品コードから、在庫数を確認できる “要求タイプ”を、もう一度簡単にまとめておきましょう。まず、顧客の問題を確実に解決できるように、システムの背後にある“ニーズ”をシステムに依存しない形で捉える。そして、システムの大きな機能のくくりである“基本要件”を捉えることでシステム全体を理解し、開発範囲の管理を容易にする。さらに、詳細なシステム定義である“ソフトウェア要求”を定義することで開発者がシステムを設計、実装、検証できるという訳です。特に、“ニーズ”を記録しておくことにより、この“基本要件” はそもそもどこからきたのか、“ソフトウェア要求”は何のためにあるのか、という視点がもてることは非常に重要です。例えば、開発者に対して何らかの変更依頼があったときに、もとの“ニーズ”という視点から実装方法を検討できるのとできないのでは大きな違いがあります。 さて、今回は要求の分類分けについてみてきましたが、次回は、要求管理プロセスの流れを解説し、ワークフローとして整理したいと思います。 先日、お客様と要求管理の話をさせて頂いたときに、要求のタイプである“ニーズ”、“基本要件”のサンプルとして良い例を伺いましたので紹介したいと思います。 校門の前に大きな道路がある小学校は全国にたくさんあると思われますが、やはり気になるのはその安全面です。 ここで、“児童が校門の前の道路を安全に渡ることができる”をニーズとみると、それを解決するソリューションの基本要件としては、“校門前の道路は信号で制御される”、または“校門前の道路は歩道橋でしか渡れない”、もしくは“みどりのおばさんが横断歩道を監視する” ( 黄色い旗を持って通学路を見張るお母さんのことを、著者の出身地の大阪では“みどりのおばさん”と呼んでいました ) があり得ます。 ニーズを解決しさえすれば、どの基本要件でそのニーズをサポートするかはソリューションの問題であり、プロジェクトの予算などと相談する話となります。非常に分かりやすいのではないでしょうか？ 「僕の田舎の道路には、普通、信号なんかないのですよ。大きな事故があったりすると、そこにやっと信号ができます(少し物騒な話しで申し訳ございません)。ただ、小学校の校門の前にはなぜか必ず信号があります。これはそこで必ず事故があったからという訳ではなくて、児童が大きくなって都会に出たときに信号を見て困らないように、教育用に作られているそうですよ」。 ちょっと某番組に出品したいネタですね。この話の真偽のほどは定かではありませんが、教育用にあえてある制約を課すというのは、システム開発の世界でもよくある話だなあ、としみじみと考えてしまいました。 IBM東京基礎研究所に入所後、超小型腕時計型LinuxコンピュータWatchPadの研究開発に従事。現在は、IBM Rational事業部にて、RUP・要求管理・オブジェクト指向分析設計の講師としてコンサルティングを行っている。 本連載では、RUPにおける要求管理の成果物とワークフローを取り上げ、要求管理の基本をできるだけ分かりやすく解説していきたい 情報マネージャのための「今日のひと言」 - 2007/11/30『値引き競争』 よく、「値引き競争に巻き込まれて困っている」という相談を受けます。他社は……>>続きはクリック 技術者としての力量を数値で把握していますか？ITSSレベルを無料で判定、12月25日（火）まで ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠IT情報マネジメント トップ｜アーキテクチャ トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 87] ＠IT：みんなが悩む要求管理（2）
[引用サイト] http://www.atmarkit.co.jp/farc/rensai/re_mgt02/re_mgt02.html
|
今回は、要求管理の中でも特に重要なアクティビティである「変更管理」にフォーカスします（一般には、変更管理という言葉には、今回取り上げる要求変更のみでなく、プログラムバグに対する修正要求なども含まれます）。「仕様変更はあって当たり前」だとか「変化ヲ抱擁セヨ」というフレーズを都合よく解釈した結果、失敗プロジェクトに転落してしまう状況は枚挙に暇がありません。このような状況はどのように改善したらよいのでしょうか。 自社のソフトウェアパッケージ製品の開発であろうと、請負開発であろうと、“プロジェクト”として行う以上は、期間、コスト、および実現される機能に制約があることに違いはありません。最終的な成果物（ソフトウェア）の品質は、この3つの要素のバランスによって決まります。「Developing つまり、バランスの取れた状態から、期間だけを半分に短縮するとか、コストを半分にするという場合には、機能も半分にしないとバランスが保てずに、品質に影響を与えるということです。機能が増えた場合は、コスト、期間も増やさなければバランスは保てません。このたとえで重要なことは、品質をその面積ではなく形としてとらえていることです。これは、プロジェクトにおけるさまざまな変更要求への対応を判断する際に、自身を冷静にする、またはユーザーにトレードオフを説明するためにも、有効であると感じています。 さて、ほとんどのプロジェクトでは、コストおよび期間が途中で積極的に変更されることはありません。多くの変更は機能に対してであり、それらへ対応した結果としてコスト、期間に変更が生じることになります。この変更によって、発注者（ユーザー）と受注者（開発者）双方が不利益となることのないように調整がなされ、合意に基づく処置が実施されれば何の問題もないわけですが、現実はそれほど美しくないことは皆さんご存じのとおりです。なぜそのようにならないのか？ ユーザー、開発者のどちらか、または双方が、その変更（または追加）による影響を過小評価している 「1. ユーザーがそれを、機能に対する変更（または追加）とは認識していない」は、本来、要求として当然抽出されているべきものであったり、暗黙的な期待を含んでいたりというように、要求開発の問題であることが多く、要求分析者のスキル（コミュニケーションスキル、クリティカルシンキング、ITスキルetc……）と、要求構造化の手法に依存するところが大きいものであり、本稿のスコープから外れるため、ここでは扱いません。「2. ユーザー、開発者のどちらか、または双方が、その変更（または追加）による影響を過小評価している」は、変更による影響のとらえ方を整理することで改善が可能なものであり、本稿はこれについて述べていきます。 多くの変更は、機能に対して発生すると述べましたが、機能を要求としても大意に違いはありませんので、以下では“要求”に統一します。要求に対しては、プロジェクトのライフサイクル全体を通して以下のイベントが発生します。 そして、これらのイベントは、図2に示す要求構造のすべての階層で起こり得ます（なお、システムに対する要求としては、ここに示す機能要求同様に、非機能要求も重要な意味を持つことは前回触れたとおりですが、今回は機能要求にフォーカスすることにします）。 さて、図2のように要求を正しく構造化しながら定義できたとすると、どの階層レベルの要求に対して変更、追加、削除のイベントが発生したとしても、その影響範囲を判断し、実際に必要な影響への対処方法、所要コストを見積もることが可能となります。もちろん、同一階層構造内にはない、例えば、複数の要求に含まれるような共通要求（典型的な例としては、何かにつけ確認メールを送信するようなシステムの場合の、“メールを送信する”などが挙げられます）との関係は、明示的に定義する必要があります。実際にプロジェクトが進行している中で前述のイベントが発生すると、以下の流れに従ってそれらへの対処方法を決定することになります。 c） イベントに対応するとしたら、必要な工数と、スケジュール、品質に対する影響を見積もる この手順自体は、皆さんにとって何ひとつ新鮮味のないものだと思います。問題は、多くのプロジェクトではこの当たり前のことの実践が、非常に困難だということです。私が知る限り、ほとんどのプロジェクトで見られるやりとりは、「これ対応できる？」という問い掛けに対して、「たぶん、できます」「難しいです」「やってみます」のいずれかで応答するというものです。。そして、このように答えているのは、設計者でも、テスト担当者でもなく、実装者またはその代弁者（通常は実装チームのリーダー）です。 従って、プロジェクト全体に対して、その時点での影響を漏れなく把握した回答にはなっていません。つまり、多くのプロジェクトでは、1-a→1-b→2→3→1-c→混乱というサイクルでイベントへの対応がなされていることになります。これは、要求へのイベントによって影響を受けるものとして、要求“以外”のものが把握できていないことに起因します（実際には、影響を受ける可能性がある要求すらも正しく把握されていないことも多く、最終的にはコスト、期間、機能、品質、すべてが破綻してしまうプロジェクトが珍しくないのは皆さんご存じのとおりです）。 要求の構造化が正しくなされていれば、1-bについては問題なく実施可能ですが、1-cについては、それだけでは十分ではないということです。ここで、プロジェクトとは何かを再確認してみます。PMBOKガイドによると、「プロジェクトは、独自の製品やサービスを創造するために実施される有機的な業務である」とあります。また、独自の製品やサービス、業務といったものは段階的に詳細化されるともあります。システム開発プロジェクトにおいては、プロジェクトは要求と、それを実現するために必要なタスクと、そのタスクによって生み出される成果物で表現することができ、それらが時間の経過とともに積み重ねられることで、最終的な目的を達成することになります。つまり、プロジェクトの完了は、これらすべての成果物の完了をもって表すことができるということです。図3はこのイメージを表現したものです。 話をイベントへの対応に戻すと、1-cで見積もっているのは、図3の実装を主としており、賢明な担当者によってテストのやり直しについて言及されることはあっても、どの程度の影響があるかを正確に把握していることは稀（まれ）です。個々のタスクの成果物まで把握するのは、“要求”管理の領域を超えているようにも思われますが、前述の手順を正しく行うために必要であれば、それが要求管理の範疇（はんちゅう）なのか、プロジェクトマネジメントの範疇なのかは重要ではないのですが、あえて前準備と実際のイベントへの対応をそれぞれの役割を意識して整理すると表1のようになります。 2. 各要求を実現するために必要なタスク、成果物、担当者を定義する（WBSの作成） 2. （影響を受ける可能性のある）あらゆる要求に関連したすべてのタスクの担当者を特定する これでお分かりいただけると思いますが、要求を構造化し、要求間の依存関係を把握することに加えて、要求／タスク／成果物の依存関係も正確に把握しておかなければ、プロジェクトのライフサイクル全般にわたって発生する変更に対して、適切な対応はできないということです。また、これらをすべて、何の仕掛けもないままで実践することは大変な労力を要しますし、プロジェクトによってはここまでやることのメリットがないものもあります。ただ、上記の実現を支援するようなツールも存在していますので、検討してみるのもいいかもしれません。 さて、3回にわたって“要求”という視点でプロジェクトが抱える問題に対する改善案をお伝えしたわけですが、これらを簡潔にまとめると、 となります。1、2は、高品質な要求を開発することを意味し、3は、要求とそれに関連する情報の品質を維持する（管理する）ことを意味します。もちろん、プロジェクトが抱えている問題は非常に多く、これらですべてが解決するわけではありません。しかし、問題の根幹の1つに“要求”があることは紛れもない事実であり、“要求”の周りで沸き起こる問題に対して、根治療法を取ることは大変効果が大きいものなのです。 メインフレームでの証券取引所データリアルタイム配信システム開発を経験後、数々のオブジェクト指向での企業情報システム開発を経て、ソフトウェア開発に関わる方々を少しでもハッピーにすべく、要求開発・管理、ソフトウェア開発プロセス構築に関する啓蒙、コンサルティングに従事。 情報マネージャのための「今日のひと言」 - 2007/11/30『値引き競争』 よく、「値引き競争に巻き込まれて困っている」という相談を受けます。他社は……>>続きはクリック 技術者としての力量を数値で把握していますか？ITSSレベルを無料で判定、12月25日（火）まで ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠IT情報マネジメント トップ｜プロジェクト管理 トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 88] ＠IT：要求仕様のボトルネックを探る（3）
[引用サイト] http://www.atmarkit.co.jp/farc/rensai/bottleneck03/bottleneck03.html
