Loading article…
要件工学において、要件抽出とは、ユーザー、顧客、その他の利害関係者からシステムの要件を調査して発見する実践です。[1]この実践は、「要件収集」と呼ばれることもあります。
要件抽出という用語は、要件収集という名前が示すように、優れた要件は顧客から収集するだけでは得られないという事実を指摘するために、書籍や研究で使用されています。要件抽出は簡単ではありません。なぜなら、システムが何をすべきか、何をすべきでないかを尋ねるだけでは、ユーザーと顧客からすべての要件を確実に得ることはできないからです (安全性と信頼性について)。要件抽出の実践には、インタビュー、アンケート、ユーザー観察、ワークショップ、ブレーンストーミング、ユースケース、ロールプレイング、プロトタイピングなどがあります。
要件を分析、モデル化、または指定する前に、要件を抽出プロセスを通じて収集する必要があります。要件抽出は要件エンジニアリング プロセスの一部であり、通常は要件の分析と指定が続きます。
一般的に使用される引き出しプロセスは、利害関係者との会議またはインタビューです。[2]たとえば、重要な最初の会議は、ソフトウェアエンジニアと顧客の間で要件に対する見解を話し合う場です。
要件抽出プロセスは、顧客、ユーザー、その他の関係者に、システムまたは製品の目的は何か、何を達成するのか、システムまたは製品がビジネス ニーズにどのように適合するのか、そして最後に、システムまたは製品を日常的にどのように使用するのかを尋ねるという、単純に見えるかもしれません。ただし、プロセスを複雑にする問題が発生する場合があります。
1992年にクリステルとカンは要件抽出の課題を示す問題を特定した。[3]
- 「範囲の問題」。システムの境界が明確に定義されていないか、顧客/ユーザーが不必要な技術的詳細を指定しているため、システム全体の目的が明確になるどころか、混乱を招く可能性があります。
- 理解の問題。顧客/ユーザーは、何が必要かを完全に把握しておらず、コンピューティング環境の機能と制限を十分に理解しておらず、問題領域を完全に理解しておらず、システムエンジニアにニーズを伝えるのに苦労しており、「明らか」であると思われる情報を省略し、他の顧客/ユーザーのニーズと矛盾する要件を指定し、または曖昧またはテスト不可能な要件を指定しています。
- 変動性の問題。要件は時間の経過とともに変化します。変化率は、要件変動性のレベルと呼ばれることもあります。
要件品質は、以下のアプローチを通じて改善することができます。[4]
- 視覚化。視覚化やシミュレーションなど、目的の最終製品の理解を深めるツールを使用します。
- 一貫した言語。自然言語で記述された要件に対してシンプルで一貫した定義を使用し、企業内で普及しているビジネス用語を使用します。
- ガイドライン。収集手法と収集する要件の種類を説明する組織のガイドラインに従います。これらのガイドラインは、プロジェクト全体で一貫して使用されます。
- テンプレートの一貫した使用。要件を文書化するために一貫したモデルとテンプレートのセットを作成します。
- 依存関係の文書化。要件間の依存関係と相互関係を文書化します。
- 変更の分析。要件の変更の根本原因分析を実行し、是正措置を講じます。
ガイドライン
1997年、ソマービルとソーヤーは、クリステルとカンが指摘したような懸念に対処するために、要件抽出のための一連のガイドラインを提案した。[5]
- 提案されたシステムのビジネスおよび技術的な実現可能性を評価する
- 要件の指定を支援し、組織の偏見を理解する人々を特定する
- システムまたは製品が配置される技術環境（コンピューティングアーキテクチャ、オペレーティングシステム、通信ニーズなど）を定義します。
- 構築するシステムまたは製品の機能やパフォーマンスを制限する「ドメイン制約」（つまり、アプリケーションドメインに固有のビジネス環境の特性）を特定します。
- 1 つ以上の要件抽出方法を定義する (例: インタビュー、フォーカス グループ、チーム ミーティング)
- 多くの人々の参加を募り、さまざまな観点から要件を定義する。記録される各要件の根拠を必ず特定する。
- 曖昧な要件をプロトタイピングの候補として特定する
- 顧客/ユーザーが主要な要件をより適切に特定できるように、使用シナリオまたはユースケースを作成します。
手順の順序
2004年にゴールドスミスは「順番に実行しなければならない6つのステップ」からなる「問題ピラミッド」を提案した。[6]
- 本当の問題、機会、課題を特定する
- 問題が現実であることを示す現在の対策を特定する
- 問題が解決されたことと、それを達成することの価値を示す目標指標を特定する
- 問題の「現状の」原因を特定します。解決しなければならないのは問題そのものではなく、原因です。
- 目標指標を達成するために実現しなければならないビジネスの「要望」を定義する
- 実際のビジネス要件を満たす製品設計を指定します
しかしゴールドスミスは、本当の問題を特定することは「極めて困難」であると指摘している。[6]
補完的なアプローチ
2008年にアレクサンダーとベウス・デュキッチは要件発見のための一連の補完的なアプローチを提案した。[7]
- ステークホルダーの特定
- モデリングの目標
- モデリングコンテキスト
- シナリオ（またはユースケース）の発見
- 「品質と制約」の発見（非機能要件）
- モデリングの根拠と仮定
- 用語の定義を書く
- 測定値の分析（受け入れ基準）
- 優先順位の分析
アレクサンダーとビュース・デュキッチは、これらのアプローチは個人（インタビューなど）、グループ（ワークショップと呼ばれる集中的な会議や電子会議システムなど）、またはプロトタイプなどの「もの」（成果物）から実行できると示唆した。[7]
非機能要件
2009年、ミラーは非機能要件を引き出すために2,000以上の質問を提案した。[8]彼女のアプローチは、利害関係者のプロファイルを作成し、それらの利害関係者に徹底的にインタビューするというものである。質問は3つのセクションにグループ化されており、すべてユーザーのニーズに焦点を当てている。[8]
- 操作: [編集が必要] はどの程度使用されていますか?
- 修正: エラーを修正したり機能を追加したりするのはどれくらい簡単ですか?
- 移行: 技術環境の変化に適応するのはどれくらい簡単ですか?
2013年、Murali Chemuturiは、「非機能的」は「決して機能しない」という意味を暗示するため、非機能要件の代わりに補助機能要件を使用することを提案しました。第二に、これらの要件は実際にはメインまたはコア機能要件をサポートするいくつかの要件を満たしています。[9]
文献
- Alexander, Ian F.; Beus-Dukic, Ljerka (2009 年 3 月)。要件の発見: 製品とサービスの仕様決定方法。John Wiley。ISBN 978-0-470-71240-5。
- ゴールドスミス、ロビン F. (2004)。ソフトウェア プロジェクトを成功させるための真のビジネス要件の発見。Artech House。ISBN 1-58053-771-5。
- Miller, Roxanne E. (2009)。ソフトウェア要件の探求: 非機能要件に焦点を当てるための詳細な質問、適切な利害関係者の関与を得るための実証済みの手法。MavenMark Books。ISBN 978-1-59598-067-0。
- サマービル、イアン、ソーヤー、ピート（1997年5月）。『要件エンジニアリング：優れた実践ガイド』。ジョン・ワイリー。ISBN 0-471-97444-7。
- Gobov, Denys, Huchenko, Inna. (2020). ウクライナの IT におけるソフトウェア プロジェクトの要件抽出手法: 探索的研究。http://dx.doi.org/10.15439/2020F16.
参照
参考文献
- ^ 要件エンジニアリング 実践ガイド、Ramos Rowel および Kurts Alfeche、John Wiley and Sons、1997 年
- ^ Kusiak, Jan. 「上司への面接方法」IRM トレーニング。
- ^ Christel, Michael および Kyo C. Kang (1992 年 9 月)。「要件抽出の問題」。技術レポート CMU/SEI-92-TR-012。CMU / SEI。2012年1 月 14 日閲覧。
- ^ 「PMI 要件 CoP 要件品質に関するウェビナー」。
- ^ サマービルとソーヤー、1997年。
- ^ ゴールドスミス、2004年、12ページ
- ^ ab Beus-Dukic, Ljerka; Alexander, Ian ( 2008). 「要件の発見方法を学ぶ」。2008要件エンジニアリング教育およびトレーニング。バルセロナ、スペイン: IEEE。pp. 12–14。doi :10.1109/REET.2008.3。
- ^ ab ミラー、2009年。
- ^ Chemuturi, M. (2013).ソフトウェア開発プロジェクトのための要件エンジニアリングと管理. doi :10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654。