要件管理とトレーサビリティの最も完全なガイド
用語解説
目次
|
略語
|
ご利用規約
|
定義
|
|---|---|---|
|
RM
|
要件管理
|
プロジェクトまたは製品の要件を特定、文書化、分析、追跡、優先順位付け、承認、および維持するプロセス。
|
|
BRD
|
ビジネス要件ドキュメント
|
プロジェクトまたは製品の高レベルのビジネス要件を説明する正式なドキュメント。 通常、ビジネス ニーズ、範囲、利害関係者、機能要件、非機能要件、仮定、制約、リスク、およびプロジェクトのタイムラインに関する情報が含まれます。
|
|
FRD
|
機能要件ドキュメント
|
プロジェクトまたは製品の特定の機能要件を説明する詳細なドキュメント。 通常、システム機能、ユーザー要件、ユース ケース、シナリオ、データ要件、および受け入れ基準に関する情報が含まれます。
|
|
NFRD
|
非機能要件ドキュメント
|
プロジェクトまたは製品の特定の非機能要件を説明する詳細なドキュメント。 通常、システムのパフォーマンス、スケーラビリティ、可用性、信頼性、セキュリティ、保守性、使いやすさ、およびアクセシビリティに関する情報が含まれます。
|
|
SRS
|
ソフトウェア要件仕様
|
ソフトウェア システムの機能要件と非機能要件を説明する包括的なドキュメント。 通常、システム アーキテクチャ、設計、実装、テスト、および展開に関する情報が含まれます。
|
|
Use Case
|
Use Case
|
システムとそのユーザーまたは他のシステムとの間の相互作用を定義することにより、システムの機能要件を把握して記述するための手法。 通常、特定の目標またはタスクを達成するためにユーザーまたはシステムが実行する手順の説明が含まれます。
|
|
トレーサビリティマトリクス
|
トレーサビリティマトリクス
|
システムの要件、設計、実装、テスト、および展開の間の追跡可能なリンクを提供するドキュメント。 これには通常、要件と他のシステム アーティファクト (テスト ケース、欠陥、変更要求など) との関係に関する情報が含まれます。
|
|
コントロールボードの変更
|
コントロールボードの変更
|
システムの要件、設計、実装、テスト、および展開に対する変更の評価、承認、および管理を担当する利害関係者のグループ。 通常、ビジネス、開発、テスト、運用など、さまざまな部門の代表者が含まれます。
|
|
要件の引き出し
|
要件の引き出し
|
利害関係者、ユーザー、およびその他の情報源から、プロジェクトまたは製品の要件を収集して文書化するプロセス。 これには通常、インタビュー、調査、観察、フォーカス グループ、ブレインストーミング セッションなどの手法が含まれます。
|
|
利害関係者
|
利害関係者
|
プロジェクトまたは製品の成功に関心を持つ個人またはグループ。 通常、顧客、ユーザー、スポンサー、事業主、開発者、テスター、およびサポート スタッフが含まれます。
|
|
要件の優先順位付け
|
要件の優先順位付け
|
プロジェクトまたは製品の要件を重要性または緊急性の順にランク付けするプロセス。 通常、最初に対処する必要がある重要な要件を特定し、ビジネス価値、技術的な実現可能性、およびリスクに基づいて各要件に優先度レベルを割り当てます。
|
|
要件管理ツール
|
要件管理ツール
|
要件管理プロセスをサポートするために使用されるソフトウェア アプリケーション。通常、要件のキャプチャ、トレーサビリティ、バージョン管理、コラボレーション、レポート、分析などの機能が含まれます。要件管理ツールの例には、Visure Solutions、IBM Rational DOORS、HP ALM などがあります。
|
|
ベースライン
|
ベースライン
|
システムのさらなる開発とテストの基礎となる承認済み要件のセット。 これには通常、利害関係者によって合意され、変更管理委員会によって承認された機能要件と非機能要件が含まれます。
|
|
検証
|
検証
|
システムの要件が完全で正確であり、利害関係者のニーズや期待と一致しているかどうかを評価するプロセス。 通常、要件文書のレビュー、利害関係者によるレビューの実施、およびテストやその他の方法を通じてシステムが指定された要件を満たしていることの検証が含まれます。
|
|
Verification
|
Verification
|
システムが指定された要件を満たしているかどうかを評価するプロセス。 通常、要件ドキュメントで定義された受け入れ基準に照らしてシステムをテストし、すべての要件が正しく実装されていることを確認します。
|
|
対象領域
|
対象領域
|
プロジェクトまたは製品の境界と目的。 これには通常、システムの特徴、機能、および機能に関する情報と、考慮しなければならない制約および制限が含まれます。
|
|
影響分析
|
影響分析
|
システムの要件、設計、実装、テスト、または展開に対する変更の潜在的な影響を評価するプロセス。 通常、システムの影響を受ける領域を特定し、変更のリスクと利点を評価し、変更を実装するために必要なリソースとタイムラインを決定します。
|
|
要件レビュー
|
要件レビュー
|
要件文書が完全で正確であり、利害関係者のニーズと期待と一致していることを確認するために、要件文書を評価するための正式なプロセス。 これには通常、開発者、テスター、ビジネス アナリスト、対象分野の専門家などの利害関係者のチームによるレビューが含まれます。チームはフィードバックを提供し、対処する必要がある問題や懸念を特定します。
|
|
要件のトレーサビリティ
|
要件のトレーサビリティ
|
要件と他のシステム アーティファクト (設計ドキュメント、テスト ケース、欠陥、変更要求など) との関係を追跡および管理する機能。 通常、トレーサビリティ マトリックスまたはその他のツールを作成して、すべての要件が開発プロセス全体にわたって説明され、要件への変更が適切に管理および文書化されるようにします。
|
|
要件ベースライン
|
要件ベースライン
|
利害関係者によって承認され、システムのさらなる開発とテストの基礎を形成する一連の要件。 これには通常、機能要件と非機能要件、および特定された制約、仮定、およびリスクが含まれます。 要件ベースラインは、開発プロセス全体で要件への変更を管理するための参照点として使用されます。
|
|
要件エンジニアリング
|
要件エンジニアリング
|
プロジェクトまたは製品の要件を引き出し、分析し、特定し、検証し、管理するための体系的かつ規律あるアプローチ。 通常、インタビュー、調査、ユースケース、シナリオ、プロトタイプなどのさまざまな手法を使用して、要件が完全で正確であり、利害関係者のニーズや期待と一致していることを確認します。
|
|
要件文書
|
要件文書
|
ビジネス要件ドキュメント、機能要件ドキュメント、非機能要件ドキュメント、ユース ケース、ユーザー ストーリー、およびその他の関連ドキュメントを含む、システムの要件を説明するドキュメントのコレクション。 要件のドキュメントは、システムの機能、機能、機能、および開発プロセス全体で考慮しなければならない制約、仮定、およびリスクを包括的に理解するのに役立ちます。
|
|
BR
|
ビジネス要件
|
利害関係者のニーズと期待を満たすためにシステムが満たさなければならない高レベルの目的と目標。 通常、ビジネス要件は、システムの実装方法に関する技術的な詳細ではなく、システムがサポートまたは改善する必要があるビジネス プロセス、ポリシー、およびルールに焦点を当てています。
|
|
FR
|
機能要件
|
利害関係者のニーズと期待を満たすためにシステムが備えなければならない特徴、機能、および機能の詳細な説明。 機能要件は通常、システムがどのように動作するか、または特定の入力またはイベントに応答するかを定義し、システムが利害関係者の要件を満たしていることを確認するために満たさなければならない制約、仮定、および受け入れ基準を含む場合があります。
|
|
NFR
|
非機能要件
|
システムのパフォーマンス、信頼性、セキュリティ、使いやすさ、および利害関係者のニーズと期待を満たすために必要なその他の品質の説明。 非機能要件は通常、システムの特定の特徴や機能ではなく、システムの属性や特性を定義します。これらには、システムが利害関係者の要件を満たしていることを確認するために満たさなければならない制約、仮定、および受け入れ基準が含まれる場合があります。
|
|
ユーザーストーリー
|
ユーザーストーリー
|
利害関係者のニーズと期待を満たすためにシステムが備えなければならない特徴または機能の簡潔で非公式な説明。 ユーザー ストーリーは通常、「[ユーザー] として、[機能] が必要なため、[メリット] が欲しい」などの単純なテンプレートに従います。 ユーザー ストーリーは、利害関係者や開発チームが簡単に伝達して優先順位を付けることができる、シンプルでわかりやすい形式で要件を把握するために使用されます。
|
|
受け入れ基準
|
受け入れ基準
|
システムが利害関係者によって受け入れられる、または満足できると見なされるために満たさなければならない基準。 受け入れ基準は通常、特定のシナリオまたはユースケースでシステムの期待される動作または結果を定義し、システムが利害関係者のニーズと期待を確実に満たすために満たす必要がある定量的または定性的な尺度を含む場合があります。 受け入れ基準は、機能要件および非機能要件に対してシステムを検証し、利害関係者の要件を満たしていることを確認するために使用されます。
|
|
ALM
|
アプリケーションライフサイクル管理
|
アプリケーション ライフサイクル管理は、アプリケーションを指定、設計、文書化、およびテストする手順です。 プロジェクトの開始から終了までのライフサイクル全体をカバーします。 開発全体を通してアプリケーションのアイデアから始まり、テスト、展開、サポート、そして最後にユーザー エクスペリエンスに進みます。
|
|
CMMI
|
能力成熟度モデルの統合
|
CMMI は、組織がソフトウェア開発プロセスの品質、効率、および有効性を向上させるのに役立つ、ソフトウェア開発、プロジェクト管理、および組織管理のための一連のベスト プラクティスを定義しています。
|
|
MBSE
|
モデルベース システムズ エンジニアリング
|
モデルを使用して複雑なシステムを表現、分析、設計、検証するシステム エンジニアリングへのアプローチ。 MBSE では、システムの要件、動作、アーキテクチャ、およびその他の重要な側面を捉えた一連のモデルを作成し、これらのモデルを使用して開発プロセスをガイドします。
|
この投稿を共有することを忘れないでください！
