[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?
- 技術評論社 (2010年5月1日発売)
- Amazon.co.jp ・本 (384ページ)
- / ISBN・EAN: 9784774142579
感想・レビュー・書評
-
システム構築が上手くいかなかったことが、「要求仕様書」が掛けていなかったことに起因していることが良く分かった。
読んでいるうちに、今回のプロジェクトのまずさを指摘されているようで苦虫をかみつぶした思い。
ただ、解決のための方法論も記載されている。慣れるまでは、負担になってしまいそうだが、愚直に取り組みたいと思わせる内容だった。詳細をみるコメント0件をすべて表示 -
正直自分のレベルが足りず消化不良です。
1部、2部、3部の3部構成になっています。
1部:動機付け
ソフトウェア開発におけるバグの原因の大半は、仕様にまつわるトラブルであると言われます。要求仕様が不完全なまま作業が進んでしまっているために、問題が発生してしまいます。
そこで、要求を適切に仕様化した文書である「要求仕様書」を作成しようというのがこの本の趣旨です。
2部:要求仕様の書き方(本編)
1部の動機付けが不要という方はここから読むのがよいと思います。要求仕様の書き方について詳しい説明が書かれています。
仕様書というのは作って欲しいことについて"Specify"できたことが書かれている文書のことです。"Specify"するというのは、開発メンバー間で内容を「特定」できるようにすることです。仕様が細かく書かれることは本質ではなく、特定できるかどうかが重要です。
要求仕様では範囲と理由を明らかにする必要があります。
要求の理由というのはHAYST法でいえば目的機能のようなもので、ここをとらえられないと的外れな実装をしてしまったりということが起きます。
また、品質要求をとらえる際に「作り方に関する要求」や「使い勝手に関する要求」は漏れてしまいがちで、注意が必要です。
要求は階層化して表現することもできます。このとき、要求の「動詞」に着目して分解するのがポイントです。ただし、階層は2階層までに留めておくのがよいです。
派生開発の場合、変更を要求でとらえるということをします。(こちらはXDDP本が詳しいです)
3部:応用編
数値の計測や応用的な話が主だったと思います。
2部を理解した人向けだと思います。
何がもっともピンとこないかというと、そもそも仕様書を自分が書いたことがないというのが大きいです。
仕事で仕様書を書く機会がある人は読んでみると良いかもしれません。
ただ、仕様書を書く以外でも文書で人とやりとりする際には役立つ内容なので、考え方はマスターしたいです。 -
読みにくい。経験がないため、理解できない感が残る本だった。
-
131019 中央図書館
システム開発の立場から、工程の効率とシステム長命化のために要求使用の煮詰めに注力すべきことを力説。まさに経験を経たコンサルならではのツボが満載(なのだろう)。
システムという狭い分野の話だけでなく、ビジネスコミュニケーション全般でも応用が利くノウハウが多い。
少なくとも、「要求」に対し「理由」を上手く聞きだすスキルは、どの分野でも必須だ。さっそく実践! -
何かこう独りよがり感はある.例えば仕様書作成のツールとして「WordではなくてExcel」を勧めるのだが,内容を読むと表形式で書けるなら何でもいい感じで,つまりMS以外の選択肢を知らないで書いてるんじゃないかという.ただ,内容としてはまあ正しそう.Agileディスってるけど,安易に飛びつく層に対しての説得力はあると思う.
-
<blockquote class="twitter-tweet"><p><a href="https://twitter.com/PoohSunny">@PoohSunny</a> なるほど、補足ですが、「ユースケース」というモデルに拘らなければ「USDM」という要求仕様を明確にする手法が存在します。興味があれば「要求を仕様化する技術 表現する技術」を読んでみてください。 [うさみみ*´×`*エンジニア]</p>— きょん@うさみみモード (@kyon_mm) <a href="https://twitter.com/kyon_mm/statuses/346937807836692480">June 18, 2013</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> -
ちょっと読みにくい
ちょっと独自なスキーマなので理解するのが大変
デファクトスタンダードとの関連がもっと明確ならいいのだが -
どのレベルまでが要件定義で、どこからが設計かはよく問題になるけど、“要求の仕様化”という見方でそのラインを考えたことはなかったなぁと実感。本の内容で中心になるUSDMは普段使ってるけど、やっぱり急いで次工程に進んでいるのが現状なので、そのあり方について考えさせられる内容でした。。。
-
要件定義(要求定義)をやったことがある人が更に質を高めるために読む本か。書いてあることは当たり前のことではあるが、忘れていたものや新たな気づきもあり、ある程度要件定義書を作ったことがある者であれば取捨選択の上、いくつか実践的に使えるネタもあるかと思われる。(紹介・勤務先)