目次

第1章　システム開発は要望の洗い出し、要求のまとめ、要件の定義から始まる

• ルール01　顧客満足度の高いシステムはライフサイクルを捉えている
• ルール02　「基本仕様書」は開発のバイブルとなるドキュメント
• ルール03　システムの必要十分条件は「要求」＋「要件」から導く
• ルール04　依頼企業の要望が「要求」、要求が集まって「要求定義」になる
• ルール05　要求定義の「実現したい」を要件定義で「実現すべき」にする
• ルール06　システム開発の第一歩は正しい要求探しと要求分け
• ルール07　要求定義が用意されなければSEは自分で作る覚悟をする
• ルール08　要件定義で技術的な視点から要求定義の正しさを確認する
• ルール09　業務フローはシステム要件の定義をサポートするツール
• ルール10　要件定義の作成は難しいのでSEが作るケースは多くなる
• ルール11　「要求仕様書」こそ、システム開発の原点だ
• ルール12　RFPで依頼企業の望むシステム開発の提案と条件がわかる
• ルール13　「要求仕様書」「概要仕様書」「基本仕様書」は整合する

第2章　要求定義は「こうしたい」の要望をシステム作りの必要条件にまとめた文書

• ルール14　要望はリストを分析・整理して要求定義を作成する
• ルール15　業務要求がなければシステム開発は始まらない
• ルール16　ユーザー要求の価値は業務要求との関連性で決まる
• ルール17　要望収集はインタビューとアンケートの組み合わせが効果的
• ルール18　収集した要望はレベル化して、矛盾・過不足の確認を行う
• ルール19　要望の分析でシステムに期待される役割を明らかにする
• ルール20　要求へ展開するために本当に必要な要望だけを再編成する
• ルール21　3つのレベルの要望項目を要求項目に整理する
• ルール22　要求項目の再評価で問題点や矛盾点を解消する
• ルール23　要求項目の追加・変更は業務フローにも影響を与える

第3章　要求定義をどう書けば、依頼企業にも開発企業にもわかりやすくなるのか？

• ルール24　要求定義は、3つの基本項目と正確な言葉の記述からなる
• ルール25　要求定義の基本は開発企業と依頼企業に正確に伝えること
• ルール26　要求の種類によって書き方のポイントは違う
• ルール27　要求定義には重要な要求を正確にわかりやすく記述する
• ルール28　要求定義の確定には依頼企業の合意が不可欠
• ルール29　要求定義の変更を管理するためのプロセスを規定する

第4章　要件定義は、依頼企業が望むシステム作りのカナメ

• ルール30　要件定義は要求定義を実現するシステムの必要十分条件
• ルール31　技術的要件は機能要件と非機能要件に分類して記述する
• ルール32　業務フローが要件定義作成をサポートする
• ルール33　要件定義にはシステム構成や運用・保守の要件が有用である
• ルール34　機能要件はシステムの「機能」「性能」「品質」を規定する
• ルール35　非機能要件はシステム開発で守るべき制約時効や制限条件
• ルール36　要件定義でシステム構成や運用・保守の要件を規定する
• ルール37　要件定義は順番に要求分析を進めることで漏れを防ぐ
• ルール38　要求定義の本質を分析することでシステムの役割を理解する
• ルール39　要求項目からシステムに必要十分な各種要件を導き出す
• ルール40　分析して導き出した要件を要求定義実現の視点から検証する
• ルール41　業務フローと要求定義・要件定義の関係を理解する
• ルール42　業務フローは現場観察・インタビュー等で文書化する
• ルール43　要件定義の前に要求定義の実現可能性を確認する
• ルール44　機密性を確保のためのリスク評価と要件定義で信頼を守る
• ルール45　完全性の維持のためのリスク評価と要件定義で信用を守る
• ルール46　可用性を確保してシステムを安定的・継続的に運用する
• ルール47　システムを安定的に運用するための要件を規定する
• ルール48　運用を安定的に継続するために保守の要件を規定する

第5章　要件定義ではシステム開発に必要十分な要件を正確かつ綿密に書く

• ルール49　要件定義はシステム設計の原点として正確に明確に規定する
• ルール50　要件定義は読み手にわかりやすく伝わる構成を基本とする
• ルール51　慎重なレビューによって要件定義の正当性を検証する
• ルール52　開発企業が作成した要件定義には依頼企業の合意が必須
• ルール53　要件定義の維持に重要な変更プロセスとバージョン管理
• ルール54　概要仕様書は「要求定義」＋「要件定義」をもとに設計する
• ルール55　「基本仕様書」の原点も「要求定義」＋「要件定義」にある