それらは同じもののように見えるので、その違いをもう少しよく理解しようとしています。
私は要件を使用していないプロジェクトで仕事をしていて、すべてが受け入れ基準であり、両方を持っているプロジェクトで働いています。
それらは同じもののように見えるので、その違いをもう少しよく理解しようとしています。
私は要件を使用していないプロジェクトで仕事をしていて、すべてが受け入れ基準であり、両方を持っているプロジェクトで働いています。
回答:
許容基準は、アプリケーションが終了したときに定義します。または、別の言い方をすると、出荷できる場合です。それはそれがhas to満たす要件のリストが含まれています。これは、一部の要件（通常は「必要な要件」）が低下し、次のバージョンで実装される可能性があることを意味します。
さらに拡張するには（ここから取得）：
Microsoft Pressは、受け入れ基準を「ソフトウェア製品がユーザー、顧客、またはその他の利害関係者に受け入れられるために満たす必要がある条件」と定義しています。Googleはそれらを「製品またはプロジェクトが満たす必要のある事前に確立された標準または要件」と定義しています。
そして
承認基準は一連のステートメントであり、それぞれに明確な合格/不合格の結果があり、プロジェクト統合の現在の段階で適用される機能的要件（市場性のある最小限の機能など）と非機能要件（品質の最小限）の両方を指定します。これらの要件は、「満足の条件」を表しています。部分的な受け入れはありません。基準が満たされているか、満たされていません。
要件は、アプリケーションの特定の機能について説明します。
または、wikiがうまく述べているように：
要件とは、特定の設計、製品、またはプロセスが実行できなければならない、単一の文書化された物理的および機能的なニーズです。
受け入れ基準とアプリケーション要件の違いは何ですか？
上記の定義では、違いは非常に明確です。
要件は、あなたがすべきことです。
受け入れ基準は、あなたがそれらを行ったことを証明するために合意された手段です。
要件は、クライアント/顧客が求めているものです。
受け入れ基準は、しばしばテストとして表され、要件を説明し、テストが合格したときに要件が満たされていることを示すために使用されます。
それはしばしばタイミングの問題です
要件は前倒しです。受け入れ基準はソフトウェア配信ポイントにあります。
これは他の人が答えたとおりです...
より深い問題がありますが、おそらくあなたはそれを見ているでしょう：
「理想的な」世界では、これらはちょうど一致します。ただし、現実の世界では、これら2つのイベントの間で多くのことが発生します。
これは「詳細レベル」の問題であることが多く、「払い戻し処理モジュール」などの高レベルの要件と、「要求された払い戻しは3時間以内に完了する必要がある」など、より低レベルでより詳細な承認基準日とお客様にメールで通知」
要件は、質問に答える検証に該当します。
製品は正しく構築されましたか？（要件ごとにボトムアップ）
受け入れ基準は、質問に答える検証に該当します。
正しい製品が作られましたか？（受け入れテストに合格することで証明されるトップダウン）
多くの場合、要件はクライアントによって決定されます。ウォーターフォール開発パターンでは、これらはプロジェクトの完了から期待される結果のリストです。最も基本的な説明では、要件はプロジェクトのTo-Doに過ぎません。
受け入れ基準は、多くの場合、2つの当事者間の関係によって決まります。それらは、要件から独立していても、要件に関連していてもかまいません。それはそれらを同じものにするのではなく、単に関連しています。要件とは異なり、受け入れ基準はタスクリストではありません。これは、合意が完了したと見なされるために満たさなければならない条件のリストです。
一部の回答では、ユニットテスト、予算編成、プロジェクト管理を例として挙げていますが、これらは、承認基準として合意に課された条件の例にすぎません。
それは完全に開発者のために可能であるなし要件の、まだプロジェクトを完了するために受入基準を満たしています。
例えば;
新しい税法の変更でPOSシステムを更新するための要件。開発者とクライアントの間の承認基準では、開発者は更新を実行するために40時間の作業を完了することに同意しています。その時間内に作業が完了しない場合、これはクライアントの予算制限であるため、システムの更新は公開されません。
開発者は契約を締結し、40時間の作業の後、変更が重大であり、完了までに40時間を超えると報告しました。クライアントはこの結果を受け入れ、開発者に賃金を支払い、契約が完了します。