|
|
概 要 要求工学はソフトウェア開発における要求を仕様化するプロセスを工学的に定式化する技術として注目を集めている。しかし、要求工学の教科書における要求仕様化プロセスは多様であり、著者ごとに異なるといってもいいくらいだ[1]-[7]。また要求と仕様とは何が違うのだろうか？本稿では、要求工学プロセスの本質的な要素とその関係を考察する。 要求と仕様 ソフトウェアの要求と仕様の違いはなんだろうか？ソフトウェアを開発する目的は、それを利用することでなにかしらの作業を自動化したり支援することにある。とすると、ソフトウェアを利用する主体としてのヒトやシステムが、ソフトウェアの外部に存在することがわかる。このようなヒトやシステムを含めた利用環境とソフトウェアの関係を考えると、ソフトウェアを利用することで実現したいコトが要求であり、そのコトを可能にするために具体的にソフトウェアを利用するときのインタフェースがソフトウェアの仕様になる。言い換えると、要求は利用環境から見たソフトウェアが実現すべき目標である。また仕様はソフトウェアが利用環境に対して必要とされる機能を提供するための境界条件である。 要求や要求仕様とソフトウェアの関係を図１に示した。この図でわかるように、要求は利用環境つまり問題領域の言葉で記述されるし、仕様は利用環境だけでなく、それを実現するための設計の基準となるという点で、アーキテクチャなどのソリューションを意識した言葉でも記述される。パルナス[8]はこのような要求と仕様との関係を４変数モデルで説明している（図２）。利用環境では入力デバイスで観測される観測変数と出力デバイスを制御する制御変数を用いてソフトウェアへの要求を定義する。これに対してソフトウェアでは入力デバイスからの入力データに基づいて出力デバイスに対する出力データを生成する仕様を定義する。このとき、観測変数と制御変数の関係が要求であり、入力データと出力データの関係が仕様となる。非常に明快に要求と仕様とが説明できることがわかる。 それでは、要求仕様という言葉は何を意味するのだろうか？与えられた要求を満足する仕様と考えればわかりやすい。仕様は要求を満たす場合と満たさない場合があることもわかるだろう。こう考えると、仕様は確定できたとしても、顧客の要求を満足する仕様でなければ、確定した仕様に基づいて開発されたソフトウェアが要求を満足しないことになり、完成と同時に変更を余儀なくされるに違いないはずだ。この問題の原因は、仕様が要求に対応しておらず、一貫性が保証できていないことにある。 このように顧客の要求とソフトウェアの仕様とは異なっていることを認識した上で相互の一貫性や追跡性を保証することが重要になる。  表1 要求、要求仕様とソフトウェアの関係  図2 変数モデルにおける要求と仕様[Parnas, 1995] 要求の優先順位付け 先に述べたように、要求と仕様とが異なることを理解しておくと、次のような問題にどのように対処すればいいかも見えてくるはずだ。 問題１．顧客の要求が曖昧で最初からすべてを確定できない 問題２．要求を早期に確定してしまうと、顧客の要望の変化に答えられない これらの問題に対する作戦としては、顧客との間でまず要求とその優先順位を合意することを目標にすることだろう。また要求の曖昧さの問題を要求自体の曖昧さと、明確化された要求に対して実現すべき機能に関する操作法や画面仕様などの曖昧さの２段階に区別することも重要だ。こうすることで、要求の曖昧さを階層的に制御できるようになる。 一方、顧客側も要求の確定プロセスに参加することができるだけでなく、明確に合意文書として要求項目が記録されるので、後から突然大きな変更要求が顧客から提案されて要求仕様全体を大幅に見直すような事態に陥ることも予防できるだろう。 つまり要求について合意した上でそれぞれの要求に対する要求仕様を優先順位の高いものから段階的に具体化していくことで、不確定要求の範囲を限定できるようになるのである。また優先順位の低い要求については可能な限り後で具体化することにより、要求の変化に答えることができるようになる。たとえば、もし優先順位の低い要求を先に確定してしまっていると、より優先順位の高い要求の具体化に対して制約をつけてしまうかもしれない。また優先順位の高い要求を定義したことで、すでに作成した優先順位の低い要求を大幅に見直すことになるかもしれない。もちろん優先順位に従った変更要求の場合でも、変更できる要求の内容には条件があり、操作性などの軽微な変更に限定される可能性はあるだろう。しかし重要なことは要求変更を制御することであり、そのプロセスを顧客とも合意しておくことであろう。 要求が確定できない場合TBD（To Be Defined）項目を用いることがある。この場合、仮に「こういう機能である」という例を示しておき、他の要求項目が仕様化された後でTBD要求を記述する。しかしTBD要求の優先順位は低く設定しておかないと、要求仕様全体に大きな影響を及ぼす恐れがある。したがってTBD項目はもし具体化できない場合には思い切って開発対象から除外することも視野に入れておくべきであろう。たとえば要求確認プロセスではTBD要求が具体化できていなければ、この要求自体を削除するというような評価基準を用意するといい。 要求仕様とプロトタイピング 顧客が理解できない要求仕様を書くよりも、プロトタイピングで顧客と折衝するほうがいいといわれることがある。 確かにプロトタイプが簡単にできれば要求も簡単に獲得できる可能性がある。しかし上述したような要求の優先順位をプロトタイプの中に組み込むことは容易ではない。またもし要求を明示的に記述しておかなければ、プロトタイプがすべての要求に対応する仕様を実現していることをどうやって確認するかという問題がある。またプロトタイプで必要な要求が確認できなかった場合にはどうするのかという問題も残る。どこにも要求に関する記録は残っていないのだ。したがってプロトタイピングであっても要求を文書化しておく必要があることに注意すべきである。またプロトタイプの場合、要求仕様が何なのかを具体的に確認するためにはいつもプロトタイプを動作させてみないとわからないため、かえって仕様確認に手間がかかる可能性もある。 ちょっと考えればわかることだが、プロトタイプの開発にもコストと時間が必要だ。製造業などでは、製造期間を短縮するために最近では「試作レス」の導入も検討され始めていることを考えると、今後はプロトタイピングレスのソフトウェア開発の方がかえって先進的なアプローチになるかもしれない。いずれにしても要求のプロトタイピングの目的を明確にして有効性を明確にしておくことが肝要だ。そうでないと何のためのプロトタイピングなのかがわからなくなる。したがって、この問題への対処としては、要求についてまず合意すること、次いでその中で真にプロトタイピングにより確定すべき要求があるときに限定してプロトタイピングを実施するというのが実践的ではないだろうか？もしプロトタイピングの目的が曖昧ならプロトタイプを作成しても要求は曖昧なままであり、徒労に終わるに違いない。逆に要求が明確ならプロトタイプを作成するよりも仕様の具体化を急ぐべきであろう。 要求工学プロセスの基本モデル 図１と図２でみたように、要求は問題領域に属し、仕様はソリューション領域に属する。要求工学プロセスには、図３に示すとおり、要求抽出、要求分析、要求の仕様化、要求確認がある。要求抽出と要求分析までが問題領域に関するプロセスとなる。これに対して要求の仕様化と要求確認がソリューション領域のプロセスである。図３では、左上に要求抽出を示し右下の要求確認まで段階的にこの４つのプロセスを示した。 この理由は４象限に４つのプロセスを配置する通常のスパイラルモデルの図は直感的ではあるが、隣接するプロセス間の追跡性が明確に表現できないためである。 図３でも継続的に４つのプロセスが反復されることを注意しておく。つまり要求確認で妥当性が確認できない場合には、要求確認から要求抽出への矢印で示したように要求が修正され抽出プロセスからもう一度繰り返される要求もあることになる。 要求抽出と要求分析の違いは、次のようである。まず要求抽出では問題領域の専門家の知識や顧客ニーズ、現状の問題、経営課題などに基づいて要求を獲得する。このときシナリオやユースケースなども利用する。要求分析では要求抽出で獲得した要求間の構造や一貫性を明らかにするとともに要求に優先順位を付与して顧客との合意を形成する。この過程で顧客には概要レベルの要求を提示する。より詳細な要求仕様を提示するのは次の段階である。 問題領域からソリューション領域への移行のポイントは要求項目と、その優先順位が明確になっていることである。要求仕様化では優先順位のついた要求を具体的に文書として記述する。このとき要求と要求仕様との追跡性を管理する。もし、すべての要求が仕様化されていなければ要求仕様には抜けがあり、不完全である。もし要求に対応しない要求仕様があればそれは冗長である可能性がある。 要求確認では要求仕様を顧客に提示して妥当性を確認する。妥当性が確認された要求仕様は設計工程に引き継がれる。これに対して妥当でない要求仕様については変更するために要求工学プロセスを反復する必要がある。妥当でない要求の可能性としては、どのプロセスで誤りが発生したかに応じて、仕様化ミス、要求分析ミス、要求ミスが考えられる。 要求ミスと要求分析ミスについては、要求の合意形成を終えているので十分な合意が形成されていれば、発生する可能性は少ないはずだ。ただし合意が十分に形成できていなければ発生する可能性がないとは言い切れない。このとき合意形成の内容が問題にはなるが、その場合であっても合意できている部分とそうでない部分が明確になっていれば想定内の変更にとどめることができる。仕様化ミスについては仕様を再度作成しなおすことになるが、要求レベルでは合意できているので影響範囲は限定的になるはずだ。ただし、要求に変更が及ばないように注意する必要がある。仕様修正によって要求に変更が生じた場合には、仕様から関連する要求を追跡して変更範囲を特定するとともに関連する仕様を修正することになる。またこれらの一連の修正に関する妥当性を確認する必要がある。  図3 要求工学の基本的なプロセスモデル 要求工学プロセスの比較 表１に主要な要求工学に関する書籍で述べられている要求工学プロセスの比較を示そう。基本的にはどの手法も基本モデルに対応するプロセスを持つことがわかる。一方で使用する用語がかなり揺れていることもわかる。この理由は、和訳が統一されていないことと要求工学が分野としてまだ未成熟で用語自体が規格化されていないことだ。したがってこれらの著作を参考にする場合には、プロセスの用語を見て表面的に判断するのではなく、意味をよく理解することが重要だ。 ところでクスマノの本[7]は、要求工学の本ではないが、マイクロソフトのソフトウェア開発手法を同期安定化プロセスとして第4章で紹介しているので取り上げた。良書である。マイクロソフトでは開発目標書と概略機能仕様書だけを作成し詳細な機能仕様については開発者の創造性に任せており仕様書としては作成しない。これにより詳細な仕様はいつでも変更可能にしておくことができるだけでなく、主要な要求項目には優先順位がつけられており、与えられた期間とコストの中で適切な要求を実現できるのである。この手法が成功するためのポイントは要求の優先順位付けと期間とコストの限定、デイリービルドにおける厳格な仕様の同期管理の３点であろう。  表1 要求工学プロセスの比較 まとめ 本稿では、要求工学における要求と仕様の考え方と基本的なプロセスモデルを紹介した。要求工学プロセスについては様々な手法が提案されているので、ソフトウェア開発の現場で適用する場合には状況に応じた取捨選択が必要になるだろう。その場合要求工学プロセスの比較が必要になるが、今回紹介したように問題領域のプロセスとソリューション領域のプロセスには何があるかを手がかりにして適切なものを組み合わせることを推奨する。次回は、要求抽出の手法について紹介する予定である。 参考文献 [1] Kotonya, G. and Sommerville,, I.,Requirements Engineering ? Process and Techniques, John Wiley & Sons,2002. [2]Loucopoulos, P. and Karakostas, V.,富野監訳、要求定義工学入門、共立出版、1997. [3]レフィンドル、ウィドリグ、ソフトウェア要求管理、ピアソン・エデュケーション、2002 [4]ウィーガーズ、ソフトウェア要求−顧客が望むシステムとは、日経BPソフトプレス、2003 [5]ロバートソン、ロバートソン、要件プロセス完全修得法、三元社、2002 [6] フル、ジャクソン、ディック、Requirements Engineering, Springer,2002 [7]クスマノ、ソフトウェア企業の競争戦略、ダイヤモンド社、2004 [8]Parnas, D.L. and Madey, J. 1995.Functional documentation for computer systems. Science of Computer Programming, 25(1):41?61.
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
