要求定義はなぜ難しい
そもそも要求定義とは
システム開発をベンダーに依頼する際には、ユーザーがあらかじめ自社内でシステム化に対する要求を整理して定義しておく必要があり、システム開発の一番はじめに行うこの工程を要求定義と呼びます。
要件定義と似た言葉なので混同しやすいですが、要求定義はユーザーがシステム化に求める目的やニーズを定義することを指し、要件定義はユーザーからの要望をシステムとして現実のものにするため、機能などに落とし込める形で定義することを指します。
要求定義はシステム開発工程の中でも最も上流の工程にあたり、難易度が高いと言われています。実際に要求定義を進めようとすると、部署間で利害関係が衝突したり過剰な要求があったりなど、調整するだけでも大変な作業量となります。また抜け漏れなく要求を整理できたかどうかの判断がつきにくいといった問題もあります。実際に、顧客が本当に望んでいることがシステムに反映されていなかったり、要求の解釈に誤りがあったりなどで、やり直し（手戻り）が発生することがあります。そして要求定義の誤りを改修するために余計な費用が発生し、コストの増加やスケジュールの遅れによりプロジェクトが失敗することがあります。
要求定義をフレームワーク化して考えよう
このように要求定義は難しい作業ではありますが、フレームワークとして落とし込むことができれば頭の中がスッキリと整理された状態で進めることができます。本記事は、要求定義初心者の方に向けて、「要求定義」に必要な知識を体系化したガイドラインである要求工学知識体系(REBOK)を紐解きながら要求定義の進め方のコツを解説していきます。
要求工学知識体系(REBOK)とは
要求工学とは、システムやソフトウェアの開発におけるユーザー要求を定義して文書にし、仕様化するためのプロセスや技術です。要求工学知識体系(REBOK: Requirements Engineering Body Of Knowledge) は、アールイーボックと読み、要求工学の知識を実践の視点から整理して体系化し、要求をいかにしてまとめるかといった技術や技法の集大成のことを指します。REBOKは、要求を合理的に獲得・仕様化し、システム開発へとスムーズに接続することを目的としています。
要求定義のプロセス
REBOKでは要求定義のプロセスは３つの要素で構成されています。はじめに問題の本質を明らかにし、問題の解決策を策定、そして解決策を実現するためのシステムがもつべき機能や性能を定めます。それぞれのプロセスを「要求獲得」「要求分析」「要求仕様化」と呼びます。
- 問題の本質を明らかにする→要求獲得
- 問題の解決策を策定する→要求分析
- 解決策を実現するためのシステムがもつべき機能や性能を定める→要求仕様化
ステップ１．要求獲得
要求獲得では、顧客を含むステークホルダー(利害関係者)を明らかにし、そのニーズや問題、課題などの本質を明らかにします。要求定義が開発プロセスの最上流工程であるように、要求獲得は要求定義プロセスの最上流工程であり、要求工学では非常に重要なプロセスと位置づけられています。
要求獲得の主要な4つの技術
要求獲得の主要な技術として次の４つをご紹介します。
ステークホルダー分析：キーパーソンを捉える
ステークホルダーとは、利害関係者のことで、「企業などの組織、あるいはその活動について何らかの関わりや影響があり、利益を得たり損害を被る人や組織などの総称」のことです。システム開発におけるステークホルダーを特定し、その業務や役割を理解するとともに、要求に対する立場を理解するために、その重要度や影響度を明らかにします。これらの分析にはオニオンモデルやステークホルダーマトリックスを活用します。
ゴール分析：ゴールから始める
ゴールとはシステムが達成すべき状態のことを指します。ゴールを特定して、ゴールを実現する手段を段階的に具体化、詳細化し、ゴール間の関係を明らかにします。達成手段が不明確であるゴールは、それが明確になるまで分解、詳細化します。
シナリオ分析：ユーザーの視点で要求を明確にする
シナリオはユーザーがシステムを使用する具体的な手順を時系列で著した記述です。この記述によって具体的な利用シーンが明確になり、真の要求を抽出することができます。
エンタープライズ分析：対象システムの枠組みを明確にする
エンタープライズとは企業、事業を意味する言葉であり、ここでいうエンタープライズ分析とは事業や業務の構造を明らかにするために行われます。しかし、現実世界の組織や業務の構造を明らかにすることと、情報システムの構造を明らかにすることとの間には、その視野に大きな差があります。そのため下図のzachman フレームワークを活用して段階的に詳細化し、視野の差を整理します。
|
(What) データ |
(How) 機能 |
Where ネットワーク |
Who 人 |
When 時 |
Why 動機 |
|
|
スコープ/ |
ビジネスエンティティ |
機能 |
地理的位置(配置) |
組織図,職務記述 |
イベントリスト |
ビジネス戦略/ゴール |
|
技術/ 物理モデル |
データ設計 |
木構造図 |
システムアーキテクチャ |
職務仕様 |
イベント仕様 |
ゴール木/ルール仕様 |
|
詳細/ サブコントラクタ |
データの詳細定義 |
プログラム (関数など) |
ネットワークアーキテクチャ |
職務明細書 作業指示書 |
イベント詳細 |
ルール詳細 |
引用：要求工学実践ガイドREBOKシリーズ2 一般社団法人 情報サービス産業協会 REBOK 企画 WG編 P15 図1.10 Zachman フレームワーク
ステップ２．要求分析
要求分析は問題の解決策を策定するプロセスです。具体的には要求獲得で得た要求を分類・構造化し、優先順位付けをしたものに対してステークホルダーと合意するまでの一連の活動を指します。優先順位付けは実現可能性、必要性、効果などに基づいて要求を絞り込みます。要求獲得でもある程度の要求の分類、構造化を行いますが、要求分析では要求を実現する上で事業や他のシステム、ソフトウェアの構造上の制約と整合性を取ります。
１．要求の分類
要求の分類では、獲得した要求の要素を次の３つの基準で分類します。分類方法としてはグループ化、KJ法、マインドマップを適用します。
要求のスコープによる分類
要求は様々なスコープ(範囲)にまたがっています。そのため、ビジネス/プロダクト要求、システム要求、ソフトウェア要求に分類します。
要求の特性による分類
要求を「機能要求」と「非機能要求」に分類します。「非機能要求」はさらに品質要求、法令順守、制約等に分類します。この分類にはISO/IEC9126やその後継であるISO/IEC25000シリーズを用いることが多いです。
要求の内容による分類
各要求に対し重要度、緊急度、難易度、安定度などの属性に適切な値を入れ、必要に応じて属性値に基づいて要求を分類します。
２．要求の構造化
要求の構造化では要求間の依存関係や一貫性を、図や表などを用いて整理し明らかにします。要求の構造化には次のような方法があります。
5W1Hによる構造化
5W1Hという６つの視点でとらえることにより、複雑な共有を多面的にとらえることが可能になり、漏れが少なく記述することができます。
| Why | Whyでは目的や方針に基づいて要求を分類します。Whyの視点から要求を分類することにより、要求とその根拠との関係が明確になります。 |
| Who | Whoでは人や組織に基づいて要求を分類します。Whoの視点から要求を分類することにより、業務フローを照合し、モデル間の矛盾点や整合性の確認が可能となります。 |
| What | Whatでは機能に関する要求を分類します。Whatの視点から要求を分類することで、要求に含まれる機能に関わる概念の全体像を明らかにすることができます。 |
| When | Whenでは時間やイベントに関する要求を分類します。Whenの視点で要求を分類することで、イベントのタイミングや回数などの要求に漏れがないかを確認することができます。 |
| Where | Whereでは場所や配置に関する要求を分類します。Whereの視点で要求を分類することにより、業務や利用者の場所による要求の制約や例外的な要求を確認することができます。 |
| How | Howでは手順や業務シナリオに関する要求を分類します。Howの視点で要求を分類することで、システム化による業務効率について技術的な実現可能性を評価することが可能となります。 |
複数視点による構造化
システム要求、ソフトウェア要求の構造化では、次の複数視点を適用した構造化ができます。
| 構造の視点(静的モデル) | 時間によって変化しない構成要素と構成要素間の関係をとらえる視点で要求を分析します。 |
| 挙動の視点(振舞いの視点)(動的モデル) | オブジェクトの生成から消滅までを表すライフサイクルを分析することでオブジェクトの時間変化を捉えます。 |
| 機能の視点 | システムが果たすべき業務を実現する機能を特定します。 |
非機能要求の構造化
非機能要求のモデルとして、非機能要求グレードや品質機能展開(QFD)を適用できます。これにより、システムに適合する非機能要求を定義できます。
３．要求の割り当て
要求をシステムの構成要素に対応づけ、要求の実現可能性や非機能要求の妥当性を評価します。
４．要求の優先順位づけ
ソフトウェアに割り当てられた要求に対して優先順位をつけます。
５．要求交渉
要求の範囲や優先順位の妥当性について、各ステークホルダーが合意を形成するまでの交渉を行います。
ステップ３．要求仕様化
要求仕様化では、要求分析で整理した要求を規定の書式や表記法で記述し、要求定義書を作成していきます。要求仕様化の成果物は文書またはその電子版です。仕様化される要求は次の３つに分けられます。
| １．ビジネス/プロダクト要求 | すべてのステークホルダーが読むためのビジネス要求定義書とプロダクト要求定義書を作成します。 |
| ２．システム要求 | 導入するシステムの機能、前提条件、制約などを定義したシステム要求仕様書を作成します。 |
| ３．ソフトウェア要求 | ソフトウェアの機能や入出力などを定義したソフトウェア要求仕様書を作成します。 |
要求仕様化のプロセスを図で表すと下記のようになります。
記述内容としては、REBOKやIEEE830を参照すれば漏れのない要求定義書が作成できるはずですが、なかなか思うようにいかないかもしれません。その理由としては、「全ての項目を埋めるべきか」「どれぐらいの粒度で書けばよいか」「どのように書けばよいか」といった知識や技術が必要となるためです。もしプロジェクト内に適任者が不在の場合は専門のコンサルタントにチェックや作業の代行を依頼することもできます。
まとめ
システム開発工程の中でも最上流であり、難しいといわれる要求定義について、成功に近づくためのコツとしてREBOKの活用をしたフレームワーク化をご提案させていただきました。[要求獲得]～[要求仕様化」のプロセスは1回まわすだけでは要求を正しく捉えきれないことが多いため、最低でも2、3回は繰り返しまわすことが必要ですが、要求工学REBOKを活用することで確実に成功確率が上がります。せひご参考にしていただければと思います。
また弊社、IT品質専門コンサルタントQualituCubeでは、システム開発プロジェクト支援として要求定義代行をご提供しております。要求定義でお困りのことがございましたらお気軽にご相談ください。
QualityCubeのソフトウェア品質向上サポートサービス
