まず、要求工学プロセスの概念を導入すること
（A）の概要
1.仕様
要求工学プロセスは、分析と様々な変換するための出発点として、ユーザーが直面するビジネス上の問題であり、そして最終的にはユーザーの環境でユーザーのビジネス上の問題を解決するために、システム・ソリューションを生成し、そのドキュメント、統合システム開発要件の開発活動であります明確な仕様に。
2.ライフサイクル
自身ののライフ・サイクル・モデルをエンジニアリング要件もありますサブプロセスシステム工学、ソフトウェア工学などのシステム開発の初期段階で展開しているプロセスエンジニアリング要件の開発が求められていること。
3.分類活動
要件の需要、需要管理、プロジェクト管理活動の開発のための誘発、要求分析、要求仕様、要件の検証活動。
（B）開発活動の成果は、簡単なドキュメントタイプを要求します
1.プロジェクトのビジョンとスコープドキュメント
システムは、ビジネス要件、仕事の範囲やシステム開発のための明確な方向性を定義しました。
2.ユーザー要件文書
ユーザ定義のユーザ行動予測の位置を表現するために、システム要件を。例えば、ケースの文書には、ユーザー要件文書に属しています。
3.要件仕様ドキュメント
システムレベル要件定義システム、開発者がタスクを完了する必要があることを指摘しました。要求仕様ドキュメント範囲のニーズは、次の2つのカテゴリに分けることができます。
（ 1）システムの仕様書
ソフトウェアおよびハードウェア要件の定義、その他の要件。
（ 2）ソフトウェアの仕様書
唯一のソフトウェア要件を記述するために使用されます。
（C）システム開発の後段
すべてのシステムの開発活動の終了後に、明確に定義された要件は、システム開発の後段に転送され、その後、多くの場合、重要な問題に直面すること、設計、実装、およびテスト- -需要の変化を。そのため、要件の開発が終了した後、需要の一元管理の開発の後の段階で効果的な措置を採用し、需要、需要管理と変更管理に変更されます。
第二に、ステップ導入によるエンジニアリング・プロセス工程の需要
（A）の要件を誘発
主な要求獲得には、5つのステップが含まれています。
背景の収集 - >問題や目標、プロジェクトの展望の定義と範囲を取得する- >利害関係者を特定し、情報源を選択- > [取得方法を選択し、非機能要件を取得する取得機能を実行- >録音結果を取得します。
各プロセスの考慮事項の以下の簡単な説明：
1.背景資料を集めます
この段階では、主にユーザーとのコミュニケーションを通じて、へのニーズの分析工程を経て、問題のユーザーを発見されたユーザーのニーズ。
2. アクセスし、目標の問題は、プロジェクトのスコープとの見通しを定義します
広いの顔に情報を取得する必要があり、そのため、情報保証へのアクセスの実効性を確保する必要があります。
（ 1）は無関係な内容にあまりにも多くの時間を費やすことはありません。
（ 2 ）重要なコンテンツを取得する必要がありますお見逃しなく。
、情報の選択されたソースを利害関係者を特定3.
このプロセスは、多くのユーザーの獲得の必要性を伴うだろうが、情報の収集と精度を容易にするために、ユーザーが分類した後、可能な限り包括的な情報を収集するために、ユーザーの代表を選択し、異なる役割に応じて大別する必要があります。このプロセスは、呼び出された「公共が関与する分析。」
4. 非機能要件を取得する取得機能を実行するの取得方法を選択します
多くの要件誘発技術および方法、フォーム、レポート、メモや他のハードのデータ取得要件の使用、ならびにインタビュー、アンケート、観察やプロトタイプを得るために一般的に使用される方法があります。あなたは、実際のシーンとに応じた適切なサービスの種類を選択してください収集方法。
5. 録音結果は、Get
取得した情報は、事後分析および処理のための各段階の記録のために必要とされている上に、そのため、記録されたコンテンツの転写産物を得るために、厄介な、ファジー、冗長性と省略および他の多くの問題を持っている傾向があります。
（B）要求分析
その主な仕事は、内に存在する要件を確認し、あらゆる種類の情報を統合するためにモデル化している様々な欠陥の誤り、記載漏れや不整合など、および修正を。これは主に6つの領域の内容が含まれています。
背景 - >問題の分析、目標の分析、業務分析、システムの境界- >ソフトウェア要件モデリング- >洗練デマンド- >最適なレベルを決定するために- >需要交渉。
1.背景
主に大規模なシステムのため、システム環境が背景分析の必要性について、この時間を整理することは困難であるため。例えば、分析の分野、企業モデリング。
このステップは、あまりにも多くの不必要なエネルギーを費やすしないように、一般的なプロジェクトでは省略されています。
2. 問題分析、目標分析、ビジネス分析は、システムの境界を決定します
システム境界は、システムが効果的な相互作用や周囲の環境を形成し、相互作用にユーザーの問題を解決するため、分析技術および方法の使用に依存し、ビジネスニーズを満たすためにできることを確認する必要があります。例えば、図のコンテキストの図を有するシステム。
3.モデリングソフトウェア要件
一般的に使用される技術のために活動情報を示し、説明するために技術をモデル化するセミフォーマル抽象記述データは図、エンティティ関係図、状態遷移図、クラス図を流れる含みます。いくつかの厳しいプロジェクト（医療機器制御）のために、また、厳格な正式なモデリング技術を使用する必要がある、ということに注意してください。例えば、 Z-モデル。
4. 洗練需要
ユーザのニーズが詳細な要件の数に、システムのモデル化によって、曖昧あいまいを有し、良好な粒子サイズ特性、すなわち、有する「システム需要のタイプ」を
5. 最適なレベルを決定します
多くのユーザーのニーズのために、要件のエンジニアは需要の並べ替えする必要があります。
6.需要相談
ユーザーが競合、ユーザーとの協議の必要性を必要とする場合、紛争の需要が選択します。
（C）要求仕様
1. カスタマイズ可能なドキュメントテンプレート
組織は通常を参照します [IEEE 1998]参照テンプレート組織を確立し、それらの特性やニーズに応じて調整し、その後仕様書をお勧めします、と。
2.文書化
通常、文書の内容が、読みやすい正確であることを保証するために、（グラフィックス、式、など）および自然言語（テキスト）モードの両方式の言語モデルを使用します。
（D）の要件の検証
バリデーション要件のドキュメントには、以下の基準を満たしています。
lは 、真にユーザの意図を反映します
リットルの 全記録需要が整合性と一貫性を持っています
リットルの 組織と書き込み読み出し可能と修正可能性の仕方
主な要件の検証は、次のタスクが含まれます。
検証を実行します。1.
ピアレビューを取るためにベスト、必要に応じて、撮影したかのアナログプロトタイプが、より高い価格することができます。
2.バグ修正
問題は、検証後にタイムリーな補正の必要があると指摘しました。改正の実施を確保するための追跡と訂正。
（E）需要管理
オンデマンドで確立する必要性開発するなど、顧客、経営、マーケティングおよびその他のステークホルダーからの変更要求を処理するよう設計、実装、フォローアップ活動のベースラインを。需要管理は、プロジェクトの管理活動において非常に重要な役割を持って、 CMMI（能力成熟度モデル統合は、ソフトウェア能力成熟度モデル統合）は、全ての第2満期の企業が持つべきとキープロセスエリアとなります。
主に次のタスクが含まれます。
ベースラインの要件のセットを確立し、維持する1
優れた構成管理、バージョン管理、ベースラインの需要を確立します。私たちはまず、不動産に関連するレコードを各要件を特定する必要があります。作業ベースラインのバージョン管理、バージョン管理ツールは、あなたが実行するために使用することができます。
要件のトレーサビリティ情報の確立2.
双方向トラックの出発点として、システムレベルの要件にトレーサビリティシステム要件。
（ 1つのトラックのポスト）
それらが存在する理由をシステムレベルの要件は製品を実装し、各デザインになぜ製品、およびバックを実現するために設計されて追跡することです。
（ 2 ）フォワードトラッキング
戻るユーザーの要件とビジネスはサポートが存在する必要のある各システム・レベルの要件。
3.変更管理
ベースラインの需要を確立した後、まだ積極的に外の世界からの変更要求を受け入れ、かつタイムリーな調整やフィードバックを行うことが必要です。
発行日：2018年4月1日夜03時03