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

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

ソフトウェア開発は、作業するソフ

ソフトウェア製品は顧客の要求によって造られます。 時には、この製品は完全に顧客/エンドユーザーが期待していたものに準拠していないが、主に、このソフトウェア製品は、エンド顧客/ユーザーが期待していたも

要件分析とは何ですか？

私たちは例の助けを借りて、要件分析を理解してみましょう。

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

顧客/エンドユーザーの受信:

顧客/エンドユーザーは、上記の画像から分析できるように、最終製品に顧客の期待との不一致があることを受け取ります。 これは、無数の理由、すなわちによるものである可能性があります。 顧客の要求の不正確な実施、不良な設計、プログラマーおよび質のチームによる顧客の要求の間違った理解、等。

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

良い製品を提供するには、前提条件として、正しい要件の収集、収集された要件の効率的な検査、そして最終的に要件文書を明確にする必要があります。 このプロセス全体は、ソフトウェア開発ライフサイクル（SDLC）における要件分析とも呼ばれます)

要件分析ステージ/ステップ

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

このチュートリアルでは、SDLCで要件分析を行う方法を説明します。 また、要件分析に関連するさまざまなステップ、結果、課題、および是正措置も表示されます。

要件分析は以下から始まります:

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

#1) 要件の収集

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

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

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

例:組織では、別のサプライヤーから受け取ったAutosarスタックとブートローダバイナリを必要とするADAS製品(有名なOEM用サラウンドビューカメラシステム)を開発しています。

要件収集段階で様々な利害関係者を巻き込むことは、相互の様々な依存関係を理解するのに役立ち、将来の競合を回避することができます。

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

この試作品の作成は、二つのタイプの製品に依存します:

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

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

例えば、OEM（GM、Volkswagen、BMWなど）用に開発されたサラウンドビューカメラシステム。）そして別のOEMに展示することができます。

製品/proto製品を開発中のお客様に提示することは、その製品が開発されている他のお客様と締結された秘密保持契約に違反する可能性があるため、賢明ではないことに注意してください。 それはまた不必要な法的争いで起因するかもしれません。

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

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

(ii)第二のケースは、単純なコーディングとアセンブリを行うことによって基本的な作業モデルを作成することによって達成することができます(ここでは主に機能はソフトウェアプログラムでハードコーディングされています)、または製品がどのように見えるかを顧客に納得させることができるフローチャートや図を作成することによって達成することができます。

いずれにしても、顧客が何を望んでいるかを知っているので、要件収集プロセスの息抜きになります。

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

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

要件収集例:ADASサラウンドビューカメラシステムでは、”ユーザーとして、車の後ろにあるものを見ることができるはずです”というユーザーストーリーが考えられます。

各ユーザーストーリーについて多くの”理由”の質問がある可能性があり、顧客が要件に関するより詳細な情報を提供するのに役立ちます。

上記のユーザーストーリーでは、顧客が”ユーザーとして、私は私の車の後ろに何があるのかを見ることができるはずです”と言って、”なぜ””ユーザーとして、私は私の車の後ろに何があるのかを見ることができるはずです”という質問をすると、私は私の車を安全に駐車できるようになります。

“なぜ”という質問をすることは、顧客から与えられた巨大な自然言語文から客観的かつ原子的な要件を作成するのにも役立ちます。 これは、コードの後半で簡単に実装できます。

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

:

#2) 収集された要件の分析

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

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

(i)お客様は、さまざまな依存関係のために実装できないいくつかの要件

例:お客様は、車を駐車するのに役立つバックビューカメラ機能を備えたカメラシステムをサラウンドビューするように求めることができます。 顧客はまた働くのにまた後部カメラを使用するトレーラーの連結器の特徴を頼むかもしれません。

顧客が駐車支援のためのバックビューカメラが例外なく常に動作する必要があるという要件を述べている場合、トレーラー機能は決して機能せず、その逆も同様です。

