NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第101回 要求発展型開発プロセスの事例国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 山本修一郎

国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授
(前NTTデータ フェロー システム科学研究所長)山本 修一郎

ISO/IEC/IEEE 29148では、「開発管理の観点から、要求を確定することが望ましいけれども、それが可能になるのはまれである」と指摘している[1]。今回は、筆者が主査をしているIPA ソフトウェアエンジニアリングセンターの要求発展型開発ワーキンググループでの議論に基づいて、要求変化対応プロセスの事例を紹介する。なお、2013年3月8日に開催されるIPA/株式会社NTTデータ共催セミナ「第7回要求シンポジウム~術の進展とビジネス環境の変化を受けたソフトウェア要求品質の向上に向けて~」では、「要求が変化する理由」と題して、本稿の内容も含め、要求発展型開発WGの議論についても講演する予定である(http://sec.ipa.go.jp/seminar/2013/20130308.html)。

環境変化への対応姿勢

ヒュー・コートニーの「不確実性時代の戦略思考」[2]によれば、不確実性に対する戦略姿勢(Strategic posture)には、適応、留保、形成があると指摘している。この考え方をソフトウェアの環境変化対応に適用すると、図1に示すようになる。

図1 環境変化への対応姿勢

図1 環境変化への対応姿勢

◆形成(Shape to the Future)

新たなしくみをシステムが提供することによって、未来の環境を形成する。

◆適応(Adapt to the Future)

環境変化に素早く、柔軟に対応することによって、未来の環境に適応する。

◆留保(Reserve the Right to Play)

環境変化に対応するための「形成」または「適応」の意思決定を留保することによって、可能な限り現状のソフトウェアを継続利用することで、未来の対応機会を待つ。

ISO/IEC/IEEE 29148の要求変更管理プロセス

要求変更の必然性を認識することと変更による影響範囲を緩和することが重要であることから、ISO/IEC/IEEE 29148では、要求追跡と要求構成管理を用いて、提案された要求変更に対する影響評価、レビュ、承認プロセスを確立する必要があるとしている[1]

要求変更管理では、プロジェクトにおける構成管理手続きに従って、要求変更レベルに応じて必要となる承認権限者と要求のベースラインを定義する。要求変更管理の対象となるベースラインとして機能(functional)、配置(allocated)、開発(developmental)、製品(product)がある。これらのベースラインに対する要求は、機能要求、設計に配置された要求、開発された要求、製品化された要求となるから、要求変更管理プロセスは上流だけではなくライフサイクル全体を対象とすべきであることが分かる。ここで、運用中の要求は、製品化された要求に対応している。

要求追跡表(Requirements Traceability Matrix, RTM)を用いることによって変更要求に対する影響評価を容易化するとともに、要求変更が承認された場合RTMを適切に更新しておく必要がある。

要求状態管理プロセス

システム要求には、図2に示すような4つの基本的な状態がある[3]。まずシステム要求が抽出されると、ステークホルダによって合意される。合意された要求が実装されると通常運用され、合意されない要求は削除される。

図2 要求状態管理プロセス

図2 要求状態管理プロセス

要求が通常運用されると、目的変化・環境変化によって新たな要求が抽出されるか、当初想定した要求が通常運用範囲を逸脱する。通常運用範囲を逸脱した要求は原因分析される。逸脱した要求が迅速対応されると、通常運用に戻る。一方、通常運用に復帰できない要求には、要求に対する実装が誤っているかどうかによって2つの場合がある。

もし、要求に対する実装が誤っていれば、要求の合意状態に遷移して要求を再実装する。

もし、要求に対する実装が誤っていなくて逸脱したのだとすると、要求を修正することにより新たな要求として抽出する。

この要求状態管理プロセスには、開発時と運用時の要求マネジメントがある。要求の抽出状態と合意状態は、開発時の要求マネジメントの対象である。これに対して、通常運用と逸脱状態の要求は、運用時の要求マネジメントの対象である。

この要求状態管理モデルには、図3に示すDEOSプロセスにおける①目的環境変化対応サイクルと、②障害対応サイクルが対応している。

従来の要求変更管理プロセスでは、開発時の要求マネジメントプロセスしか考慮していなかった。したがって、要求状態管理プロセスが示すような運用時を含めた要求マネジメントが必要である。

図3 DEOSプロセス

図3 DEOSプロセス



続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。

第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。