前項のような問題を防ぐために、派生モデルの開発（保守開発）では、最初から「差分」で開発することも考えて下さい。顧客から変更点が「要求」として出てくる場合も、内部で企画される新製品の製品仕様という形で出てくる場合も、いずれも、開発にあたっては最初から「ベースモデル」が存在しています。顧客もそれを意識しているでしょうし、企画部門も、「ベース」を意識しています。そして開発部門も、どのモデルのソースを元に開発するかということを意識しています。
（インデックスに戻るときはウィンドウをクローズしてください）
差分に基づく修正作業の流れは下図のように、
１）まず、製品仕様や顧客の要求を元に、ベースの仕様書や設計書、あるいはソースから要求の差分を抽出します。
２）ここで一旦、顧客や企画担当と確認のためのレビューを行い、変更点の認識のズレや勘違い、モレを無くします。
３）リストされた要求によっては、差分をさらに具体的変化点に分解します。→「変更要求仕様書」
４）この段階で、設計内部で詳細なレビューを行い、影響範囲や副作用が網羅されているかチェックします。
５）変更要求仕様書の要求項目ごとに、その実現方法を検討し関数単位で修正の方法を記述していきます。
ただし、ここではソースリストを転記するようなことは避けて下さい。 →「変更設計書」
６）変更設計書を、その要求単位でレビューします。ここでは比較的少量でレビューを行います。事前に「変更要求仕様書」で、要求項目についてのレビューが行なわれていれば、ここでは、要求単位でのレビューは可能でしょうが、もし、不安があれば、要求のカテゴリ単位にまとめてレビューするのもよ良いでしょう。
７）変更設計書から、要求番号と関数名を抽出し、関数名をキーとして並び替えた一覧表を用意します。 →「関数別要求一覧表」
８）ここで、一つの関数が複数の要求のために修正されることが分かった場合は、関連する要求の変更設計書を再検討し、お互いに干渉しあわないことを確認します。
９）関数別要求一覧は、ソースの修正作業の進捗チェックにも使えます。また、バグが発生したときに、その関数に修正を加えることになった「要求番号」を知るときにも有用です。
これは、ベースモデルに潜在するバグを除けば、生成された派生モデルのソースから姿を現わしたバグは、基本的に今回の修正作業によって入り込んだものである、という考えに基づいています。したがって、発現したバグを消していくには、生成された派生モデルのソースを弄り回すのではなく、ソース修正の元になった「変更設計書」に立ち戻って考えるべきで、開発作業はそのための手段を残しながら進めるべきです。
（インデックスに戻るときはウィンドウをクローズしてください）
これは、単純に言えば、ベースモデルと今回要求されているモデルとの「差」を表したものです。今回の派生モデルの製品仕様や顧客からの「要求」を元に、ベースとなるモデルの仕様書や設計書、あるいはソースを参考にして、「仕様上の差」「性能上の差」「機能上の差」などの「差分」を求めて、それを個条書きにします。
このとき、要求毎にユニークな番号（＝要求番号）を付けることを忘れないで下さい。ここに「番号」が割り振られていないと、この後のいろいろな場面に応用できなくなります。要求番号は、要求の追加や変更に耐えられるように工夫する必要があります。基本的な書き方は新規開発時の「要求仕様書」と同じですので、そちらを参考にして下さい。
この「差分」は、この後の開発グループの作業の「源泉」となるものです。つまり、派生モデルの開発作業というのは、この「差分」を実現する行為でもあるのです。したがって、「差分」を正確に把握するということは、正しく派生モデルを生成する為の大前提となるものです。
仕様上の「差分」は、時には、粒度が大きく、もう一段ブレークダウンする必要があることがあります。例えば「ＣＰＵが○○から３２ビットの□□に変わる」という「差分」は、性質の大きく異なる「変更点」を内包しています。つまり「モニターのアセンブラ部分を書き直す」という変更や、「データ構造をワードバウンダリに調整する」「電源投入時のシステムの初期設定の方法を変更する」「メモリ管理テーブルのアドレス情報の構造が変わる」など、色々な変化を誘発します。
このような場合、あまり抽象度の高い「差分」表現のままでは、変更設計書が書きにくくなります。変更設計書は、個々の「差分＝要求」に対して、具体的な変更方法を記述するもので、その際に「差分」の抽象度が高いと、一つの「要求」についての具体的な変更方法が多岐にわたってしまい、焦点がぼやけて、副作用や隠れた影響範囲についての注意が発散してしまいます。
したがって、要求の抽象度が高いと思われるときは、変更要求仕様書の段階で要求をもう一段落して下さい。それでも、段数は精々２段程度にとどめるようにして下さい。
（インデックスに戻るときはウィンドウをクローズしてください）
変更設計書は、変更要求仕様書に記述されれた要求の一つひとつに対して、その要求の実現についての修正方針や、修正しようとする具体的な関数名と、それぞれの関数においてどのような変更を加えるかと言ったことを記述します。
その際、データ構造が変化する場合は、その旨の説明が必要になってきますし、関数の追加は勿論のこと、関数の呼び出し構造が変わるような場合は、有効な範囲で構造図も必要になるでしょう。
これによって、個々の要求ごとに、「どのような関数」を「どのように修正しよう」としているのかを知ることが出来ます。したがって、チームのメンバーなどで、この修正方法についてレビューすることが可能となります。逆に、最初からレビューし易いように意識して変更設計書を書くべきでしょう。
ここで注意しなければならないことは、具体的な関数名を挙げて、その変更点を説明する際に、ソースコードをそのまま引用して、旧状態と新しく変更される状態のリストを掲載しないことです。安直にこれをやれば、この取り組みは失敗する可能性が非常に高くなります。
そのような誘惑に駆られたときは、変更個所付近の「ＰＡＤフロー」で、変更の要点を記述する程度にとどめて下さい。追加される関数以外は、関数全体のフローチャートは必要ないでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
変更設計書は要求単位に構成されていて、実際にソースを修正する際には使いづらいことがあります。また、一つの関数が複数の要求によって修正されるような場合、関数単位に把握しないと副作用の問題を見落とす可能性もあります。もちろん、修正作業中に気付くかも知れませんが、その場合は、既にソースの修正作業に着手しているために、副作用等について急遽検討されたとしても、それぞれの要求に基づいた視点からしか為されていない可能性があります。
関数別要求一覧表は、変更設計書から、要求番号と関数名をセットにして抽出し、それを関数名をキーにしてソートしたものです。これによって、関数別に、その関数を変更しようとしている要求番号が分かります。
実際のソースの修正作業は、この一覧表に沿って進めても構いませんし、変更設計書に沿って進めても構いません。一つの関数が複数の要求から変更されることがないような場合は、どちらから修正作業に入っても問題はないでしょう。
この資料は、おっくうがらずに、是非作って欲しい資料です。あとで個々の関数から、これに関係する「要求」を知る際にとても役に立ちます。
（インデックスに戻るときはウィンドウをクローズしてください）
関数から要求を知りたくなる場面として、バグの発症があります。バグは基本的には、今回手を加えた行為に起因しています。もちろん、修正した関数で発症して行き止まるケースもあれば、関係のない関数で行き止まるケースもあります。その場合でも、そこまでたどり着いた関数のルートは分かっていることが多く、その途中で、今回修正した関数が存在していることがあります。そのような場合は、関数別要求一覧表を使って、その関数に関係する変更要求をたどり、その要求の実現方法に問題はないか再検討します。
また、機能テストや総合テストは要求されている機能や性能が達成できているか確認する行為ですから、一般に「要求」に沿って実施されることが多く、その場合には、変更要求仕様などから要求番号を知り、変更設計書の関連する要求番号のページをたどって、その実現方法を検証することになります。
何れにしろ、修正方法が不完全であったためにバグが発生したのであり、バグの追及行為の早い時期に、ここに立ち返ることによって、問題の解決を早めることが出来るはずです。
残念ながら、多くの開発現場では、バグの追及は、不完全に生成されたソース上で行うため、発症の原因を錯覚したり、修正方法を間違えたりして、さらに混乱の種を蒔いてしまうものです。
（インデックスに戻るときはウィンドウをクローズしてください）
バグは、今回の要求に対する修正の不完全さでもあるということは、その発症の原因を究明した結果は、必ず今回の要求の何れかに収まるはずです。つまり、変更設計書の何れかのページの、関数毎に具体的に修正方法を記述している個所に追加されることになります。この結果、その要求の変更方法が完全なものとなるのです。
多くの開発現場では、このように要求ごとに構成された「変更設計書」が存在しないため、バグとして発見された問題の解決方法が、「不具合処理票」に記載されているだけで取り残されてしまうのです。
そのため、バグは修正されても、個々の要求単位に、完全な修正個所を記したドキュメントは存在しないことになります。そしてこの問題は、次回以降の派生モデルの開発時に、障害となって現れてくるのです。