要求定義の要求獲得について

n-ozawan

2023.09.27

開発手法要求定義

皆さん、こんにちは。技術開発グループのn-ozawanです。
広島県の大久野島はウサギの島として有名ですね。だいぶ昔に行ったことあるのですが、その時は１羽も見かけませんでした。いつからウサギが繁殖するようになったんですかね？

本題です。
突然ですが、自分が何のためにシステムを開発しているのか考えたことはありますか？生活のためとか、上司から指示を受けたからとか、そういう話ではないです。自分がプロジェクトに携わり、開発したこのシステムに、顧客は何を期待しているのか？何を求めているのか？今回はシステム開発の上流工程である要求定義と、要求獲得についてのお話です。

要求定義

要求定義と要件定義

「要件定義」はよく聞くけど、「要求定義」はあまり馴染みがないかもしれません。どちらも英語では「Requirement definition」ですし、実は言葉が似通っているだけで、同じ意味なのではと思った方もいるかと思います。しかし、「要求定義」と「要件定義」はそれぞれ意味が異なります。

「要求定義」とは、システムを取り巻くステークホルダ（利用するユーザーも含む）が、そのシステムに対して求めている事柄（要求仕様）を明確にし、定義するフェーズです。そして「要件定義」は、その要求仕様を元に、システムを構築するために必要な仕様を定義するフェーズになります。

V字モデルでは、一番最初に行う工程が要求定義になります。

要求定義とは？

一般社団法人情報サービス産業協会が発行する要求工学知識体系（REBOK）では、要求の定義をIEEE標準に準拠して以下の3項目で定義しています。

問題を解決したり、目標を達成するために、ステークホルダが必要とする条件、あるいは、能力。ここで、条件とは、たとえば、ステークホルダが現状からあるべき姿へ到達するために必要な条件を意味する。
契約、標準、仕様、あるいは、その他の正式に要請された文書を満たすために、システム、あるいは、システムコンポーネントが満たすべき条件、あるいは、持つべき能力。
上記の1と2の条件や能力を記述した文書

また、REBOKでは「要求とは、ステークホルダが抱えている課題を解決し、彼らが望んでいる状況を作るために実現すべき事柄を指す。」とも表現しています。

ステークホルダは何らかの課題や問題を抱えており、システムを利用することでそれら課題や問題を解消したいと望んでいます。要求定義とは、それら課題や問題を解消するために、システムに何を求めているのかを抽出して、明確にするフェーズになります。

要求定義の流れ

REBOKでは要求定義の流れを以下のように定義しています。大まかに３つのステップになります。

要求獲得
ステークホルダに対して質問やインタビューを通じて、現状の課題や問題を理解し、要求の獲得を行います。
要求分析
獲得した要求を整理、分類して、要求間の構造や依存関係、一貫性や整合性を明らかにします。
要求仕様化
分析した要求を仕様化して文書化します。

上記３つのステップを行った後、要求の検証・妥当性確認・評価をします。

要求獲得の流れ

REBOKでは要求獲得のフローを以下のように定義しています。

ステークホルダの識別
まずはそのシステムのステークホルダは誰なのかを認識するところから始まります。
現状システムの理解
ステークホルダへのインタビューなどを通じて、現状システムの理解を深めます。
現状システム(As-Is)のモデル化
現状システムをモデル化することで、ステークホルダ間で現状システムの理解を共有します。
課題の抽出と原因分析
現状システムにおける課題の抽出と、その原因を分析します。
課題解決に向けたゴールの抽出
抽出した課題を解決するにあたり、ゴール（本来あるべき姿）を抽出します。
ゴールを達成する手段の抽出
現状システムの課題を解決し、ゴールが達成された状況を実現する手段を抽出します。
実現すべき将来システム(To-Be)のモデル化
将来システムをモデル化することで、関係者間でゴール達成に向けた将来システムの理解を共有します。
要求の記述と詳細化
これまで獲得した要求を明文化して詳細化する。

要求獲得で得られた要求は、あくまでステークホルダから得た要求です。現時点ではまだその要求をシステム化するかどうかは決まっていません。ステークホルダが１枚岩でないケースもあり、得られた要求が相反する場合もあり得ます。後続の要件分析では、要求獲得で得られた要求を整理して、どうシステム化していくのかを検討していきます。