◆仕様書で情報を整理する！ITプロジェクトには、さまざまな「情報｣と｢人｣が入り交じっています。それゆえ、全体像が掴みにくく、情報が混乱して遅延や失敗に終わるケースが少なくありません。プロジェクトを成功に導くには、入り交じる情報を｢仕様書」で正確に整理し、関係者の認識を統一することが必要です。本書では、要求定義から納入、リプレースの流れとともに、要求定義書や要件定義書、基本設計書などの「仕様書」の種類と目的、作成のポイントと注意点、各開発工程での使い方などをストーリー形式で解説します。【目次】第1章 システム開発の流れ◎システム開発の流れの概要◎プロジェクトの流れ◎成果物の流れ...ほか第2章 業務分析－要求定義書◎顧客が望む目標を分析する◎システムの利用者を考える◎業務の流れを図式化する...ほか第3章 システムの検討①－要件定義と基本設計◎『提案書』作成の流れ◎要件定義でイメージを統一する◎基本設計でシステムの概要を検討する第4章 システムの検討②－外部設計◎基本設計から外部設計へ◎外部設計における視点の重要性◎外部設計での問題への対応...ほか第5章 文書作成における注意点◎顧客と開発者の用語を統一する◎文書のつながりを考える◎文書全体の流れを考える...ほか第6章 要素の抽出－外部設計と内部設計◎外部設計と内部設計の違い◎ユーザー機能の抽出◎既存システムとの連携と仕様変更...ほか第7章 試験項目に対する視点－試験工程◎クリアする目標を明確にする◎自動化される単体試験の活用◎ユーザー視点での試験...ほか第8章 スケジュールと見積り◎開発スケジュールの決め方◎見積りの出し方◎品質計画の立て方...ほか第9章 工程の進め方◎進捗の管理◎要件定義工程での進め方...ほか第10章 仕様変更に対応する－要求管理◎顧客から要求される仕様変更◎仕様書の量と仕様変更...ほか第11章 不具合に対処する－障害情報◎障害票の流れ◎対処の記録...ほか第12章 システム移行に対応する－移行計画◎システムをリプレースする◎移行計画を立てる...ほか第13章 ナレッジマネジメント◎プロジェクトの情報を残す◎プロジェクトの情報を参照する...ほか.

第1章 システム開発の流れ ◎システム開発の流れの概要 ◎プロジェクトの流れ ◎成果物の流れ ◎情報の流れ 第2章 業務分析－要求定義書 ◎顧客が望む目標を分析する ◎システムの利用者を考える ◎業務の流れを図式化する ◎利用者の視点からシステムを記述する ◎ベータ版と順次リリース 第3章 システムの検討①－要件定義と基本設計 ◎『提案書』作成の流れ ◎要件定義でイメージを統一する ◎基本設計でシステムの概要を検討する 第4章 システムの検討②－外部設計 ◎基本設計から外部設計へ ◎外部設計における視点の重要性 ◎外部設計での問題への対応 ◎ユーザーインターフェイスを重視する場合 第5章 文書作成における注意点 ◎顧客と開発者の用語を統一する ◎文書のつながりを考える ◎文書全体の流れを考える ◎パッケージアプリやWebアプリ開発での文書や用語集 第6章 要素の抽出－外部設計と内部設計 ◎外部設計と内部設計の違い ◎ユーザー機能の抽出 ◎既存システムとの連携と仕様変更 ◎内部設計の省力化 第7章 試験項目に対する視点－試験工程 ◎クリアする目標を明確にする ◎自動化される単体試験の活用 ◎ユーザー視点での試験 ◎安全な運用に関する試験 第8章 スケジュールと見積り ◎開発スケジュールの決め方 ◎見積りの出し方 ◎品質計画の立て方 ◎構成管理の実行方法 第9章 工程の進め方 ◎進捗の管理 ◎要件定義工程での進め方 ◎設計工程での進め方 ◎実装工程での進め方 ◎試験工程での進め方 ◎計画の実行と仕様書の役割 第10章 仕様変更に対応する－要求管理 ◎顧客から要求される仕様変更 ◎仕様書の量と仕様変更 ◎突発的な問題による仕様変更 ◎試験工程での仕様変更 ◎リリース後の変更、バージョンアップ 第11章 不具合に対処する－障害情報 ◎障害票の流れ ◎対処の記録 ◎対処方法の分類 ◎プロジェクト管理の視点 第12章 システム移行に対応する－移行計画 ◎システムをリプレースする ◎移行計画を立てる ◎運用手順を見直す ◎試験運用とデータ移行 第13章 ナレッジマネジメント ◎プロジェクトの情報を残す ◎プロジェクトの情報を参照する ◎過去のプロジェクトの情報を活用する ◎社内情報の形式知化 コラム ・プロジェクトマネージャの役割 ・プロジェクトのビジョンを決める ・計画駆動とは何か？ ・ウォーターフォールとスパイラルモデルの組み合わせ ・パッケージアプリ開発、Webアプリ開発 ・プロジェクトリーダーの役割 ・要求定義でのOSやミドルウェアの扱い ・提案書を提出する前に行うこと ・自分たちのために要件定義を作る ・外部設計とファンクションポイント法 ・プログラマーの役割 ・試験担当者の役割 ・計画駆動は仕様変更を許容するのか？ ・ラショナル統一プロセス風に「辞書」を作る ・ユーザビリティ試験を行う時期は ・プロジェクトバッファと保険 ・利用者の代弁者 ・試験工程のバーンダウンチャート ・カバレッジ率にこだわるべきか？ ・フレームワークを更新して機能アップ ・納入時に注意すべき事柄 ・要件から機能へのつながり ・試験工程での安定化を予測する ・障害票のトレーサビリティ ・システム移行時の見積り方法① ・システム移行時の見積り方法② ・テスタビリティに気を付ける ・システムの賞味期限