書籍概要

【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術
~仕様が書けていますか?

著者
発売日
更新日

概要

好評既刊の改訂第2版。開発の根本であり工程すべてに関わってくる「要求の仕様化」について,その重要性からじっくりと解説。「要求」とは何か「仕様」とは何かという本質から説き,仕様書作りの考え方や表現方法を具体的に提示します。第1版では,要求を表現する際に「振る舞い」に注目し,分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱しました。第2版ではその方法論をさらに深め,上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。

こんな方におすすめ

  • ソフトウェア開発をスムーズに進めたいエンジニア
  • 相次ぐ「仕様の変更」や「バグの発生」に悩まされているエンジニア
  • 要求の仕様化に関心があるすべてのエンジニア

目次

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

サポート

現在サポート情報はありません。

商品一覧