はじめに
こんにちは。NTTデータ先端技術の亀井（@kamein）です。
本記事はデータ活用基盤を作ってみた連載記事のその２(要件定義)です。
本シリーズの取り組みの内容についてはその１(構成シナリオ)をご覧ください。
本記事では、データ活用基盤の要件定義の考え方・進め方についてご紹介します。
目次
- 要件定義の考え方
- 要件定義で実施したこと
- 要件定義で注意したこと
要件定義の考え方
要件定義では、システム化で実現する仕様（必要な機能や非機能目標）を定義付けします。定義付けを行うことで、使用する製品・技術選定や開発工数を具体的に見積ることができるようになります。そのため、要件定義は「様々な観点からから仕様を検討すること」、「責任分界点を明確化し、システム化範囲を定めること」が重要です。
要件定義が曖昧なまま後続工程に進むと、想定外のシステム開発を求められたり、低品質なシステム納品を迎えて顧客満足度下がる事態となります。
システム開発はどの工程も重要なタスクですが、要件定義工程はシステム全体の品質(Q)・コスト(C)・納期(D)に大きな影響を及ぼすところなので、特に重要な工程だと考えます。
要件定義で実施したこと
今回のPJは学習目的で顧客はおらず、要件定義の曖昧さが後々問題となっても自分たちでQCDをコントロールできるので、"えいや"で要件定義付けして後続工程に進みました。
〇実案件での要件定義について
実案件では顧客ヒアリングを重ねて実現すべき仕様を明確化する必要がありますが、限られた打ち合わせ時間の中で全ての仕様をヒアリングのみで仕様定義付けを行うことは現実的ではありません。
システム目的からシステム開発者側である程度は"えいや"で仮定してから、顧客と具体的な仕様を定める方が良いです。要件定義の抜け漏れを防いだり、効率的に進めることに繋がります。
顧客側と開発側が一体となって定義付けを進めていくんだという意識を持つことが大切です。
要件定義で注意したこと
要件定義は抜け漏れなく仕様を決定することが難しいです。
それは、検討範囲が多岐にわたる上に案件ごとに実現するシステムが異なるため、それぞれ独自の要件定義項目を検討して成果物を作成するためです。
今回のPJでは、ユースケースから整理することおよび活用できる他ドキュメントを流用することを意識して作成しました。参考にできそうなドキュメントにNTTDATAが提供しているビッグデータ活用基盤リファレンスアーキテクチャがありましたので、こちらを活用しつつ、ユースケース整理を意識して以下の成果物を作成しました。
| 成果物 | 概要 | 参考 |
|---|---|---|
| 観点一覧.xlsx | 分析要件の文書化 | ビッグデータ活用基盤リファレンスアーキテクチャを引用 |
| ビッグデータ活用基盤_検討項目表_非機能編.xlsx | 非機能要件の文書化 | ビッグデータ活用基盤リファレンスアーキテクチャを引用 |
| アクター定義一覧.txt | アクター一覧表 | - |
| 業務フロー図.xlsx | ユースケース一覧図 | - |
| システム構成図.xlsx | システム構成図 | - |
最後に
機能要件はシステムごとに大きくことなるので検討が難しいですが、非機能要件はIPA(情報処理推進機構)が提供する非機能要求グレード表が基盤構成検討に必要な観点がほとんど盛り込まれており強力です。これまで基盤構成を検討してことが無い方は、一度は目を通しておいた方が良いと思います。（今回はNTTDATA資料を活用しましたが、こちらもベースはIPAの非機能要求グレード表です。）
次の記事は、データ活用基盤を作ってみたその３(基本設計)です。
最後までお読み頂きありがとうございました。