(ii)ビジネスアナリストは、プログラマがどのように解釈したかとは異なる顧客からの要件を理解している可能性があります。

プログラマは技術専門家として考えているので、顧客の要求が誤って機能仕様に変換され、後でアーキテクチャや設計文書に誤って作成され、その後コー 影響は指数関数的であるため、チェックする必要があります。

可能な是正措置は、ソフトウェア開発のアジャイルな方法、顧客が提供するユースケースなどに従うことによって可能性があります。

#3)分析された要件の文書化

要件の分析が完了すると、要件の文書化が開始されます。 要件の分析からは、さまざまな種類の要件が出てきます。

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

(i)顧客の要求の指定。

(ii)ソフトウェアアーキテクチャ要件。

:

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

:

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

例:”インフォテインメントHMIのBluetoothアイコンをタップすると、Bluetooth画面が表示されるはずです”

(v)非機能要件仕様(viz. 性能、圧力、負荷、等。).

例：”システム性能を低下させることなく、15台のBluetoothデバイスとインフォテインメントシステムをペアリングすることが可能である必要があります”。

(vi)ユーザーインターフェースの要件。

: “チューナー FM画面で、異なるステーションを選択するためのボタンを提供する必要があります”

上記の要件は、IBM DOORS、HP QCなどの要件管理ツールに記録され、文書化 時には、組織は、コストを削減するために、カスタムメイドの要件管理ツールを持っています。

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

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

ビジネス要件は、上記で説明したように、エンドユーザーがソフトウェアシステム上で定義されたアクショ これらの要件に基づいてソフトウェアシステム全体を開発することは、ソフトウェアシステムまたはコンポーネントがどのように実装されるかの詳細な説明が言及されていないため不可能である。

したがって、ビジネス要件は、より詳細なソフトウェア要件に分解されなければならず、機能要件および非機能要件にさらに詳細に説明されます。

これを行うには、次の手順に従います:

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

まず、自動車用インフォテインメントシステムの例を見てみましょう。

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

だから、上記の手順は、次のように実装することができます:

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

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

まず、このユーザーストーリーに可能な質問をすることから始めましょう。

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

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

この時点で、ユーザーのサブストーリーの一つを取り上げて質問を開始することができます。 私たちは（いいえ）を取るようにしましょう. 3):

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

#2) 活動の流れを定義するためのフローチャートを導出する。

これで、ビジネス要件が非常に詳細なユースケースに分類されていることがわかります。:

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

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

• 宛先エントリを表示するための画面の読み込み時間は1秒でなければなりません。
• 宛先エントリのキーボードには、英数字と特殊記号が必要です。
• GPS有効/無効トグルボタンは、ナビゲーション先の入力画面に存在する必要があります。

上記の情報は、ユーザーストーリーを満足させ、要件を離散的かつ測定可能にテストすることを可能にし、機能として実装されながら要件との混乱を避け

#4)オブジェクトのワークフローを説明するためのワイヤフレームダイアグラム。

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

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

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

しかし、機能要件は、システムの性能や可用性、信頼性などの他の定性的パラメータを明確にするものではありません。

例:

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

車のドライバー（エンドユーザー）がUSBから音楽を再生し、ナビゲーションガイダンスが進行中の場合、ハンズフリーモードでBluetooth経由で着信を取得し、複数のプロセ

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

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

例えば、インフォテインメントシステムは、接続されたBluetooth電話を介してバックツーバックSms(多分20SMS以内10秒)を受信します。 インフォテインメントシステムは、すべての着信SMSを処理することができるはずであり、いかなる時点でインフォテインメントHMI上の着信SMS通知のい

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

非機能要件の理解ケース

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

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

だから、これは私たちがビジネス要件からソフトウェア要件を導出する方法です。

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

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

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

結論

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

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

組織は、根本原因分析、5つの理由文書の準備、障害ツリー分析、8D文書などの損傷制御タスクを実行することになります。 ソフトウェア開発と品質に集中するのではなく。

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