要求定義とは│要求工学REBOKをフレームワーク化して要求定義を成功させる

システムの構築をシステム開発会社に依頼する場合は、あらかじめ自社内でシステム化に対する要求を整理して定義する必要があります。

この要求を定義するシステム開発の一番はじめに該当する工程を「要求定義」と呼びます。

実際に要求定義を進めようとすると、部署間での利害関係が衝突したり過剰な要求があったりなど、調整するだけでも大変な作業量となります。
また抜け漏れなく要求を整理できたかどうかの判断もつきにくいため、悪戯に時間だけが経過していくといったこともままあります。

このように、要求定義は確かに難しい作業ではありますが、本記事を読み終えた時に皆さんの頭の中がスッキリと整理された状態になるよう、要求工学REBOKをフレームワークに見立てて要求定義を紐解いていきたいと思います。

少し文章が長くなりましたが、どうぞ最後までお付き合いください。

要求工学とは

実際に、顧客が本当に望んでいることがシステムに反映されていなかったり、システム要求そもそもに誤りがあれば、やり直し（手戻り）が発生します。
そして、要求の誤りを改修するための余計な費用が発生し、開発コストの増加や開発スケジュールの遅れにより開発プロジェクトは失敗という結果になります。

要求工学は、要求をいかにしてまとめるかといった技術や技法の集大成のことで、要求工学では、要求を定義するためのプロセスとして、以下の5つが挙げられています。

工学とは

工学については、徳島大学工学部案内>工学とは？から引用してご紹介します。

『工学とは、通常「数学と自然科学を基礎とし、時には人文社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問である」と言われています。工学はその目的を達成するために新しい知識を求め統合し、応用するばかりでなく対象の広がりに応じてその領域を拡大し、周辺分野の学問と連携を保ちながら発展します。したがって、工学の定義は時代とともに変化すると言えるでしょう。いずれにしても、技術を体系づける科学であると言えます。社会が高度技術化、人工システム化した現代においては、工学は広く人工システムの開発企画・設計、製作、運用、保全のための基礎となる学問ということも出来ます。』

引用：徳島大学工学部案内>工学とは？

つまり、工学が指し示すものとしては、机上の空論ではなく、実際に現場で現物を観察し、現実を認識した上で問題解決を図ろうとする三現主義を原則としたものと言えます。

システム工学について

折角なので、システム工学についても少し触れておこうと思います。

システム工学は、今から遡ること約80年前の1940年に米国のベル研究所にて初めて『システム工学』という言葉が用いられました。
当時に最新システムに当たる「通信システムにおける増幅とスイッチのための素子として真空管に代わるトランジスタ」の発明で、理論物理学者、電子物理学者、機械技術者、化学者、実験家が集まり開発研究がなされたそうですが、このように異分野の研究者や技術者が集まり今までにない新しいシステムを開発するための技法や理論を扱うシステム工学が生まれました。

そののちシステム工学が真価を発揮したのはアポロ計画の時で、それまでは機器や装置は単独で発展してきたところを、半導体技術をはじめとする各分野の技術革新の影響により、小型化・複雑化・高機能化した機器や装置を互いに連結させることにより、単独の場合よりもはるかに高度な機能を得られるようになり、システム工学の発展につながりました。

現代においては、より大規模で複雑かつ高度なシステムが多くなっているため、システム工学の観点から開発しないと対処できないような状況となっています。

要求定義の概要

要求定義の概要について触れていきます。

要求定義とは？

要求定義とは、システムライフサイクルの一番はじめに位置し、システム利用者の抱える問題やニーズを正確に定義する工程のことです。
要するに、システムの顧客（発注側）がシステム開発の目的やニーズを定義することを要求定義と言います。

要求定義書の書き手は誰か？

要求定義では、「顧客（発注側）として何を実現したいのか」を明らかにする必要がありますので、要求定義書は、夢や希望などの要望を持っている顧客が書くのが自然です。

しかし、顧客（発注側）はシステムへの知識や理解が乏しい場合が多く、要求定義書の作成が現実的でないことも少なくありません。
よって多くの場合は、顧客（発注者）とITコンサルタントなどのシステムに詳しい者との共同作業となります。

