要件管理計画の作成、要件ベースラインの定義、要件の理解とコミットメントの取得、要件の変更の管理、要件の双方向追跡の維持、プロジェクト作業と要件の間の不一致の特定

要件の双方向追跡: 順方向追跡では、どのユースケースで元の要件が実現されるか、元の要件がすべて実現されているかどうか、逆方向追跡では、ユースケースが元の要件をまったく実現しない場合、それは刺激的なニーズになります。 。

問題領域に関連する情報、解決すべき問題に関連する情報、ユーザーの期待と制約

利害関係者、レガシー システム、競合他社、ドメインの専門家

共同討議要件会議（多者協議）、ユーザーインタビュー（主要ユーザーが質問を作成）、書面調査（人数が多い場合）、現地視察、史料閲覧、実務参加

グラフィカル ツール: 階層ブロック図、ユースケース図、IPO 図、ワーニア図

要件開発は非ウォーターフォールの反復的な進化プロセスであり、問​​題を上から下に層ごとに分解し、システムの論理ビューと物理ビューを提供します。

システムと外部エンティティとの関係のスコープ図の作成、ユーザーインターフェイスのプロトタイプの作成、要件の実現可能性の分析、要件の優先順位の決定、要件の分析モデルの確立（ユースケースモデル、ER図、データフロー図） 、データディクショナリを作成し、品質関数を使用して割り当てます

構造化分析手法

オブジェクト指向の分析手法

地域問題領域分析手法

論理ビュー (機能要件を満たす)、プロセス ビュー (同時実行の問題)、コンポーネント ビュー (実装の問題)、展開ビュー (配布の問題)

ソフトウェア要件をデータ構造とソフトウェアシステム構造に変換し、機能をモジュールに分割し、モジュールの機能やモジュール間の呼び出しと構成関係を決定するなど、主に全体の設計を完了します。

トップダウン、段階的な改良、情報隠蔽（操作インターフェイス）、独立したモジュール（高凝集性、低結合）

各モジュールのデータ構造とアルゴリズム、パフォーマンス、ターンアラウンドタイム、応答時間、スループット、精度などを設計します。

受信モジュール、送信モジュール、変換モジュール、調整モジュール

変換、トランザクション、混合

プログラムの構造や処理に関わらず、機能仕様に従ってテストケースを設計し、機能が要件を満たしているかどうかを確認します。

等価クラス分け

境界値解析

推測エラー

因果関係図

試験内容

試験方法

ブラックボックステストとホワイトボックステストを組み合わせる

コーディング段階で、モジュールインターフェイス機能テスト、ローカルデータ構造テスト、パステスト、エラー処理テスト、境界条件テストなどの一般的なホワイトボックステストで実施されます。

設計段階でのエラーが発見された場合、モジュールが組み立てられた後、モジュール間のインターフェイスと通信がテストされます (通常はブラック ボックス テスト)。

模擬環境での要求仕様、妥当性試験、ソフトウェア構成レビュー、受入試験（解析レポート、ユーザーマニュアル、開発概要レポート）に基づき、ソフトウェアの機能・性能がユーザーのニーズと一致しているか確認します。

本番環境テスト、要求仕様に基づくブラックボックステスト、すべての結合コンポーネントを対象としたソフトウェア製品の品質評価

ソフトウェア、ハードウェア、周辺機器、データ、サポート ソフトウェアなどが含まれます。具体的には、回復テスト、セキュリティ テスト、強度テスト、パフォーマンス テスト、信頼性テスト、設置テストなどです。

製品型ソフトウェアの場合、@ 開発者が存在し、顧客がテストを実装します。b 開発者は存在しません。

目的 (システム機能の評価、弱点の特定、システムのチューニング、安定性と信頼性の検証)、タイプ (負荷テスト、強度テスト、容量テスト)

ソフトウェア要件分析、受入テスト計画およびプロジェクト受入基準の作成、テスト設計およびテストケース設計、テスト環境構築、テスト実施、結果分析、テストレポート

仲介者 -- 北京ソフトウェア評価センター

要件分析 -- 考えられる改善点と修正点について説明します

設計段階 - 拡張が容易、移植可能、再利用可能なソリューション、オブジェクト指向

コーディングフェーズ - アノテーション、品質、オブジェクト指向

テスト段階 - テストが良好であれば、メンテナンスも良好です。テスト関連のドキュメントはすべて利用可能です。

メンテナンスフェーズ - 適切な構成管理と同期されたドキュメント

ループ数（ソースコードの複雑さ）、ソフトウェアのサイズ、その他の要因