|
|
概 要 要求の管理では、ソフトウェア開発の全工程にわたって要求の作成だけでなく変更まで含めて管理する。このため要求管理は、下流工程の作業と並行して実施される。本稿では、要求変化の要因、要求管理項目、要求の変更管理プロセス、要求管理の発達段階、投資効果などについて説明し、今後の課題についても言及する。 要求管理の位置づけ 要求管理の目的は、要求抽出、要求分析、要求の仕様化、要求確認からなる要求作成過程で要求を管理するだけでなく、要求に基づいてソフトウェアが設計され実装される過程や、システムが運用されてから発生する要求の変更についても管理することである。要求管理の対象は、要求属性、要求変更、要求の版、要求追跡である[1][2][3]。また要求管理では、要求の作成プロセス、監視内容についても明らかにする必要がある[4]。もし要求作成プロセスの中でどこまで処理されているかを監視することができなければ要求作成の進捗状況を精確に管理できないだろう。 このように要求管理により、要求を識別でき、どういう属性を持ち、どのような状態にあるか、他の要求との関係などが一貫して把握・管理できるようになる。したがって、要求管理で管理する情報には、要求そのものの情報、要求と他の要求との関係、要求と要求仕様との関係、要求の作成状態、下流工程の生産物との関係などがある。 もし、要求がこのような情報によって管理されていなければ、どのようなシステムが実現されるのかを確認することは困難だろう。 また要求仕様書があったとしてもその中で要求が個別に識別されていなければ、要求の影響範囲の分析・修正や確認作業を効率化できないだけでなく、その進捗を客観的に把握することも困難である。 要求属性 要求属性は要求を管理するための情報項目である。たとえば、次に示すような情報を管理する。 ・識別番号：要求を一意に識別するための番号。要求を識別するために、要求仕様書の章節番号を利用することもできる。しかし、この方法だと、仕様書の作成過程で構成が頻繁に変更されたりするときには、識別番号も影響を受けてしまうという問題もある。ソフトウェア開発を管理する上でも、開発工程全般にわたって、要求の識別番号が変化しないような命名規則を定義しておくことは重要である。 ・日付：作業開始日・終了日 ・要求理由：要求がなぜ必要となるかを示す理由や根拠を明確にする。また要求が前提として想定する仮定を記録する。これにより要求が前提としている環境などの根拠が変化したときに、影響を受ける要求の特定を容易化できる。 ・分析内容：要求の分析内容、経費・期間などを明確にする。 ・利害関係者：要求の依頼元を明らかにする ・分析状況：要求に対する検討状況を記述する。たとえば、分析中・保留中・確認中・修正中・確認済みなどの状態が考えられる。これらの要求の状態は要求の作成・変更管理プロセスに応じて決める必要がある。 ・責任者：要求に対する責任部門を明確にする ・安定性：要求が確定しているか、将来変化する可能性があるかを明示することにより、要求変更時の影響範囲の追跡を容易化できる。 ・サブシステム：要求を実現するサブシステム ・版：要求を実現するシステム製品の版番号 ・優先順位：要求の優先順位 ・関連要求：要求変更に関連する要求 ・備考：要求変更に関する上記以外の参考情報 要求の変更要因 要求が変更される要因としては、要求誤り、利害関係者の知識の変化、技術・計画・経費などの制約、優先順位の変更、システム環境の変化、組織変更などが考えられる（表１）。 ◆要求の誤り 要求分析、確認段階や設計工程以降の下流工程で検出された要求の誤り・矛盾を訂正する。 ◆利害関係者の知識の変化 要求が詳細化されることにより、利害関係者がシステムに対して何を必要としているかがより明確になるために要求の内容を変更する。 ◆技術・計画・経費の制約 要求を実現するための経費・期間・所要技術の成熟性などの理由で、実現すべき要求の内容が変更される。 ◆優先順位の変更 システム開発の途中で、当初想定したビジネス環境が変化することにより、実現すべき要求の内容が変更される。 ◆システム環境の変化 システムの走行環境が変更されると、システム要求に依存する要求の内容が変更される。 ◆組織変更 システムの利用組織の変更に伴う業務プロセスの変更により、要求の内容が変更される。  表1 要求の変更要因 変更されやすい要求の分類 変更されやすい要求を予め特定しておくと管理を容易化できる。このような不安定な要求が持つ特性としては、環境変異性、詳細留保性、想定依存性、相互接続性などが考えられる。 ・環境変異性：システムの運用環境の変更を許容するための要求 ・詳細留保性：要求作成時に検討を効率化するために要求の内容を「仮設定」しておき、システム開発の途中で、具体化される要求。仮設定した要求の内容がそのまま担ったままで、実装されてしまうと、必要な機能が実現されていないという問題が発生する。保留された要求は実装前に具体的な要求に変更しておく必要がある。 ・想定依存性：システムが想定する利用環境に依存する要求。要求作成時に想定した環境が実際の環境と異なれば、要求は変更される。もし要求で想定した範囲を超えたシステムの使用があったとき、その使用が想定範囲外であることを確認するためには、要求が前提としている仮定が明記されている必要がある。 ・相互接続性：装置・プロセスとの相互接続性を保証するための要求。接続する対象の変化によって、要求も変更される。 このような変化しやすい要求の分類とその内容を前述した要求属性の「安定性」欄に記述しておくことで、要求の変化にも柔軟に対応できるようになる。 要求の変更管理手順 要求の変更管理では「要求変更依頼票」に基づく次のような手順が必要になるだろう[1][2]。ここで要求変更依頼票では表２に示すように、変更要求の識別番号、日付、変更理由、分析内容、依頼元、分析状況、修正担当、関連要求、版番号、備考などの項目を記述する。 ◆要求変更依頼票の作成 変更すべき要求について「要求変更依頼票」を作成し、修正すべき要求とその理由を明確にする。要求管理部門が「要求変更依頼票」を受付ける。 ◆要求変更依頼票の分析 提案された要求変更による影響範囲を分析し、修正経費・期間などを明確にする。この過程で要求変更の妥当性を吟味する。もし妥当でなければ要求変更依頼の却下を依頼元に通知する。要求変更を受理するか却下するかの判断では、関連する利害関係者の合意も必要になるだろう。 このため、要求管理部門では、要求変更に関する判断方針を規定しておくことも重要だ。 ◆要求の変更 要求文書を修正して、文書の妥当性・品質を確認することにより、要求仕様書を更新する。関連する他の文書に関する変更依頼を通知する。 ◆要求変更の確認 関連する変更依頼に対する確認結果を受理する。要求変更の完了を依頼元に通知する。  表2 要求変更依頼票の構成 要求の版管理 要求仕様書に対する版管理では、どのような要求変更を反映したかを変更履歴により明確にする必要がある。要求変更依頼票にも、どの版の要求仕様書で変更が反映されるかを記述しておき、相互に確認できるようにしておくことで、確実な要求の変更を保証することができる。 要求仕様書の版管理では、製品として実装される要求変更だけを選択して仕様書を修正するべきであろう。そうしないと、必ずしも実現されない要求を仕様化することになるので、仕様書とコードとが対応しなくなってしまう。個々の要求変更ごとに要求仕様書の版を更新しようとすると、要求仕様書の版数が多くなりすぎて、管理効率が悪くなるだけでなく、要求仕様書の版に対応してコードを実装・試験することは実行上不可能に近いだろう。また、コードと対応する要求仕様を管理する場合、後者の方が、個別の変更要求を直接コードと対応付けるよりは管理が容易である。したがって、現実的には、複数の変更要求をまとめて「要求変更ベースライン」を構成し、この変更要求の集合に対して製品を実装することが望ましい。このときの問題は、「では一体どれだけの変更要求を集めてベースラインを構成すればいいか？」ということになる。変更要求に対する作業には、変更要求の分析・修正・確認と、それに後続する設計・製造・試験がある。これらの作業を個々の要求変更ごとに実施するよりも、複数の変更要求の集まりに対して実施するほうが効率的である。この理由は要求変更から見るとこれらの共通的なコストを複数の要求変更でシェアできるからである。 要求管理手法 要求管理手法として、ワープロと要求管理ツールとを比較してみると表３のようになるだろう。これまでに多数の要求管理ツールが製品化されている。要求管理ツールをまとめて紹介しているサイトもある[4]。要求管理ツールの比較サイト[5]では、比較項目として、要求識別、要求構成管理、要求の関係管理、追跡管理、文書化支援、グループウェア連携、外部ツール連携、システム環境、ユーザインタフェース、標準対応、ツールのサポート・保守、訓練コースなどを挙げて評価している。ただしこのサイトで比較されている22個のツールベンダからの回答を紹介している。この中で日本語化されているツールとしては、Borland 社のCaliberRMTM6.5日本語版[7]やIBM Rational のRequisitePro[ 8 ]、Telelogic のDoors[9]がある。文献［４］には最終章にDoorsの紹介がある。比較結果を見てみると分かるが、どのツールもこれらの比較項目に対する機能やサービスを何らかの形で提供している。実際に要求管理ツールを選択する場合には、プロジェクトの特性に応じて、より具体的な内容を評価する必要がある。  表3 要求管理手法の比較 要求管理の発達段階 ソフトウェア開発プロセスには、ハンフリーの成熟度モデルCMM（Capability Maturity Model）があるが、要求工学についてはどうなるだろう。Heumannによる要求管理の成熟度では要求の情報構造に着目して次のような5段階の要求の成熟レベルを定義している[10]。 レベル１：要求が文書化されている。[H１] レベル２：要求が定型化、版管理されている。[H２] レベル３：要求が構造化されている。機能要求と非機能要求の分類だけでなく、要求属性が管理されている。[H３] レベル４：要求が追跡可能な形で管理されている。[H４] レベル５：要求が設計,変更管理、試験,プロジェクト管理で利用できるように、要求管理が他のソフトウェア開発環境と統合されている。[H５] この要求管理成熟度モデルでは静的な情報構造は定義しているが、ソフトウェア開発プロセスの観点から見ると、要求管理のプロセスとしての動的な側面は規定できていない。 これに対して、Linscomb[11]は要求工学の成熟レベルの高さを判定するプロセス面での条件として、以下を示している。 ［L1］複数の利害関係者の合意を得た上で要求を文書化している ［L2］多様な要求抽出獲得技術に習熟しプロジェクトや利害関係者の実態に応じて活用している ［L3］プロジェクトのライフサイクルを通して承認された最新の要求をリポジトリで管理している ［L4］要求変更管理プロセスを定義し、一貫して利用している ［L5］要求追跡マトリクスを定義・管理できる しかし、これらの条件では成熟した要求管理プロセスが持つべき性質を定義しているだけで、要求管理プロセスを継続的に改善するという視点が考慮されていない。したがって要求管理プロセスの発達段階として、次の3段階があると考えるのがいいのではないだろうか。 段階１：要求情報を管理する[H1-H5] 段階２：要求作成プロセスを定義する[L1-L5] 段階３：要求作成プロセスを継続的に改善する それでは要求作成プロセスをどのようにすれば継続的に改善できるのだろうか？それにはまず、要求作成プロセスを可視化することが必要だ。 要求作成プロセスの可視化 要求に識別番号（RQID）を付与して管理していれば、要求抽出・要求分析・要求仕様化・要求確認のどの工程で指定されたRQIDを持つ要求が処理されているかを追跡できる。ここでは各工程での作業開始・終了日時をRQIDごとに記録しておくことにより、要求作成プロセスを可視化する方法を紹介しよう。たとえば、図1に示すように要求管理情報の履歴に基づいて要求作成工程ごとの処理状況を時系列的に可視化することができる。図１の横軸は時間、縦軸は要求の個数を示す。折れ線で各工程の時間に対する作業量を示している。この折れ線の傾きが時間当たりの作業量（要求の処理量）であり各作業の生産性を示すことがわかる。このような図は生産管理分野では「流動数曲線」と呼ばれている。 この流動数曲線を描くことで工程間のリードタイムや在庫量を可視化できる。流動数曲線を分析することにより、生産プロセスの課題を発見し改善策を検討することができる。要求管理ツールでも、要求管理工程ごとの作業の開始終了時間を記録していれば、要求作成プロセスの流動数分析ができるであろう。このように要求管理の効果には、要求に対する作業状況を可視化することで、ボトルネックになっている工程などの課題を発見し、作業の効率化を実現できることも挙げられる。もし、要求を管理していなければこのようなプロセスの可視化もできずプロセス改善もできないであろう。これまでの要求管理ツールのレポート機能ではここで紹介したような流動数分析ができるものは残念ながらまだないようである。プロセス改善は要求管理の重要な応用になると思われるので、要求管理ツールの今後の拡充に期待したい。  図1 流動数分析 要求管理の投資対効果 要求管理の効果は間接的にしか見えないので、要求管理のための経費を必ずしも十分にかけにくいというプロジェクトも多いのではないだろうか。 要求管理ツールに対する投資対効果（ROI）については、次のような議論がある[12]。たとえば5000万円のソフトウェア開発プロジェクトがあるとき、開発工程で発生する手戻り率が30%、そのうち要求分析工程に関する手戻りが70%だとすると、要求分析に関する手戻りコストは1050万円になる。もし要求管理ツールでこのような要求分析工程に関する手戻りを抑止できるとすると、要求管理ツールが仮に100万円だとしても、ROIは10.5になる。しかし、実際にはこのようなROIの計算は楽観的過ぎるとも言えるだろう。この理由は、要求管理ツールが解決するのは要求の管理効率や検索効率の向上であり、要求誤りそのものを発見し、修正するのは要求分析や要求を仕様化し確認する担当者の役割だからだ。要求管理についてROIをより現実的に評価するには要求管理作業の具体的な内容に立ち入って議論する必要がある[13]。いずれにしろ効果的な要求管理のプロセスをプロジェクトの実態に応じて具体化していくことが重要だ。こう考えると、逆説的ではあるが、要求管理のROIを精確に議論するためには、要求がどのように仕様化されていくかという要求作成プロセスの個々の作業とその負荷の大きさを把握しておく必要があることに気づく。結局、要求をきちんと管理していなければ、要求作成プロセスの作業コストが精確に把握できず、したがって、要求管理ツールに対するROIも評価できないことになる。 要求管理の将来 要求管理では、要求仕様書と要求の関係だけでなく、要求仕様と要求分析モデルとの対応関係も明らかにしておく必要がある。要求仕様は日本語で記述するが要求分析モデルはUMLなどの図式表記法で記述するため、何らかの変換が必要になる。 現状では、図式の構成要素やそれらの接続関係を日本語に変換して表現することはできるが、そのままでは冗長で顧客から見て必ずしも理解しやすいとはいえない。したがって、簡潔にまとめて表現するための抽象化などの工夫が必要だ。 要求変更を管理するためのプロセスをワークフロー管理ツールや要求管理ツールと組み合わせて効率化することも課題の一つだ。もし影響範囲の解析手順や要求仕様書の変更手順などをツールで管理できれば、このような作業を効率化できる可能性がある。 また要求間の関係では、機能要求と非機能要求の関係の管理も重要な課題だ。一つの方法としては、すでに紹介したが、ゴール指向分析などの方法で、対応付けていくことができる。この場合、要求属性として機能要求や非機能要求とともに、ゴール要求などを管理することになる。 したがって要求管理の中でどこまで要求分析手法を取り込んでいくかが課題になる。また最近では、MDA（ModelDriven Architecture）[14]などのようにプラットフォーム独立な要求分析モデルからプラットフォーム固有のコードを自動生成する手法も注目されている。今後はMDAを前提にした要求管理手法の開発も必要になるだろう。この場合、モデルからコードが自動生成されるので、モデルの版管理と要求仕様書の版管理との同期が課題になると思われる。 今回、要求管理について紹介した基本的なことがらについては、実は昔からあまり変わっていないように思われる。やはり重要なことは、要求管理手順を明らかにして当たり前のことをきちんと確認しながら実践することと、作業結果をリアルタイムに監視することによって継続的に問題点を改善していくことなのであろう。 さて次回は、要求管理についてのもう一つの重要なテーマである要求追跡について紹介する予定である。[15] 参考文献 [１]Kotonya, G. and Sommerville,, I., Requirements Engineering-Process and Techniques,John Wiley & Sons, 2002. [２]Wiegers,K.,ソフトウェア要求―顧客が望むシステムとは、日経BP、2003 [３]Leffingwell,D. and Widrig,D., ソフトウェアの要求管理〜新世代の統一アプローチ〜、ピアソンエデュケーション, 2002 [４]Elizabeth, M., Hull, C., Jackson,K., and Jeremy,A.,Dick,J.,Requirements Engineering, Springer, 2002 [５]INCOSE, Requirements Management Tools Survey,http://www.paper-review.com/tools/rms/read.php [６]Requirements Management Tools, http://www.jiludwig.com/Requirements_Management_Tools.html [７]IBM Rational、RequisitePro,http://www.ibm.com/jp/software/rational/products/req/reqpro/fb.html [８]Borland, CaliberRM、http://www.borland.co.jp/caliber/ [９]Telelogic, Doors, http://www.telelogic.com/jp/ [10]Heumann, J., The Five Levels of Requirements Management Maturity., http://www.therationaledge.com/content/feb_03/f_managementMaturity_jh.jsp. [11]Linscomb, D., Requirements Engineering Maturity in the CMMI,http://www.stsc.hill.af.mil/crosstalk/2003/12/0312linscomb.html [12]Dean Leffingwell, "Calculating Your Return on Investment from More Effective Requirements Management." IBM Rational Whitepaper available at: http://www-106.ibm.com/developerworks/rational/library/347.html [13]Denney,R., ROI On Requirements Management tools, http://www.itmanagementnews.com/2003/0826.html [14]MDA, http://www.omg.org/mda/ [15]山本修一郎、要求工学、ビジネスコミュニケーション, http://www.bcm.co.jp/
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
