最終更新: cloudhands 2018年07月26日(木) 00:19:14履歴
「前ページ(その2)」からの続きです。
前ページまでは、「業務要件」と「システム要件」をざっくりとした大きな箱で表していましたが、もちろん実際にはそれぞれの要件を詳細に定義していく必要があります。
この詳細化ですが、上図のようにレベル分けして考える必要があります。
可能な限りレベルを深くしていくことでより明確にすることができます。
「業務要件」と「システム要件」の両方のレベル分けができたら、個々の「業務要件」と「システム要件」を対応付けしていきます。
つまり、どの「業務要件」はどの「システム要件」で実現するかということです。
この対応付けは1対1とは限りません。
1つの「業務要件」を2つの「システム要件」で実現することもあるでしょうし、1つの「システム要件」で2つの「業務要件」を実現することもあり得ます。
詳細なレベルで「業務要件」と「システム要件」の対応付けができれば、この両者の溝はかなり埋められたと言えるでしょう。
つまり、「発注者」と「受注者」の溝も埋まり、プロジェクトの成功に一歩近づくということです。
前ページまでは、「業務要件」と「システム要件」をざっくりとした大きな箱で表していましたが、もちろん実際にはそれぞれの要件を詳細に定義していく必要があります。
この詳細化ですが、上図のようにレベル分けして考える必要があります。
可能な限りレベルを深くしていくことでより明確にすることができます。
「業務要件」と「システム要件」の両方のレベル分けができたら、個々の「業務要件」と「システム要件」を対応付けしていきます。
つまり、どの「業務要件」はどの「システム要件」で実現するかということです。
この対応付けは1対1とは限りません。
1つの「業務要件」を2つの「システム要件」で実現することもあるでしょうし、1つの「システム要件」で2つの「業務要件」を実現することもあり得ます。
詳細なレベルで「業務要件」と「システム要件」の対応付けができれば、この両者の溝はかなり埋められたと言えるでしょう。
つまり、「発注者」と「受注者」の溝も埋まり、プロジェクトの成功に一歩近づくということです。
タグ
このページへのコメント
非常にわかりやすく、参考になりました。
記事を作成いただきありがとうございます!