また、要求定義の段階で既にシステム開発の依頼先が決まっているような場合は、状況により開発側が要求定義と要件定義をまとめて要件定義書として作成することもあります。

要求定義が難しいとされる理由

先に要求定義書の書き手の話をしましたが、要求定義の書き手の問題と要求定義の難しさは密接に関係しています。

顧客（発注側）は自社の業務については精通していますが、ITについては知識がない（少ない）一方、開発側はITについては精通しているが、顧客の業務については知識がない（少ない）といったギャップがどうしても発生します。この互いのギャップが要求の認識齟齬や思い込み、考慮漏れなどが起こる原因で、それに気づかないまま開発を進めてしまうことにより不備が混入し、後に不具合となって発覚するといったことが起こるのです。

これが、要求定義が難しいとされる一番大きな理由です。

要求定義のフレームワーク

さて、ではここから本題に入っていきたいと思います。要求定義をよりよく実施するためには、BEBOKをフレームワークに見立てて活用するのが有効的な方法となります。
ただフレームワークを活用するうえで、ひとつだけ注意して頂きたいことがあります。

フレームワークは埋めるものではなく、考え抜いた結果をフレームワークの規定のところに記述すること。

これは非常に重要なことですので、必ず頭の片隅に置いておいてください。

要求定義の成果物

ちなみに、弊社ではIEEE830をベースとしながらも、以下のような構成をスタンダードとしていますので、こちらも参考にしてください。

要求定義のプロセス

「要求工学とは？」で述べたとおり、BEBOKでは要求定義のプロセスは以下の5つ要素で構成されています。

顧客（発注者）には何らかの問題あるいはニーズがあって、その問題解決やニーズの実現のためにシステム開発を行う訳ですが、現代におけるニーズの多様化や技術の高度化、システムの複雑化により、要求の複雑さ、曖昧さ、矛盾を明らかにすることの困難さは日々増しています。

要求定義は、

といった一連の過程ですが、要求定義では「1.問題の本質を明らかにする」の段階を『要求獲得』と言い、そのあと『要求分析』→『要求仕様化』→『要求の検証・妥当性確認・評価』という順にプロセスを辿ります。
（『要求計画・管理』はプロセス全体に係ります）

要求獲得

要求獲得では、顧客のニーズ、現状の（抱える）問題、経営課題などに基づいて要求を獲得します。
ここでの注意点は「顧客は一人ではない」ということです。

要求はステークホルダ全体に対して捉える必要があり、まずはステークホルダを特定することから始めます。

ステークホルダの特定においては、オニオンモデル（図1）やステークホルダマトリクス（図2）によるポートフォリオ分析を行い、ステークホルダを一覧にまとめますが、特にキーパーソンを確実に捉えることが大事です。

▲図1：オニオンモデルのイメージ図

▲図2：ステークホルダマトリクスのイメージ図

要求獲得に向けては、事前に「システム化の背景・目的」を十分に理解しておく必要があります。

顧客の業界・業種・業態、顧客のビジョンや今後の方向性、システム化の背景や目的について、十分に調査し、深く理解・把握しておくといった事前準備こそがプロジェクトの成功には不可欠です

ステークホルダとは

ステークホルダとは、利害関係者のことで、「企業などの組織、あるいはその活動について何らかの関わりや影響があり、利益を得たり損害を被る人や組織などの総称」のことです。

引用：ステークホルダ（利害関係者）とは - IT用語辞典 e-Words

ことシステム開発においては、システムに関与する個人や組織のことで、ステークホルダはシステムに対する要求の源泉というふうに捉えると理解が深まります。

▲ステークホルダのイメージ図

要求分析

要求分析とは、要求獲得で得た要求を分類・構造化し優先順位付けをしたものに対してステークホルダと合意するまでの一連の活動のことです。
要求分析では「何を実現するのかを明らかにする」作業を行います。

要求の分類については、①要求のスコープ、②要求の特性、③要求の内容、の3つの軸で分類を行います。

業務要求

業務要求では、システム化に至った背景やビジネスの目的・課題、達成すべきゴール、期待する効果を整理します。
ビジネスモデル図といったビジネス全体を把握できる資料と、ビジネスを遂行するための業務プロセスとしてのAs-Is（現状）とTo-Be（あるべき姿）の業務フローも作成します。

