【正文】 有些大，但客戶會很重視，所以說明必須得到贊同。你也許想通過這些質(zhì)量標(biāo)準(zhǔn)評估你的工程需求。這個開發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權(quán)衡。如果需求是不可驗證的，決定需求是不是正確的實現(xiàn)就成了判斷的事。修改需求時一定要謹(jǐn)慎，如果只審定修改的部分，沒有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。問題的后果，就是需求的不可證實?，F(xiàn)在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設(shè)計人員決定。　　句子和段落要短。如：“對于紅色合法的顏色代碼應(yīng)是R”及“對于綠色合法的顏色代碼應(yīng)是G”就有可以以分散的需求分離開，而“產(chǎn)品應(yīng)能對來自語音編輯指示做出反應(yīng)”應(yīng)作為一個子系統(tǒng)，不應(yīng)作為單個的功能性需求。一個需求中的連接詞“和”/“或”建議幾個需求合并。相對于開發(fā)階段和用戶的抱怨電話，在這個階段修補缺陷是便宜的。單詞“快速”使其模糊，沒有加進錯誤報告的定義也是其部完整。因為你我都不是真正的客戶，我們只能猜測每個需求的意圖。　　如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時，就可以從一個給定的需求集中解決所有的缺陷。要避免使用一些對于SRS作者很清楚但對于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個，藝術(shù)級，改善的，最大，最小等等?！　≈挥杏脩舻拇砟軌驔Q定用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的代理的關(guān)鍵所在 。而且，沒有非常多的好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個好的借鑒，其他原因是公司不愿意將其產(chǎn)品說明書放在公共區(qū)域。 　　許多軟件需求說明書（SRS）寫得非常糟糕。 　　正確：每個需求必須精確描述要交付的功能。 　　我是用3種級別的優(yōu)先權(quán)：高優(yōu)先權(quán)表明需求必須體現(xiàn)在下一個產(chǎn)品版本中，中優(yōu)先權(quán)表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu)先權(quán)表明有它很好，但我們必須認(rèn)識到如果沒有充足的時間或資源，它可以被放棄掉?！　≡谛枨蟪橄髸r，相對于系統(tǒng)功能，你過多的注意用戶的業(yè)務(wù)，將導(dǎo)致在需求的全局觀和引進不是真正必需的需求上顯得不足。我將對每個例子都提出自己的分析和改進的建議。由于沒有定義觸發(fā)條件，需求對設(shè)計沒有約束力?！　≡诶斫飧鱾€已完成的糟糕需求上，開發(fā)人員將會遇到的難題是：開發(fā)人員與客戶將會在審核需求，未達成共識前發(fā)生激烈的爭論。如果你認(rèn)為一小部分測試可以驗證一個需求的正確，那么它已經(jīng)正確的細化了。文檔的多