要件定義の成果物の作り方をわかりやすく解説！
システム開発顧問関連仕事の仕方技術解説お知らせピックアップコラム
目次
ポッドキャストでも解説しています
↓
はじめに
要件定義はシステム開発プロジェクトにおける最上流工程に位置づけられる非常に重要なステップです。
要件定義が不十分であったり不明確であると、プロジェクト全体に影響を及ぼし、納期遅延やコスト超過の原因となります。
フロントローディング開発という言葉が最近よく言われますが、その肝となるのが、”要件定義”の工程になります。
”要件定義”でまとめられたものは”成果物”にする必要があります。次の工程である一般的には、”基本設計”に引き継ぐためです。
本記事では、要件定義の成果物の作り方について、5つの章に分けて詳しく解説します。
第1章：要件定義とは
要件定義の重要性
要件定義は、システム開発において必要な機能や条件を明確にするプロセスです。
一般にはユーザーの要求を反映した要求仕様書（稀に要求定義書とも言います）に基づいて、実際に開発する側の立場として、開発に必要な機能を洗い出して定義づけることが重要になります。
要件定義を行うことによって、以下の3つが果たせることになります。
1）次工程の実際の開発チームが何を開発するかが明確になる。
2）前工程の要求仕様を作成した側（企業では商品企画グループやマーケティンググループがそれに相当、または実際のお客様の場合もあります）が要求仕様に合致した要件定義していることを確認して貰って仕様凍結が出来る。
3）ステークホルダーに今後の開発の理解を得てもらう事が出来る。
要件定義の成果物
要件定義の成果物は、プロジェクトのガイドラインとして機能します。主な成果物には以下のものが含まれます。
- 要件定義書
- ユースケース図
- データフロー図（必要に応じて：フローチャート、状態遷移図、シーケンス図などが適切なケースもあります）
- システムアーキテクチャ図
以降の章でこの4つの成果物について順番に解説していきます。
第2章：要件定義書の作成
要件定義書の構成
要件定義書は、要件定義の中でも一番重要な成果物になります。そしてプロジェクトの基盤となるドキュメントになります。
要件定義書の基本的な構成を以下に記します。
-
- プロジェクトの背景と目的
- スコープ
- 機能要件
- 非機能要件
- 制約条件
- リスク
この6つの構成について、以下順番に解説します。
プロジェクトの背景と目的
要件定義を行うより前にプロジェクトが始まる場合と、後にプロジェクトが始まる場合があります。
実際にはプロジェクトに関するプロジェクト起案書などでもプロジェクトの背景や目的を書くことになりますが、要件定義書の冒頭でも触れるべきだと思います。
プロジェクトの背景や目的を明確に記述することで、全員が同じ方向を向いてプロジェクトに取り組むことができます。
目的から説明するというのは非常に重要なことです。何のためのプロジェクトかというのを説明するようにしましょう。
スコープ
プロジェクトの範囲を定義します。スコープを明確にすることで、プロジェクトの目標が明確になり、範囲外の要求が追加されるのを防ぎます。
機能要件と非機能要件
機能要件はシステムが何をするべきかを定義し、非機能要件はシステムの性能や品質を定義します。具体的な記述が求められます。
非機能要件は単品の商品で無いシステム物、さらにはシステムを用いてのサービス事業を行う場合に極めて重要になります。
制約条件
どのようなシステム開発をする場合も、何らかの制約条件が発生します。それを要件定義の中で、可能な限り洗い出しておくことが重要です。
リスク
プロジェクトマネジメント全体の中でもリスクマネジメントは重要になりますが、要件定義を行う場合もリスクについて触れておくことをおすすめします。
なぜなら、特にシステム物に関しては長期間使用している中で、滅多に起きないようなことが起きるというのが常です。
その滅多に起きないが起きてしまうと、大変な問題になるような事柄をリスクとして洗い出しておくことがとても大切です。
第3章：ユースケース図の作成
ユースケース図とは
ユースケース図は、システムが提供する機能を視覚的に表現する図です。オブジェクト指向設計という考え方の中で、ユースケース図が考案され、普及しました。
アクター（ユーザーや他のシステム）とシステムの間のやり取りを示します。
要件定義書は一般に文章の羅列になり、機能によっては文章だけではわかりにくいものがあります。そうしたときにこのユースケース図を記述することが必要になります。
ユースケース図の作成方法
-
- アクターの特定: システムとやり取りするすべてのアクターを識別します。
- ユースケースの特定: アクターがシステムに対して行うアクションを洗い出します。
- ユースケース図の作成: アクターとユースケースをつなぐ線を描き、システムの振る舞いを視覚化します。
ユースケース図の活用
ユースケース図は、要求仕様書を作成した側やステークホルダーとのコミュニケーションのときにとても役立ちます。
開発設計者でない方も図であればシステムの動作のイメージをつかみやすくなる上、アクターによってユーザーが表せますので、ユーザの操作、および操作による動作や表示が理解できます。
すなわち、要件の確認や検証を行う際に役立ちます。
第4章：データフロー図の作成（必要に応じて）
データフロー図とは？
データフロー図（DFD）は、システム内のデータの流れを視覚化する図です。
プロセス、データストア、データフロー、エンティティ（外部システムやユーザー）を示します。
なおデータフロー図は、ビジネス系のシステムで有効であり、組み込み系のシステムでは必ずしも必要でありません。
組み込み系ではデータフロー図よりも、フローチャート、状態遷移図や
シーケンス図などが役に立つ場合が多いですが、本記事では割愛します。
データフロー図の作成方法
-
- プロセスの特定: システム内の主要なプロセスを洗い出します。
- データの特定: プロセス間でやり取りされるデータを特定します。
- データストアの特定: データが保存される場所（データベースなど）を特定します。
- データフロー図の作成: プロセス、データフロー、データストア、エンティティをつなぐ線を描きます。
データフロー図の活用
データフロー図は、システムのデータ処理の流れを理解しやすくし、データのやり取りに関する問題を早期に発見するために使用されます。
第5章：システムアーキテクチャ図の作成
システムアーキテクチャ図とは
システムアーキテクチャ図は、システム全体の構造を視覚化する図です。コンポーネント、モジュール、サブシステムなどの関係を示します。
場合によっては、このシステムアーキテクチャ図は、要件定義でなく後工程である基本設計で書くべきかも知れません。
ただし、要件定義書の中でもシステムアーキテクチャ図を書いておくこと自体、後工程の基本設計をスムーズに行うために有効と言えます。
システムアーキテクチャ図の作成方法
-
- コンポーネントの特定: システムを構成する主要なコンポーネントを洗い出します。
- モジュールの特定: 各コンポーネント内の詳細なモジュールを特定します。
- システムアーキテクチャ図の作成: コンポーネントとモジュールをつなぐ線を描き、全体の構造を視覚化します。
システムアーキテクチャ図の活用
システムアーキテクチャ図は、システムの設計や開発において、全体像を把握しやすくするために使用されます。
これを要件定義の中で行うのがフロントローでイング開発になると言えます。
システムアーキテクチャ図を作成することにより、システムのスケーラビリティや拡張性を考慮した設計が可能になります。
まとめ
要件定義の成果物は、プロジェクトの成功に不可欠な要素です。
要件定義書、ユースケース図、データフロー図、システムアーキテクチャ図などを正確に作成し、要求仕様書を作成した発注側（自社内であれば、商品企画部門やマーケティング部門）やステークホルダーとのコミュニケーションを円滑に行うことでき、ひいてはその後の開発プロジェクトをスムーズに進めることができます。
本記事での内容を参考にして、具体的かつ明確な要件定義を行い、超上流工程で仕様の凍結を図り、その後のシステム開発の品質を高めていきましょう。
関連記事
↓
前の記事へ