バグ：要件からの逸脱と期待からの逸脱
これについてはよくわかりません。用語に関係なく、結局のところ、ソフトウェアの障害/バグが原因です（多くのソースによると）。
要件からの逸脱
期待からの逸脱
しかし、期待が要件に含まれていない場合、利害関係者は、このようなものであると期待していたので、どこにでもバグが表示される可能性があります。私は、仕様が物事を見逃す可能性があることを読みましたが、もちろん、それは期待されていますが、（誤って）指定されていません。
しかし、期待が要件に含まれていない場合、利害関係者は、このようなものであると期待していたので、どこにでもバグが表示される可能性があります。
要件を読むことで、要件の内容がわかります。 （記載されていない要件もあるかもしれません。つまり、誰もわざわざ書き留める必要がないほど明白なものです。しかし、これらは問題になる可能性があります。以下を参照してください。）
ユーザーに尋ねることで、ユーザーの期待が何であったかを知ることができます。
満たされていないユーザーの期待が「バグ」であるかどうかは、実際に利害関係者間の議論の問題です。
残念ながら、慎重なソフトウェアサプライヤーや請負業者は、書面による要件ではない合理的なユーザーの期待に対して、大したことはありません。しかし、逆に言えば、期待が明記されていない要件であるかのように装うことで、コストのかかる/非難のゲームをプレイする準備ができている顧客は、それほど慎重ではない。
私はそれが少し古い学校であることを知っています、しかし（全体として）何かが何をすべきかについての誤解は2つの文書のうちの1つによって分類されるべきです：
- ソフトウェア要件仕様（これはあなたが求めていると私たちが考えるものです）
- ソフトウェア設計仕様（これは私たちがそれを行う方法です）
これらは両方とも顧客の承認を得て、賛同する必要があります。
しかし、より「柔軟な」開発システム（アジャイル、スクラムなど）により、正式なライフサイクルは廃止されています。これ（IMHO）は、初期のソフトウェアエンジニアリングの「ワイルドウエスト」への回帰です。
これは、アンドリューのプロジェクト管理の法則につながりました。
最初に正しく実行するための時間/予算/リソースはありませんが、2回目（おそらく3回目）に実行する時間/予算/リソースは見つかります。
理想的な世界では、要件は可能な限り完全である必要があり、すべての期待が要件に変換されるため、期待からの逸脱はありません。
一方、現実の世界では、要件が不完全であることがよくあります。そのため、不本意な期待に応えることができます。例：
アプリケーションは最も単純なタスクを実行するのに10分かかり、完全に使用できなくなります（上記のDavid Schwartzの回答を参照）。
アプリケーションには青いボタンがありますが、利害関係者は青を嫌い、彼女の好きな色は黄色です。
すべてのユーザーのパスワードはプレーンテキストで保存され、「パスワードを忘れた」手順を実行するすべてのユーザーに表示されます。
ビジュアルデザインは最低です。
アプリケーションは機密情報を開発者に送り返します。開発者は、アプリケーションへのバックドアアクセスも可能であり、好きなことを実行できます。
いくつかの期待は非常に簡単に要件に変換されます。たとえば、最初の要件は、パフォーマンスに関連する単純な非機能要件で検証できます。
[...]のロードは、500ミリ秒未満の時間の85％を実行します。付録Gパート2で指定されたパフォーマンスを備え、CPUの負荷が15％未満、メモリの負荷が40％未満で、アクティブなR/Wディスク操作がないマシンでテストした場合。
他の人は1つではなく、いくつかの要件が必要です。たとえば、3番目のものは次のように表現できません。
システムは安全です。
または：
パスワードは安全な方法で保存されます。
どちらも要件ではないため、十分に正確ではなく、解釈の対象となります。客観的にテストすることはできません。つまり、ハッシュアルゴリズムに関する要件と、暗号化された安全な疑似乱数ジェネレータでパスワードを生成し、それを電子メールで送信することによる「パスワードを忘れた」手順の動作に関するいくつかの要件が必要になります。
また、いくつかの期待は他よりも客観性に近いです。少なくとも、ほとんどの人は5番目の例が有害なものを示していることに同意します：開発者は機密情報への完全なアクセス権を持つ必要はありません彼はもうプロジェクトに取り組んでいません。同じことはポイント4には当てはまりません。ポイント2の場合はなおさらです。好きな色は個人的なものであり、プロジェクトに対して文句なしの妥当な期待にはなりません。
客観性はあなたの質問に答えます。「利害関係者は、バグがこのようなものであると予想していたので、どこでもバグを見ることができました。それで、どうすれば本当に知ることができますか？」：
ほとんどの人が同じ製品に対して同じ期待を抱いている場合は、期待を実装することをお勧めします。すべてのパスワードをプレーンテキストで保存した場合、これを修正してコストをサポートするのはあなた次第です。結果の。一方、SHA512でハッシュしたが、ソルトを使用しなかった場合、PBKDF2が代わりに使用されることを期待したという理由だけで、利害関係者はこれをバグとして宣言できません。
異なる人々が異なる意見を持っている場合、利害関係者はより完全な要件を書いているはずです、あなたはおそらく利害関係者の好みを知ることができなかったので。
注：常識的な期待と常識的な期待を区別することを忘れないでください。
一部の要件は、適切な開発者から期待される一般的な慣行をカバーするため、省略されることがよくあります。これらの慣行から逸脱し、要件がないという事実によってそれを正当化することは、専門家ではありません。たとえば、非常に経験の浅いプログラマと作業しない限り、SQLインジェクションをウェブサイトに含めないように指定する必要はないと思います。
なぜこれらの要件が省略されているのですか？すべてを説明するのは費用がかかるからです。 WebアプリケーションがHTTPを使用する必要があることを伝える必要がありますか？データベースを使用する必要があることを伝える必要がありますか？または、Microsoft SQL ServerのFILESTREAM機能を使用しない限り、1GBの長さのファイルをRDBMSに保存しないということですか？
常識的な期待の例：「ローカルホストからだけでなく、どこからでもWebサイトにアクセスする必要があります。」ええ、そうです、それがウェブサイトの目的です。
一般的な慣行の期待の例：「WebサイトはHTML 4、HTML 5、またはXHTMLを使用する必要があります。」実際、HTML 3のWebサイトをゼロから作成することは、当時は非常にまれです。
要件は、期待値と開発された製品の間のインターフェースです：期待値->要件->製品
製品が期待から逸脱した場合、実際には2つの状態が含まれます。
要件と製品の偏差：それは明らかな「バグ」です。
要件と期待の間の偏差：バグかどうかを定義する方法は？私はMainMaの答えを好みます。要件は不完全であることが多いため、ほとんどの人が同じ製品に対して同じ期待を持っている場合は、要件で定義されていなくても、期待を実装することをお勧めします。
私は1つのケースを追加します：それが要件に転送されたときに期待が失われました。これらのバグは、分析からのバグまたはシステムレベルのバグとして定義されます。