要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

要件定義書と受け入れテストの関係

 

よくある企業の話として、要件定義書は上流工程のエンジニアが担当し、受け入れテスト作成や実施に関しては、経験の浅いエンジニアやベンダーが担当するという場合がある。

要件定義と受入テストの担当を分けるべきか?

筆者としては、この役割分担に反対の立場である。要件を定義した者(図では上級エンジニアと書いているが、ベンダのエンジニアではないことに注意)が、要件通りに動くかどうかを確認すべきである。要件を書いた者は、要件の中でもどこが特に重要なのかを感覚的にわかっている。受入テストの確認時点で、認識の齟齬が起こりにくいのだ。

下記図の例でいうと、上級エンジニアが要件定義したのならば、受入テストの作成、実施にその担当は積極的に関与すべきである。

 

f:id:req-definer:20220115133303j:plain

要件定義と受入テスト担当

担当は分けるべきではない。要件定義をしたなら受入テストの作成実施もすべき

原則的には、要件定義者が受入テスト仕様書も作成し、テストも行うべきである。そうはいっても、忙しくてテストをする暇がないという場合は、受入テストの作成だけでも担当すべきである。しっかりした要件定義が作成されているならば、受入テストは、要件をコピーするだけでよいのだから。

良い要件定義書は、要件に番号が振られ、それらのすべてが、〇〇できること、〇〇することといったような表現になっている。要件がすなわち受入テスト仕様書になるのだ。

要件定義書を作成したら、すぐに受入テストが作成できるはず

受入テスト実施直前に、受入テストを作成するようなことがありうるが、あまり好ましくない。要件定義書を書いたら、さっさと受入テスト仕様書を作ってしまえばいいのだ。受入テスト仕様書が書けない場合は、要件定義書に不備があるということである。受入テスト仕様書を作成するために、外部設計書や詳細設計書をみなければならないというのは、V字開発における責務分担を意識した開発ができていないということだ。

 

結論:要件定義書を作成したら、すぐに受入テストを作成しましょう