SDLCの要件分析と収集とは何ですか？

what is requirement analysis

このチュートリアルでは、SDLCでの要件分析、要件分析の手順、例、および要件収集の目標について説明します。

ソフトウェア開発は、実用的なソフトウェア製品を作成するための膨大な作業です。

ソフトウェア製品は、お客様の要件に従って構築されています。ほとんどの場合、このソフトウェア製品はエンドユーザー/ユーザーの期待に準拠していますが、この製品がお客様/エンドユーザーの期待に完全に準拠していない場合もあります。

学習内容：

• 要件分析とは何ですか？
  • 要件分析の段階/ステップ
    • ＃1）要件の収集
    • ＃2）収集された要件の分析
    • ＃3）分析された要件の文書化
  • ビジネス要件のソフトウェア要件への変換
  • 非機能要件のケースを理解する
  • ビジネス要件とソフトウェア要件の違い
• 結論
  • 推奨読書

要件分析とは何ですか？

例を使用して、要件分析を理解しましょう。

顧客/エンドユーザーの期待：

顧客/エンドユーザーは以下を受け取ります：

上記の画像から分析できるように、最終製品には顧客の期待との不一致があります。これは、無数の理由による可能性があります。顧客要件の誤った実装、設計の誤り、プログラマーや品質チームによる顧客要件の誤った理解など。

ただし、ご覧のとおり、製品の配送が間違っている理由が何であれ、主な理由は要件にあります。したがって、正しい要件の理解、キャプチャ、実装、およびテストが行​​われた場合、顧客/エンドユーザーへの誤った不完全な製品配信を軽減するのに役立ちます。

優れた製品の納品には、前提条件として、正しい要件の収集、収集された要件の効率的な調査、そして最後に明確な要件の文書化が必要です。このプロセス全体は、 ソフトウェア開発ライフサイクル（SDLC）の要件分析

要件分析の段階/ステップ

ご覧のとおり、要件分析はSDLCの最初のアクティビティであり、次に機能仕様などが続きます。要件分析は、顧客による製品の受け入れに不可欠な受け入れテストと共鳴するため、SDLCの重要なステップです。

このチュートリアルでは、SDLCで要件分析がどのように行われるかを説明します。また、要件分析に関連するさまざまなステップ、結果、課題、および修正措置についても説明します。

要件分析は次のように始まります。

1. 要件の収集 これは、誘発とも呼ばれます。
2. これに続いて 分析 これらの要件を可能な製品に変換することの正確性と実現可能性を理解するために収集された要件。
3. そして最後に、 文書化 収集された要件。

＃1）要件の収集

上記のすべての手順が適切に実行されるようにするには、明確、簡潔、かつ正しい要件をお客様から収集する必要があります。顧客は要件を適切に定義でき、ビジネスアナリストは顧客が伝えようとしているのと同じ方法で要件を収集できる必要があります。

多くの場合、顧客のビジネスアナリストが要件の収集を効率的に行うことは不可能です。これは、予想される最終製品、ツール、環境などに関連する多くの人々への依存が原因である可能性があります。したがって、最終製品に影響を与える可能性のある、または影響を受ける可能性のあるすべての利害関係者を巻き込むことは常に良い考えです。

考えられる利害関係者のグループは、ソフトウェア品質エンジニア（QCとQAの両方）、プロジェクトでサポートを提供できるサードパーティベンダー、製品の対象となるエンドユーザー、ソフトウェアプログラマー、提供する可能性のある組織内の別のチームです。製品開発用のモジュールまたはソフトウェアプラットフォーム、ソフトウェアライブラリなど。

例： 組織では、彼らは必要なADAS製品（一流のOEM向けのサラウンドビューカメラシステム）を開発しています Autosarスタック そして ブートローダー 別のサプライヤから受け取ったバイナリ。

要件収集段階にさまざまな利害関係者を参加させることは、相互のさまざまな依存関係を理解するのに役立ち、将来起こりうる競合を回避することができます。

場合によっては、計画した目的の製品のプロトタイプモデルを作成し、それを顧客に示すことをお勧めします。これは、顧客が期待している製品と、後でどのように見えるかを顧客に伝えるための優れた方法です。これは、顧客が期待している製品を視覚化するのに役立ち、明確な要件を考え出すのに役立ちます。

このプロトタイプの作成は、次の2種類の製品に依存します。

1. 顧客が意図した同様の製品が組織内に存在します。
2. 開発する新製品。

