アジャイル環境で必須 ビジネス要件定義書(BRD)を作成する際のポイント:どう作るか、どう活用するか
アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。
ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書(BRD:Business Requirements Document)を用意すれば、顧客のニーズを満たすことが可能になる。
アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプロジェクト管理にBRDがどのように適合するか、BRDを実際のコードに変換する方法、ソフトウェアチームがBRDを満たしているかどうかを判断する方法について考える。
BRDによって想定結果を設定する方法
BRDには、プロジェクトが目指すビジネス目的を記述する。BRDでは、製品の目的、製品の仕組み、クライアントの使用目的など、製品の製造方法を定める。BRDがあれば、コストに影響する可能性のある要因や制限、ソフトウェアプロジェクトの工程やスケジュールを確認できる。また、個々のプロジェクトの想定結果や必要な納品物の概要を示し、量と質の両面でプロジェクトの成否を判断するベンチマークを設定することもある。
BRDにはさまざまな構成がある。製品開発チームは、BRDをゼロから作成することも、サンプルテンプレートを利用しニーズに合わせて調整することも可能だ。とはいえ、どのように作成するとしても、BRDの効果を高めるには次の10件の標準情報を構成要素として含めるのが一般的だ。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- アジャイル開発をウオーターフォール開発と比較して、向き不向きやメリデメを把握しよう
IT用語の基礎の基礎を、初学者や非エンジニアにも分かりやすく解説する本連載、第9回は「アジャイル開発」です。ITエンジニアの学習、エンジニアと協業する業務部門の仲間や経営層への解説にご活用ください。 - 強いチームを作るために学んでおきたい、ソフトウェア開発の「次に来ること」
エンタープライズにおけるソフトウェア開発をより発展させるために学んでおくべきトレンドを振り返っておこう。 - 技術的負債が引き起こす12の“悪夢” コスト増、パフォーマンス低下だけでは終わらない
不適切に記述されたコードに機能を追加すると、評判が悪くなり、ユーザーエクスペリエンスが損なわれる。本稿では技術的負債が引き起こす12の悪影響を紹介する。