|
|
概 要 要求の妥当性確認では、要求仕様書の一貫性、完全性、正確性、実現可能性を確認する。要求については分析段階でも妥当性を確認している。要求分析では関係者が合意できる真の要求を獲得することが目標だった。要求確認では要求が正しく記述できていることを保証して関係者と合意して、設計工程を開始する前の最終的な要求仕様を確定することが目標になる。本稿では、要求確認手法を概観する。 要求確認の位置づけ まず要求工学プロセスの中での要求分析の位置づけを復習しておくと、次のようになる[1][2]。要求工学プロセスには、要求抽出、要求分析、要求の仕様化、要求確認がある。要求抽出と要求分析までが問題領域に関するプロセスである。これに対して要求の仕様化と要求確認がソリューション領域のプロセスである。要求確認では、要求工学の最終段階として、これから設計され実装されるシステムの要求仕様書が一貫性・完全性・正確性・実現性を持つことを保証する。 要求確認の課題 ソフトウェアの設計では、要求仕様に対して設計の妥当性を検証できる。またコーディングでは、設計に対してコードの妥当性を検証することができる。これに対して要求仕様の場合には、ソフトウェア開発の最上流であるため、設計やコードなどの下流の生産物のように要求仕様に相当するような「要求の要求」としての比較すべき仕様が存在しない。 したがって誤りのない正確な要求仕様であることと、求められている要求を記述できているかどうかということは必ずしも一致しないかもしれない。また関係者が想定する要求や要求間の関係が実際の組織や業務プロセスに対して受け入れることができるかどうかも問題になる。もし関係者の合意があっても、関係者の思い込みや見込み違いがあれば、現実の組織や環境面での要求の見落としがあるかもしれない。よく言われることだが、ユーザーは自分が何を要求しているのか、何が実現できるのかを必ずしもよく理解していない。このように要求仕様を何に対して確認するのかが要求確認における最大の課題だ。 要求確認の対象は、要求仕様の中に閉じた確認だけではなく、要求仕様を実現したソフトウェアが利用される業務やそれによって解決される経営課題を含めた環境と要求仕様との一貫性の確認も必要になる。要求確認では、何が確認できれば、要求仕様の妥当性を確認できたことになるかという評価基準について関係者と合意しておくことが必要だ。 要求仕様の確認項目 要求の妥当性の確認では要求仕様書について次の項目を確認する。要求分析段階でも要求を対象として同様の項目を確認している場合には、要求分析モデルと要求仕様書との追跡性が保証されれば、要求仕様の妥当性確認を省略できるだろう。ただし外部環境との一貫性については要求確認で再確認したほうがいいと思われる。 ◆要求の正確性 要求の記述が曖昧でないことを確認する。複数の意味に解釈できるような要求の記述は曖昧である。 ◆記述の最小性 要求の記述が重複していないことを確認する。また設計段階で解決するようなことまで含めて詳細に記述しすぎている要求も問題である。逆に、設計ができるようになるまで、詳細化できていないと、設計段階で要求分析段階の積み残しの検討を追加でやり始めることになる。 ◆外部環境との一貫性 記述された要求と問題領域の業務やシステム環境、組織の中で情報システムが持つべき基本的な条件とが互いに矛盾しないことを確認する。 もし対象領域の現実を十分正確に把握できていないと、要求仕様と外部環境との一貫性を確認することができない。外部環境には組織の中での情報の扱いや作業の順序などの約束事の暗黙のルールも含まれるので注意が必要だ。たとえば、最近ではセキュリティや個人情報の管理の仕方などが外部環境との一貫性の確認項目として考えられるだろう。 ◆要求の完全性 必要な要求がすべて記述されていることを確認する。要求仕様の完全性を確認するためにはシステム開発の目的が具体的に抽出されていることが必要になる。たとえば、経営課題や業務プロセスと要求仕様における機能要求との対応関係を確認する必要がある。経営課題として「在庫量を圧縮する」という非機能要求があったとしよう。このままではどんな機能なのかがわからないので具体化する必要がある。そこでどのようにすれば無駄な製品を作成しないようにできるかを考えて「仕掛かり量を提示する」とか「注文中の部品量を提示する」などの機能要求をもちいて「在庫量を圧縮する」ための業務フローを仕様化することになると思われる。どのような経営課題を解決するために、それぞれの機能要求がなぜ必要なのかということを確認することが重要である。 また経営課題にはKPIが対応付けられることが多い。このようなKPIの値を作成した要求が満足できるかどうかは、実際にシステムを開発して稼動してみないと評価できないので、机上で効果を予測することにより確認する必要がある。これは性能や品質などの非機能要求についても言えることである。 ◆要求の実現可能性 記述された要求を実現するために、技術的に開発可能であることと、必要な経費や開発期間、開発要員が用意できることを確認する。要求の実現可能性が確認できるということは開発規模を見積もることができるということである。たとえば開発規模を見積もるためには要求仕様を実現するために必要な画面仕様、処理仕様、データ仕様が明らかになっていることが必要であろう。 要求確認手法 次のような要求の確認手法がある[2][3]。 ◆要求仕様のレビュ 要求文書の公式レビュでは複数のレビュ担当者からなる会議で要求誤りを抽出し、要求仕様の妥当性を確認する。妥当性の確認基準を定めて対応するチェックリストを用意しておくと効率的で公平なレビュを実施できる。前述した確認項目も要求レビュのチェックリストとして利用できる。 また要求レビュでは、レビュ対象の要求に関連する関係者にも同席してもらってレビュに対する合意を受けることが必要である。 ◆プロトタイピング 要求に基づいてシステムのプロトタイプを作成することにより、顧客からの効果的なフィードバックを得ることができる。プロトタイプの利点は実際のイメージに近い形で要求が提示できるので、顧客に理解しやすいため、要求の妥当性について文書よりも深い議論ができることである。一方、プロトタイプの欠点は、試作のためにコストがかかること、プロトタイプの品質が完成版のシステムの品質について顧客に誤った先入観を植え付けてしまう可能性があることである。 プロトタイピングには短期（ラピッド）プロトタイピングと長期プロトタイピングがある。短期プロトタイピングでは、システムの特定の機能に焦点を絞り込んで妥当性を確認する。長期プロトタイピングは進化型開発のひとつであり、環境変化や顧客の要求変化に合わせて段階的に成長させていく。 ◆モデルの確認 要求分析で作成したモデルの品質について確認する。データフロー図やユースケース図などで要求を記述した場合には、自然言語を用いて顧客にも分かりやすい表現に翻訳してから確認することも必要になるかもしれない。また、現実の業務やデータに基づいてモデルの妥当性を客観的に評価することも重要である。 ◆要求テスト 完成したソフトウェアが満たすべき条件を明らかにしておかないと、受入れ検査ができない。妥当性を確認できないような要求があると、受入れ検査の条件も明確化できない。したがって、受入れテストの仕様は要求の妥当性確認にも利用できる。 ただし、前述したように性能などの非機能要求は実際にシステムが実現されてからでないと確認することが困難である。この場合でも、要求される性能がどのようなシステム環境の下で達成されるのかという環境条件については確認しておくことができる。現実には想定外の条件で利用されたために所期の性能が実現できない場合も多いものだ。 要求をテストするためには、機能要求に対して、業務フローなどを用いてどのような場面で機能が利用されるかという条件を具体化する必要がある。このような利用条件は「利用シナリオ」などとも呼ばれる。利用シナリオでは対象とする機能に対する入力事例に対して想定される出力事例を列挙する。この意味で要求テストは、要求を動的な側面から妥当性を確認する手法であるといえる。 要求テストの記録を管理することも重要である。要求テスト記録では、要求識別番号、利用シナリオ（要求に対する入力と出力や必要な振る舞い）、テスト結果、コメントや必要な対処策などを記述する。 以下では、進化型長期プロトタイピングと概念モデリングにおける要求確認の事例を紹介する。 長期プロトタイピングの事例 NTT研究所で1998年に研究に着手しNTTデータ技術開発本部でΣservとして実用化したサービス連携プラットフォームは国土交通省の自動車保有関係手続きのワンストップサービス[4]に適用されている。この連携プラットフォームの６年にわたる研究開発の歴史は、要求工学の視点からみると、図１に示すように反復的プロトタイピング・プロセスであり、次の４段階で進化したと考えることができる。 （１）要求の提案（1998-1999） 連携プラットフォームの概念を着想し、利用シナリオと想定効果を明確化することによりInfoStage研究計画を策定した。研究計画にあたって包括的な特許調査を実施した。研究計画が承認されると、プロタイプの開発と権利化を進め、適用評価により利用シナリオの有効性を確認した。この段階ではインターネット上のWebサイトを連携することを想定していた。 （２）要求の合意形成（2000-2001） 事業部門や官公庁の研究部門など、主要なステークホルダにプロトタイプをデモすることにより、研究プロジェクトや実システムへの適用を提案した。またデモなどにより収集した意見をプロトタイプに反映する。この段階からWebサービスの連携を可能とするため標準化にも対応した。 （３）仕様化と実用化（2002-2003） 自動車保有関係手続きのワンストップサービス（MOTAS）への導入が決定した。実システムへの導入が決まると、性能や操作性などの非機能要求を明確化し必要な機能を実現するための仕様を作成し、実用化した。さらにΣservを用いてWebサービスを連携するWebアプリケーションを開発し性能などの問題がないことを確認した。 （４）導入と拡張による要求の進化（2004-） Σservを用いた自動車保有関係手続きのワンストップサービスの開発に着手し試行運用する予定である。またΣservの利用を想定した上位機能としてビジネスプロセスコンパイラやセキュリティや性能などの非機能要求の実現を容易化するポリシー制御方式の研究開発に着手した。 この事例では、インターネット上のサービスを連携するためのプラットフォームを段階的に成長させていった。まずInfoSTAGE ではXMLを用いて複数のサイトが提供するインターネットサービスを一連のシナリオとして記述し自動的に連携できるサービス連携の基本的な機構を実現した。次いでΣServ V1では、連携プロセスを高信頼化するための長時間トランザクション機構を実現した。ΣServ V2では、Webサービス標準SOAP、WSDLへの対応を実施し、高信頼SOAPメッセージ機構とクラスタ構成対応を実現した。現在は、新たな進化プロセスの次の周期に入った段階であるといえる。この事例は顧客の要求だけでなく情報技術という外部環境の変化に対応させていく手法として進化型プロトタイピングが有効であることを示しているといえる。  図1 プラットフォームのプロトタイピングプロセス 経営戦略における要求確認の事例 当社では、図２に示すような事実に基づくコラボレーションモデリング手法を開発している。この手法のポイントは、作成した要求の妥当性を現場観察カードとKPIデータという客観的な現実に基づいて確認するところにある。これにより、顧客の組織がもつ現実と記述された要求の間での一貫性も保証することができる。要求が妥当であるためには、要求そのものが矛盾なく記述されているということだけではなく、このような要求の外部との一貫性も確認する必要がある。 従来からバランススコアカードを用いた経営戦略の記述は行われてきたが、KPI項目が多すぎて本質的な業務構造を分かりやすく可視化することが困難だった。したがって、業務状況を適切に把握できない、業務を効率化したいがどこをどう直せばいいか分からないということになりやすい。この原因は、経営戦略モデルとしてだけBSCを用いており、その妥当性を実際のKPIデータなどで客観的に確認していなかったからではないのか？実際に最近、あるお客様から「SCMをモニタするKPIはあるのだが、何が必要かわからない」というお話があった。 そこで、事実に基づくコラボレーション戦略モデリングをご紹介したところ、お客様から「ほしかったのは、これだ。ぜひこのモデリング技術を用いて、SCM戦略を具体化してKPIを精査したい」ということになった。 早速、当社とお客様と共同で「物流におけるコラボレーション戦略モデリング」の検討を進め、物流に関連する複数組織の業務をモデリング対象として、物流業務の戦略構造を可視化し、各組織の業務目標を明確化した。 この結果、お客様から、次のようなご意見をいただくことができた。 ・これまでは個別的な戦略の議論しかできていなかったが、全体戦略を作成できた。これで部門間や個別戦略間の関係が明確にできた。 ・企画部では現場の姿が見えていなかったが、現場の実態に基づく戦略を立案できた。これによって、いま当社が何をすべきかを具体化できた。 ・KPI間の依存関係が明確になっただけでなく必要なKPI が明確化できた。これまではKPI間の関係を分析したことはなかった。 ・ぜひ今回立案した戦略を実行可能なプランとしてソリューション化したい。 この事例からわかるように、顧客の求める要求に対するモデル化された要求の妥当性を確認するための客観的な手法として、事実の観察やKPI項目の統計的なデータ分析が有効である。この理由は、事実やKPIデータが外部環境の具体的な情報を与えており、それが要求仕様に対する「要求の要求」という役割を果たすからだと考えられる。  図2 コラボレーションモデリングのステップ 要求確認の留意点 要求確認では、まず確認すべき要求の内部的な構造と外部的な構造を明らかにしておく必要がある。内部的な構造では、要求仕様の構成要素として何があるか、それらの依存関係はどうなっているかを明らかにする。たとえば、経営課題、業務モデルなどを要求仕様の中で機能要求に対する上位要求として記述する場合と、そうでない場合があるので注意が必要である。 要求が満たすべき外部的な項目としては、要求の発生源や要求の利用者としての関係者、ソフトウェアが満足すべき組織における標準、外部システムとのインタフェースなどがある。また暗黙の仮定なども外部的な確認項目のひとつだ。 要求の妥当性確認の前に、発生する可能性のある誤りや問題点のレベルを修正量や影響範囲の大きさなどに基づいて想定しておき、問題解決や対処の仕方について顧客と合意しておくことも重要である。 次回は、要求管理について紹介する予定である。 参考文献 [１]山本修一郎、要求工学、ビジネスコミュニケーション, http://www.bcm.co.jp/ [２]Kotonya, G. and Sommerville,, I.,Requirements Engineering ? Process and Techniques, John Wiley & Sons,2002. [３]Wiegers,K.,ソフトウェア要求―顧客が望むシステムとは、日経BP、2003 [４]国土交通省、「自動車保有関係手続のワンストップサービスのグランドデザイン」http://www.mlit.go.jp/kisha/kisha02/09/090820_.html
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
