目次
第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 会社の方針がそのまま降りてくる