要看需求是否被有效的定義,可以以開發(fā)人員的觀點(diǎn)看看。在內(nèi)心將“當(dāng)你們做完了找我”這句加到文檔尾部,看看能不能是你緊張起來。換句話說,你是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求,以便于設(shè)計和實現(xiàn)?如果是的話,在繼續(xù)工作前,需求還需要細(xì)化。 需求編寫者還要努力正確地把握細(xì)化程度。要避免包含多個需求的長的敘述段落。有幫助的提示是編寫?yīng)毩⒌目蓽y試的需求。如果你認(rèn)為一小部分測試可以驗證一個需求的正確,那么它已經(jīng)正確的細(xì)化了。如果你預(yù)想到多種不同類的測試,幾個需求可能已擠到了一起,需要拆分開。 密切關(guān)注多個需求合成了單個需求。一個需求中的連接詞“和”/“或”建議幾個需求合并。不要在一個需求中使用“和”/“或”。 通篇文檔細(xì)節(jié)上要保持一致。我曾看見過多個需求說明書前后不一致。如:“對于紅色合法的顏色代碼應(yīng)是R”及“對于綠色合法的顏色代碼應(yīng)是G”就有可以以分散的需求分離開,而“產(chǎn)品應(yīng)能對來自語音編輯指示做出反應(yīng)”應(yīng)作為一個子系統(tǒng),不應(yīng)作為單個的功能性需求。 避免在SRS中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀,但也會給文檔的維護(hù)增加困難。文檔的多份文本要在同一時間內(nèi)全部更新,避免不一致性。 如果你遵從了這些方針,你能夠盡早地經(jīng)常正式或非正式的審查需求,這些需求對于產(chǎn)品的構(gòu)造,系統(tǒng)測試以及最后的客戶滿意,都會成為好的奠基石。并且要記住,沒有高質(zhì)量的需求,軟件就象一盒巧克力,你永遠(yuǎn)不知道你會得到什么。
此文章共有5頁 上一頁 1 2 3 4 5
文章來源:中國項目管理資源網(wǎng)
軟件開發(fā)項目管理培訓(xùn)課程方案 |