機能要求と非機能要求

ソフトウェア要求は、機能要求と非機能要求に分類して整理します。

機能要求

機能要求は、システムが「何をするか」を表したもので、システムが行うべきこととしての「What」に該当します。
機能要求の例としては、以下のようなものが挙げられます。

・営業情報をシステム上で共有し把握したい
・受発注情報に連動した在庫管理を行いたい

非機能要求

機能要求以外のソフトウェア要求を非機能要求と呼びます。具体的にはシステムが業務要求や機能要求を満たす上での特性のこと、といった説明になりますが、非機能に関する要求は顧客からの要求として出てこないことが多いため、非機能要求グレードのフレームワークを使って丁寧に確認していくことが重要です。

非機能要求の例としては、以下のようなものが挙げられます。

・レスポンスは3秒以内にして欲しい
・システムダウン時は3時間以内に復旧して欲しい

機能要求と非機能要求の相違点と課題

分類	要求の例	相違点	課題
機能要求	・営業情報をシステム上で共有し把握したい ・受発注情報に連動した在庫管理を行いたい	・ビジネスに直結する ・イメージし易い 利用者が自らの言葉で語れる
非機能要求	・レスポンスは3秒以内にして欲しい ・システムダウン時は3時間以内に復旧して欲しい ・将来の処理量増加に備え、2倍の性能に拡張できるようにして欲しい ・業務時間中はシステムに関する質問に答えてくれる担当者が欲しい	・ビジネスに直結しない ・イメージし難い ・具体化が進まないと利用者が語りにくい	・要求項目が漏れやすい ・開発者との共通認識を持つことが難しい

▲IPAの『機能／非機能要求の相違点と課題』から作図
システム構築の上流工程強化（非機能要求グレード）-IPA（情報処理推進機構）

非機能要求グレードとは？

「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。

引用：非機能要求グレードとは -IPA情報処理推進機構-

IPAでは非機能要求グレードとして、非機能要求を6つのカテゴリに分類し定義しています。

分類カテゴリ	概要
可用性	システムサービスの継続的な利用可能性に関する要求
性能・拡張性	システムの性能と将来的な拡張性に関する要求
運用・保守性	システムの運用・保守サービスに関する要求
移行性	システム資産（データ）の移行に関する要求
セキュリティ	システムの安全性やセキュリティに関する要求
システム環境・エコロジー	システムの設置環境やエコロジーに関する要求

「要求分析」の続き

要求の構造化では、要求間の依存関係や一貫性を明らかにします。
このときできるだけ適切な図や表などで表現し、互いの認識齟齬が起こらないように工夫します。

構造化においては5W1Hを用いて整理すると、要求を多面的に捉えることができ、抜け漏れ防止につながります。

要求の優先順付けでは、構造化し整理した要求に対して、相対的な優先順位をつけていきます。
優先順位付けには様々な方法がありますが、例えば、要求のゴール達成への貢献度、要求同士の依存関係性、開発コストや開発期間などにより決定します。

要求分析で決めた要求のスコープや優先順位の妥当性については、各ステークホルダと合意形成することが重要で、この交渉を「要求交渉」と呼びます。
要求交渉では、ステークホルダと開発者が仕様化すべき要求のスコープに対して合意が得られるまで続けますが、もしステークホルダ間で対立した場合は、①協調 あるいは、②妥協 による合意を目指します。

①協調：ステークホルダ全員の関心事を考慮し、各ステークホルダの問題に対する解決策を探る方法で、問題解決型と呼ばれる。
②妥協：各ステークホルダが互いに一定の負担や妥協をするような中間解を示す方法で、共有型と呼ばれる。
この方法ではWin-Winにならないが、現実的な解を得られる場合が多い。

要求仕様化

要求仕様化では、要求分析で整理した要求を規定の書式や表記法で記述し、要求定義書を作成していきます。

記述内容に関しては、REBOKやIEEE830を参照すれば漏れのない要求定義書が作成できるはずですが、なかなか思うようにいかないかもしれません。
その理由としては、「全ての項目を埋めるべきか」「どれぐらいの粒度で書けばよいか」「どのように書けばよいか」といったテーラリングの技術が必要となるためで、もし上手くいかない場合は、専門家や専門のコンサルタントにチェックを依頼するとよいでしょう。

