田舎エンジニアのBlog

コメントを追加

# re: 仕様書の書き方が分からない 2008/12/26 11:19 επιστημη

いや実際明確に定まったものはないように思えます。
おっしゃるとおり、そもそも「×××仕様書」の定義/内容が"あいまい"かつヒト/会社/部署/プロジェクトで"まちまち"なんじゃないかしら。

「次の工程に進むのに必要な資料/情報」くらいに考えてますですねー

# re: 仕様書の書き方が分からない 2008/12/26 12:14 nakaP

＞επιστημηさん
＞「次の工程に進むのに必要な資料/情報」
なるほど。
なにやらぼんやりと見えてきたような気がします。
と同時に、自分が最初から完璧を目指そうとして無理な壁を乗り越えようとしているのが分かりましたorz

少しずつ理解しながらやっていきます。

# re: 仕様書の書き方が分からない 2008/12/26 12:21 やじゅ

記述の仕方はいろいろありますけど

入力と出力をきっちり書けばいいです。
ここが大事ですが、設計の意図と設計の経緯を
記述しておくことですね。
(どうしてそのような設計になったのか)

仕様書の真髄
http://homepage2.nifty.com/cat-chy/cp/specification.html

# re: 仕様書の書き方が分からない 2008/12/26 12:32 nakaP

＞やじゅさん
＞設計の意図と設計の経緯
やはりそこですよね。
なぜそうなったのか？が書かれてないものほど、後で混乱しますよね。
そこだけは抜かりのないようにとは思ってます。

# re: 仕様書の書き方が分からない 2008/12/26 12:44 επιστημη

んむ。

「なにを食わすと(in)
　なにをして(process)
　なにを吐くか(out)」
そして「なぜそうしたか」

# できることなら「なぜこうしなかったか」があるとべたぁ。

# re: 仕様書の書き方が分からない 2008/12/26 12:55 やじゅ

あとは共通仕様(動作)参照　などと記述して
出来るだけ記述して省くといいですよ。

その為には、共通仕様(動作)をきっちり記述
しとかないといけませんけどね。

# re: 仕様書の書き方が分からない 2008/12/26 12:55 やじゅ

あとは共通仕様(動作)参照　などと記述して
出来るだけ記述を省くといいですよ。

その為には、共通仕様(動作)をきっちり記述
しとかないといけませんけどね。

# re: 仕様書の書き方が分からない 2008/12/26 13:07 nakaP

＞επιστημηさん
＞「なぜこうしなかったか」
これは少し難しそうですね(^^;
「なぜこうしたか」の理由は限定的ですけど、「なぜこうしなかったか」の理由は広範囲にわたりそうです。

＞やじゅさん
＞共通仕様(動作)
こちらはそのシステム全体の、ということですよね。
それだと多少はボリュームを抑えれそうですね。

# re: 仕様書の書き方が分からない 2008/12/26 13:53 kox

>「なぜこうしなかったか」
難しいけれども、重要だったりします。
選択しなかったのは理由（デメリット）があるわけです。
仕様変更などでそのデメリット部分が埋もれてしまうのを
防ぐことができます。

# re: 仕様書の書き方が分からない 2008/12/26 14:57 nakaP

＞koxさん
＞仕様変更などでそのデメリット部分が埋もれてしまうのを
＞防ぐことができます。
なるほど。そういうことであれば重要ですね。

よく考えれば、それほど広範囲でもないのか。
「方法Ａとした理由」
「方法Ｂとしなかった理由」
「方法Ｃとしなかった理由」
・
・
・
と書いていけば分かりやすくなるのかな。

# re: 仕様書の書き方が分からない 2008/12/26 16:11 まさる

一つの参考としてどうぞ。
Joel on Software：やさしい機能仕様
http://japanese.joelonsoftware.com/Articles/PainlessFunctionalSpecifi-2.html

# re: 仕様書の書き方が分からない 2008/12/26 17:21 nakaP

＞まさるさん
情報ありがとうございます。

パート１は検索で見つけてたんですけど、パート４まであるのは知りませんでした。
この方の文章は分かりやすく、非常に参考になってます。

# re: 仕様書の書き方が分からない 2008/12/26 21:01 biac

> まさるさん

あ、 これ良いですね。 > Part 2 からリンクされている 「WhatTimeIsIt.com 機能仕様書」

最初に、ペルソナ-シナリオ法で、 このサービスは 「どんなものか?」 ( どうやって使うものか? ) のイメージを具体的に示してから、 全体のラフなフローを示し、 それから各画面の仕様に入って行くんですが、 そこでもそれぞれの画面の概要・目的を示してから詳細に進んでいます。

そして、 nakaP さんは気が付かれましたでしょうか? 図表よりも、 文章が圧倒的に多いことを。
世間では、 なにやら UML の図が並んでいるのがソフトウェアの仕様書だ、 っていう風潮があるみたいですが、 今の UML 2.0 じゃ、図だけで意思疎通ができるなんてことはありえません。
# 人間を相手にするより、 はるかにロジカルで、 だからそういう意味でははるかに簡単だと言える、 コンピュータに伝達することさえ、 UML 2.0 ではまだまだ不完全ですからね。 ( Model Driven が、 まだ上手くいっていませんよね? )

…が。
どーも、 文章が多いのはウケがよろしくない (;;
概要とかシナリオの部分は、 そんなん分かってるからイラン、 ってお客さんに言われる。 (;;
# いや、 そちらが分かっていても… わたしらがちゃんと分かったかどうか、 検証してくださいよ～ ( フィールドテストになってから、「そんな使い方するわけねぇだろ!」 と怒る前に ) f(^^;

# re: 仕様書の書き方が分からない 2008/12/26 23:43 nakaP

＞biacさん
＞図表よりも、 文章が圧倒的に多い
ここに気付いたのが今回の一番の収穫かもしれません。

今日は仕様書のことをWebで調べながら、持っているUMLの書籍を見てました。
書籍には「UMLだけでユーザーとの意識統一ができる」というような書き方をしていたのですが、それは間違いだと気付きました。
確かにUMLは、プログラムのことが分からないユーザーにとってその振る舞いが視覚的に理解しやすいものの一つだと思います。
ただ、それだけですべてが理解できるものでもありませんね。
文章でできた仕様書が主で、UMLはその補助的な役割で使用すべきなんだと感じました。


＞どーも、 文章が多いのはウケがよろしくない (;;
内容が分かっている（つもりの）文章ほど面白みがないのかもしれませんね(^^;
いかに読ますか、というのも一つの技術なのかもしれませんｗ

# 仕様書（続き） 2009/01/08 18:27 田舎エンジニアのBlog

仕様書（続き）

# re: 仕様書の書き方が分からない 2009/02/04 14:20 nan

卒業研究に仕様書を書かなければならないのですが、

仕様書の書き方がわからなくて困っています。

また、とりやえず仕様書を参考にしたものの、これでいいか

どうか心配です。

# re: 仕様書の書き方が分からない 2009/02/04 15:36 nakaP

＞nanさん
はじめまして。

このエントリのコメントを読んで頂くと分かると思いますが、業界標準のテンプレートなどは存在していないようです。

作られてるプログラムにもよるかもしれませんが、まずは
・そのプログラムの機能
・どういった情報が必要か
・その情報をどのように加工するか
・その結果どういった情報を出力するか
といったところを洗い出してみてはいかがでしょうか。
何らかの手がかりにはなるかと思います。

# ２００９年２月ページビュー 2009/03/07 11:01 田舎エンジニアのBlog

２００９年２月ページビュー

タイトル
名前
URL
コメント
名前をブラウザに記憶する