ソフトウェア試験の上級システムアーキテクトのためのソフトウェア要件エンジニアリング

概要

完全なソフトウェアライフサイクルは要件から始まります。ソフトウェア要件とは、機能、動作、パフォーマンス、設計制約などの観点からシステムに対するユーザーの期待を指します。

要件開発:

要件の取得
需要分析
要件定義（要件仕様書）
要件の検証

需要管理：

変更管理
バージョン管理
要件の追跡
要件ステータスの追跡

需要開発と需要管理は相互に補完し合うものであり、需要開発が主軸であり目標であり、需要管理はサポートと保証です。

需要特性

ソフトウェア要件の基本特性: 検証可能性。

理想的には、すべてのユーザー、ビジネスニーズ、および機能要件が次の特性を持つ必要があります。

完全性: 各要件は、提供される機能を完全に説明する必要があります。
正確性: 各要件は、開発する機能を正確に記述しなければなりません
実現可能性: 要件は、システムとその動作環境の既知の機能と制約の範囲内で達成可能でなければなりません。
必要性: 要件に記録されている各機能は、ユーザーの実際のニーズである必要があります。
曖昧さがない: 各要件ステートメントは、すべての読者に対して一貫した解釈を 1 つだけ持つ必要があります。
検証可能性: 要件が検証可能でない場合、その実装が正しいかどうかの判断は主観的になります。

要件開発

要件開発プロセスには、次の 4 つの主要なアクティビティがあります。

要件取得：ユーザーと積極的にコミュニケーションをとり、対象システムに対するユーザーニーズを把握・分析・修正し、問題解決に適したユーザーニーズを抽出し、「ユーザー要求仕様書」を作成します。
要件分析: さまざまな要件情報を分析して抽象的に記述し、対象システムの概念モデルを確立することを目的とします。
要件定義：需要調査や需要分析の結果に基づいて、製品要件をさらに正確に定義し、「要件仕様書」を作成することが目標です。システム設計者は、「要求仕様書」に基づいてシステム設計作業を行います。
要件の検証: これは、開発者とユーザーが共同で要件文書をレビューし、両当事者が要件について合意に達した後に書面による約束を行い、要件文書が商業契約の効力を持つようにすることを指します。

要件の取得

要件を取得するにはさまざまな方法があります。

ユーザーインタビュー: ユーザーインタビューは要件を取得するための最も基本的な手段であり、その形式には構造化されたものと非構造化されたものがあります。ユーザーインタビューとは、ユーザーと1対1（または1対2、1対3）の形で対面でコミュニケーションをとり、ユーザーのニーズを汲み取ることです。ユーザーインタビューは柔軟性が高く、応用範囲も広いです。しかし、ユーザーが多忙で時間調整が難しい、インタビュー時の情報量が多く録音が難しい、コミュニケーションに多くのスキルが必要であり、システムアナリストにも十分な専門知識が必要であるなど、困難も多い。さらに、面接中に、会社の機密事項や機密性の高い話題に遭遇する場合もあります。したがって、この一見単純なテクノロジーには、システムアナリストの豊富な経験と強力なコミュニケーションスキルも必要です。

サンプリング: 母集団から代表的なサンプルセットを系統的に選択するプロセスを指します。選択されたサンプルセットを注意深く調査することで、母集団全体に関する有用な情報が明らかになります。情報システムの開発では、既存のシステムのドキュメント (ファイル) がサンプリング母集団となります。システムの要件分析を開始するときは、既存のシステムのドキュメントを確認することが、システムを予備的に理解するための最良の方法です。しかし、システムアナリストはどのような種類のドキュメントを参照する必要がありますか? ドキュメント内のデータが膨大な場合、サンプリング手法を使用して代表的なデータを選択する必要があります。サンプリング技術はデータ収集だけでなく、ユーザーへのインタビューやユーザーの収集・観察にも活用できます。人々をサンプリングする場合には、上で説明したのと同じサンプリング手法が適用されます。サンプリング技術により、母集団全体ではなく一部を選択することで、データ収集プロセスが高速化されるだけでなく、効率が向上し、開発コストが削減されます。サンプリング手法では、数学的統計の原理を使用して、データ収集の偏りを軽減します。ただし、サンプリング技術は統計原理に基づいているため、サンプルサイズの決定は、期待される信頼性と既存の事前知識に依存し、システムアナリストの主観的な要素、個人的な経験、経験に大きく依存します。依存性が高く、システムアナリストには高度で豊富な経験が求められます。

共同需要計画: 需要獲得の効率を向上させるために、多くの独立したインタビューの代わりにグループワーキングミーティングを使用する企業が増えています。共同要件計画 (JRP) は、企業内の問題を分析し、高度に組織化されたグループ会議を通じて要件を取得するプロセスであり、共同アプリケーション開発 (JAD) の一部です。