（私） 最初のケースでは、最終製品がどのように見えるか、そしてそれがどのように開発されるかを顧客に示す方が簡単です。自動車ADASでは、すでに市場に出ており、組織内で開発された別の製品を顧客に示すことができます。

例えば、 OEM（GM、フォルクスワーゲン、BMWなど）向けに開発されたサラウンドビューカメラシステムで、別のOEMに展示することができます。

ご注意ください 、開発中の顧客に製品/プロト製品を提示することは賢明ではありません。その製品が開発されている別の顧客と締結した機密保持契約に違反する可能性があるためです。また、不必要な法的問題が発生する可能性もあります。

もう一つの例 組織によって開発され、すでに市場に出ているインフォテインメントシステムのものである可能性があります。組織内のビジネスアナリストやその他の利害関係者は、顧客向けのワークショップデモを計画し、具体的なHMI、デバイスコネクタポート、サンドボックスなどを備えたインフォテインメントシステムを表示できます。

これは、最終製品がどのように見えるかを顧客が理解し、要件をより明確に提供するのに役立ちます。

（ii） 2番目のケースは、単純なコーディングとアセンブリ（ここでの機能のほとんどはソフトウェアプログラムでハードコーディングされています）を実行して基本的な作業モデルを作成するか、製品の外観を顧客に納得させることができるフローチャートまたは図を作成することで実現できます。

いずれにせよ、顧客は自分が何を望んでいるのかがわかったので、要件収集プロセスの息抜きになります。

ビジネスアナリストは、正式な要件引き出し会議を開催できるようになりました。この会議では、すべての利害関係者を招待できるため、顧客から提供されたさまざまな要件を書き留めることができます（場合によっては、利害関係者の数が多い場合は、別のスクライブを任命して顧客を書き留めることができます。ビジネスアナリストが会議のモデレートに集中できるようにするための要件またはユーザーストーリー）。

収集される要件は、次の形式にすることができます。 ユーザーストーリー （アジャイル開発）、ユースケース、顧客の自然言語ドキュメント、図、フローチャートなど。ユーザーストーリーは、現代のソフトウェア開発ライフサイクルで人気が高まっています。ユーザーストーリーは基本的に、自然言語での一連の顧客入力です。

要件収集の例： ADASサラウンドビューカメラシステムで考えられるユーザーストーリーの1つは、「ユーザーとして、車の後ろ姿に何があるかを確認できるはずです」です。

多くの可能性があります 'なぜ、' 各ユーザーストーリーで尋ねられる質問。これは、顧客が要件に関するより詳細な情報を提供するのに役立ちます。

上記のユーザーストーリーで、顧客が「ユーザーとして、自分の車の後ろ姿に何があるかを確認できるはずです」と言った場合、質問をします。 'なぜ 」は、「ユーザーとして、自分の車の後ろ姿に何があるかを確認できるはずです。 車を安全に駐車できるように 」。

質問をする 'なぜ' また、顧客から提供された膨大な自然言語ステートメントから客観的で原子的な要件を作成するのにも役立ちます。これは、コードの後半で簡単に実装できます。

アルファテストとベータテストの違い

要件を収集する別の方法は、次の形式です。 ユースケース 。ユースケースは、特定の結果を達成するための段階的なアプローチです。これは、ソフトウェアがユーザー入力に対してどのように機能するかを示すものではなく、ユーザー入力に何が期待されるかを示しています。

例：

＃2）収集された要件の分析

要件の収集後、要件の分析が開始されます。この段階で、さまざまな利害関係者が座ってブレインストーミングセッションを行います。彼らは収集した要件を分析し、それらを実装するための実現可能性を探します。彼らは互いに話し合い、あいまいさは解消されます。

このステップは、次の主な理由により、要件分析プロセスで重要です。

（私） お客様は、さまざまな依存関係のために実装できない可能性のあるいくつかの要件を提供する場合があります。

例： お客様カメラシステムをバックミラーカメラ機能でサラウンドビューするように依頼する場合があります。 パーキング 車。顧客はまた、 トレーラー リアカメラも使用するヒッチ機能。

お客様がバックミラーカメラの要件を述べている場合 パーキング 支援は例外なく常に機能するはずです。 トレーラー 機能が機能することはなく、その逆も同様です。

（ii） ビジネスアナリストは、 お客様 どのように異なる プログラマー 解釈したでしょう。

プログラマーは技術の専門家と考えるため、顧客の要件が機能仕様に誤って変換され、後でアーキテクチャや設計ドキュメント、さらにはコードに誤って作成される可能性が常にあります。影響は指数関数的であるため、確認する必要があります。

