1樓：夏花4399
有標準情況和非標準情況，這個問題很靈活，先說下標準情況
標準情況：
1.先有需求，也就是說我要什麼：A
2.研發團隊，根據需求做了什麼：B
3.測試檢驗需求和研發的匹配度，也就是A和B的匹配度，不一樣的地方統稱為bug
4.bug有不同的等級，嚴重的、一般的等等，如果bug越嚴重，越多，那麼開發團隊質量就越差
非標準情況：
1.需求：我要一條褲子，左腿長100公分，右腿長90公分
2.開發：做了一條褲子，左腿長100公分，右腿長90公分
3.測試：根據需求，褲子是對的，但是客戶兩條腿都是100公分，那麼現在算不算bug？
4.為了解決這個問題，我們把這個稱為需求bug
因為需求也是人寫的，只要是人寫的就會有問題，所以我們也說測試也是需求的提出人。
有不懂的再問
2樓：amoom
我認為的區分：
大家說的bug，往往指狹義的產品bug，其實需求也有bug，需求bug需要的是今早發現和解決，在確定需求階段就解決。
需求：之前未覆蓋的業務邏輯，使用者需求等。相對比較寬泛。
需求的bug如果進入到研發工程階段，最好是提交乙個「需求變更" 。需求變更其實是為了應對需求的bug。需求變更是需要額外的開發測試資源，並對產品的交付日期產生影響。
agile的乙個邊角作用就是應對這種後期發生的需求bug和需求變更。
3樓：城下秋草
需求-功能-bug
需求在功能實現前，bug在功能實現後。
需求描述需要實現的功能
bug描述功能實現未滿足需求的所在。
比較特殊的還有需求bug。即需求本身存在問題，在按照需求實現之前就能確定功能會存在缺陷，此時就是需求本身存在bug
4樓：醬油瓶12138
bug和需求有什麼難區分的？
bug是什麼？不符合需求的都屬於bug，也就是缺陷，這些是需要解決的，如果測試人員沒有發現，遺漏到生產環境，這是重大事故！相關人員是要追責的！
需求是什麼？需求是先於產品的，也就是說先有需求再有產品，產品是按照需求來製作的，需求也是測試的唯一標準。沒有需求就沒有產品，沒有標準也就沒有了所謂的缺陷bug。
5樓：allen
我把的這個問題理解為你是乙個產品經理在因為一些互動效果的缺失或者修改與工程師有爭執時的困惑：
產品經理：這個介面轉場應該是從坐至右切換，不是從上至下切換，這是個bug，請修改；
工程師：你的文件又沒定義具體的轉場效果，我現在給你做了個轉場就不錯了，你又要改，改你妹啊，動不動新增需求，專案延遲了不關我的事。
如果產品經理盡可能的把細節事先都考慮到，程式設計師盡可能的多點耐心和責任感，這樣子的爭執都不會存在。
所以與其弄清楚需求與BUG的區別，不如多些理解和包容。
求教「 」和「 」如何區分？
kirito 其實很好理解，並沒有其他人說的那麼麻煩 給你舉個例子你就知道了 時計 表掛在那 時計 正在掛表 再來一組 車 止 車停在那 車 止 正在停車 在車裡面操作著，正在停車 你也可以吧 理解為過去式 料理 頼 這個菜我已經點了 日本語教師 大東 誘N4 勉強 方 答意味不明 別途說明致 狀態...
如何區分be going to和will？
史蒂芬 be going to和will都是將來時，但這兩種將來發生的事情發生方式不同 be going to要發生的事情，一定是擺上了議事日程，已經進入發生的程式了，比如going to school,going to work，一定是心裡已經在計畫了，只等著下一步了。going to rain也...
經濟學上怎樣區分有效需求和社會負擔？
改之理zcw 有效需求這個概念通常是針對gdp這類東西提出的，也就是多生產出來的產品，而不是財富的總量。換句話說，財富減少了，所以我們提高生產，雖然財富並沒有變多，但有效需求提高了。有效需求的提高並不必然帶來產出的提高，它只在實際產出低於潛在產出的時候才能帶來這種提高。而如果例如治安惡化降低了潛在產...