上流工程で多いお悩みなど、相談だけでも大歓迎！

要求の検証・妥当性確認・評価

要求仕様化で作成した要求定義書は、『要求の検証・妥当性確認』としてステークホルダによるレビューを実施したのち、『評価』→『承認』というフローを辿ります。

要求の検証では、以下の観点で検証を行います。要求定義に求められる要求品質は、ISO9126のソフトウェア品質特性でも検証は可能ですが、REBOKの特性の方が考えやすいためREBOKの方をおすすめします。

REBOKの品質特性	品質特性の意味
妥当であること	顧客のニーズと一致していること。要求定義書以外に作成した関連ドキュメントとの矛盾がないこと
曖昧でないこと	要求定義書に記述されている要求が、ただ一通りに解釈できること
完全であること	顧客のシステムに対するニーズが漏れなく要求定義書に記述されており、かつ図表の参照や用語の定義などの要求定義書の形式が整っていること
矛盾がないこと	要求定義書内部で矛盾や衝突がないこと
重要度と安定度のランク付けがされていること	各要求について、重要度と安定度を示す指標を明確につけておくこと
検証可能であること	開発されたシステムが要求定義書に記述された要求を満たしているかどうか確認可能であること
変更が容易であること	要求定義書に対する変更が、容易に完全に一貫して行えるようになっていること a)目次や索引、明確な相互参照が整備され使いやすい構造になっている b)冗長でないこと（同じ要求が要求定義書内で複数個所に記載されていないこと） c)他の要求と混ざらず、各要求を独立・分離して表現していること（要求が互いに依存していないこと）
追跡可能であること	要求定義書に記述された個々の要求に関し、起源が明確であり開発が進行するに伴って作成された文書等との対応付けがとれること a)後方追跡可能性 b)前方追跡可能性

要求の妥当性確認については、要求のスコープごとに応じてそれぞれの要求の妥当性確認が必要です。
以下の手順で確認することにより全体の妥当性を確保します。

1. 最初に業務要求の妥当性を確認し、次に妥当性確認済みの業務要求と照らしてシステム要求の妥当性を確認する
2. その次に妥当性確認済みのシステム要求と照らし合わせてソフトウェア要求の妥当性を確認する

検証・妥当性確認の方法としては、要求者であるステークホルダが要求定義書の内容について検証・妥当性確認としての要求レビューを実施します。
このレビューをより有効的に実施する方法としては、先に示した『REBOKの品質特性』や、この後に示す『主要な要求欠陥』の一覧表を参照したチェックリストを作成し、活用するとよいでしょう。

要求の誤り	誤りの内容
漏れ	要求そのものが漏れている
矛盾	要求間で矛盾がある
不足	要求が十分に記載されていない
曖昧	要求の記述が曖昧である
測定/評価不可	要求を満たしているかどうかを評価したり測定したりできない
ノイズ	無意味な要求になっている
過剰	過剰な要求になっている
実現不可	制約条件のもとで実現できない要求である
理解不可	要求の内容が記述されていない、あるいは後で記述することになっているなど、読者が要求の内容を理解できるように記述されていない
構成不良	要求が表記法に則った記述でなかったり構成が適切でない
前方参照	要求の項目や用語が未定義のまま用いられている
変更困難	一部の要求変更が要求全体に影響するなどの変更が困難な定義や記述となっている
不透明/不明瞭	根拠が不明であったり、依存関係や責任者が不明な要求である

要求の計画・管理

要求定義書は、システムライフサイクルの一番はじめに作成する文書で、これの上位に該当する文書は存在しないことより、システム開発における最も重要なドキュメントです。

要求定義書は、その後の開発工程における全てのインプット資料となるため、要求定義書の変更状況は後工程に大きな影響を及ぼします。
よって、要求定義書を管理する仕組みを確立することは必須となります。

要求の管理に向け、要求文書に付加したい要求属性には以下のような情報が挙げられます。

