「入門+実践」要求を仕様化する技術・表現する技術
改訂第2版
仕様が書けていますか？
著：清水 吉男
出版社：技術評論社
良書、どろくさいシステム開発のなぜを考える書です。難易度が高いです。
本書の目的は、コンピュータシステムの構築の要求を適切に表現することで仕様を引き出す方法を語ってくれています。
本書を読めば、仕様変更率を５％以下に抑えることができ、仕様関係のバグも激減し、当初の納期通りにシステムができあがる、という、なんというありがたい書なのである。
要求の仕様化技術は、ソフトウエアエンジニアリングの技術の中の一部にすぎない
仕様化技術を生かすために、設計技術、見積技術、スケジューリング、進捗管理も重要である
さらに、要件開発は、２１世紀に入って、さらに高度な要求仕様の書き方や、要件の抽出、分析方法の研究もすすんでいる。
が結論です。
本書の構成は３部構成です。
①要求仕様にまつわる問題とはどんなものがあるのか
②問題に対して、どう要求仕様をかけばいいのか
③要件管理をどうするのか、なにを、計測すればいいのか
ソフトウエア開発とは、大勢の人間がかかわっているのでコミュニケーションの問題、個々のエンジニアが、みえない要求、仕様を、プログラム言語でコードにするので、対応する個々の人間のスキルや理解度に左右される、やっかいなものです。
あたまの痛い内容がたくさんでてきます。
・解釈の違いは伝言ゲームの中で発生する
・ウォータフォールの最大の欠点は、問題を発見するタイミングが遅くなることである
・テスト期間が短くなるのは、設計や実装に時間をとられているので、テストする時間が短くなるからである
・派生開発（追加開発）での潜在バグは、前任者が作りこんだバグがたまたま発見されたもの、なぜ作り込まれたのかは永遠にわからない
・設計や実装ベースであきらかになった、要求仕様や設計のミスは、要求仕様書に追記されることはない
・保守性という品質要求は、機能とはまったくことなるため、設計段階で、品質要求を行い、あらかじめ、組み込んで置かなければすり抜けてしまう
・要求仕様を丸投げした段階で、分割発注をおこなっても、まともなコードはかけない
・要求されない仕様は、実装されない
・仕様レビューは、１回しか見積工数として見られていないし、多くの指摘事項をもらうことを前提とはしていない
・仕様変更の流れ
①変更依頼の内容の不備をチェック
②内容の軽重や変更の範囲を検討
③範囲が広い場合は、関係者を集めて対応方法を検討
④現行仕様と矛盾しないか、他の機能仕様に影響がないかを検討
⑤手分けして、手戻り作業を行い
⑥修正作業と確認作業を行い
⑦対応完了の報告を行う
・要求仕様の粒度を小さくすると、「とてもそこまで書いている時間がありません」
⇒でも、仕様化されていないまま、設計はできない
⇒手戻りをするくらいであれば、粒度を小さくするほうが効果がたかく、おつりがくる
・顧客との関係を高める
仕様書のサンプルを用意して、成果物を例示して、なぜ必要なのか意味を説明する
・お互い「わかった」が一致していないケース、勘違いしています。
・文章が書けない人に他人の文章を理解させることは容易ではない
・理解するという行為は、時として、作成するよりも、難しい
・仕様モレよりも、要求モレを防ぐほうが難しい
・要求がきちんと文書化されることはほとんどありません
・仕様が分かりにくければ、理由と、説明をセットにしておく
・システムを適切なカテゴリに分割する、要求を分割して範囲を小さくする
・仕様書は、エクセルで書く
・派生開発（追加開発）の難しさ
①一般的に開発期間が短い
②自分で書いたコードではない、人の書いたコードを解析する必要がある
③要求仕様の文書がない、あっても不足している
④ほしい設計書がない
・言われたことを、メモしているだけではだめ
メモや議事録を、ドキュメント体系の中にうまく反映するための仕組みが必要
・仕様化されない要求は実現されない
目次
第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 会社の方針がそのまま降りてくる
おわりに
参考文献
ISBN：9784774142579
出版社：技術評論社
判型：A5
ページ数：384ページ
4.31巻2,838円 (税込)好評既刊の改訂第2版。開発の根本であり工程すべてに関わってくる「要求の仕様化」について，その重要性からじっくりと解説。「要求」とは何か「仕様」とは何かという本質から説き，仕様書作りの考え方や表現方法を具体的に提示します。第1版では，要求を表現する際に「振る舞い」に注目し，分割・階層化により振る舞いの範囲を狭くして仕様漏れをなくしていく方法を提唱しました。第2版ではその方法論をさらに深め，上位要求の表現や分割・階層化したときの下位層の要求を表現する際に「動詞」を意識する視点を全面的に打ち出しています。
4.41巻2,838円 (税込)トラブルが頻発する「派生開発」を改善するにはどうしたらよいか。著者が現場で培ってきた方法論をまとめあげました。「派生開発」専用のこのプロセスにより，確実にプロジェクトを成功させます。現場で抱える問題の解決に必ず役立つ，「定番」となる一冊です。