入門+実践 要求を仕様化する技術・表現する技術 の商品レビュー

清水吉男(著者)

2021/04/03

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

2014/10/05

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

2014/05/26

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

2012/11/28

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

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

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

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

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

2013/10/13

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

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

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

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

（終）

2011/10/23

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

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

2011/10/01

こういう風に仕様書が書けているかと聞かれれば、まあ、書けていないんですがね。読んだ後もそんな状態です。
「要求」、「仕様」とは何かという本質をつかむということで、参考にはなります。

2010/02/23

USDM表記法について書かれているが、本の構成がわかりずらい。
要求モレについて書かれているのがあらゆる章に散見されていたりして、現状の問題と解決手段としてのUSDM表記、そしてその表記方法がまとまっていないため読みづらい。

表記法そのものは導入したいと思ったが参考するための本としては…

2009/10/04

筆者の経験やノウハウを元に要求を仕様化・表現する技術をまとめた本。
独自色有るが、具体的な手順・考え方・確認すべき事項など分かりやすくまとまっており、参考になる。

要求・仕様
・要求で範囲を明確にする。（≒状況や条件などをある程度具体的に記載する）
・理由を明記する。（適切な仕様＝実現方法を導く、必要性の明確化、抜け漏れの防止。)
・必要に応じて説明をつける（ただし要求や仕様と明確に区別する）
・要求のカテゴリ化・階層化で、システム化範囲の明確化と抜け漏れを防止する。(MECEで分ける、要求コードはカテゴリ名略称を使う)
・非機能要求を明確化する
・検証可能な表現にする
・Excelでまとめる（要求、仕様をそれぞれ複数段・親子で表現、右セルに実装のコード(画面コードなど)を記載)
・派生開発でも要求を確認、なければ作る。機能追加時の既存コード変更を忘れない。
・画面仕様書も要求と仕様形式で書く。画面遷移で画面仕様書をつなげる。
・変更管理委員会では判断と支持のみ。
・メトリクス収集と分析を繰り返す。

顧客との関係
・無理なFIX(仕様の確定)はしない。要求・仕様の導出根拠を明確化、有効期限を意識。
・TBDではなく、AorBという程度までは確定させる。5%以下。
・顧客に参加意識を持たせる
・要求の項目数による見積。

その他
・親子階層で仕様をまとめるなら、Accessの方がいいかもしれない。
・意味ありコードを各要求・仕様に付けるのはいいが、ある程度固まってから番号を振るとは言え、変更に弱い気がする。
・業務プロセス等をモデリングする話が出てこなかったが、若干組み込み系に偏っていたからか？

2009/10/04

要件定義の大切さを何度も何度も訴えています。同じことを何度も繰り返しているので最後のほうは正直あきあきするかも？でも入門書としてはおすすめだと思う。