要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?

著者 : 清水吉男

• 技術評論社 (2005年10月7日発売)

作品紹介・あらすじ

数々のソフトウェア開発の現場で指導にあたっているプロセスコンサルタントが、その培ってきたノウハウを惜しげなく展開する。

感想・レビュー・書評

[横さんの感想 · 2021年4月3日]

個々のパーツとしての記載はあるものの、要求仕様書、要件定義書を実際にならべたものでないだけに、ある程度の力量のある方が対象。
要否を論ずるのであれば、上流のシステム企画、下流の概要設計にも言及すべきでは。
この本を渡して、要件定義やってこいとはいえない。
システム開発の上流に問題があるのは、要件定義を一からつくることができる啓蒙書があまりみあたらないことにもよるのでは。

[Kamakuraさんの感想 · 2019年5月15日]

購入：2005年12月31日　廃棄：2019年5月17日

[haruharu5050さんの感想 · 2016年5月14日]

ソフトウェア開発で要求分析する上で役立っています。

[fmizunoさんの感想 · 2014年10月5日]

仕様書はあっても、求められていることがわからない。
そんな開発に疲れました。
受け手ではなく、発注側にぜひ読んでもらいたい。

[suさんの感想 · 2014年5月26日]

システム開発における要求定義、要求の仕様化について細かくまとまられている。仕様化はベンダー向きの細かい内容もあるが、そもそも要求とは何かから学べるので発注側も読むべき。経験者は気になることをトピックで調べられる辞書のような使い方がいいのではないかと思う。

[moke039さんの感想 · 2012年11月28日]

仕様はソースコードに書いてある。
ただそこにはその仕様が生まれた要求や背景・理由が書かれていない。また全体像を俯瞰するあらすじやガイドがなければ、膨大なソースコードを時間をかけて1つ1つ読み解いて 仕様を理解し、その背景を推測していく必要がある。

このため、仕様が競合していること、要求が競合していることに気づかずに大量のバグが生み出される。影響範囲を理解しきれないまま一か八かの修正を入れ、二次障害が発生し注意不足/工数不足のせいにする。五月雨式に発生する要求変更、仕様変更を適切にまとめ、時期を見極めて現場に落とせないマネジメントの欠如、体系的にとらえずその場しのぎの修正でやっつけるエンジニアが混乱に拍車をかける。

そんな状況を打開するための手段の一つが、要求仕様書の本質を理解し、その記述テクニックを磨くことだと確信できる。もちろん本書だけで完璧な要求仕様書の記述ができるようになる訳ではなく、演繹法、帰納法、MECE や 7±2 などのドキュメント作成テクニックを磨きながら記述内容の粒度などをそのプロジェクトの特性や要員にあわせて見直していく必要がある。こうした積み重ねにより要求から仕様項目数、ソースコードステップ数を見積り、計画の精度を向上させたり、要求-理由-仕様を分析するようにリスク-要員-軽減策を検討することで、リスク管理などにも応用できるようになるだろう。また改善の効果をより適切に評価するため、改善により削減できた時間を推測し、実際の投入時間と比較することも忘れてはならない。

仕様書のボリュームが大きく書ききれないなら、それをどう覚えきり、制御しきるのか。すべてを同じ粒度で書き出す必要はない。制御するため、コードを読み返さなくても掌握するため、一つ一つ体系的に書き出していこう。

筆者自身の開発経験、コンサルティング経験から思わずうなる事例が多数紹介されていて参考になるが、テーマが拡散して繰り返し冗長に語られている部分や、ありふれた事例で回りくどい説明となっている点、結論が読み取りづらい箇所も少なからずみられるのが少々残念。

[tetsuomikamiさんの感想 · 2012年1月18日]

読み終わったというか目を通しただけな気もする。具体的な例とかがもっとほしかった。

[ボンツトさんの感想 · 2011年12月7日]

５年ほど前に読み終えた本なので詳しい内容は良く覚えていませんが・・・(m´・ω・｀)m

要求仕様書を書くにあたって、「あいまいさを排除する」ことや「要求と理由と仕様を区別する」ことを本書を通じて意識するようになりました。
要求仕様書の表現という意味では、マトリクス表を併用して境界値を明確にすることでテストにも役立たせるといった手法も同じように本書から学んだことです。

また、要求や仕様にIDを付与してトレーサビリティを確保する手法などは、当時の私にとって業務の中で要件定義を行うにあたって非常に参考になりました。

反面、ユーザの「ストーリー」によって要求の漏れを防ぐという観点の記載が若干足りない気がします。
これについては他の書籍を参照してうまくミックスさせて実践するのが良いのではないでしょうか。

（終）

[yama219さんの感想 · 2011年11月9日]

この本にはいいことが色々と書かれているのだが、まとまりが無いためいまいちわかりにくい。そんな中でも機能仕様ではなく、要求仕様を書くべきであること、分かりにくい要求は動詞毎に分割して使えば分かりやすくなるといったノウハウはシンプルながら、知っているのといないのでは設計にかかる工数が大きく異なるので、この本を読んであらためて、この2点のことに気づけたのは収穫だったと思う。

[a-yamadaさんの感想 · 2011年10月23日]

保守フェーズで仕様だいやバグだという話があったので後学のために購入。
システムがどうしてこの形になっているのかが明文化されてるとメンテのしんどさが格段に違ってくる。

この本のように要求仕様書じゃなくても外設にコメントで理由を書くとかあとで影響あるかもしれないとこは課題に書いておくとか「なんで」の部分を残しておくのは大変重要だと思う。