ホーム > 要求工学 > 第9回 要求追跡

NTTデータ 
技術開発本部 副本部長 
山本修一郎

概 要

 
前回は要求管理について紹介した[1]要求追跡の目的は、ソフトウェア開発における多様な設計情報と要求とを互いに対応付けて管理しておくことで、これらの設計情報と関連する要求を必要に応じて検索できるようにすることである。したがって要求追跡性を実現するためにはソフトウェア開発の全工程にわたって要求の作成だけでなく変更まで含めて下流工程の生産物とともに要求を管理する必要がある。要求追跡の重要性については要求工学研究の初期段階から認識されており、SREMやARTSなどの要求追跡システムが今から30年前の1970年代後半にはすでに開発されていたのである[2][3]
 本稿では、要求追跡性の定義、要求追跡プロセス、要求追跡関係の種類、要求追跡の効果、要求追跡ポリシ、要求追跡の留意点などについて説明する。

要求追跡性とは

◆Davisの追跡性
 Davisは、図1に示すように、ビジネス要求、ソフトウェア要求仕様、設計仕様などの下流生産物に対して、4つの要求追跡性を定義している[4]

・Forward-to R :要求に先行する他の文書から要求への追跡性。たとえば、ビジネス要求からソフトウェア要求仕様への追跡性がある。

・Forward-from R:要求から下流生産物への追跡性。たとえば、ソフトウェア要求仕様から設計仕様への追跡性がある。

・Backward-from R :要求から発生源への追跡性。この関係はForward-to Rの逆関係である。

・Backward-to R:下流生産物から要求への追跡性。この関係はForward-from Rの逆関係である。

◆IEEE-Std 830の追跡性

 IEEE のソフトウェア要求仕様(SRS)の推奨プラクティスでは、第四節:優れたSRS作成に必要な情報の中で、追跡性を挙げている[5]
 SRSは、各要求の発生源が明確であり、文書作成または拡張する際に各要求が参照しやすい状態になっている場合に限り、追跡することができる。IEEE-Std 830では次の二つの追跡性を推奨している。

a)後方追跡性(要求定義以前の開発プロセス)

 要求を作成する以前に作成された文書の情報源を明確に参照できること。

b)前方追跡性(SRS によって生成されるすべての文書)

 SRSの各要求には、一意に識別できる名前と参照番号が割り当てられていること。

 前方追跡は、ソフトウェア生産物が運用および保守段階に入る時点で、特に重要になる。この理由は、コードや設計文書が変更されると、このような変更の影響を受けるすべての要求を確認する必要があるからだ。

◆DOD-Std-2167Aの追跡性

 DOD-Std-2167Aでは、要求から設計仕様への追跡性と、要求からテスト仕様への追跡性を規定している[6]
 また文書間の追跡性を構成する要素として次の5条件を定義している。

(1)下流工程の文書が上流工程の文書が規定する条件をすべて含むか実現している

(2)用語、頭字語、省略語が同一の意味を持つ

(3)要求項目や概念が同じ名前や記述で参照される

(4)下流工程文書の内容の根拠が上流工程の文書に必ずあり、追跡できない内容が記述されていない

(5)2つの文書が互いに矛盾しない


                     図1 要求追跡性の定義

要求追跡プロセス

 要求追跡プロセスは、1)要求の作成・変更プロセスで要求と他の文書との追跡関係を記録・管理するプロセスと、2)要求の追跡時に、これらの追跡関係を検索・利用するプロセスに分けることができる。
 要求追跡関係の記録プロセスでは、要求を識別・分類し、アーキテクチャに従って、要求を機能に配分していく工程で要求追跡の対象となる情報とそれらの関係を定義する。とくに識別された要求追跡情報をいつだれがどのようにして獲得するかを定義する必要がある。要求追跡情報を獲得する方法には、要求の作成・変更過程で自動的に獲得するオンライン方式と、要求仕様や他の文書を作成した後で追跡情報を改めて作成するオフライン方式の2つがある。オンラインで獲得するためには、ソフトウェア開発環境に要求追跡情報の管理機能を組み込む必要がある。
 意味的な要求追跡を可能にするためには、どの要求追跡情報をだれがどんな目的で必要とするかについても記述しておく必要がある。
 要求追跡情報の保守では、要求追跡情報をだれがどのように変更管理するかを定義する必要があり、要求追跡情報の獲得プロセスと緊密な関係がある。
 要求追跡情報を検索することにより、要求変更の影響分析や要求の導出分析、要求の網羅性分析などを実施できる。要求追跡性に基づくこれらの分析と各工程の生産物との対応関係を図2に示した[7]
 影響分析では、前方関係を追跡して「もしこれを変更したら?」という質問に答えることができる。たとえば、システム要求からサブシステム要求を追跡したり、システム要求からシステム試験を追跡することができる。
 導出分析では後方関係を追跡して「なぜこの情報がここにあるのか?」という質問に答えることができる。
 たとえば、システム要求から関係者の要求を追跡することや、サブシステム試験からサブシステム要求を追跡することができる。
 網羅性分析では関係を持つ要求項目を計上して「すべて網羅したか?」という質問に答えることができる。網羅性分析は進捗状況を計測できるので開発管理の手段になる。


                       図2 要求変更管理