考えられる改善策は、ソフトウェア開発のアジャイルな方法に従うこと、顧客が提供するユースケースに従うことなどです。

＃3）分析された要件の文書化

要件の分析が完了すると、要件の文書化が始まります。要件の分析から、さまざまなタイプの要件が生まれます。

これらのいくつかは次のとおりです。

（私） 顧客要件仕様。

（ii） ソフトウェアアーキテクチャの要件。

例：

（iii） ソフトウェア設計要件。

例：

（iv） 機能要件仕様（顧客の仕様から直接派生）。

例： 「ユーザーがインフォテインメントHMIのBluetoothアイコンをタップすると、Bluetooth画面が表示されます」

（v） 非機能要件仕様（つまり、パフォーマンス、ストレス、負荷など）。

例： 「システムパフォーマンスを低下させることなく、15台のBluetoothデバイスをインフォテインメントシステムとペアリングできるはずです」。

（私達） ユーザーインターフェイスの要件。

例： 「チューナーFM画面で、さまざまなステーションを選択するためのボタンを提供する必要があります」

上記の要件は、IBM DOORS、HPQCなどの要件管理ツールに記録および文書化されています。組織には、コストを削減するためのカスタムメイドの要件管理ツールがある場合があります。

変換のプロセスを見てみましょう ビジネス要件 に ソフトウェア要件 （機能的および非機能的）。

ビジネス要件のソフトウェア要件への変換

上で説明したように、ビジネス要件は、ソフトウェアシステムで定義されたアクションからエンドユーザーが何を望んでいるかについて説明する高レベルの要件です。ソフトウェアシステムまたはコンポーネントの実装方法の詳細な説明が記載されていないため、これらの要件に基づいてソフトウェアシステム全体を開発することはできません。

したがって、ビジネス要件は、機能要件と非機能要件にさらに詳細化される、より詳細なソフトウェア要件に分解する必要があります。

これを行うには、次の手順を実行できます。

1. 高レベルのビジネス要件を詳細なユーザーストーリーに分類します。
2. アクティビティのフローを定義するためのフローチャートを導き出します。
3. 派生したユーザーストーリーを正当化する条件を提供します。
4. オブジェクトのワークフローを説明するワイヤーフレーム図。
5. ビジネス要件から非機能要件を定義する。

自動車インフォテインメントシステムの例から始めましょう。

ビジネス要件には、「エンドユーザーはインフォテインメントシステムHMIからナビゲーションウィジェットボックスにアクセスでき、宛先アドレスを設定できる必要があります」と記載されています。

したがって、上記の手順は次のように実装できます。

＃1）高レベルのビジネス要件を詳細なユーザーストーリーに分解します。

このビジネス要件を高レベルのユーザーストーリーに変換しましょう。 ユーザーとして、宛先アドレスを入力できるように、ナビゲーションウィジェットボックスにアクセスできる必要があります 」。このユーザーストーリーは、エンドユーザーが何を必要としているかを示しています。この要件を実装する方法を定義しようとします。

このユーザーストーリーに考えられる質問をすることから始めましょう。

1. ユーザーは誰ですか？
2. ナビゲーション、オンボード（SDカードから）、またはスマートフォンからアクセスするにはどうすればよいですか？
3. どのような宛先エントリを入力できますか？
4. 車が駐車しているときでも目的地に入ることができますか？

これらは、高レベルのユーザーストーリーから派生した、より詳細なレベルのユーザーストーリーであり、ビジネス要件をより深く理解するのに役立ちます。

この時点で、ユーザーサブストーリーの1つを取り上げて、質問を開始できます。 （3番）を見てみましょう：

1. 地理座標、住所、音声認識などの宛先エントリを入力できますか？
2. 地理座標を入力するためにGPSが必要ですか？
3. アドレス履歴から検索して現在の宛先アドレスを入力できますか？

＃2）アクティビティのフローを定義するためのフローチャートを導き出します。

これで、ビジネス要件が非常に詳細なユースケースに分類され、フローチャートで次のようにマークできることがわかります。

＃3）派生したユーザーストーリーを正当化する条件を提供する。

何でjarファイルを開くか

高レベルのビジネス要件が詳細な低レベルのユーザーストーリーとフローチャートに分解されたため、より詳細な情報が出現していることがわかります。このフローチャートから、実装に必要な技術的な詳細を取得できます。

