要求とは？/ プロミス
[ 556] 要求工学の概要（要求工学：第1回）
[引用サイト] http://www.bcm.co.jp/site/2004/2004Oct/04-youkyuu-kougaku-10/04-youkyuu-kougaku-10.htm
|
開発したソフトウェアが納入され変更することなく使われたとき、開発プロジェクトは成功したといえるだろう。ソフトウェア開発プロジェクトが失敗するのはこの逆で、次のような場合が考えられる。 c）要求仕様を満足するソフトウェアを開発したが、変化した顧客の目標に対してソフトウェアを修正できなかった d）要求仕様を満足するソフトウェアを開発し、変化した顧客の目標に対してソフトウェアを修正する必要があった これらの問題を解決するためには、ソフトウェア開発の上流で可能な限り完全に顧客要求を確定しておくことが重要になる。c）d）については、予めソフトウェアが使用されたときの状況を想定することにより、要求変化を考慮した要求仕様を作成する必要があることを示している。実際にはソフトウェアを使って見ないと分からない要求もあるので、継続的なソフトウェア進化の中で要求仕様の成長を考える必要があるだろう。 このようにソフトウェアの要求仕様は、だれでも自然に記述できるものではなく、系統的な手法により、抽出した要求仕様を継続的に検証して更新していく必要がある。つまりアドホックな要求仕様作成ではなく、定式化された要求仕様の作成方式が必要だということで要求工学の重要性が認識されたのである[３]。要求工学の目的は、要求を分析し文書化することに関する科学および原理を解明することにより要求分析を効率化しソフトウェア開発を成功させることであるといえよう。 要求工学は、ユーザ要求を仕様化するプロセスである。作成された仕様がシステム開発の設計、製造、試験工程をガイドする。 要求工学は要求の系統的な処理を表す。ソフトウェア要求は要求工学プロセスから生じる生産物である。 要求工学は、コンピュータシステムに関する要求の集合を、発見、文書化、保守することに関するすべての活動を対象とする。要求工学では系統的で反復可能な技術を用いてシステム要求が完全、無矛盾、実際的であることを確認する。 問題分析時に相互作用的で協調的なプロセスにより要求を生成すること、観察結果を種々の表現形式により文書化すること、取得された理解の精度を検討すること、これらをシステム的に行うプロセスのことをいう。 要求工学はソフトウェアシステムに関する実世界のゴール、機能、制約を扱うソフトウェア工学の分野である。要求工学では、これらとソフトウェアの振る舞いに関する正確な要求仕様との関係や、時間ならびに関連するソフトウェアに関してこれらの要因がどのように進化していくかについても扱う。 このように要求工学の定義には、ソフトウェア要求仕様を作成するプロセス（定義１〜定義４）とソフトウェア工学研究の分野（定義５）との2つがある。以下ではまず要求工学プロセスを構成する要素について紹介する。次いで要求工学の主要な研究課題を概観しよう。 SWEBOKでは、要求工学プロセスを、要求の抽出、要求分析と折衝、要求の仕様化、要求の妥当性確認と要求管理から構成している。これらの活動では、まず非公式に提示された要求が合意された要求になり、その要求が仕様書として文書化され、さらに妥当性が確認されるという過程がスパイラルモデルで反復的に繰り返される。 ステークホルダ（システムの利害関係者：経営者、発注者、ユーザ、運用者など）、文書、業務知識（ドメイン知識）市場調査などからシステム要求を見つける。このプロセスは要求の発見や獲得などとも呼ばれる。要求抽出では、インタビュー、シナリオ分析、プロトタイピング、打合せ、ユーザ行動の観察などの手法を用いる。 要求分析では、異なるステークホルダから抽出した要求間の競合を解決し、システム化の範囲を明確化する。このため要求分析では、適切なモデルを用いて要求の構成要素間の関係を理解する。このような要求のモデルには、データフロー、制御フロー、イベント、ユーザインタフェース、オブジェクトなどがある。要求を具体化する過程で、ソフトウェアのアーキテクチャを考慮して、どのコンポーネントが要求に対して責任を持つかということを検討する場合がある。つまりシステムをどのようなアーキテクチャに基づいてコンポーネントに分割し、要求をどのコンポーネントに割り当てるかを考える。 要求の折衝では、ステークホルダ間、機能と制約間などで発生する要求間の競合を解決する。このためには競合解決のためのトレードオフについて合意を形成しておく必要がある。 合意された要求についてすべてのステークホルダが理解できるように文書化する。したがって対象業務の用語を用いて記述する必要がある。また開発者が設計や製造で参照できるように定式化されたモデルで要求を適切な詳細さで文書化することも必要である。 要求の一貫性と完全性をソフトウェアの設計や製造を始める前に検証しておく必要がある。要求仕様書のレビュ、プロトタイピング、モデルを用いた形式的な検証などの手法がある。 要求管理ではソフトウェア開発の全工程で次のようにして要求を管理する。まず合意された要求を識別し、要求の内容を管理する。また指定された要求に対する変更を管理する。さらに要求間の関係や要求とソフトウェア開発に関する他の文書との関係を管理する。 要求工学ではスパイラルモデルにより反復的に要求の仕様が成長していくと考える。このためソフトウェア開発の全工程にわたって要求を管理することの重要性が認識された。これに対して、従来の要件定義ではウォータフォールモデルにより、要求仕様を上流工程で確定してから、下流工程に進む開発工程を想定していた。 1980年代までは、要求仕様ではシステムの実現方法（How）ではなくシステムの目的（What）を記述するべきであると考えられていた。たとえば文献[10]では「要求分析とは、利用者のニーズを明らかにして、システムやソフトウェアに対する外部特性を記述するプロセスである」と述べている。しかし、1990年代に入って、C/Sやインターネット、コンポーネント、Webサービスなどの新しいソフトウェア技術の登場により、アーキテクチャを前提にして要求仕様を記述するようになってきている。SWEBOKでも、すでに述べたように要求工学プロセスでアーキテクチャ設計を考慮している。 要求工学がソフトウェア開発にもたらす作用には、次のような受容性と完全性の向上という２つの方向がある。 発注者の目的に適した要求仕様を記述することで、納入後も継続的に使用できるソフトウェアを提供できソフトウェアの受容性が向上する。 このような要求仕様を満足するソフトウェアを開発することでソフトウェアの完全性を向上できる。 また要求工学の価値をソフトウェアの開発工程ごとに考えてみると次のようになる。ソフトウェア開発の工程には分析、設計、製造、試験、保守がある。分析工程では系統的な要求工学手法を用いることにより完全性の高い要求仕様を作成できる。設計工程では、設計したソフトウェアの構成要素が要求仕様を満足することを検証することにより設計の妥当性を保証できる。製造工程では、コードの必要性を対応する設計の根拠となる要求を追跡することで確認できるだけでなく、コード変更の波及効果も分析できる。試験工程では試験仕様を要求仕様に基づいて作成することにより、信頼性の高い試験を実施できる。またソフトウェアの誤りを修正するために必要なコストの相対比は、要求分析：設計：製造：試験：保守で１：５：10：50：200であるといわれている[11]。 この理由は下流工程に行くほど、誤りの検出が困難になるだけでなく、手戻りがより多く発生するためである。したがってできるだけ要求工学プロセスの段階で誤りを発見することが望ましい。 本稿では、要求工学の必要性と概要ならびに研究課題を紹介した。要求工学はこれまで約30年にわたって発展してきた。今後もこれらの課題にたいして精力的な技術開発が進んでいくことだろう。 |
[ 557] ＠IT：マインド・マップとUMLを使った要求分析支援（前編）
[引用サイト] http://www.atmarkit.co.jp/farc/rensai/mm01/mm01a.html
|
マインド･マップをご存じでしょうか？ 最近、日本でも新しい「メモ技術」として注目されるようになってきた記法です。この記事では、このマインド・マップという記法が、ITの現場でうまく使えないだろうか、というアイデアを紹介します。特に、IT分野で標準化されているUMLをうまく補完するツールとして、要求分析という上流工程をまず取り上げたいと思います。 ITシステム開発において要求分析を行う場合、現在ではUMLを使ったオブジェクト指向による概念モデリングや、ユースケース分析が主流になってきています。しかし、UMLには強い制約（記法の意味と文法）があり、誰でもすらすらとまとまるものではありませんね。特に、顧客へのインタビューを行う場面では、その場でUMLにまとめるというのは至難です。そこで、顧客との対面場面ではとにかく「顧客の言葉を集める」ことに徹し、それをメモ（インタビューの議事録）として持ち帰り、いったん、じっくり考えてからUMLで仕上げ、それを顧客と合意する、という二段構えで要求分析を行うのが一般的だと思います。 この記事では、その「顧客の言葉を集める」場面において「マインド・マップ」という記法を使うことを提案します。この記法は、高速に、かつ、印象深いメモを取ることが可能で、後でそのメモを見返したときにその場面を思い出しやすい、という特徴があります。そのマインド・マップで書かれたメモから、UMLによる要求分析にどのようにつないでいくか、という具体的指針まで提案したいと思います。 人間の脳は、1兆程度の脳細胞（ニューロン）からできています。そして、その脳細胞は樹状突起と呼ばれる放射状に伸びた千程度の触手でほかの脳細胞と結合しています（シナプス）。シナプスは脳全体では100兆から1000兆あり、われわれの大脳は10テラバイトを超える記憶容量を持つといわれています。これは、DVDの映画なら2000タイトルに相当し、1日12時間見ても見終わるまでに1年間かかる情報量です。ものが思い出せない場合、よく、「記憶力が悪い」といういい方をしますが、実際には記憶されているものを取り出すことができない、という表現が正確です。この膨大な記憶量から必要なものを探り当てる能力、すなわち「想起力」が記憶力のキーだ、というのがトニー・ブザンの主張です。 また、右脳と左脳の働きについても、最近よく分かってきました。右脳は図形処理や直感的思考を担当し、左脳は言語処理や論理的な思考を担当しています。マインド・マップは、ニューロンとシナプスの構造を模した放射状のビジュアル構造と、キーワード連想を使った論理構造で、右脳と左脳の両方を刺激します。マインド･マップに近いものにダ・ヴィンチのノート（図2）があります。その構造は、絵と文章が交錯しており、右左両脳の協調によって成り立っていることが分かるでしょう。 このような人間の脳の働きを、コンピュータと対比してみます。コンピュータは情報をデジタルで処理するため、大量の情報を正確に長期間記憶することが得意です。一方、人間の脳は、脳細胞のシナプスを伝わる電気信号の強弱というアナログな情報処理メカニズムのため、時間の経過とともに情報の細部が失われる記憶の劣化は避けられません。しかしながら、与えられた情報に対して無意識に重み付けを行いながら、同時に過去の記憶の中から類似、関連する情報を検索するという、現在のコンピュータではまねのできない高度な処理を瞬間的に行うことが可能です［2］。 ［2］ 例えば、毎日鏡で見慣れているはずの自分の顔ですら、「正確に」思い浮かべることは困難ですが、小学校以来の友人にばったり出会っても、それまでに知り合った数百人、数千人の友人・知人の中から瞬間的に個人を特定し、その名前や忘れていた過去のエピソードまで次々に思い出したという経験は誰にでもあると思います。 記憶しているものを思い出す力、それは、連想とかかわっています。連想は、発想の連続です。うまくビジュアルな刺激を使えば、昔の友人のようにこの連想を喚起することができ、記憶を呼び覚ますことができるのです。 この想起力・発想力を高めるに、脳のメカニズムにうまく働きかけるのがマインド･マップです。情報を簡潔なキーワードに集約し、キーワード間の連想関連を放射状に広がるビジュアルな位置関係で描くことで、イメージによる記憶が呼び起こされるだけでなく、図形処理のために右脳が働き、同じ右脳による直感的思考を喚起して、脳の記憶と検索のメカニズムを働きやすくします。 この記憶を呼び覚ます力、想起力のおかげで、例えば、ボーイング社では、航空機の製造マニュアルを長さ7メートルのマインド・マップにし、研修期間を大幅に短縮、1000万ドルの経費削減をしたという報告があります。また、自閉症の子供がこの記法を使うことでどんどん自分の世界を広げていったという報告もあります。 さて、少々マインド・マップについての説明が長くなりました。次に、これをどのように私たちの仕事の現場で使っていくか、という観点で考察していきましょう。 ここでは日々の仕事の場面において、どのようにマインド・マップが活躍しているか、具体例を基に示したいと思います。以下に、筆者らの周りのマインド・マッパー［3］たちが実際に行っている具体例を、5つ紹介します。 マインド・マップで、議事録やインタビューの記録を作ります［4］。決まったこと、聞き取ったことなどをどんどん打ち込んでいきます。テンプレートとなるBOI（議事録であれば、日時、場所、参加者、目的、アジェンダ、宿題、インタビューであればインタビューしたい項目）などをあらかじめ用意しておくことで、素早く記録することができます。マインド・マップツールによっては、マウスを使わずに「リターン」キーでどんどん兄弟トピックスを作って、「INS」キーで子トピックスを作っていくことができますので、とても快適に入力できます（図3）。また、目立たせたい部分を塗りつぶす、などの細工もできます（宿題、の部分など）。 マインド・マップで、プレゼンテーションの骨格（メモ）を作ります。パワーポイントの資料の下書きとなります。マインド・マップツールによっては、そのままプレゼンテーションできるものもあります。マインド・マップでプレゼンテーションの骨格を作成する利点としては、全体を見渡すことができるという点です。プレゼンテーションソフトで全体表示もできますが、基本的には1画面1枚のシートの集合です。全体のストーリー展開や、つながりを一望できるため、プレゼンテーションの骨格がぶれないようにチェックすることが容易です。さらに、マインド・マップをそのままプレゼンテーションに利用すれば、通常のシート集合のプレゼンテーションに比べて、聴衆が常に全体感を知ることができるという利点もあります。先のKent Beckは骨子のマインド・マップを1枚表示したまま講演をしていました。恐らくそのマインド・マップは聴衆に非常に強いインパクトを与えたはずです。 大きなホワイトボードにテーマを書き、全員でマインド･マップを作るという手法があります。お互いのアイデアに刺激されて、どんどんマップが広がっていきます。数人で書いたブレインストーミングの成果は、壮大なマインド・マップになります。図4は、プロジェクトの「振り返り」（KPT）をマインド・マップを利用して行った例です（図4）。 KPTはプロジェクトの振り返りを行う際のフォーマットの1つです。KeepのBOIには、今後も続けたいことを、ProblemのBOIには、問題点を、そしてTryのBOIには、次回試してみたいことを書き込んでいます。マインド・マップを使わない会議で、参加者がここまでたくさんのホワイトボードに書き込みをするという情景があるでしょうか？ マインド・マップの自由な記法は、ホワイトボードの隅々までコメントを書けるほど柔軟性に富んでおり、自分の言葉でコメントを書こうという意欲を促進させます。 読んだ本、聞いた講演・セミナーの概要を、マインド・マップを使ってまとめることもできます。講演・セミナーでは、素早くメモを取る必要があるため、キーワード指向のマインド・マップは非常に相性が良いといえます。さらには、完成したマインド・マップを見ることで、講演・セミナーの構成がバランスが取れていたかが一目で分かる［5］という利点もあります。そして、このメモを見ることで、実際にそのセミナーの場面を思い出すことができる、という想起性が生かされる使い方です。特に最近ではセミナーに行くと、その場でスケッチブックを取り出してマインド・マップにメモを取っている人を見かけるようになりました（図5）。 『3色ボールペンで読む日本語』や『声に出して読みたい日本語』で有名な斎藤孝さんの著書に『偏愛マップ』自己紹介手法があります。これは、自分の趣味（偏愛しているもの。特にオタクであればあるほど、特殊であればあるほどよい）をマップに書いて見せ合う、という手法です。プロジェクトのキックオフのときに、これを使って自己紹介しているチームがあります（図6）。 マインド・マップという記法を、UMLを補完するツールとして、要求分析などの上流工程で応用する方法を紹介 |
プロミスのサイトです。
