要件定義の確からしさをテストするのは要件定義です

on

少し前のプロジェクトメンバが三々五々と集まって続きのプロジェクトをすることになったと、続きのプロジェクトマネージャをすることになったエンジニアがワタシに話し始めたのは偶然フロアで遭遇したからで。実はその人もそのときのプロジェクトに一瞬だけ、そう数週間だけヘルプに入ってもらっていたんですね。


でもそのヘルプしてもらったときにいたチームメンバは1名だけしか参画しないのらしい。とは言え、ヘルプが終わってプロジェクトチームからアウトした後に大幅にメンバを入れ替えてしまったのだからその人は顔見知りが1名いたのは全く顔見知りがいないよりはましかも。プロジェクトが続く間の人間関係を位置から築くのは大変ですから。だって、プロジェクトってそのチームの中の関係性の濃さと言ったら。


続きのプロジェクトは始まっていて、テーマは機能拡張なので既存システムとの整合性や既存システムがすでに本番稼働しているのでシステム変更をすることは十分な準備と細心の注意も必要なことは勿論のこと、実現性が担保されていることが重要になります。


なんて当たり前ですよね。そうしたプロジェクトのプロジェクトマネージャがアナタだったらどういう進め方をして本番システムに影響を与えないで成功裏に機能拡張を実現するのでしょうか。


要件をテストするのはユーザ受入試験では遅い
いやいや、「V字モデルならただしいのでは。」と思うのも仕方がないし、正解なのです。じゃあ、「何か問題があるの。」と聞かれれば、

「要件のテストはUATでは遅いですよ。方式のテストは総合試験では遅いですよ。」


ということなんです。それも、

「プロジェクトの制約によっては。」

なんですが。単純な仮定の話をすれば、本番として稼働しているシステムに対してインパクトのある機能追加、構成変更をすると変更後のシステムが要件を満たしているのはもちろんのこと、その変更の過程においても状態の変化が設計されおり、変更の状態遷移が設計どおりに実現されなければらないのですよね。


それは機能追加に依る要件の追加が引き起こすさまざま影響を巻き込んだ上で実現できていなければならないということです。


ではどうすればいいか。多分、ほとんどのシステム開発のプロジェクト、機能追加が既存システムに与える影響の大小は差し置いて、恰も新規システムの機能開発のように工程を順を追って進めるのではないか、と思うんです。それが上手くいくのは構成偏向の度合いが小さいか、基幹コンポーネントに対する影響がほとんどないから問題が無いのだと思うんです。


そう、変更の大小に関わらず影響が大きいケースがあるんですよね。そのときどうするか、です。


一例として。
オーソドックスですが、追加する機能に対する既存システムへの影響度合いをしっかり把握するしか方法はないです。だから、機能追加部分の要件定義であっても、

「要件を定義していく中でテストをする」


のです。もちろん実機は存在しないですから、机上で、です。それも、テストケースを出していく、というテストをします。


テスト対象は、本番の既存システムと最終的に機能追加が完了したシステムとその間の構成変更の状態遷移のステップのシステムです。これに対してテストをします。


制約条件も上記のそれぞれについて明らかにしておく必要があります。

  • 本番稼働しているシステム
  • システム変更中の状態遷移のステップごと
  • 機能追加後のシステム


これらの3つに対して制約条件を洗いざらいにしておきます。システム変更中は利用者はシステムを利用できないとかシステム変更に掛けられる時間とか。


こうした制約を踏まえた上で、機能追加していく状態の遷移も含め機能が追加される新要件が最終的な機能束後のシステムが保有しているか、それを確認できるテストケースを出していく。


想像がつくと思いますが、要件定義の工程ですからテストの記述レベルは業務のシステムの要件のレベルです。試験項目表のタイトルか大項目、そのレベルです。


兎に角、そのレベルでケースを引っ張り出していくんです。面白いことにケースを出していくと想像もしていなかったパターンがあることに気付くんです。「このケースをやっちゃうとシステムはどうなっちゃうんだっけ。あれ、考えていなかった。」みたいな。


それって、気付けていなかった要件を実現するうえで必要なもう一つの要件なんじゃないんでしょうか。一応、伏線ポイので回収の意図で書いておきますが、システム変更途中の、状態遷移も同じようにケースを出してください。


これどんな状況だかわかりますか。そう、要件に曖昧なところがあるということを明らかにするというテストしているんですよね。そしてそのテストの結果を要件にフィードバックしなけばなりません。


でも、これをやると機能追加に掛かる総合試験とかユーザ受入試験の段階になってから試験検証で発覚するより1000倍増しです。なんで1000倍なのかですって。それは仕様を決めるときの変更にかかるコストを1とするとテストの時点で変更しなければならなくなったらコストが1000倍掛かると言われているからです。