第1部　要求仕様にまつわる問題

第1章　要求仕様にまつわる問題

• 1.1　どこで問題が発生しているか？
• 1.2　要求仕様のトラブルの実態
• 1.3　曖昧な仕様で作業に入っている
• 1.4　顧客からの仕様変更が頻発して……
• 1.5　要求した機能を満たしていない
• 1.6　納期の遅れとなって表面化する
• 1.7　品質要求に応えられないSE
• 1.8　派生開発での仕様トラブルはもっと複雑
• 1.9　設計書が省かれてしまう原因になっている

第2章　なぜ仕様のトラブルが起きるのか

• 2.1　問題が明らかにされたか？
• 2.2　仕様化の作業を放棄した
• 2.3　ドメインの知識がない
• 2.4　バグの経験だけでは役に立たない
• 2.5　レビューできた仕様書か
• 2.6　FIXした・しないでもめる理由
• 2.7　途中で仕様変更が混乱する理由
• 2.8　望みはある

第3章　要求仕様は不要か？

• 3.1　テスト仕様で代われるか？
• 3.2　仕様化しないほうが儲かる？
• 3.3　“不完全な要求仕様”の誤解
• 3.4　“コードなら書ける”の仕組み
• 3.5　GUI構築ツールで仕様を引き出せるか？

第4章　仕様化の効果

• 4.1　要求仕様書がすべての始まり
• 4.2　一気に解消する混乱
• 4.3　設計や実装のイメージができる
• 4.4　不用意な「試作」が減る
• 4.5　設計や実装時に仕様の確認ができる
• 4.6　レビューで感じる仕様化の効果
• 4.7　トータル工数が短くなる
• 4.8　設計に入る前に機能の難易が見える
• 4.9　顧客との良好な関係を築ける
• 4.10　ITゼネコンとの訣別
• 4.11　要件管理に取り組める

第5章　要件開発の重要性

• 5.1　文書にする理由
• 5.2　“わかる”の問題に対応する
• 5.3　なぜ“要求”仕様書というのか？
• 5.4　要求仕様書は誰が書くのか
• 5.5　顧客からの要求仕様書を洗練する
• 5.6　仕様モレと仕様間の衝突を早期に発見する
• 5.7　要件開発をスケジュール管理のなかで行う
• 5.8　要件開発と要件管理は車の両輪
• 5.9　要求工学における世界の動き

第2部　要求仕様を書く

第6章　“要求”を書く

• 6.1　要求の役割
• 6.2　要求の表現
• 6.3　要求には「理由」がある
• 6.4　必要なら「説明」を付ける
• 6.5　要求のカテゴリ化
• 6.6　要求のモレを防ぐことが重要
• 6.7　品質要求を確認する
• 6.8　品質要求の表現

第7章　要求の階層化テクニック

• 7.1　要求を階層化して範囲を狭める
• 7.2　「MECE」の活用
• 7.3　階層化しても「要求」に変わりはない
• 7.4　依頼者と分割の基準を共有する
• 7.5　階層は2層ぐらいで止める

第8章　要求を仕様化する

• 8.1　仕様とは
• 8.2　“Specify”の意味
• 8.3　仕様で衝突する
• 8.4　いつ仕様化すべきか？
• 8.5　検証可能性について
• 8.6　固有の番号を付ける
• 8.7　要求の階層のなかで仕様を捉える
• 8.8　さらに範囲を狭めるためのグループ化
• 8.9　シナリオ機能と単純機能の違い
• 8.10　仕様と要求の混在の問題
• 8.11　仕様から要求を立てる
• 8.12　“ペースト作文”の弊害
• 8.13　「否定表現」などの曖昧な表現を避ける
• 8.14　“FIX”から“賞味期限”へ
• 8.15　品質要求の仕様化
• 8.16　確定しない仕様の表現
• 8.17　設計情報の扱い

第9章　Excelによる仕様化の勧め

• 9.1　「Excel」のほうが細かな使い方ができる
• 9.2　要求書と要求仕様書を一体化
• 9.3　要求TM（トレーサビリティ・マトリクス）への展開
• 9.4　自在に「列」を設計する
• 9.5　WBSとの違い
• 9.6　Excelで書くときの注意

第10章　派生開発における要求仕様書

• 10.1　“部分理解”の世界である
• 10.2　要求仕様書の体系を持ち込む
• 10.3　旧状態を表現する
• 10.4　何が変更されるかを表現する
• 10.5　「差分」を書く
• 10.6　変更の種類
• 10.7　変更の要求
• 10.8　追加の要求
• 10.9　移植の要求
• 10.10　削除の要求
• 10.11　派生開発の品質要求

第11章　画面仕様書のあり方

• 11.1　画面仕様書の問題点
• 11.2　画面操作全体に対する要求はあるか？
• 11.3　個別の画面設計の指針としての仕様
• 11.4　画面遷移と画面仕様を連携させる
• 11.5　機能仕様との連携

第12章　ヒアリング時の注意

• 12.1　ヒアリングの目的
• 12.2　“システムの目的”を確認する
• 12.3　今回の要件定義の手順について同意を得る
• 12.4　仮説見積りに基づいた仕様作成期間
• 12.5　契約時には，仕様の項目数の見積りを付ける
• 12.6　要求仕様書の「体系」を示す
• 12.7　事前にヒアリングの範囲を知らせる
• 12.8　こちらの要求仕様のフォーマットに慣れてもらう
• 12.9　言われたことをメモしただけではダメ
• 12.10　品質要求をヒアリングする
• 12.11　未決項目を含んだ状態でのベースライン設定
• 12.12　顧客を仕様化作業に巻き込む

第3部　要件管理と計測

第13章　仕様化を支える要件管理

• 13.1　なぜ，仕様が変更されるのか？
• 13.2　関係者へのオリエンテーリング
• 13.3　要求仕様書をレビューする
• 13.4　ベースライン設定と合意
• 13.5　以後の仕様変更をコントロールする
• 13.6　未確定だった仕様が決まる
• 13.7　いつ仕様変更を実施するか
• 13.8　仕様変更を期間限定で募集する方法もある

第14章　仕様化の出来栄えを測る

• 14.1　何を計測するか
• 14.2　レビューでの指摘件数とバグ件数の関係
• 14.3　データは組み合わせると声を発する
• 14.4　バグから学ぶ要件開発の方法

第15章　仕様化技術の応用

• 15.1　リスク管理へ応用
• 15.2　課題への対応が見えずにうろうろする
• 15.3　作り替えても前と変わっていない
• 15.4　業務指示もその場で具体化しよう
• 15.5　会社の方針がそのまま降りてくる