「ITアーキテクチャのセオリー」に続く「セオリー」シリーズである。
このシリーズは現場担当者により書かれているので、若干考え方に偏りがある気もするが、現場の経験に裏打ちされた貴重な情報を得ることができる。
また、上流工程の本は少ないので、とても助かる。

この本よる要件定義の基本的な考え方は、以下の通りである。
1.理想のToBeを作る
2. AsIsを作る
3. 実現を目指すToBeを作る
この3.が要件定義の作業である。

要求と要件には次のような関係がある。
ビジネス要求からビジネス要件。
業務要求から業務要件。
システム要求からシステム要件。
またビジネス、業務、システムと要求や要件は展開する。
「要求」は、実現したいこと。
「要件」は、「要求」に基づきつつ制約を踏まえ、情報システムに盛り込むべきもの。

要求を明確にし、管理することの重要性が語られている。
その際は、トレーサビリティを確保することが重要である。

要件定義時に、ER図等を用いて、データ要件を明確にするのが重要である、としている。
最初にデータ要件を明確にしておけば、システムのライフサイクル全般でデータの品質が安定し、手戻りを防ぐことができる。

要件定義を含む上流工程とは、システム屋と業務屋のコミュニケーションを円滑にする為にお互いの言語を翻訳し、整理した上で、システム構想を固めていく段階とも言える。

現場の問題点や課題を解決するためだけに、業務を整理した業務フローを最初から作ってはいけません。あくまで、トップダウンの視点で枠組みを作成し、ボトムアップで肉付け、が大前提です。トップダウンのプロセスを見直すことにより、現場が問題と認識しているプロセス時代がそもそも必要でなくなることもあります。

[amazonjs asin=”4865940685″ locale=”JP” title=”だまし絵を描かないための– 要件定義のセオリー”]