だまし絵を描かないためのーー 要件定義のセオリー

◆◆◆業務とシステムの接点をしっかり捉える!◆◆◆

前著『システム設計のセオリー』で論理設計に範を示した著者が、さらなる上流工程である要件定義の手順と成果物を定式化します。
ユーザー企業と SI ベンダの両方を長く経験した著者だからこそ、ビジネス要求からシステム要件への「最初の入り口」で躓かないための極意を明らかにすることができました。
企業の情報システム部門と SI ベンダ、両者をつなぐ必読書です。
序 章 なぜいま「要件定」なのか?

第 1 章 情報システムにおける要件定義

第 2 章 要件定義の基本方針

第 3 章 要件定義の前にやっておくべきこと

第 4 章 要件定義でやるべきこと

第 5 章 非機能要件の定義

第 6 章 アーキテクチャの整備

第 7 章 妥当性確 / 合意形成

『だまし絵を描かないためのーー 要件定義のセオリー』 (赤 俊哉 著、リックテレコム、2018 年 5 月刊) は、ビジネス要求をシステム要件へ変換する要件定義の工程について、その手順と成果物を定式化した実務書です。版元の書誌登録の紹介文は、前著『システム設計のセオリー』で論理設計を扱った著者が、さらに上流の工程に当たる要件定義を主題にした本と案内し、企業の情報システム部門と SI ベンダーの両者をつなぐ本と位置づけています。国立国会図書館の書誌では、件名は「要件定義」です。

序章と第 1 章から第 7 章、要件定義の手順と成果物

目次は、要件定義を取り上げる理由を述べる序章に続き、第 1 章「情報システムにおける要件定義」、第 2 章「要件定義の基本方針」、第 3 章「要件定義の前にやっておくべきこと」、第 4 章「要件定義でやるべきこと」、第 5 章「非機能要件の定義」、第 6 章「アーキテクチャの整備」と進み、第 7 章が妥当性の確認と合意形成です。

業務とシステムの接点、機能要件と非機能要件

要件定義 は、業務で実現したいことを、システムが満たすべき条件として書き出し、発注する側と開発する側で合意する工程です。業務の流れや画面、帳票、扱うデータのように利用者が求める働きを機能要件と呼び、性能、可用性、セキュリティ、運用と保守のしやすさのように、システムの品質や制約に関わる条件を非機能要件と呼びます。非機能要件は利用者の側から言葉にされにくい条件で、決めないまま設計や開発へ進むと、後の工程で性能や運用の前提が食い違うことがあります。システム全体をどの部品に分け、部品同士をどうつなぐかという アーキテクチャ の方針も、求める応答時間や停止の許容範囲のような非機能要件によって選択が変わります。

ユーザー企業と SI ベンダーの両方を経た著者

刊行時の著者紹介によれば、赤 俊哉は 1964 年生まれで、SI 会社のプログラマーと SE を経てユーザー企業 (劇場) の情報システム部門に着任し、全社のシステム化を推進したあと、業務現場で営業、飲食事業、座席予約管理業務のマネジメントや BtoC ビジネスなどを担当しました。刊行時には全社の IT 戦略とともに、業務改革、データ経営の推進、データモデリングとプロセスモデリングなど業務管理全般に携わっていると紹介されています。著書には『システム設計のセオリー』 (リックテレコム) と『SE 職場の真実』 (日経 BP) があります。版元の紹介文は、ユーザー企業と SI ベンダーの両方を長く経験した経歴を、ビジネス要求からシステム要件への「最初の入り口」で躓かないための極意を示す根拠として挙げています。

本書は、序章と全 7 章からなります。要件定義を取り上げる理由を述べる序章から、情報システムにおける要件定義、基本方針、要件定義の前にやっておくべきこと、要件定義でやるべきこと、非機能要件の定義、アーキテクチャの整備、妥当性の確認と合意形成までを収めています。