仕様書ってどう書くの？？

ハンバーグ位ならまだいい
自動車にしてくれ並みの事言って来るお客様を何とかしてくれ

68 ：仕様書無しさん：04/01/29 13:07

> カレールー入れれば完成のところまで来たのに、やっぱハンバーグにしてって言われても
> 困るだろ。
スープを捨ててミキサーで粉々にし、つなぎを混ぜて焼けば、
はい出来上がり！ってなわけにはいかねーかなー、いかねーだろーなー。

味噌汁にしてくれぐらいだったら許容できるかな。
シチューにしてくれも大丈夫か。

69 ：なぎさっち ◆Nagi/FmYMM ：04/01/29 13:41

>68
> 味噌汁にしてくれぐらいだったら許容できるかな。

　でも「味噌代は、そっち（作っている側）持ちでお願い」とか言われちゃうんだよな。
で、急遽和食料理人を追加投入でデスマーチ突入、みたいな。

70 ：仕様書無しさん：04/01/29 17:26

>>68
カレールー入れてからシチューにしてくれとか・・・

シチューとカレー、ルー入れるまではほとんど同じだよ。

71 ：仕様書無しさん：04/01/29 18:20

>70
貧しいな、今度晩飯おごってやるよ。

72 ：仕様書無しさん：04/01/31 15:22

「最良のシステム設計所とは？」

http://jibun.atmarkit.co.jp/lskill01/rensai/devgenba04/devgenba01.html

73 ：仕様書無しさん：04/01/31 15:38

難しく考える事ないよ。
要はどういう事をしたいか。どういうプログラムを書けばいいかというのが解ればいい。
形なんかないよ。要はこれを見て物が作れたらいいだけ。

どんなにテンプレが綺麗でも見て「はぁ？」なもんは仕様書として失格だが、
上にもあったように内容よりも重量が大事、というのも成果物としてあげるときに重要になってくるのは
お約束（ｗ
まぁそんなんは見た目上の問題として。

まぁ言語ややることに依存するが、
大体の機能概要。
それから使用DB使用関数
画面があれば画面遷移。
簡単な処理フロー
データ編集がある場合はデータ編集仕様書
処理概要は最低限書くタイプと細かく書くタイプとまちまちだが、
個人的な好みで言えば更新の仕方なんかも書く方が好き。
要は一発でこれみたら他に書類を探さなくても作れるようにしたいということ。
仕様書の最後には使用DBのレイアウトなんかも添付してると良い。

エラーチェック、エラーメッセージ、戻り値など共通化できるところはがんがん共通仕様書にのっけていき、
なるべく全仕様書に同じ記述がある、ということは避ける。
米共通仕様書参照　をばらまくと修正が楽。

74 ：仕様書無しさん：04/02/01 04:27

仕様書のキモは
決めるべき事が決まっているのか、
すなわち定義がされているかどうか、という点だろう。

それは特定の機能に関して、それの概要と
行われなければならない処理、
行ってはならない処理を明記したモノと考えられる。

定義すべき部分を曖昧に書いて体裁を整えたような、
顧客へのご機嫌伺い文書は仕様書と呼べないし、
画面だけまとめて、動作の方向やinterfaceが未定義な文書も
仕様書とは呼べまい。

75 ：仕様書無しさん：04/02/01 05:34

いったいお前らは何の「仕様書」に関して話してるのだ？

76 ：仕様書無しさん：04/02/01 05:58

http://www.google.co.jp/search?q=%E4%BB%95%E6%A7%98%E6%9B%B8&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

世に溢れる仕様書

77 ：仕様書無しさん：04/02/01 12:20

少なくとも
・要求仕様書（要件定義書）
・外部仕様書（概要設計書）
・内部仕様書（詳細設計書、モジュール設計書）
くらいに分けないと、話が混乱するだけじゃ？

78 ：仕様書無しさん：04/02/01 19:20

詳細設計以降のドキュメントしか見たこと無いﾔｼが多いのかな。

79 ：仕様書無しさん：04/02/01 20:03

・提案依頼
・提案
・要件定義
・基本設計
・詳細設計
・単体テスト
・結合テスト
・システムテスト
・検収
・ユーザー教育
・システム移行
・運用
・障害対応

それぞれのフェーズで必要となる仕様書には何があるか。
そのドキュメントは
　・いつ
　・誰が
　・何のために
　・誰のために
作るのか。

Excelでマトリクスでも作って埋めてみやがれ。

80 ：仕様書無しさん：04/02/01 20:16

とりあえずこれでも読んどけ。
『実践！システムドキュメント徹底活用―設計・構築からテスト・運用まで』
http://www.amazon.co.jp/exec/obidos/ASIN/4798105082/qid=1075634149/sr=1-1/ref=sr_1_10_1/249-1822478-5401946

81 ：仕様書無しさん：04/02/01 20:36

>>1
おまいがクライアントだろ？
クライアントが仕様書を書くなんて聞いたことない。

まずクライアントは

１．こんな処理がしたい
２・こんな機能がほしい
３．こんな画面にしてほしい（例　作業しやすい画面）

などをＳＥに聞く

それに対してＳＥが出来るか否かを判断して設計（仕様書を書く）する。
まあ、おまいは用件定義をしっかりしておけばいい。

82 ：仕様書無しさん：04/02/01 20:43

要件を定義するのはSEの側なんだが。

83 ：仕様書無しさん：04/02/01 20:55

>>81-82
なるほど、コミュニケーションが成立しないわけだ。

84 ：仕様書無しさん：04/02/01 20:58

クライアントが提示する必要があるのは要求仕様だな。
なかでももめる火種になるのは外部システム連携仕様だな。

作るときには決まっていないことも多く、どんぶりにならざるをえないこともある。

85 ：仕様書無しさん：04/02/01 21:00

>>46
くだらないことかいてんじゃねえよｳﾞｫｹ

86 ：仕様書無しさん：04/02/01 21:01

>>43
UMLでユースケース図を使えば素人でもわかる仕様書のできあがり

87 ：仕様書無しさん：04/02/01 21:02

つーか、仕様書の作成にはUMLを使うことが絶対条件で
常識となる時代がそろそろやってきて欲しいな。

仕様書作成の共通規格としてUML使うのは当たり前とな。
UMLでかいてくれりゃ
それを即座にクラス図に変換してくれるのでこちらもプログラミングの手間が
かかりにくくそのほうがありがたいわ