要件分析におけるシステムエンジニアリングの観点[ 1 ]

システム工学とソフトウェア工学において、要件分析は、様々な利害関係者の矛盾する可能性のある要件を考慮し、ソフトウェアまたはシステムの要件を分析、文書化、検証、管理しながら、新規または変更された製品やプロジェクトを満たすニーズや条件を決定するタスクに焦点を当てています。[2]

要件分析は、システムやソフトウェアプロジェクトの成否を左右する重要な要素です。[3]要件は文書化され、実行可能で、測定可能で、テスト可能で、[4]追跡可能で、[4]特定されたビジネスニーズや機会に関連し、システム設計に十分な詳細レベルで定義されている必要があります。

概要

概念的には、要件分析には3種類の活動が含まれます。[引用が必要]

  • 要件の抽出：（例：プロジェクト憲章または定義）、ビジネスプロセスのドキュメント化、ステークホルダーへのインタビュー。これは、要件収集または要件発見と呼ばれることもあります。
  • 要件の記録: 要件はさまざまな形式で文書化されることがあります。通常は概要リストが含まれ、自然言語ドキュメント、ユースケース、ユーザーストーリー、プロセス仕様、データモデルなどのさまざまなモデルが含まれる場合があります。
  • 要件分析：明示された要件が明確、完全、重複なし、簡潔、妥当、一貫性があり、曖昧さがないかどうかを判断し、明らかな矛盾があれば解決します。分析には、要件の規模設定も含まれる場合があります。

要件分析は、多くの繊細な心理的スキルが関わる、長く骨の折れるプロセスになりかねません。新しいシステムは環境や人々の関係性を変えるため、すべての利害関係者を特定し、彼らのニーズをすべて考慮し、新しいシステムの影響を彼らが理解していることを確認することが重要です。アナリストは、顧客から要件を引き出すために、いくつかの手法を活用できます。これには、シナリオの開発（アジャイル手法ではユーザーストーリーとして表現されます）、ユースケースの特定、職場観察やエスノグラフィーの活用、インタビューやフォーカスグループ（この文脈では、要件ワークショップまたは要件レビューセッションと呼ぶ方が適切です）、要件リストの作成などが含まれます。プロトタイピングは、利害関係者にデモンストレーションできるサンプルシステムを開発するために用いられる場合があります。必要に応じて、アナリストはこれらの手法を組み合わせて利害関係者の正確な要件を確立し、ビジネスニーズを満たすシステムを構築します。[5] [6]要件の品質は、これらの手法やその他の手法によって向上させることができます。

  • 視覚化。視覚化やシミュレーションなど、望ましい最終製品の理解を深めるツールを使用します。
  • テンプレートの一貫した使用。要件を文書化するために、一貫したモデルとテンプレートのセットを作成します。
  • 依存関係の文書化。要件間の依存関係と相互関係、および前提条件と集合を文書化します。

要件分析のトピック

ステークホルダーの特定

システムに正当な利害関係を持つ個人または組織（企業などの法人や標準化団体）については、 「ステークホルダー分析」を参照してください。これらの個人または組織は、システムから直接的または間接的に影響を受ける可能性があります。

1990年代に新たに重視されたのは、ステークホルダーの特定でした。ステークホルダーはアナリストを雇用する組織に限定されないことがますます認識されるようになりました。その他のステークホルダーには、以下のようなものがあります。

  • システムを操作する人（通常オペレーターと保守オペレーター）
  • システムから利益を得る人（機能的、政治的、経済的、社会的受益者）
  • システムの購入または調達に関わるすべての人。マスマーケット向け製品を扱う組織では、製品管理、マーケティング、そして時には営業が代理消費者（マスマーケットの顧客）として機能し、製品開発を導きます。
  • システムの側面を規制する組織（金融、安全、その他の規制当局）
  • システムに反対する人々または組織（否定的な利害関係者。誤用事例も参照）
  • 設計中のシステムとインターフェースするシステムを担当する組織。
  • アナリストがシステムを設計している組織と水平に統合される組織。

共同要件開発（JRD）セッション

要件は、個々のステークホルダーには認識されていない機能横断的な影響を持つことが多く、ステークホルダーへのインタビューでは見落とされたり、不完全に定義されたりすることがよくあります。こうした機能横断的な影響は、訓練を受けたファシリテーター（ビジネスアナリスト）がファシリテートする、管理された環境でJRDセッションを実施することで明らかにすることができます。このセッションでは、ステークホルダーが議論に参加し、要件を引き出し、その詳細を分析し、機能横断的な影響を明らかにします。議論を記録する専任の記録係を配置することで、ビジネスアナリストはセッションの目的を満たす適切な要件を生み出す方向に議論を導くことができます。

JRDセッションは、共同アプリケーション設計セッションに類似しています。前者では設計を導く要件を抽出しますが、後者では抽出された要件を満たすために実装される具体的な設計機能を抽出します。

契約形式の要件リスト

要件を文書化する従来の方法の一つは、契約書形式の要件リストです。複雑なシステムでは、このような要件リストは数百ページに及ぶこともあります。

適切な比喩としては、非常に長い買い物リストが挙げられるでしょう。このようなリストは、現代の分析においては非常に不評です。なぜなら、その目的を達成する上で見事に失敗することが証明されているからです[要出典]。しかし、今日でも依然として見かけられます。

強み

  • 要件のチェックリストを提供します。
  • プロジェクトスポンサーと開発者間の契約書を提供します。
  • 大規模システムの場合、高レベルの説明を提供して、そこから低レベルの要件を導き出すことができます。

弱点

  • このようなリストは数百ページに及ぶこともあります。これらは、希望するアプリケーションについて読者に分かりやすく説明することを意図したものではありません。
  • このような要件リストはすべての要件を抽象化しているため、コンテキストがほとんどありません。ビジネスアナリストは、付随する設計ドキュメントに要件のコンテキストを含める場合があります。
    • この抽象化は、要件がどのように適合するか、または連携して動作するかを説明することを意図したものではありません。
    • リストは要件間の関係性や依存関係を反映していない可能性があります。リストを使用すると各項目の優先順位付けが容易になりますが、文脈から外れた項目を1つ削除すると、ユースケース全体やビジネス要件が役に立たなくなる可能性があります。
    • このリストは、望ましいシステム/アプリケーションの設計への影響について理解を深めるために、関係者と要件を慎重に検討する必要性をなくすものではありません。
  • リストを作成しただけでは、その完全性は保証されません。ビジネスアナリストは、実質的に包括的なリストを発見・収集するために誠意を持って努力し、不足している要件については関係者に指摘を求める必要があります。
  • これらのリストにより、利害関係者と開発者の間で誤った相互理解が生じる可能性があります。ビジネスアナリストは翻訳プロセスに不可欠です。
  • 開発とテストのプロセスが始まる前に、すべての機能要件を明らかにすることはほぼ不可能です。これらのリストを不変の契約として扱うと、開発プロセスで発生する要件によって、議論の余地のある変更要求が発生する可能性があります。

要件リストの代替

アジャイル ソフトウェア開発では、要件リストの代わりに、ユーザー ストーリーを使用して日常的な言語で要件を提案します。

測定可能な目標

ベストプラクティスでは、要件リストを単なる手がかりとして捉え、「なぜ？」と繰り返し問いかけ、真のビジネス目的が明らかになるまで続けます。ステークホルダーと開発者は、各目標がどの程度達成されたかを測定するためのテストを考案できます。こうした目標は、具体的だが測定されていない要件の長いリストよりも変化が緩やかです。重要な目標を少数設定し、測定可能な目標を設定すれば、迅速なプロトタイピングと短期の反復開発フェーズに移行することで、プロジェクトが半分も完了しないうちに、ステークホルダーにとっての実際の価値を実現できる可能性があります。

プロトタイプ

プロトタイプとは、別のコンピュータプログラムの特性の一部を示すコンピュータプログラムであり、ユーザーがまだ構築されていないアプリケーションを視覚化できるようにします。プロトタイプの一般的な形式はモックアップで、将来のユーザーやその他の関係者がシステムの外観を把握するのに役立ちます。プロトタイプを使用すると、アプリケーションを構築する前にアプリケーションのさまざまな側面を確認し、共有できるため、設計上の決定が容易になります。プロトタイプの導入により、ユーザーと開発者間のコミュニケーションが大幅に改善されることがよく見られました。アプリケーションの早期の外観は、後からの変更を減らし、全体的なコストを大幅に削減することにつながりました。[要出典]