需要分析

要件分析は、システムレベルのソフトウェア割り当てとソフトウェア設計の間の橋渡しとして機能するソフトウェアエンジニアリング活動です。要件分析により、システムエンジニアはソフトウェアの機能とパフォーマンスを特徴付け、ソフトウェアと他のシステム要素間のインターフェイスを指定し、確立することができます。ソフトウェアが満たさなければならない制約。

要件分析により、システムアナリストはソフトウェアの分解を改良し、ソフトウェアによって処理されるデータ、機能、および動作のモデルを構築できます。最後に、要件仕様は、ソフトウェア開発完了後の品質評価の基礎を開発者と顧客に提供します。要件分析は、データ、アーキテクチャ、インターフェイス、プロセス設計に変換できるモデルをソフトウェア設計者に提供します。

要件分析のタスクは、システムエンジニアによって確立され、ソフトウェアプロジェクト計画で指定されたソフトウェアスコープの詳細な調整、必要なデータ、情報、制御フロー、およびデータの作成を含む、発見、改良、モデリング、および仕様のプロセスです。さらに、モデルは代替ソリューションを分析し、それらをソフトウェア要素に割り当てます。

要件分析段階では詳細な仕様を入手することは不可能です。顧客は何が必要なのか正確に分からない可能性があり、開発者は機能とパフォーマンスを適切に達成するためにどのような具体的な方法を使用できるのかが分からない可能性があります。

要件の抽出と分析のプロセス

ニーズを発見する
要件の分類と整理
要件の優先順位付けと交渉
要求仕様

DFD

データフロー図はSA手法における重要なツールであり、システム内のデータの流れを表現し、データの流れを通じてシステムの機能を記述する手法です。
DFD はシステムモデルと考えることもでき、情報システム開発において構造化アプローチが採用されている場合、DFD は一般に要件仕様の不可欠な部分として使用されます。ユースケースモデルは、一連のユースケース、アクター、およびそれらの間の関係を記述します。

データディクショナリは、このツールの補足としてよく使用されます。

DFD は、ユーザーのニーズを理解して表現するためのツールであり、需要分析の手段です。DFD は簡潔で理解しやすく、理解するためにコンピュータの専門知識を必要としないため、システムアナリストは DFD を通じてユーザーとコミュニケーションできます。
DFDは、システムの内部論理処理を簡潔に記述したもので、要件分析結果を表現するツールであり、システム設計の重要な参考資料であり、システム設計の出発点となります。
アーカイブされたテキスト資料としての DFD は、開発計画をさらに改訂し、充実させるための基礎となります。

ここに画像の説明を挿入します

データフロー指向の分析手法: 構造化分析手法。

はい

オブジェクト指向分析、主な活動

要件モデル、つまりユースケース図を確立する
- システム境界を決定する
- 参加者を発見する
- ユースケースを定義する
基本モデル、つまりクラス図を構築する
- オブジェクトとそれを定義するクラスを発見する
- オブジェクトの内部特性 (プロパティと操作) を定義します。
- オブジェクトの外部関係を定義します - 一般的な固有の構造、部分全体の構造、関連付け、およびメッセージ
補助モデルの構築
- パッケージを分割してパッケージ図を作成する
- シーケンス図の作成
- アクティビティ図の作成
- コンポーネント図の作成
- 展開図の作成
- 他のモデル図を作成する
モデル仕様の確立: モデル内のコンポーネントの標準化された定義とテキストによる説明を提供します。
プロトタイプ開発: オプション、他のアクティビティと組み合わせて繰り返します

上記の OOA プロセスは一般に、基本モデルの確立と、需要モデル、基本モデル、補助モデルの確立、修復、改善を中心とした反復的かつ継続的な改善プロセスです。
ここに画像の説明を挿入します

要件定義

要件定義のプロセスは要件仕様を作成するプロセスであり、要件定義には通常、厳密定義方式とプロトタイプ方式の 2 つの方式があります。

要件の事前定義、厳密な定義とも呼ばれる厳密な定義アプローチは、次の基本的な前提に基づいています。

すべての要件を事前に定義できます。これは、実際のシステム操作経験がなくても、すべてのシステム要件を論理推論によって導き出すことができることを意味します。しかし、多くの場合、この仮定は確立できません。
開発者とユーザーの間で正確かつ明確にコミュニケーションできる能力。
最終的なシステムを完全に表現するには、グラフィックス (またはテキスト) を使用します。厳密に定義された要件を使用する開発プロセスでは、開発者とユーザー間のコミュニケーションのための主なツールは、テキスト、グラフィックス、論理ルール、データディクショナリなどの技術ツールを含む定義レポートです。