要求追跡関係の種類

 要求、発生源、根拠、アーキテクチャ、設計、インタフェースと要求との追跡関係を示すと次のようになる[8]
 要求・発生源:要求の発生源である人や文書と要求との関係要求・根拠:なぜその要求が仕様化されたのかという説明と要求との関係

要求・要求:要求とそれに依存する他の要求との関係。たとえば、要求が複数の要求に展開される階層関係や要求が変更されて別の要求に発展する進化関係などがある。

要求・アーキテクチャ:要求が実装されているサブシステムと要求との関係

要求・設計:要求を実装するコンポーネントと要求との関係

要求・インタフェース:要求が使用する外部システムと要求との関係

 このような要求追跡関係を利用すると、次のような性質を確かめることができる[9]

充足性:要求がシステムにより実現されていることを確認する

妥当性:機能の存在理由や要求の変更理由を確認する

一貫性:名前の一致関係や要求の詳細化関係を確認する

要求追跡ツール

 小規模開発ではエクセルなどの表計算ソフトを用いて要求間の関係を管理することが多い。しかし、基本的には、紙による要求追跡の電子版であり、人手で変更管理するため要求管理が難しいという問題がある。
 このため要求追跡に特化した専用ツールが開発されている。要求追跡情報を細粒度で管理すれば、特定の要求追跡には高い追跡能力を発揮できるが、逆にすべての要求追跡には対応できないという制約もある。これに対して疎粒度で要求追跡情報を管理することにすれば、詳細な情報を持たないため要求追跡能力は低下するかもしれないが、いろいろな場面で利用できるので追跡の汎用性は高くなる。
 要求追跡ツールを用いて影響範囲を検出し修正する場合には次の4つがある。

誤りがない:すべての影響部分を検出し、正しく更新する

検出もれ:検出できない影響部分があると、変更の影響を反映できない

更新誤り:影響範囲を正しく検出したにもかかわらず、変更に対して正しい修正をしていない

不正検出:影響ない部分を影響範囲であるとして検出し誤って更新する

 現状の要求追跡ツールでは完全に自動化できるわけではないので、変更による影響を受ける生産物に対して人間が最終的には判断して更新する必要がある。

要求追跡の効果

 要求追跡の効果には、設計の妥当性の評価、矛盾の検出と一貫性の保証、検査証跡などがある[9][10]
 設計妥当性の評価としては、要求に対する設計がすべて存在することを確認できるので設計漏れを予防できるだけでなく、逆に設計に対する要求が存在することを確かめることにより過剰設計を抑止できる。同様にして機能が顧客要求に適合していることや冗長な機能を実現していないことを確認できる。
 また性能・品質などの非機能要求と機能要求との関係を確かめることにより、非機能要求に対して設計仕様が妥当であることを確認できる。
 顧客要求が変更された時には影響波及分析により、どの機能や設計に影響が出るかを把握することもできる。
 要求追跡情報に基づいて関連する要求を抽出して可視化し人間が確認することで、矛盾検出や一貫性の保証を容易化できる。たとえば、代替案、決定事項、前提条件などを設計理由も含めて要求から追跡できれば、顧客によるシステムの理解を向上できるだけでなく、検討経緯を再利用することで無用な手戻りを削減し変更管理作業を効率化できる。
 要求と関係者との関係を追跡することにより、変更要求を誰と議論するかを選択したり、チームメンバのコミュニケーションを改善できる。

要求追跡ポリシ

 要求を追跡するためには、要求追跡に関する方針を要求追跡ポリシとして、プロジェクトごとに規定しておく必要がある。要求追跡ポリシでは、次のような追跡情報、追跡方式、追跡条件、例外条件、追跡プロセスなどを定義する。

追跡情報:要求項目間の依存関係情報

追跡方式:要求追跡性を維持管理するための情報管理方式

追跡条件:要求項目間の関係情報をいつ記録するかという説明。また追跡情報を管理する責任者の役割も定義する

例外条件:要求追跡性を管理する上での、時間的な制約など例外の扱いを定義

追跡プロセス:要求の抽出・変更時に、要求追跡性を獲得・維持管理するためのプロセスを定義する

 大規模システムを対象にした要求追跡のための情報管理モデルの例を図3に示す[9]。要求追跡ポリシに従って、どの範囲まで要求追跡情報を管理するかを決定する必要がある。
 重要なことはすべてを管理することではなく何を管理するかをプロジェクトで決定しておくことである。また要求追跡ポリシに影響する要因としては次のような項目がある。

要求項目数:要求項目が増加すれば要求追跡ポリシの必要性が高まる。

生存期間:システムの存続期間が長ければ、理解しやすい要求追跡ポリシが必要である。

