需求的方針
編寫優(yōu)秀的需求是沒有公式化的方法的。這需要大量的經(jīng)驗(yàn)，要從你在過去的文檔中發(fā)現(xiàn)的問題學(xué)習(xí)。請?jiān)诮M織軟件需求文檔時，嚴(yán)格遵從這些方針。
句子和段落要短。采用主動語氣。使用正確的語法，拼寫，標(biāo)點(diǎn)。使用術(shù)語，要保持一致性，并在術(shù)語表或數(shù)據(jù)字典中定義它們
要看需求是否被有效的定義，可以以開發(fā)人員的觀點(diǎn)看看。在內(nèi)心將“當(dāng)你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細(xì)化。
需求編寫者還要努力正確地把握細(xì)化程度。要避免包含多個需求的長的敘述段落。有幫助的提示是編寫?yīng)毩⒌目蓽y試的需求。如果你認(rèn)為一小部分測試可以驗(yà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)不知道你會得到什么。
項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
