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