組織の成熟度:
CMMの上位レベルでは要求項目間の詳細な追跡関係を管理する。下位レベルでは要求間の追跡レベルにとどめる。

システム種別:基幹系システムと情報系システムでは、異なる要求追跡ポリシが必要である。

顧客要求:顧客が必要とする要求とシステム機能との関係を追跡するために、機能仕様の付加情報として顧客要求であることを明示する必要がある。


                  図3 要求追跡性の管理モデル

要求追跡のメトリックス

 要求追跡関係が定義されていると、要求間の関係に基づいて、次のようなメトリックスを定義できる[7]

◆要求追跡のひろさ

・指定された層を追跡関係がどれくらい網羅しているか?

・指定された層に含まれる要素のうち追跡関係を持つ要素の割合

◆要求追跡のふかさ

・指定された要素がどれくらい深く影響を与えるか?

・指定された追跡関係が到達可能なレベルの個数の最大値

◆成長性

・指定された要素が追跡関係によってどのように詳細化されているか?

・指定された追跡関係が与えられたレベルまでに到達可能な要素の個数

要求追跡の留意点

 効果的な要求追跡を実現するための主な留意点を列挙すると次のようになる。

◆ツール

 要求追跡ツールを活用すること。しかし効果的にツールを活用できないと逆効果である。

◆トップのコミット

 プロジェクトごとのアドホックな手法では、全社的な取り組みにならず、効果も限定的である。トップによる組織的なコミットによる要求追跡の積極的な支援が必要である。しかし一方で、要求追跡専門のスタッフ部門を配備しても、オーバヘッド作業をプロジェクトごとに実施するのでは逆効果になるかもしれない。

◆プロジェクトの取組み

 開発プロジェクトの内部スタッフが標準的な手法により自立的に要求追跡に取り組んでいく体制を構築する必要がある。要求追跡がソフトウェア開発プロセスを改善する「しくみ」であることをよく理解した担当者によって実施されることが重要である。要求追跡をソフトウェア開発におけるオーバヘッドであると考えて、企業内の開発標準に従うことだけを目的とした後ろ向きの要求追跡作業なら逆効果である。

◆要求追跡情報の獲得

 要求追跡情報を均等に満遍なく獲得しようとすると、システム開発のオーバヘッドになりやすく逆効果である。この問題を回避するためには、ライフサイクル全体の開発コストを考慮して要求追跡対象を絞り込む必要がある。

まとめ

 今回は要求追跡について紹介した。要求追跡は、変化しやすいソフトウェア要求を追跡管理し、影響範囲を限定し正確に変更することができ、開発リスクを低減するためにも必要な技術である。要求追跡により、顧客の要求品質を達成するだけでなく、無矛盾性、完全性を確認できるという利点がある。
 しかし、現状では人手で要求追跡のための情報を要求文書や下流工程生産物に追加する必要があるため、開発チームから見ると、直接的な効果が見えないという不満もあるだろう。この理由は追跡性の効果が下流工程(統合試験、導入、運用、試験、機能拡充)にならないと見えないことにある。したがって、開発チームから見ると、要求追跡作業の優先順位は必ずしも高くないという問題がある。要求追跡の潜在的な効果には、手戻りや要求誤りの抑止などもあるが、一言でいえば、要求追跡は想定される将来の開発リスクに備える保守のための技術といえよう。このような開発リスクは必ずしも完全に予測できるわけではないので、どこまでの範囲で追跡情報を用意しておくのが最適なのかということを見極めることが重要だ。要求追跡性の投資対効果を測定するための実践的な事例研究が望まれる。
 さて今回までで、要求工学についての一通りの解説が終わったことになる。次回は要求工学についての最近の話題について紹介する予定である。


参考文献

[1] 山本修一郎、要求工学、ビジネスコミュニケーション, http://www.bcm.co.jp/

[2] M. Alford, A requirements engineering methodology for real-time processing requirements,IEEE trans. On SE, Vol. SE-3,No.1, pp.66-69, 1977

[3] M.Dorfman and R.F.Flynn, ARTS? An Automated Requirements Traceability System, The Journal of Systems and Software, Vol.4, 1984, pp.63-74.

[4] A.M.Davis, Software Requirements:Objects, Functions and States, Prentice-Hall, 1993

[5] IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specification

[6] DOD-STD-2167A , DEFENSE SYSTEM SOFTWARE DEVELOPMENT, 1988

[7] E.Hull, K. Jackson and J. Dick,Requirements Engineering, Springer-Verlag, 2002

[8] Kotonya, G. and Sommerville,, I.,Requirements Engineering ? Process and Techniques, John Wiley & Sons, 2002.

[9 ] B.Ramesh and M. Jarke, Toward Reference Models for Requirements Traceability,IEEE TRANS. ON SOFTWARE ENGINEERING, VOL. 27,NO. 1, pp.58-93, 2001

[10] Palmer, J., Traceability, Software Engineering, M.Dorfman and R.H. Thayer,eds., 1996, pp.266-276, IEEE


















Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved