要件分析

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

要件分析に関するシステムエンジニアリングの視点。[1]

システムエンジニアリングおよびソフトウェアエンジニアリングでは、要件分析は、さまざまな利害関係者の競合する可能性のある要件を考慮して、ソフトウェアまたはソフトウェア分析、文書化、検証、および管理を考慮して、新しいまたは変更された製品またはプロジェクトを満たすためのニーズまたは条件を決定するタスクに焦点を当てます。システム要求。[2]

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

概要

概念的には、要件分析には3つのタイプのアクティビティが含まれます。[要出典]

  • 要件の引き出し:(プロジェクト憲章や定義など)、ビジネスプロセスの文書化、および利害関係者へのインタビュー。これは、要件収集または要件検出とも呼ばれます。
  • 要件の記録:要件は、通常は要約リストを含むさまざまな形式で文書化でき、自然言語のドキュメント、ユースケースユーザーストーリー、プロセス仕様、およびデータモデルを含むさまざまなモデルが含まれる場合があります。
  • 要件の分析:記載されている要件が明確、完全、重複していない、簡潔、有効、一貫性があり、明確であるかどうかを判断し、明らかな矛盾を解決します。分析には、サイジング要件も含まれる場合があります。

要件分析は、多くの繊細な心理的スキルが関与する、長くて骨の折れるプロセスになる可能性があります。新しいシステムは環境と人々の間の関係を変えるので、すべての利害関係者を特定し、すべてのニーズを考慮に入れ、新しいシステムの意味を確実に理解することが重要です。アナリストは、顧客から要件を引き出すためにいくつかの手法を採用できます。これらには、シナリオの開発(アジャイル手法ではユーザーストーリーとして表される)、ユースケースの特定、職場の観察または民族誌の使用、インタビューの開催、またはフォーカスグループが含まれる場合があります。(このコンテキストでは、要件ワークショップまたは要件レビューセッションとしてより適切に名前が付けられます)および要件リストの作成。プロトタイピングを使用して、利害関係者にデモンストレーションできるシステムの例を開発できます。アナリストは、必要に応じて、これらの方法を組み合わせて、利害関係者の正確な要件を確立し、ビジネスニーズを満たすシステムを作成します。[要出典] これらの方法やその他の方法で要件の品質を向上させることができます

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

要件分析のトピック

利害関係者の識別

システムに有効な関心を持っている人や組織(企業、標準化団体などの法人)の議論については、利害関係者の分析を参照してください。彼らはそれによって直接的または間接的に影響を受ける可能性があります。1990年代の主な新たな重点は、利害関係者の特定に焦点を当てることでした。利害関係者は、アナリストを雇用している組織に限定されないことがますます認識されています。その他の利害関係者は次のとおりです。

  • システムを操作する人(通常および保守オペレーター)
  • システムの恩恵を受ける人(機能的、政治的、経済的、社会的受益者)
  • システムの購入または調達に関与する人。マスマーケットの製品組織では、製品の管理、マーケティング、場合によっては販売が代理消費者(マスマーケットの顧客)として機能し、製品の開発をガイドします。
  • システムの側面を規制する組織(財務、安全、およびその他の規制当局)
  • システムに反対する人々または組織(否定的な利害関係者。誤用の事例も参照)
  • 設計中のシステムとインターフェースするシステムを担当する組織。
  • アナリストがシステムを設計している組織と水平方向に統合している組織。

共同要件開発(JRD)セッション

要件には、多くの場合、個々の利害関係者には不明であり、利害関係者のインタビュー中に見落とされたり、不完全に定義されたりする、部門間の影響があります。これらの部門の枠を超えた影響は、訓練を受けたファシリテーター(ビジネスアナリスト)が促進する管理された環境でJRDセッションを実施することで引き出すことができます。この場合、利害関係者は、要件を引き出し、詳細を分析し、部門の枠を超えた影響を明らかにするためのディスカッションに参加します。専任の筆記者がディスカッションを文書化するために立ち会う必要があります。これにより、ビジネスアナリストは、セッションの目的を満たす適切な要件を生成する方向にディスカッションを主導できるようになります。

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

契約スタイルの要件リスト

要件を文書化する従来の方法の1つは、契約スタイルの要件リストです。複雑なシステムでは、このような要件リストは数百ページの長さになります。

適切な比喩は、非常に長い買い物リストです。このようなリストは、現代の分析では非常に好まれていません。彼らは彼らの目的を達成するのに見事に失敗したことが証明されたので[要出典] ; しかし、彼らは今でも見られています。

強み

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

弱点

  • このようなリストは、数百ページに及ぶ可能性があります。これらは、目的のアプリケーションの読みやすい説明として機能することを目的としたものではありません。
  • このような要件リストはすべての要件を抽象化しているため、コンテキストはほとんどありません。ビジネスアナリストは、付随する設計ドキュメントに要件のコンテキストを含めることができます。
    • この抽象化は、要件がどのように適合または連携するかを説明することを目的としたものではありません。
    • このリストには、要件間の関係や依存関係が反映されていない場合があります。リストを使用すると、個々のアイテムに優先順位を付けるのは簡単ですが、コンテキストから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. ^ a b c d e f g h Systems Engineering Fundamentals Archived 2011-07-22 at the Wayback Machine Defense Acquisition University Press、2001
  2. ^ コトーニャ、ジェラルド; イアン・サマービル(1998)。要件エンジニアリング:プロセスとテクニック英国チチェスター:ジョン・ワイリーとサンズ。ISBN 9780471972082
  3. ^ アランアブラン; ジェームズW.ムーア; ピエール・ボーク; ロバート・デュプイ編 (2005年3月)。「第2章:ソフトウェア要件」ソフトウェア工学知識体系へのガイド(2004年版)。カリフォルニア州ロスアラミトス:IEEE Computer Society Press ISBN 0-7695-2330-72007年2月8日取得これらの活動が不十分に実行されると、ソフトウェアエンジニアリングプロジェクトは非常に脆弱であることがソフトウェア業界内で広く認識されています。

参考文献

外部リンク