1概要
要求工学は、顧客のニーズを決定するためにニーズ分析を行うために証明されている効果的な技術や方法の適用には、ヘルプのアナリストは、問題を理解し、実現可能性を評価し、合理的な解決策、明確に法律プログラムを交渉し法令および実行する変換の法律を確認しました要求抽出、要求分析と相談：システム要件エンジニアリングでの需要管理は、常に要件定義、ドキュメントに繰り返され、需要の進化の過程ではと、最終的には、6つのフェーズに分けることができ、要求工学の検証に基づいて需要を凍結します、システムモデリング、要求仕様、要件の検証、需要管理。
2つの要求獲得
需要アナリスト取得フェーズ、既存のシステムとタスクの観測は、システムは技術的環境と製品関連の機能や人々のリストを記載したシステムや製品の限定的な説明を決定し、利用者とのコミュニケーションによって分析することができ、システムシステムは、基礎ニーズ分析を築くために、異なる動作条件の下でアプリケーションシステムまたは製品の使用シナリオを記述し、機能リストと各要件の制限に使用されます。
2.1ソフトウェア要件
ソフトウェア要件の手段その機能、動作、性能、デザイン上の制約、などの面で、ターゲット・ソフトウェア・システムのユーザーの期待：
2.1.1機能要件
何がいつ、どのように変更またはアップグレードするために、やってたときに、実行するシステムを検討してください。
2.1.2パフォーマンスの要件
ソフトウェア開発の技術的指標、例えば、記憶容量の制限、実行速度、応答時間とスループットを考えます。
2.1.3ユーザまたはヒト因子
ユーザのタイプ、ユーザのコンピュータ能力を訓練を受け入れるために必要とされるように、ユーザが理解され、システム、システム・ユーザ誤操作の可能性等を使用することの難しさを考えます。
2.1.4環境要件
ハードウェアとソフトウェア、モデル、周辺機器、インターフェイス、位置、分布、温度、湿度、磁場干渉を含むハードウェアデバイスの需要を含む、ソフトウェアアプリケーション環境の未来を考える。等オペレーティングシステム、ネットワーク、データベース、を含むソフトウェアの需要。
2.1.5インタフェース要件
他のシステムの出力、所定の特別なデータ形式、所定のデータ記憶媒体に、別のシステムからの入力を考えます。
2.1.6文書化要件
どのような文書、読者のニーズに合わせて文書を考えてみましょう。
2.1.7データ要件
入力、出力データ形式、送信データの周波数を受信し、正確さおよび精度データ、トラフィックデータを考慮し、時刻データは次のように維持するのに必要。
2.1.8リソースニーズ
ソフトウェア、他のソフトウェア、メモリおよびその他のリソースソフトウェア開発、必要な人員、ソフトウェアのサポートおよび開発機器のメンテナンスを実行するのに必要なデータを考慮します。
2.1.9セキュリティと機密性要件
他のプログラムおよびオペレーティングシステムの分離とシステムのバックアップ要件とその他のシステムやシステム情報へのアクセスを制御、ユーザデータと分離の方法は、どのようにユーザプログラムへの必要性を考えてみましょう。
2.1.10信頼性要件
かどうかは、システム技術の信頼性を検討するために、システムが監視し、エラーを分離し、エラー許容時間後にシステムを再起動する必要があります。
2.1.11ソフトウェアの開発スケジュールやコストの消費需要
開発スケジュール、ハードウェアとソフトウェア投資の規定は無制限というようにしているかどうかを検討します。
2.1.12その他の非機能要件
特定のモデル開発の使用は、品質管理基準は、マイルストーンと審査、検査要件、および標準化、品質要件と優先順位の保守性を決定します。
戦略は2.2要求獲得方法
2.2.1円滑な通信経路を確立します
問題の円滑な分析を確保するために、ユーザー、システムアナリスト、ソフトウェア開発チームと経営陣との間で良好な通信を確立します。
2.2.2インタビューや調査
すでに、または業界標準から存在する類似のソフトウェア製品の分析から、アナリストは、ルールは初期のニーズを抽出し、その後、個々の面接やグループミーティングの形の形でユーザーとの予備的な通信を開始する。インタビューに加えて、しかし、することができマーケットリサーチが開発されるソフトウェアの市場を理解するために、種類の要件のため、調査の様々な、指定された調査の概要を取ることができるか、異なるユーザのレベル、またはユーザアクセスとドメインの専門家にアンケートを送りました。
ユーザ操作フローを観察2.2.3
、観察するユーザーのワークフローにおけるユーザーの実際の作業環境は、ユーザーの実際の動作環境を理解するために、操作・運用の要件は、利用者から提出された制御問題文は、ユーザーのニーズをより包括的かつ詳細に理解する必要があります。
合同チームを確立するために、2.2.4
技術者や開発者FAST（促進アプリケーションsepcification技術）と呼ばに関して確立合同チームの使用、およびプレイその強みにして、プロジェクトを推進するための共同責任者は、識別するために一緒に働いて、ユーザーと開発チーム間の協力の設立を奨励.FAST問題、異なるアプローチ、初期の特性ソリューションを議論する要素のソリューション。
それは可能性のある様々な用途で互いに通信を改善するための技術を提供主流の技術情報システムは、チームがソフトウェアとハードウェアエンジニアリングだけでなく、製造市場組成物からの代表者で構成さ.FAST、およびコーディネーターとして外国人労働者を選択することになっています。この方法の基本的な原則を見ている人があります。
- 中立的な場所に開発者とユーザが出席し、会議
- 準備し、会議の参加のルールを確立します
- あなたが自由にやり取りできるように、正式な議題十分に確立
- 「コーディネーター」（ユーザー、開発者、または他の誰か）による制御会議へ
- 「定義されたメカニズム」（ワークシート、アイコン等）の使用
- 目標は、問題を識別するためにある、異なるアプローチを議論するための要素のためのソリューションを提案し、雰囲気の完了目標を支持して初期需要を示しています
2.2.5ユースケース
条件は、多くの場合、ユースケースと呼ばれると、それは含まれています
- 主なタスクや機能の実装を完了するために、
- アクターは、農産物や変更どのような情報を取得します
- エグゼキュータは、外部環境の変化に関する情報をシステムに伝える必要があるかどうか
- 何幹部は、システムからの情報が欲しいです
- あなたがパフォーマー予想外の変更を通知されるようにしたいですか
3人のニーズ分析
3.1原則
- 情報ドメインを表現し、問題を理解することができなければなりません
- ソフトウェアは、完全な関数を定義することができなければなりません
- 私たちは、ソフトウェアの動作を表現することができなければなりません
- データモデルは、説明、機能と動作を分割する必要があります
- 分析プロセスは、要素情報の詳細から移動する必要があります
3.2情報フィールド
情報フィールドは、情報コンテンツ、構成情報、および情報の流れを含んでいます。
3.2.1情報コンテンツ
コンテンツ及び制御データの単一の標的を表し、対象ソフトウェア情報セットは、すべてのプロセスで構成される。
3.2.2情報の流れ
これは、データストリームとシステムの変化は、入力オブジェクトの情報が中間に変換し、さらに出力に変換され、フロー制御モードを示しています。
3.2.3情報構造
各種データや制御の内部組織を示す情報構造図。
3.3需要相談
需要が会議は通常、競合を解決するための最速の方法です、紛争のニーズを議論する協議を必要とする、紛争になりやすいです。
3.4要件のモデリング
情報、機能と動作を理解するのに役立ちアナリストへのソフトウェア要件に簡潔でモデルが重要なイベントが分析を必要としている。モデル、道の構造を正確かつ明確な記述システムを作成し、モデルは、ソフトウェアの設計の基礎となり、デザイナーのためのソフトウェア要素のビューを提供します。
4つの要件の仕様
要件仕様は、対象ソフトウェアの多様なニーズ与えられ、完全な説明、機能と動作の詳細な説明、性能要件と設計上の制約、適切な受け入れ基準を説明を確立することにより、分析タスクの最終製品である。規程のソフトウェア要件メインフレームは、5つの部分に分割されます。
4.1はじめに
はじめに、全体的なソフトウェアプロジェクトの制約を記述し、システムの参照を含む、コンピュータベースの言語システムの領土で説明した、ソフトウェアの目標を述べました。
4.2説明
記述は、情報コンテンツ、情報の流れ、情報の構造を記録する問題を解決しなければならないソフトウェアの詳細な説明が与えられます。
4.3機能の説明
各機能の機能説明は、問題を解決するために必要な、各機能の処理の説明を含め、説明した設計上の制約を説明し、性能特性は、1枚のまたは複数のソフトウェアの全体構成を示すグラフィック画像およびソフトウェア機能と、記載そして、他の要素との相互作用。
4.4動作の説明
外部イベントと前記内部生成動作の制御の動作を説明するためのソフトウェアの説明。
4.5検査規格
試験規格は一種の結果、それはシステムが正常に達成された何を意味するのか。検査基準は、試験的に確認され、どのような種類のテストのシステムで成功の検査システムの記号を、説明しています。
4.6参考資料
ドキュメント、技術文献、ベンダーの文学とソフトウェア工学の他の基準を含むソフトウェアおよび関連ドキュメントのすべてを参照します。
4.7付録
法律の詳細な説明は、追加の情報、フォームデータ、アルゴリズム、チャート、および他の材料を含んでいます。
5つの要件の検証
オンデマンド検証は、そのユーザーの希望、検査の様々なを実行するために、文書で定義された需要の要件へのニーズを反映しているかどうかをテストすることを目的としている、評価チームは、システム定義のターゲットを含め、全体として需要、一貫性と完全性の妥当性をチェックする必要がありますこれは、既には十分に説明するかどうか、ソフトウェアの主な機能は、指定された範囲に含まれるかどうか、データ構造決意で開発されたデータストリームかどうか、および十分な、文書化システム要件分析フェーズが完了提供し、ユーザの要求と一致しています制約や制限デザインは技術の開発のリスクは、テストの精緻化は、彼らが確認するためのシステムを定義することができるかどうかであるか、現実的です。
6需要管理
需要管理は、その缶、一度需要をマークし、一意の識別子を与えられるように、識別するために、任意の時点でのプロジェクトの進行中のチームを助けるためにグループで管理し、需要管理で需要の活動を追跡し、それぞれのニーズ目的各テーブルには、コードの異なるバージョン間のトラックの関係をマークし、追跡テーブルの確立を要求、テストケースは、需要およびその他の要件や設計文書。これらのテーブルは、開発プロセス全体の要件のトレーサビリティを追跡するために使用することができ、要件のトレーサビリティが行われますすべての実装は、ユーザーのニーズをベースに基づいていることを確認するためにテストを開始するためにユーザーのニーズとの整合性と完全性を確立し、維持するために、すべての出力は、ユーザーのニーズを満たし、かつユーザーのニーズを包括的にカバー。