• 宛先エントリを表示するための画面読み込み時間は1秒である必要があります。
• 宛先入力キーボードには、英数字と特殊記号が必要です。
• GPSの有効化/無効化の切り替えボタンがナビゲーションの宛先入力画面に表示されている必要があります。

上記の情報はユーザーストーリーを満たし、機能として実装されている間、要件を個別に測定可能にテストして、要件との混同を回避することを可能にします。

＃4）オブジェクトのワークフローを説明するワイヤーフレーム図。

上記のユースケースから、ユーザーインターフェイスをより明確にするワイヤーフレーム図を導き出します。

＃5）ビジネス要件から非機能要件を定義する。

詳細なソフトウェア要件は高レベルのビジネス要件から導き出されることが不可欠ですが、多くの場合、特定のユーザー入力/アクションに対してシステムがどのように動作するかを示す機能要件のみが特定されます。

ただし、機能要件では、システムパフォーマンスや、可用性、信頼性などの他の定性的パラメータは明確にされていません。

例：

a）上記の自動車用インフォテインメントシステムの例を取り上げます。

車のドライバー（エンドユーザー）がUSBから音楽を再生し、ナビゲーションガイダンスが進行中の場合、ハンズフリーモードでBluetooth経由の着信もあり、複数のプロセスがあるため、CPUとRAMの消費量が最大レベルまで増加します。バックグラウンドで実行されます。

この時点で、ドライバーがインフォテインメントシステムのタッチスクリーンインターフェイスをタップして、自動返信SMSを介して着信を拒否した場合（携帯電話の場合と同じ方法）、システムはこのタスクを実行でき、ハングしたりクラッシュしたりしないはずです。これは、負荷が高い場合のシステムのパフォーマンスであり、可用性と信頼性をテストします。

b）別のケースはストレスシナリオです。

例を挙げると、インフォテインメントシステムは、接続されたBluetooth電話を介して連続したSMS（おそらく10秒以内に20 SMS）を受信します。インフォテインメントシステムは、すべての着信SMSを処理できる必要があり、インフォテインメントHMIでの着信SMS通知を見逃してはなりません。

上記の例は、機能要件だけではテストできない非機能要件のケースです。時々ですが、顧客はこれらの非機能要件の提供を見逃します。製品が顧客に配達されるときに、この情報を提供するのは組織の責任です。

非機能要件のケースを理解する

以下の表は、非機能要件を説明しています。

非機能要件は、機能要件とは異なり、プロジェクトのライフサイクル全体を要して実装されます。これは、それぞれのアジャイルスプリントまたはさまざまな反復で段階的に実装されるためです。

したがって、これがビジネス要件からソフトウェア要件を導き出す方法です。

ビジネス要件とソフトウェア要件の違い

高レベルのビジネス要件からソフトウェア要件を導き出す方法については、上記で説明しました。ソフトウェア要件により、プログラマーとテストエンジニアはシステムを開発し、効率的にテストすることができます。したがって、ビジネス要件は高レベルの顧客の自然言語要件であり、ソフトウェア要件はソフトウェアシステムの実装に役立つ詳細な低レベル要件であることがわかりました。

2つの要件タイプの詳細な違いを見てみましょう。

結論

要件分析は、SDLCモデルのバックボーンです。

要件分析中に見逃され、単体テストで検出された問題は、組織に数万ドルかかる可能性があり、コールバックとして市場から来る場合、このコストは数百万ドルにつながる可能性があります（2017年、米国のエアバッグメーカーであるタカタエアバッグの爆発による10億ドルの罰金）。

組織は、ソフトウェア開発と品質に集中するのではなく、根本原因分析、なぜなぜ分析、フォールトツリー分析、8Dドキュメントなどの損傷制御タスクを実行することになります。

最悪の場合、影響を受ける機能がセキュリティアクセス、エアバッグ、ABS（アンチロックブレーキシステム）などのセキュリティ/安全関連である場合、組織は顧客によって提起された訴訟に巻き込まれます。

推奨読書

• SDLC（ソフトウェア開発ライフサイクル）のフェーズ、方法論、プロセス、およびモデル
• 機能要件と非機能要件の特徴
• ソフトウェア要件仕様（SRS）をテストする方法は？
• 要件管理における5つの致命的な間違いとそれらを克服する方法
• 要件なしでアプリケーションをテストする方法は？
• SSDLC（安全なソフトウェア開発ライフサイクル）の対策
• スパイラルモデル-SDLCスパイラルモデルとは何ですか？
• SDLCウォーターフォールモデルとは何ですか？