プロトタイプは、平面的な図（ワイヤーフレームと呼ばれることが多い）の場合もあれば、統合された機能を備えた実際のアプリケーションである場合もあります。ワイヤーフレームは様々なグラフィックデザイン文書で作成され、最終的なソフトウェアにグラフィックデザインが適用される場合、デザインからすべての色を削除する（つまり、グレースケールのカラーパレットを使用する）ことがよくあります。これにより、プロトタイプがアプリケーションの最終的な外観と操作性を反映しているかどうかの混乱を防ぐことができます。[要出典]

ユースケース

ユースケースとは、システムの機能要件を文書化するための構造であり、通常はソフトウェア（新規または変更対象）が含まれます。各ユースケースは、特定のビジネス目標を達成するために、システムが人間のユーザーまたは他のシステムとどのように相互作用すべきかを示す一連のシナリオを提供します。ユースケースでは通常、専門用語は避け、エンドユーザーまたはドメイン専門家の言語が優先されます。ユースケースは、要件エンジニアと利害関係者が共同で作成することがよくあります。

ユースケースは、ソフトウェアやシステムの動作を記述するための、一見シンプルなツールです。ユースケースには、ユーザーがソフトウェアやシステムをどのように操作することが想定されているかをテキストで記述します。ユースケースでは、システムの内部動作や実装方法を説明するべきではありません。ユースケースは、特定の手順を前提とすることなく、タスクを実行するために必要な手順を示します。

要件仕様

要件仕様とは、現状のビジネス ニーズに関する発見事項とそれらのニーズに対する評価を統合し、焦点を当てているソリューション スコープ内でニーズを満たすために必要なものを決定および指定することです。発見、分析、および仕様指定により、理解は現状から将来のあるべき状態へと広がります。要件仕様指定では、実現すべき将来の状態の全範囲と深さを網羅することも、優先的に修正すべきソフトウェア システムのバグや実施すべき機能強化など、埋めるべき特定のギャップを対象にすることもできます。大規模なビジネス プロセスではほぼ常にソフトウェア、データ システム、テクノロジが採用されているため、要件仕様指定はソフトウェア システムの構築、購入、クラウド コンピューティング戦略、製品またはデバイスに組み込まれたソフトウェア、その他のテクノロジと関連付けられることがよくあります。要件仕様のより広義の定義では、トレーニング、ドキュメント ガイド、人員、マーケティング戦略、機器、サプライなど、あらゆるソリューション戦略またはコンポーネントが含まれるか、それらに焦点を当てています。

要件の種類

要件はいくつかの方法で分類されます。以下は、技術管理に関連する要件の一般的な分類です。[1]

ビジネス要件

詳細な機能には言及せず、ビジネスレベルの目標を記述したもの。通常、ビジネス成果を達成するために必要な高レベル（ソフトウェアおよび／またはハードウェア）の機能を指します。

顧客の要件

システムの期待事項を、ミッション目標、環境、制約、有効性・適合性（MOE/MOS）の観点から定義する事実と仮定の記述。顧客とは、システムエンジニアリングの8つの主要機能を実行する者であり、特に主要顧客である運用事業者に重点を置く。運用要件は、基本的なニーズを定義し、少なくとも以下のリストに挙げられる質問に答えるものである。[1]

  • 運用の配布または展開: システムはどこで使用されますか?
  • ミッション プロファイルまたはシナリオ: システムはどのようにしてミッションの目的を達成するのでしょうか?
  • パフォーマンスと関連パラメータ: ミッションを達成するために重要なシステムパラメータは何ですか?
  • 利用環境: 各システムコンポーネントはどのように使用されるか?
  • 有効性要件: システムはそのミッションを遂行する際にどの程度効果的または効率的である必要がありますか?
  • 運用ライフサイクル: ユーザーはどのくらいの期間システムを使用するのでしょうか?
  • 環境: システムが効果的に動作することが期待される環境は何ですか?

アーキテクチャ要件

アーキテクチャ要件は、システムの必要なシステム アーキテクチャを特定することによって、何を実行する必要があるかを説明します。

行動要件

動作要件は、システムの 必要な動作を特定することによって、何を実行する必要があるかを説明します。

機能要件