プロトタイピングの要件定義プロセスは、開発者とユーザーが協力して作業する反復的なプロセスです。ユーザーの基本的なニーズを満たすプロトタイプシステムから出発し、開発プロセス中により良い要件を提案し、ユーザーの要件に応じてシステムを継続的に改善するという、基本的に反復的かつ循環的な開発手法です。
プロトタイプ方式を使用する場合、注意すべき問題がいくつかあります。

システム開発前にすべての要件を正確に表現できるわけではない
プロジェクトの関係者間でコミュニケーションが困難になることがよくあります
ユーザーが参加できる実際のシステムモデルが必要
適切なシステム開発環境があること
繰り返しは完全に必要であり、提唱する価値があります。要件が特定されたら、厳密に定義されたアプローチに従う必要があります

要件の検証

要件検証の基本的な方法は、検査、デモンストレーション、テスト、分析の 4 つです。これら 4 つのメソッドは本質的に階層化されており、各メソッドは製品またはシステムの要件をより厳密に検証します。

チェック: 要件をチェックする場合、要件文書は、導き出された指示が漏れていないことを確認するために校正され、すべての要件間のトレーサビリティのレベルもチェックされます。これを行うには、すべての要件が適切に考慮され、指定されたすべてが正当であることを保証するトレーサビリティマトリックスを作成する必要があります。要件が明確であるかどうか、要件の形式もチェックされます。
プロトタイピング: これは、開発者が構築するシステムのモデルまたはシミュレーションを構築する方法です。これは、問題を簡単に特定し、欠落している要件を検出し、テクノロジがどのように役立つかを理解するのに役立つため、関係者やユーザーの間で非常に人気のある要件検証手法です。ユーザーや関係者に連絡してフィードバックを得ることができます。
テスト設計: テスト設計中、テストチームはいくつかのテストシナリオを構築するための小さな手順に従います。テストは要件仕様から導き出す必要があります。このプロセスの目的は、テストシナリオの定義を困難にする仕様内のエラーや欠落している詳細を見つけることです。
要件レビュー: 要件レビューでは、知識のある人々のグループが要件を分析し、構造化された詳細な方法で潜在的な問題を特定します。次に、集まって問題について話し合い、解決方法を見つけます。レビューの正式な出力を提供するためにレビュー担当者が記入するチェックリストを準備します。最終承認署名で完了します。

要件検証の原則
IREB シラバスによると、次の 4 つの要件検証原則を考慮すると、検証結果の品質を向上させることができます。

適切な関係者を関与させる
エラーの個別の特定と修正
さまざまな角度から検証する
繰り返しの検証

需要管理

要件管理は、システム要件を変更、理解、制御するプロセスであり、通常、要件ベースラインの定義、必要な変更の処理、要件の追跡が含まれます。要件管理プロセスと要件開発プロセスは相互に関連しています。要件管理計画は、最初の要件が導き出されるときに開始されます。要件文書の最初の草案が形成されると、要件管理活動が始まります。

要件管理では、需要ベースラインの変更の制御、プロジェクト計画と要件間の一貫性の維持、個々の要件と要件文書のバージョンの管理、要件とコンタクトチェーンの管理、または個々の要件と他のプロジェクト成果物の間の依存関係の管理を重視します。ベースラインの要件。

要件管理プロセス領域の原則とポリシーについては、以下を参照してください。

要件管理の主要なプロセス領域では、プロジェクトの要件を収集して分析することは含まれず、代わりに、ソフトウェア要件が収集されているか、上位システムから与えられていることが前提となります。
開発者は顧客や関連部門に特定の要件を約束する前に、要件と制約、リスク、偶発性、仮定などを確認する必要があります。
主要な処理分野では、バージョン管理と変更管理を通じて要件文書を管理することも推奨されています。

要件管理アクティビティには次のものが含まれます。

変更管理
バージョン管理
要件の追跡
要件ステータスの追跡

要件変更管理

大規模なソフトウェアシステムの要件は常に変化します。多くのプロジェクトでは、システムソフトウェアは常に継続的に改善する必要があります。一部の要件の改善は合理的であり、避けられないものです。ソフトウェア要件をまったく変更しないようにすることは不可能かもしれませんが、制御されていない変更はプロジェクトを混乱に陥らせ、それを不可能にします。ソフトウェアの品質を保証できない主な理由の 1 つは、スケジュールどおりに完了する必要があることです。優れた変更管理プロセスでは、プロジェクトの関係者に、要件に対する提案された変更に対する正式なメカニズムが提供されます。提案された変更のステータスは、変更管理プロセスを通じて追跡され、提案された変更が失われたり無視されたりしないようにすることができます。要件変更管理プロセス:

問題の分析と変更の説明。これは、要件の問題または明確な変更提案を特定して分析し、その有効性をチェックすることで、より明確な要件変更提案を作成します。
変更分析とコスト計算。トレーサビリティ情報とシステム要件の一般的な知識を使用して、要件変更提案の影響分析と評価を実行します。変更コストの計算には、要件文書の変更、システム変更の設計および実装にかかるコストを含める必要があります。分析が完了して確認されたら、変更を実装するかどうかを決定する必要があります。
実装を変更します。これには、要件文書とシステム設計および実装の両方を同時に変更する必要があります。最初にシステムプログラムを変更し、次に要件ドキュメントを修正する場合、要件ドキュメントとプログラムの間に不一致が生じることはほぼ避けられません。自動化ツールは、変更管理プロセスをより効率的に実行するのに役立ちます。多くのチームは、ビジネス問題追跡ツールを使用して、要件の変更を収集、保存、管理しています。このようなツールを使用して作成された、最近提出された変更提案のリストは、CCB 会議の議題として使用できます。問題追跡ツールでは、いつでも変更ステータスごとに分類された変更リクエストの数をレポートできます。利用可能なツール、ベンダー、機能は頻繁に変更されるため、ツールに関する具体的な推奨事項をここで示すことはできません。

ただし、要件変更プロセスをサポートするには、ツールには次の機能が必要です。

変更リクエスト内のデータ項目を定義できます。
変更要求のライフサイクルを定義できる状態遷移モデル。
状態遷移モデルは、許可されたユーザーのみが許可された状態変更を行えるように強制できます。
各ステータス変更の日付と変更を行った人を記録できます。
提案者が新しいリクエストを送信したとき、またはリクエストのステータスが更新されたときに、電子メール通知を自動的に受信できるユーザーを定義できます。
標準およびカスタマイズされたレポートとグラフを生成できます。

一部のビジネス要件管理ツールには、単純な変更提案システムが組み込まれています。これらのシステムは、提案された変更を特定の要件に関連付けることができるため、誰かが関連する変更リクエストを送信するたびに、要件の責任者全員が電子メール通知を受け取ります。

大規模なソフトウェアシステムの要件は頻繁に変更されます。需要を変更する場合は、次の需要変更戦略を参照できます。

すべての要件の変更は変更管理プロセスに従う必要があります。
設計および実装作業は、承認されていない変更に対して行うべきではありません。
変更はプロジェクト変更管理委員会によって行われ、どの変更を実装するかを決定する必要があります。
プロジェクトの関係者は、変更データベースの内容を理解できる必要があります。
変更リクエストの元の文書をデータベースから削除したり、変更したりしてはなりません。
統合された要件変更はすべて、承認された変更リクエストまで追跡できる必要があります

バージョン管理

要件の追跡

要件の追跡には、各要件と、他の要件、アーキテクチャ、他の設計コンポーネント、ソースコードモジュール、テスト、ヘルプファイル、ドキュメントなどのシステム要素との関係を文書化することが含まれます。機能情報を追跡することで、変更の影響分析が容易になり、提案された要件変更を実装するために必要な作業を特定および評価できます。要件トレーサビリティリンクを使用すると、要件を使用するプロセス全体、つまり、最初の要件から実装までのライフサイクルを追跡できます。トレーサビリティは優れた要件仕様の特徴であり、トレーサビリティを実現するには、各要件を明確にレビューできるように均一に識別する必要があります。

顧客の要件はソフトウェア要件にまで遡ります。このようにして、開発中または開発後の顧客要件の変更によって影響を受けるソフトウェア要件を区別することができ、これにより、ソフトウェア要件仕様にすべての顧客要件が含まれていることを確認できます。

ソフトウェア要件から顧客の要件に応えます。これは、あらゆるソフトウェア要件を特定するための情報源となります。顧客の要件が例の形式で説明されている場合、顧客の要件とソフトウェア要件の間の追跡は、例と機能要件を使用することによって行われます。ソフトウェア要件から次のレベルの作業成果物まで逆算して作業します。開発プロセス中にシステム要件がソフトウェア要件、設計、コーディングなどに変換されるため、個々の要件と特定の製品要素の間の（接続）チェーンを定義することによって、要件を次のレベルの作業成果物まで追跡することができます。この一連の接続により、どの製品部品が各要件に対応するかがわかり、それによって製品部品が各要件を確実に満たすことができます。製品の部品からソフトウェア要件まで遡ります。各コンポーネントが存在する理由を説明します。設計要素、コードスニペット、またはテストを要件まで遡ることができない場合は、不必要なプロセスが存在する可能性があります。ただし、これらの分離された要素が正当な機能を示している場合、要件仕様には要件がありません。

要件追跡マトリックス RTM