こうして、派生モデルの開発が終わったとき、手元に残されているドキュメントは、差分開発に使用した、「変更要求仕様書」「変更設計書」「関数別要求一覧表」、そして恐らくは「不具合処理票」ということになります。もちろん、状況によっては、追加される個々の要求についての「補足資料」のようなものも存在しているかも知れませんが、派生モデルそのものを表したドキュメントは作られていません。
そこで、テストを完了したあとで、手元にあるドキュメントを元に、ベースモデルのドキュメントの修正にとりかかります。一見、“後付けのドキュメント”のように見えますが、単純にソースから生成している訳ではありませんので、一般的な“後付けのドキュメント”の弊害は生じないでしょう。
派生モデルの開発の場合、その求められた開発期間でソースの開発を終了したとき、意外とドキュメントを整備する時間が確保出来るものです。
もし、評価部門が別にある場合は、自分たちの手によるテストが完了し、評価部門に渡ってから、派生モデルのドキュメントの整備に取り掛かって下さい。もちろん、まだ、バグは発生するかも知れませんが、そんなに多くはないはずです。それに、ドキュメントを整備している時に、要求の勘違いや修正ミスなどを発見することがあります。
システムを見る視点が変わると、今まで見えなかったものが見えてくることがあります。まだ、評価中なのですから、一つでも多くの「不具合」を見付けることは、製品の品質を高める事であり、それはエンジニアとしての「誠意」でもあります。