機能要件は、達成すべき必要なタスク、アクション、またはアクティビティを特定することで、何を行う必要があるかを説明します。機能要件分析は、機能分析の最上位機能として使用されます。[1]

非機能要件

非機能要件とは、特定の動作ではなく、システムの動作を判断するために使用できる基準を指定する要件です。

パフォーマンス要件

ミッションまたは機能の実行範囲は、通常、量、品質、範囲、適時性、または準備状況によって測定されます。要件分析では、システムライフサイクル要因に基づいて、特定されたすべての機能にわたってパフォーマンス要件（どの程度の精度で実行する必要があるか）が対話的に作成され、見積りの確実性、システムの成功に対する重要度、および他の要件との関係に基づいて特徴付けられます。[1]

設計要件

製品の「構築」、「コーディング」、「購入」要件とプロセスの「実行方法」要件は、技術データパッケージと技術マニュアルで表現されます。[1]

派生要件

上位レベルの要件から暗黙的に、または変換された要件。例えば、長距離または高速の要件は、軽量化という設計要件につながる可能性がある。[1]

割り当てられた要件

要件は、高レベルの要件を複数の低レベルの要件に分割または割り当てることによって確立されます。例：2つのサブシステムで構成される100ポンドのアイテムの場合、2つの低レベルのアイテムの重量要件はそれぞれ70ポンドと30ポンドになる可能性があります。[1]

よく知られている要件分類モデルとしては、 Hewlett-Packardで開発されたFURPSと FURPS+ があります。

要件分析の問題

ステークホルダーの問題

Steve McConnell は、著書『Rapid Development』の中で、ユーザーが要件収集を阻害するさまざまな方法について詳しく説明しています。

  • ユーザーが何を望んでいるのか理解していない、またはユーザーが自分の要件を明確に把握していない
  • ユーザーは書面による要件のセットにコミットしない
  • コストとスケジュールが決まった後でも、ユーザーは新たな要件を要求する
  • ユーザーとのコミュニケーションが遅い
  • ユーザーはレビューに参加しない、または参加できないことが多い
  • ユーザーは技術的に未熟である
  • ユーザーは開発プロセスを理解していない
  • ユーザーは現在の技術について知らない

これにより、システムや製品の開発を開始した後でも、ユーザーの要件が変化し続けるという状況が発生する可能性があります。

エンジニア/開発者の問題

要件分析中にエンジニアや開発者が引き起こす可能性のある問題は次のとおりです。

  • コードを書くことへの自然な傾向により、要件分析が完了する前に実装が開始され、実際の要件が判明した時点でそれを満たすためにコードが変更される可能性があります。
  • 技術者とエンドユーザーの語彙は異なる場合があります。そのため、完成品が納品されるまでは、両者は完全に一致していると誤解してしまう可能性があります。
  • エンジニアや開発者は、クライアントのニーズに特化したシステムを開発するのではなく、要件を既存のシステムやモデルに適合させようとする場合があります。

試みられた解決策

コミュニケーションの問題に対する解決策の 1 つは、ビジネスまたはシステム分析の専門家を雇うことです。

プロトタイピング、統一モデリング言語(UML)、ユースケース、アジャイル ソフトウェア開発など、1990 年代に導入された手法も、従来の方法で発生した問題の解決策として意図されています。

また、新しいタイプのアプリケーションシミュレーションツールやアプリケーション定義ツールも市場に登場しています。これらのツールは、ビジネスユーザーとIT組織間のコミュニケーションギャップを埋めるだけでなく、コードを作成する前にアプリケーションの「テストマーケティング」を可能にするように設計されています。これらのツールの中でも特に優れたツールは、以下の機能を備えています。

  • アプリケーションフローをスケッチし、代替案をテストするための電子ホワイトボード
  • ビジネスロジックとデータニーズを把握する能力
  • 最終的なアプリケーションを忠実に模倣した高忠実度のプロトタイプを生成する能力
  • インタラクティブ性
  • コンテキスト要件やその他のコメントを追加する機能
  • リモートおよび分散ユーザーがシミュレーションを実行し、対話する機能

参照

