上流工程を加速する! 要求定義・要件定義 55のルール

[表紙]上流工程を加速する! 要求定義・要件定義 55のルール

A5判/224ページ

定価(本体1,880円+税)

ISBN 978-4-7741-3403-1

ただいま弊社在庫はございません。

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

ユーザーがシステムへ抱く要求を整理して集めたものが「要求定義」。要求定義の「実現したい」を「実現すべき」要求へと明確にするのが「要件定義」です。本書では一筋縄ではいかない「要求定義・要件定義」の絶対に押さえるべき約束事を「ルール」として55の項目にまとめました。要求定義・要件定義について未経験な若手SEや,今まさに要求定義にとりかかっているSEの皆さまにお勧めです。

こんな方におすすめ

  • 上流工程の経験が少ない20代~30代の若手エンジニア
  • 上流工程のハウツーを効率的に吸収したいエンジニア
  • 上流工程のイントロの知識を求めているプログラマ

著者の一言

SEや開発企業にとってもっとも困ることは「これは依頼したシステムではない」と依頼企業にクレームを言われることです。特に,システムの完成間際時に言われると,システムの完成の遅延や,システムの開発コストの増加といった問題が起きます。また,「完成したシステム」と「期待したシステム」が違うことは依頼企業にとっても一大事です。予定通りにシステムの運用を開始できず,大損害を被ることもあります。

本書では,55のルールを通じて,システム開発にとって非常に重要な要求定義と要件定義の目的や役割,具体的な記述方法や注意点を説明します。本書を通して,SEの方々が,要求定義と要件定義の重要性をより理解し,適切に作成することで,設計仕様書をはじめ,各種の仕様を変更することなく,期待されたシステムを完成できるノウハウを得ていただければ,何よりの喜びです。

目次

第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 「基本仕様書」の原点も「要求定義」+「要件定義」にある

著者プロフィール

秋本芳伸(あきもとよしのぶ)

1976年沖電気工業株式会社入社。ミニコンピュータ用のプログラム言語などの開発やパソコン,ワークステーションの基本ソフトウェアの研究開発などに従事。1987年マイクロソフト株式会社を経て,1992年にオープンインタフェース株式会社を共同で設立。

現在,1999年に設立した有限会社ワイツープロジェクトでシステム開発を行う傍ら,コンピュータ関連書籍の執筆も行っている。

主な著書には,『若手SEのためのシステムエンジニアという仕事の流れと役割』『若手SEのためのソフトウェアテストの常識』『オープンソースを理解する』(ディー・アート),『基礎から学ぶシステム仕様書』(日経BP社)など多数。


岡田泰子(おかだやすこ)

1992年よりIT企業でソフトウェアのユーザーインタフェースを担当する一方,マニュアル制作に携わる。1995年インターネットポータルサイト構築に参加。

現在,1999年に設立した有限会社ワイツープロジェクトに従事する傍ら,コンピュータ関連書籍の執筆も行っている。

主な著書,訳書には,『基本から理解したい人のためのルーティング入門』(ディー・アート),『ペルソナ戦略―マーケティング,製品開発,デザインを顧客志向にする』(ダイヤモンド社),『90分で学べるRFPの作り方』(日経BP社)など多数。