要件定義−基本設計−詳細設計(または直接実装)というような、段階別のシステム設計を考える。数10年前にこんな要件があったとする。・プリペイドカードの導入効果を知りたいのでプリペイドカードでの売上合計を簡単に知りたいねというわけで、プリペイドカードを利用した売上を調べられるようにしたとしよう。それから幾星霜、システムの更改時期がやって来る。基本は単純移行+最新鋭のいろいろと決まる。その時に、現行のプログラムを眺めながら、当時の基本設計も参照しながら、移行プランを練ったり、移行プログラムの仕様を切ったり実装したりすることになる。この「プリペイドカード売上レポート」とか「プリペイド売上計上サブシステム」ってなんだ?「はて?」そこで相談することになる。「これ、使ってるのか?」こういうとき、お客さんと相談するのはあまりうまくない。使っているかどうかに関係なく、あるものは移行しろということになるからだ。使っていないことが明らかなら、あるいは単に惰性で出力だけしているようなら、こちらから提案すべきだろう。「〜という理由であったわけです。今は〜ですから、この機能は落としましょう」こういった、どのような理由によってそのモジュールが必要で、どのようなユースケースを満たしているのか、といった情報は、要件定義にはあるはずなのだが、基本設計以降はわりとすっぱり消えてなくなっている。10数年前のシステムであれば、それはわからなくはない。ユースケースはモジュールの設計には直接関係してこないからだ。いうよりも、ユースケースという捉え方をしていなかったのだな。経験を積んだおかげで、ユースケースは最初と最後に役に立つことがわかった。いずれにしても、基本設計であろうが実装設計であろうが、とにかくここ数年のプログラミング言語の進歩というものは、「何をしているか」「いかに処理しているか」というような情報は、ほぼソースファイルで表現しきれているのだ。(あるいは実装そのもの」というような段階的な文書を後世のために残すのならば、経験的には、要件定義は残らず、設計と設計成果物しか残らないため、そこにこそ、ユースケース(とその前の段階としての、システムの目的)を記述すべきなのだ。これは、ソースファイルのコメントにちょっと似ている。何を書くかではなくなぜを書く、というやつだ。言え、さすがにソースファイルにユースケースおよびそれの前段階を書くのは、やり過ぎのようには思う。そこで、基本設計というものに、それを入れるべきだろう。基本設計書というものに含まれていたものは、複数から抽出して1つのアーキテクチャ設計書に移動したほうが良い。いうのは、そこに非機能要件を入れることで、後世の文書解析の分離がうまくいくからだ。いうのは、非機能要件は、システムの進歩にしたがって、個々のプログラム実装からは排除できるようにこれまでなってきたし、今後もなると考えられるからだ。したがって、開発するモジュールを規定していく基本設計とは別にしておきたい。良いネガティブな書評ネガティブな評価をする場合は、このくらいかっちりとどういう観点から読むとどのような理由からどういう点を評価できないのかを書いてほしいね。12:31)こんな紹介をされるとは思いませんでした(^^;<br>コーディングの前段階としてアーキテクチャがあってその設計は別の人が行う、というのは古いと思うんですよね、やはり。<br>もうちょっといろいろ読んでみますが。19:20)いやぁ、おもしろいです。<br>「移植性が大切だ、だからレイヤーパターンを使う事にした」<br>これなんか、そのまんまパターンランゲージになっているけど、もちろん、生でこう書いてあるわけじゃないですよね。確かになぜそうなったかの検討が見えないという指摘は実にもっともだし。<br>というわけで、読みたくなったのでした(いや、現時点では時間的に無謀なので読まないけど)。