要求属性	情報
基本属性	識別番号（ID） 作成者 日付、など
要求内容に関する属性	重要度 緊急度 コスト見積もり 制約条件、など
要求の状況を示す属性	要求の状態（提案、承認、検証済み） 優先順位 リスク、など
要求の関連	トレーサビリティ 要求間の依存関係、など

要求管理については、「要求定義書の変更管理」のほか、①要求スコープ管理、②要求トレース管理、③要求変更による影響分析、などを行います。

①要求スコープ管理
要求スコープ管理では、業務要求、システム要求、ソフトウェア要求に分類して段階的に管理します。
一般的にステークホルダはスコープを意識した要求出しはしないため、要求スコープ管理をしないと要求定義書にスコープを超えた要求が混入したり、要求の抜け漏れや矛盾が混入する恐れがあります。

②要求トレース管理
要求トレース管理では、個々の要求の源泉から実装までを記録し、その間の関係をID等で紐づけてトレース可能な状態で管理します。トレースには源泉から実装に向かう前方トレーサビリティと実装から源泉に向かう後方トレーサビリティがあります。その他、要求間の相互依存性についても管理する必要があります。

③要求変更による影響分析
要求変更においては変更が及ぼす影響範囲を正確にわかる状態にすることも重要で、これを影響分析と言います。影響分析により、次のような影響を特定できるようにします。

要求定義書の変更管理プロセスについてもここで触れておきます。

1. 要求ベースライン登録
   • ステークホルダと合意し承認された要求定義書を、開発のベースラインとしてリポジトリに登録します。
2. 要求変更の受付
   • ベースラインに対する変更について、変更一覧など規定の書式で受け付けます。
3. 変更の影響分析
   • 変更による影響を分析し、変更に必要な作業と工数を見積もります。
4. 変更の審査
   • 影響分析に基づいて盛り込むべき変更を審査します。ステークホルダとは審査した変更の合意形成を図り承認を得るようにします。
5. 要求定義書の変更
   • ステークホルダに承認された変更を要求定義書に盛り込み、ベースラインを改版します。
6. 要求定義書の検証
   • 要求定義書が正しく変更されたことをチェックします。

要求言語

最後に、要求定義書を作成する際に用いる要求言語について確認しておきましょう。

要求言語としては、日常的に使っている日本語や英語などの「自然言語」と、図形や表を用いた「図式言語」が一般的ですが、それぞれに特徴がありますので、要求の不備が混入しないよう、
また内容がよりわかりやすくなるよう、意識的に使い分けたいところです。

ちなみにUML（Unified Modeling Languageの略語で、日本語訳は「統一モデリング言語」）も図式言語に含まれます。

要求言語	メリット	デメリット
自然言語	1.新たに勉強しなくても読み書きできる 2.システム開発の非専門家で読み書きできる 3.どんな分野の要求でも表現できる	1.曖昧な表現になりやすい 2.語句の省略や代名詞を使うことができる 3.多義語が使われると認識齟齬を起こすリスクが発生する 4.定量的に表現できることでも定性的な表現が可能
図式言語	1.一目で内容が理解できる 2.フロー図にできるフロー要求は文章で表すより容易に表現できる 3.少しの訓練で使えるようになる	1.表現対象が限定的であるため、対象外は図式で表現できない 2.全く知らない人には正確に理解してもらえない

まとめ

要求定義は難しいと言われていますし、難しさの要因は記事内でも折に触れ記述いたしましたが、その打開策として、要求定義のフレームワーク化をご提案いたしました。
私の経験則からしても、要求定義は要求工学REBOKを上手く活用することで確実に成功確率が上がりますので、参考になった箇所がありましたら、是非とも貴社の要求定義工程に取り入れて頂けましたら幸いです。

なお、『要求獲得』～『要求検証・妥当性確認・評価』のプロセスは1回まわすだけでは要求を正しく捉えきれないことが多いため、最低でも2、3回は繰り返しまわすことが必要です。

弊社では、プロジェクト支援として実務支援をサービスとしてご提供しております。
中でも、『要求定義代行支援』や『要件定義代行支援』といった上流工程支援は、近年のDX推進の動向とも相まって、現在多数のご相談を頂いている状況です。

皆様に置かれましても、もしご課題やお悩みごとがございましたら、まずはお問い合わせフォームからご相談ください。