参考文献

  1. ^ abcdefgh システムエンジニアリングの基礎 Archived 2011-07-22 at the Wayback Machine Defense Acquisition University Press, 2001
  2. ^ コトニャ、ジェラルド、サマービル、イアン (1998). 『要件エンジニアリング：プロセスとテクニック』 チチェスター、イギリス: ジョン・ワイリー・アンド・サンズ. ISBN 9780471972082。
  3. ^ Alain Abran、James W. Moore、Pierre Bourque、Robert Dupuis編（2005年3月）。「第2章 ソフトウェア要件」。ソフトウェアエンジニアリング知識体系ガイド（2004年版）。カリフォルニア州ロサンゼルス：IEEE Computer Society Press。ISBN 0-7695-2330-7. 2009年3月23日にオリジナルからアーカイブ。2007年2月8日に閲覧。ソフトウェアエンジニアリングプロジェクトは、これらの活動が適切に行われないと、非常に脆弱になることがソフトウェア業界では広く認識されています。
  4. ^ ab Project Management Institute 2015、p. 158、§6.3.2。
  5. ^ Amin, Tauqeer ul; Shahzad, Basit (2024-09-01). 「顧客エンゲージメントの低下を伴う大規模ソフトウェアプロジェクトにおける要件抽出の改善：費用対効果の高いモデルの提案」 . Requirements Engineering . 29 (3): 403– 418. doi :10.1007/s00766-024-00425-2. ISSN  1432-010X.
  6. ^ Pacheco, Carla; García, Ivan; Reyes, Miryam (2018年8月). 「要件抽出技術：技術の成熟度に基づく体系的な文献レビュー」 . IET Software . 12 (4): 365– 378. doi :10.1049/iet-sen.2017.0144. ISSN  1751-8806.

[1]

参考文献

  • ブライアン・ベレンバッハ、ダニエル・ポーリッシュ、ユルゲン・カッツマイヤー、アーノルド・ルドルファー（2009年）『ソフトウェア＆システム要件エンジニアリング：実践編』ニューヨーク：McGraw-Hill Professional. ISBN 978-0-07-160547-2。
  • Hay, David C. (2003). 『要件分析：ビジネス視点からアーキテクチャへ』（第1版）. Upper Saddle River, NJ: Prentice Hall. ISBN 0-13-028228-6。
  • ラプランテ、フィル（2009年）『ソフトウェアとシステムのための要件工学』（第1版）ワシントン州レドモンド：CRC Press. ISBN 978-1-4200-6467-4. 2014年10月22日時点のオリジナルよりアーカイブ。2011年10月14日閲覧。
  • プロジェクトマネジメント協会 (2015年1月1日). 『実務家のためのビジネス分析』 . プロジェクトマネジメント協会. ISBN 978-1-62825-069-5。
  • マコーネル、スティーブ（1996年）『ラピッド・デベロップメント：ワイルドなソフトウェアスケジュール管理』（第1版）ワシントン州レドモンド：マイクロソフト・プレスISBN 1-55615-900-5。
  • Nuseibeh, B.; Easterbrook, S. (2000). 要件エンジニアリング：ロードマップ(PDF) . ICSE '00.ソフトウェアエンジニアリングの将来に関する会議議事録. pp.  35– 46. CiteSeerX  10.1.1.131.3116 . doi :10.1145/336512.336523. ISBN 1-58113-253-0. 2015年11月6日にオリジナル（PDF）からアーカイブ。2015年8月28日閲覧。
  • アンドリュー・ステルマン＆ジェニファー・グリーン（2005年）『応用ソフトウェアプロジェクトマネジメント』ケンブリッジ、マサチューセッツ州：オライリーメディア、ISBN 0-596-00948-8。
  • Karl Wiegers & Joy Beatty (2013). ソフトウェア要件（第3版）. Redmond, WA: Microsoft Press. ISBN 978-0-7356-7966-5。
ウィキメディア コモンズには、要件分析に関連するメディアがあります。
  • 要件工学と分析に関する査読済み百科事典のエントリ
  • 国防調達大学のステークホルダー要件定義プロセス---ウェイバックマシンのステークホルダー要件定義プロセス（2015年12月23日アーカイブ）
  • MIL-HDBK 520 システム要件ドキュメントガイダンス
  1. ^ Anderson, Charlotte (2022年6月8日). 「ステークホルダーの特定と分析が必要な理由 | Acorn」. Acorn PLMS . 2024年1月19日閲覧。