目次
わかりやすい仕様書を書くには
- 箇条書きやテーブルをつかう。
- プログラムのように段下げ（インデント）をする。
- 仕様書の最初に、言葉の定義を記述し、意味を明確にしておく。（特に略語）
仕様書における解決できない問題
- バージョン管理の方法。（ソフトはバージョンアップしたが、仕様書をバージョンアップし忘れる等）
- 章の分け方に迷う。
Javadoc のような、ソフトを書くと仕様書が出来上がる仕組みって、いいですよね。
コメントいろいろ
- そういえば、テストファーストプログラミングというけれど、
プログラミングでドキュメントファースト、という考え方もありますね。
ドキュメントとプログラムをあわせて書くというのは昔から好きです。
文芸的プログラミング(LiterateProgramming?)とかね。--結城
- わかりやすい仕様書を書くには。
- 項目を押さえる：仕様書というと、おさえなきゃいけない項目はどれだろう？と書く前に考えます。
プログラミングの場合、I/O（入出力）インタフェースをきっちり押さえるように
こころがけます。次に処理の部分をおさえます。このとき、I/Oや処理が
ごちゃごちゃにならないように気をつけます。
- データのフローが書いてあると、理解が楽になりますね。 --Coffee
- 目次を整理する：また、仕様書に限らず、ドキュメントを作成する場合には、
目次の項目立てや階層に注意を払います。
目次すらどういう項目があるのか思いつかないときは、
職場にある仕様書作成マニュアルや、
プログラムの解説書や、
第二種情報処理のテキストを参考にします。
あと最低限、作成日付と更新日付、作成者名はおとさないようにしています。
- コミュニケーションも大事：それから一人で作業しているわけではないので、
コミュニケーションを取り、チームメンバが同じ意識で仕様書を書くようにする、
というのも大切な作業（ミーティング）です。
- 仕様書について語りはじめると熱くなるので、ここら辺でとめておきます（苦笑）。--shino
- ところで、プログラミングの仕様書と設計書の区別ってどこら辺なのでしょうか。みなさんはどう意識されていますか？
- 僕は、「何を作るか」を書いてあるのが「仕様書」、「どう作るか」を書いてあるのが「設計書」だと理解しています。(money)
- 現実には特に区別なく使われているように思えますね。
- 時間が無いと、大抵わかりやすさが犠牲にされてしまうので、作業の合理化も大切かと。
- プログラムの目的（例：見積もり入力画面）単位で縦割り的に仕様を書くのでなく、プログラムの機能（例：日付入力）単位で横断的に仕様を書く。
こうすることで、プログラミング工程でのモジュール化をプログラマに明示的に指示できるし、
仕様書の内容の重複が無くなり、その結果修正忘れも減り、作業効率が良くなる。
まあ、某書籍の受け売りなんだけどね。 -- Coffee
