要件定義の構成要素
要件定義として何を定義するか
筆者が考える要件定義の内容は表1の通りです。前ページの図1に登場しているものを説明する内容となっています。
| このシステムの目的（価値）は？ どのような責務を持つ人に使われるのか？ どのような外部システムとかかわるのか？ システムはどのような使われ方をするのか？ システムとの接点は？ その時の入出力情報は？ システムに必要な機能は？ その機能が使用するデータは？ |
表1の構成要素はそれぞれがWhatを表し、上に向かってWhyを表しています。そのため、システムについてこれらを踏まえて説明するとスムーズに理解できます。例えば次のような説明になります。
- 「このシステムの目的は△△△です」
- 「この目的は次のアクターによって実現され、□□の効果を発揮します」
- 「そしてこの目的を実現するためには次のような業務を行います」
- 「まず○○業務はYYYを実現するための業務です」
- 「次にこれらの業務では～」
- ～～～
このようにシステムの目的、システムを取り巻く環境、そして機能とデータへとつなげて定義することで「なぜその機能が必要なのか」を容易に説明できるようになります。それは結果的に理解しやすいドキュメントでもあります。
何を大事にしないといけないのか
先に挙げた図書館の例に置き換えて考えてみましょう。そのシステムが「誰にどのような場面」で使われるのか、そしてこのシステムによって「何を実現しようとしているのか」を要件定義書に含めていれば、画面設計などの詳細な仕様を決める段階で、もう少し利用者への配慮がなされたシステムになったと考えられます。
「図書予約機能」と書かれていれば、わざわざ「システムを誰が使うのか」など要件定義書に書かなくても自明であると考えるかもしれません。しかし、それでもあえて記述する必要があるのは、発注者側の意志を表明するためです。「本を予約する人」というだけでもさまざまなことが考えられます。そこを「図書利用者」としての記述が含まれていれば、今回のシステムにおいて、どのような人が関わるのかを明確にしていることになります。そうすることでその「図書利用者」にとってどうあるべきなのかを考えることができます。
要件定義において大事なことは、詳細な仕様を決めるために「本当に必要な機能は何か」ということの判断材料を提供することです。従って、要件定義を行っているときには機能の仕様について時間を割くよりもその機能が必要だと考えた筋道を明らかにすることが重要です。表1はその筋道を示しているのです。
要件定義書の目的は発注者側がシステム化で意図していることを示し、それを伝えることです。そのためにもシステムが使われる環境を明確に定義する必要があります。そうすることでシステム化にあたって何に配慮しないといけないかが分かるようになります。
まとめ
要件定義は詳細なシステムの機能を決めるための入力情報となります。そのためにはWhatとWhyが記述されていることを説明しました。また、その内容として表1にある項目を示しました。
要件定義書のフォーマットは会社によってさまざまな形式が考えられますが、その内容について検討する場合はここで示したWhatとWhyの関係を意識して、その内容を見直すだけでも説明しやすく、理解しやすい要件定義書になります。
筆者は要件定義の手法として「リレーションシップ駆動要件分析（RDRA）」を提唱しています。具体的な要件定義の内容や進め方は次のサイト「リレーションシップ駆動要件分析（RDRA）」、著書『要件定義マニュアル』（秀和システム刊）を参照ください。また、簡潔にまとめたものとして『DBマガジン 3月号』71ページ（1月24日発売）ではどのように要件定義を進めていけばいいかを記述したのでそちらも参照ください。
参考文献
- リレーションシップ駆動要件分析（RDRA）
- 『顧客の要求を確実に仕様にできる要件定義マニュアル』神崎 善司 著、秀和システム、2008年10月
- DBマガジン 2010年3月号 株式会社翔泳社
