第一篇：如何編寫高質(zhì)量的“軟件需求說明書”

如何編寫高質(zhì)量“軟件需求說明書”

你的工程應(yīng)該有個(gè)好的起點(diǎn)。一個(gè)小組要帶領(lǐng)客戶進(jìn)入需求啟發(fā)階段而且你要寫軟件需求說明書。這份說明有些大，但客戶會(huì)很重視，所以說明必須得到贊同。

現(xiàn)在你正在設(shè)計(jì)其中的一個(gè)特性，已經(jīng)發(fā)現(xiàn)了需求的一些問題。你可以用多種不同的方式解釋需求15；需求9 的說明正好與需求21相反，你因該相信哪一個(gè)？需求24非常含糊，你根本不明白它的意思；你不得不花上一個(gè)小時(shí)與2位開發(fā)人員討論需求30，只因?yàn)槟銈儗?duì)其各有各的理解；并且，唯一能夠澄清這些問題的客戶沒有給你們答復(fù)。你被迫破解眾多需求的含義，并且你能預(yù)料到，如果你錯(cuò)了，你要做大量的重復(fù)工作。

許多軟件需求說明書（SRS）寫得非常糟糕。任何產(chǎn)品的質(zhì)量需要其原始材料的質(zhì)量保證，糟糕的軟件需求說明書不可能產(chǎn)出優(yōu)秀的軟件。不幸的是，幾乎沒有開發(fā)人員受過與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的教育。而且，沒有非常多的好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個(gè)好的借鑒，其他原因是公司不愿意將其產(chǎn)品說明書放在公共區(qū)域。

這篇文章描述了高質(zhì)量需求敘述和說明的幾個(gè)特性（特點(diǎn)）。我們將用這些觀點(diǎn)檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會(huì)談一些如何編寫好的需求的提示。你也許想通過這些質(zhì)量標(biāo)準(zhǔn)評(píng)估你的工程需求。對(duì)于修訂，也許遲了，但你會(huì)學(xué)到一些有用的東西，并幫助你的小組在下次編寫出更好的需求。

不要期望能夠編寫出一份能體現(xiàn)需求應(yīng)具備的所有特性的SRS。無論你怎么細(xì)化、分析、評(píng)論和優(yōu)化需求，都不可能達(dá)到完美。但是，如果你牢記這些特性，你就會(huì)編寫出更好的需求，生產(chǎn)出更好的產(chǎn)品。

高質(zhì)量需求敘述的特性

我們?nèi)绾螐囊恍┯袉栴}的需求中分辨出好的軟件需求？這一節(jié)將分別介紹需求敘述應(yīng)體現(xiàn)的6個(gè)特性，下一節(jié)將從整體上介紹SRS文檔應(yīng)具備的特性。判斷每個(gè)需求是否具備應(yīng)有的特性的一種方式是由持有不同觀點(diǎn)的工程資金管理人所作的正規(guī)檢查。另一種有力的方法是在編寫代碼前依據(jù)需求編寫測(cè)試?yán)?。測(cè)試?yán)幽軌蛎鞔_顯現(xiàn)在需求中描述的產(chǎn)品行為（特性），能夠顯現(xiàn)缺陷、冗余和含糊之處。

正確：每個(gè)需求必須精確描述要交付的功能。正確性依據(jù)于需求的來源，如真實(shí)的客戶或高級(jí)別的系統(tǒng)需求說明書。一個(gè)軟件需求與其對(duì)應(yīng)的系統(tǒng)需求說明書相抵觸是不正確的（當(dāng)然，系統(tǒng)需求說明書本身可能不正確）。

只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶的需求檢查就會(huì)導(dǎo)致開發(fā)人員的：“這是沒意義的”，“這可能是他們的意思”等眾所周知的猜測(cè)。

可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。為了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開發(fā)人員參與，在抽象階段應(yīng)該有市場(chǎng)人員參與。這個(gè)開發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權(quán)衡。

必要性：每個(gè)需求應(yīng)載明什么是客戶確實(shí)需要的，什么要順應(yīng)于外部的需求，接口或標(biāo)準(zhǔn)。每個(gè)需求源于你認(rèn)可、具有權(quán)說明需求的原始資料，這是考慮必需的另外情形（譯注，此句翻譯不順，請(qǐng)參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來自其他用戶的意見。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒有真正的必須。

優(yōu)先權(quán)：為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)，需要為每個(gè)需求，特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)?？蛻艋蚱浯矶紤?yīng)有強(qiáng)烈的責(zé)任建立優(yōu)先權(quán)。如果所有的需求都被視為同等重要，那么由于在開發(fā)中，預(yù)算削減，計(jì)劃超時(shí)或組員的離開導(dǎo)致新的需求時(shí)，項(xiàng)目經(jīng)理將不能起到作用。優(yōu)先權(quán)的作用是提供給客戶的價(jià)值，實(shí)現(xiàn)的相關(guān)費(fèi)用，實(shí)現(xiàn)相關(guān)聯(lián)的有關(guān)技術(shù)風(fēng)險(xiǎn)。

我是用3種級(jí)別的優(yōu)先權(quán)：高優(yōu)先權(quán)表明需求必須體現(xiàn)在下一個(gè)產(chǎn)品版本中，中優(yōu)先權(quán)表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu)先權(quán)表明有它很好，但我們必須認(rèn)識(shí)到如果沒有充足的時(shí)間或資源，它可以被放棄掉。

明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。自然語(yǔ)言極易導(dǎo)致含糊。要避免使用一些對(duì)于SRS作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡(jiǎn)單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。每寫一個(gè)需要都應(yīng)簡(jiǎn)潔，簡(jiǎn)單，直觀的采用用戶熟知的語(yǔ)言，不要采用計(jì)算機(jī)術(shù)語(yǔ)。檢查需求模糊的有效方式包括需求說明書的正規(guī)檢查，根據(jù)需求寫測(cè)試，建立用戶的假想來說明產(chǎn)品某個(gè)特定部分預(yù)期的特性。

可證實(shí)：看你是否能夠做出測(cè)試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。如果需求是不可驗(yàn)證的，決定需求是不是正確的實(shí)現(xiàn)就成了判斷的事。需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。任何需求如果說產(chǎn)品將要支持什么也是不可證實(shí)的。

高質(zhì)量需求說明的特征

一個(gè)完整的SRS不僅是包括長(zhǎng)長(zhǎng)的功能性需求列表，還包括外部接口描述和一些諸如質(zhì)量屬性，期望性能的非功能性需求。下面描述了高質(zhì)量的SRS的一些特性。

完整：不應(yīng)該遺漏要求和必需的信息。完整性也是一個(gè)需求應(yīng)具備的。發(fā)現(xiàn)缺少的信息很難，因?yàn)楦静淮嬖?。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。

在需求抽象時(shí)，相對(duì)于系統(tǒng)功能，你過多的注意用戶的業(yè)務(wù)，將導(dǎo)致在需求的全局觀和引進(jìn)不是真正必需的需求上顯得不足。在需求抽象上，應(yīng)用用例方法會(huì)發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。

一致性：一致性需求就是不要于其他的軟件需求或高級(jí)別的系統(tǒng)（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開發(fā)開始前得到解決。只有經(jīng)過調(diào)研才能確定哪些是正確的。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。

可修改性：當(dāng)每個(gè)需求的要求修改了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。也就是說每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立目錄表，索引，以及前后參考（照）。

可追蹤：你應(yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)，如高級(jí)系統(tǒng)需求，用例，用戶的提議等。也能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的測(cè)試相對(duì)應(yīng)?？勺粉櫟男枨髴?yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫，不應(yīng)過大，不應(yīng)是敘述性的文字和公告式的列表。

需求質(zhì)量的評(píng)審

這些有關(guān)需求質(zhì)量的特性的描述在理論上都是非常好的，但一個(gè)好的需求到底是個(gè)什么樣子的呢？為了體現(xiàn)得更切合實(shí)際，我們做個(gè)小練習(xí)。下面有幾個(gè)從實(shí)際的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評(píng)估每個(gè)需求，看看有什么問題，然后用更好的方式重寫。我將對(duì)每個(gè)例子都提出自己的分析和改進(jìn)的建議。也歡迎你提出不同的見解。我所占優(yōu)的只是我知道每個(gè)需求的出處。因?yàn)槟阄叶疾皇钦嬲目蛻?，我們只能猜測(cè)每個(gè)需求的意圖。

例1．“產(chǎn)品應(yīng)在不少于每60秒的正常周期內(nèi)提供狀態(tài)信息”

這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個(gè)需求有幾處含糊。我們?cè)谡務(wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超過60秒，那么1毫秒是不是太短？“每”這個(gè)詞導(dǎo)致了不確定性。問題的后果，就是需求的不可證實(shí)。

彌補(bǔ)缺陷，重寫需求的一種方法：

1、狀態(tài)信息

1．1后臺(tái)任務(wù)管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息

1．2如果后臺(tái)進(jìn)程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù)/比

1．3任務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息

1．4后臺(tái)任務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息

為了分別測(cè)試和追蹤，我將其分成了多個(gè)需求。如果將幾個(gè)需求串接在一節(jié)中，在構(gòu)造和測(cè)試時(shí)就很容易漏掉一個(gè)。

例2．“產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換”

計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動(dòng)作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個(gè)的文檔，或其他的？這也是個(gè)模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問題的后果，就是需求的不可證實(shí)。

象這樣編寫需求也許更好一些：“用戶能夠在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換”?，F(xiàn)在就很清楚，不可打印字符是HTML標(biāo)記。由于沒有定義觸發(fā)條件，需求對(duì)設(shè)計(jì)沒有約束力。只有設(shè)計(jì)人員選定了觸發(fā)條件后，你才能編寫測(cè)試驗(yàn)證觸發(fā)的正確操作。

例3．“HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門者快速解決錯(cuò)誤”。單詞“快速”使其模糊，沒

有加進(jìn)錯(cuò)誤報(bào)告的定義也是其部完整。我不知道，你怎么驗(yàn)證這個(gè)需求。找一個(gè)自稱為HTML的入門者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤？

試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描述。如果沒有錯(cuò)誤，就不會(huì)產(chǎn)生錯(cuò)誤報(bào)告”。現(xiàn)在我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則留由設(shè)計(jì)人員決定。我們還指定了一個(gè)例外：如果沒有發(fā)現(xiàn)錯(cuò)誤，不產(chǎn)生錯(cuò)誤報(bào)告。

例4．“如果可能，主管號(hào)碼應(yīng)通過聯(lián)機(jī)校驗(yàn)，而不是通過主全體主管號(hào)碼列表校驗(yàn)”。真感到絕望，什么是“如果可能”：如果技術(shù)上可行？如果主全體主管號(hào)碼列表可以聯(lián)機(jī)獲得？要避免象“應(yīng)該”的這類不確切的詞?？蛻羰切枰@個(gè)功能性還是不需要。我曾看過一些需求說明書，采用諸如：應(yīng)，將，應(yīng)該/將要等一些詞描述優(yōu)先級(jí)的細(xì)微差別。但我更喜歡用“應(yīng)”清楚的說明需求的意圖，指明優(yōu)先級(jí)。這是修改后的：系統(tǒng)應(yīng)校驗(yàn)輸入的主管號(hào)碼而不通過聯(lián)機(jī)的主全體主官號(hào)碼列表。如果在列表中沒有發(fā)現(xiàn)主管號(hào)碼，將會(huì)顯示一條錯(cuò)誤信息，也不接受指令。

在理解各個(gè)已完成的糟糕需求上，開發(fā)人員將會(huì)遇到的難題是：開發(fā)人員與客戶將會(huì)在審核需求，未達(dá)成共識(shí)前發(fā)生激烈的爭(zhēng)論。詳細(xì)檢查大的需求文檔不是一件輕松的事情。我清楚有人做過，而且他們花在檢查上的每一分鐘都是值得的。相對(duì)于開發(fā)階段和用戶的抱怨電話，在這個(gè)階段修補(bǔ)缺陷是便宜的，編寫質(zhì)量需求的方針

編寫優(yōu)秀的需求是沒有公式化的方法的。這需要大量的經(jīng)驗(yàn)，要從你在過去的文檔中發(fā)現(xiàn)的問題學(xué)習(xí)。請(qǐng)?jiān)诮M織軟件需求文檔時(shí)，嚴(yán)格遵從這些方針。

句子和段落要短。采用主動(dòng)語(yǔ)氣。使用正確的語(yǔ)法，拼寫，標(biāo)點(diǎn)。使用術(shù)語(yǔ)，要保持一致性，并在術(shù)語(yǔ)表或數(shù)據(jù)字典中定義它們

要看需求是否被有效的定義，可以以開發(fā)人員的觀點(diǎn)看看。在內(nèi)心將“當(dāng)你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細(xì)化。

需求編寫者還要努力正確地把握細(xì)化程度。要避免包含多個(gè)需求的長(zhǎng)的敘述段落。有幫助的提示是編寫?yīng)毩⒌目蓽y(cè)試的需求。如果你認(rèn)為一小部分測(cè)試可以驗(yàn)證一個(gè)需求的正確，那么它已經(jīng)正確的細(xì)化了。如果你預(yù)想到多種不同類的測(cè)試，幾個(gè)需求可能已擠到了一起，需要拆分開。

密切關(guān)注多個(gè)需求合成了單個(gè)需求。一個(gè)需求中的連接詞“和”/“或”建議幾個(gè)需求合并。不要在一個(gè)需求中使用“和”/“或”。

通篇文檔細(xì)節(jié)上要保持一致。我曾看見過多個(gè)需求說明書前后不一致。如：“對(duì)于紅色合法的顏色代碼應(yīng)是R”及“對(duì)于綠色合法的顏色代碼應(yīng)是G”就有可以以分散的需求分離開，而“產(chǎn)品應(yīng)能對(duì)來自語(yǔ)音編輯指示做出反應(yīng)”應(yīng)作為一個(gè)子系統(tǒng)，不應(yīng)作為單個(gè)的功能性需求。

避免在SRS中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會(huì)給文檔的維護(hù)增加困難。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。

如果你遵從了這些方針，你能夠盡早地經(jīng)常正式或非正式的審查需求，這些需求對(duì)于產(chǎn)品的構(gòu)造，系統(tǒng)測(cè)試以及最后的客戶滿意，都會(huì)成為好的奠基石。并且要記住，沒有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠(yuǎn)不知道你會(huì)得到什么。

第二篇：如何編寫高質(zhì)量“軟件需求說明書”.doc

如何編寫高質(zhì)量“軟件需求說明書”2003-01-27· · ··天極論壇 2 下一頁(yè)

你的工程應(yīng)該有個(gè)好的起點(diǎn)。一個(gè)小組要帶領(lǐng)客戶進(jìn)入需求啟發(fā)階段而且你要寫軟件需求說明書。這份說明有些大，但客戶會(huì)很重視，所以說明必須得到贊同。

現(xiàn)在你正在設(shè)計(jì)其中的一個(gè)特性，已經(jīng)發(fā)現(xiàn)了需求的一些問題。你可以用多種不同的方式解釋需求15；需求9 的說明正好與需求21相反，你因該相信哪一個(gè)？需求24非常含糊，你根本不明白它的意思；你不得不花上一個(gè)小時(shí)與2位開發(fā)人員討論需求30，只因?yàn)槟銈儗?duì) 其各有各的理解；并且，唯一能夠澄清這些問題的客戶沒有給你們答復(fù)。你被迫破解眾多需求的含義，并且你能預(yù)料到，如果你錯(cuò)了，你要做大量的重復(fù)工作。

許多軟件需求說明書（SRS）寫得非常糟糕。任何產(chǎn)品的質(zhì)量需要其原始材料的質(zhì)量保證，糟糕的軟件需求說明書不可能產(chǎn)出優(yōu)秀的軟件。不幸的是，幾乎沒有開發(fā)人員受過與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的教育。而且，沒有非常多的好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個(gè)好的借鑒，其 他原因是公司不愿意將其產(chǎn)品說明書放在公共區(qū)域。

這篇文章描述了高質(zhì)量需求敘述和說明的幾個(gè)特性（特點(diǎn)）。我們將用這些觀點(diǎn)檢查一些有缺陷的需求，帶著痛楚重新編寫。而且我會(huì)談一些如何編寫好 的需求的提示。你也許想通過這些質(zhì)量標(biāo)準(zhǔn)評(píng)估你的工程需求。對(duì)于修訂，也許遲了，但你會(huì)學(xué)到一些有用的東西，并幫助你的小組在下次編寫出更好的需求。

不要期望能夠編寫出一份能體現(xiàn)需求應(yīng)具備的所有特性的SRS。無論你怎么細(xì)化、分析、評(píng)論和優(yōu)化需求，都不可能達(dá)到完美。但是，如果你牢記這些特性，你就會(huì)編寫出更好的需求，生產(chǎn)出更好的產(chǎn)品。

高質(zhì)量需求敘述的特性

我們?nèi)绾螐囊恍┯袉栴}的需求中分辨出好的軟件需求？這一節(jié)將分別介紹需求敘述應(yīng)體現(xiàn)的6個(gè)特性，下一節(jié)將從整體上介紹SRS文檔應(yīng)具備的特性。判斷每個(gè)需求是否具備應(yīng)有的特性的一種方式是由持有不同觀點(diǎn)的工程資金管理人所作的正規(guī)檢查。另一種有力的方法是在編寫代碼前依據(jù)需求編寫測(cè)試?yán)?。測(cè)試 例子能夠明確顯現(xiàn)在需求中描述的產(chǎn)品行為（特性），能夠顯現(xiàn)缺陷、冗余和含糊之處。

正確：每個(gè)需求必須精確描述要交付的功能。正確性依據(jù)于需求的來源，如真實(shí)的客戶或高級(jí)別的系統(tǒng)需求說明書。一個(gè)軟件需求與其對(duì)應(yīng)的系統(tǒng)需求說明書相抵觸是不正確的（當(dāng)然，系統(tǒng)需求說明書本身可能不正確）。

只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶的需求檢查就會(huì)導(dǎo)致開發(fā)人員的：“這是沒意義的”，“這可能是他們的意思”等眾所周知的猜測(cè)。

可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。為了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開發(fā)人員參與，在抽象階段應(yīng)該有市場(chǎng)人員參與。這個(gè)開發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權(quán)衡。

必要性：每個(gè)需求應(yīng)載明什么是客戶確實(shí)需要的，什么要順應(yīng)于外部的需求，接口或標(biāo)準(zhǔn)。每個(gè)需求源于你認(rèn)可、具有權(quán)說明需求的原始資料，這是考慮 必需的另外情形（譯注，此句翻譯不順，請(qǐng)參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來自其他用戶的意見。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒有真正的必須。

優(yōu)先權(quán)：為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)，需要為每個(gè)需求，特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)。客戶或其代理都應(yīng)有強(qiáng)烈的責(zé)任建立優(yōu) 先權(quán)。如果所有的需求都被視為同等重要，那么由于在開發(fā)中，預(yù)算削減，計(jì)劃超時(shí)或組員的離開導(dǎo)致新的需求時(shí)，項(xiàng)目經(jīng)理將不能起到作用。優(yōu)先權(quán)的作用是提供給客戶的價(jià)值，實(shí)現(xiàn)的相關(guān)費(fèi)用，實(shí)現(xiàn)相關(guān)聯(lián)的有關(guān)技術(shù)風(fēng)險(xiǎn)。

我是用3種級(jí)別的優(yōu)先權(quán)：高優(yōu)先權(quán)表明需求必須體現(xiàn)在下一個(gè)產(chǎn)品版本中，中優(yōu)先權(quán)表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu)先權(quán)表明有它很好，但我們必須認(rèn)識(shí)到如果沒有充足的時(shí)間或資源，它可以被放棄掉。

明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。自然語(yǔ)言極易導(dǎo)致含糊。要避免使用一些對(duì)于SRS 作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡(jiǎn)單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。每寫一個(gè)需要都應(yīng)簡(jiǎn)潔，簡(jiǎn)單，直觀的采用用戶熟知的語(yǔ)言，不要采用計(jì)算機(jī)術(shù)語(yǔ)。檢查需求模糊的有效方式包括需求說明書的正規(guī)檢查，根據(jù)需求寫測(cè)試，建立用戶的假想來說明產(chǎn)品某個(gè)特定部 分預(yù)期的特性。

可證實(shí)：看你是否能夠做出測(cè)試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。如果需求是不可驗(yàn)證的，決定需求是不 是正確的實(shí)現(xiàn)就成了判斷的事。需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。任何需求如果說產(chǎn)品將要支持什么也是不可證實(shí)的。

高質(zhì)量需求說明的特征

一個(gè)完整的SRS不僅是包括長(zhǎng)長(zhǎng)的功能性需求列表，還包括外部接口描述和一些諸如質(zhì)量屬性，期望性能的非功能性需求。下面描述了高質(zhì)量的SRS的一些特性。

完整：不應(yīng)該遺漏要求和必需的信息。完整性也是一個(gè)需求應(yīng)具備的。發(fā)現(xiàn)缺少的信息很難，因?yàn)楦静淮嬖?。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。

在需求抽象時(shí)，相對(duì)于系統(tǒng)功能，你過多的注意用戶的業(yè)務(wù)，將導(dǎo)致在需求的全局觀和引進(jìn)不是真正必需的需求上顯得不足。在需求抽象上，應(yīng)用用例方法會(huì)發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。

一致性：一致性需求就是不要于其他的軟件需求或高級(jí)別的系統(tǒng)（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開發(fā)開始前得到解決。只有經(jīng)過調(diào)研才能確定哪些是正確的。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。

可修改性：當(dāng)每個(gè)需求的要求修改了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。也就是說每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立目錄表，索引，以及前后參考（照）。

可追蹤：你應(yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)，如高級(jí)系統(tǒng)需求，用例，用戶的提議等。也能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的測(cè)試相對(duì)應(yīng)?？勺粉櫟男枨髴?yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫，不應(yīng)過大，不應(yīng)是敘述性的文字和公告式的列表。

需求質(zhì)量的評(píng)審

這些有關(guān)需求質(zhì)量的特性的描述在理論上都是非常好的，但一個(gè)好的需求到底是個(gè)什么樣子的呢？為了體現(xiàn)得更切合實(shí)際，我們做個(gè)小練習(xí)。下面有幾個(gè) 從實(shí)際的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評(píng)估每個(gè)需求，看看有什么問題，然后用更好的方式重寫。我將對(duì)每個(gè)例子都提出自己的分析和改進(jìn)的建議。也歡 迎你提出不同的見解。我所占優(yōu)的只是我知道每個(gè)需求的出處。因?yàn)槟阄叶疾皇钦嬲目蛻?，我們只能猜測(cè)每個(gè)需求的意圖。

例1．“產(chǎn)品應(yīng)在不少于每60秒的正常周期內(nèi)提供狀態(tài)信息”

這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個(gè)需 求有幾處含糊。我們?cè)谡務(wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超 過60秒，那么1毫秒是不是太短？“每”這個(gè)詞導(dǎo)致了不確定性。問題的后果，就是需求的不可證實(shí)。

彌補(bǔ)缺陷，重寫需求的一種方法：

1、狀態(tài)信息

1．1后臺(tái)任務(wù)管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息

1．2如果后臺(tái)進(jìn)程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù)/比

1．3任務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息

1．4后臺(tái)任務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息

為了分別測(cè)試和追蹤，我將其分成了多個(gè)需求。如果將幾個(gè)需求串接在一節(jié)中，在構(gòu)造和測(cè)試時(shí)就很容易漏掉一個(gè)。

例2．“產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換”

計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性 表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動(dòng)作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個(gè)的文檔，或其他的？這也是個(gè)模糊的問題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問題的后果，就是需求的不可證實(shí)。

象這樣編寫需求也許更好一些：“用戶能夠在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換”?，F(xiàn)在就很清楚，不可 打印字符是HTML標(biāo)記。由于沒有定義觸發(fā)條件，需求對(duì)設(shè)計(jì)沒有約束力。只有設(shè)計(jì)人員選定了觸發(fā)條件后，你才能編寫測(cè)試驗(yàn)證觸發(fā)的正確操作。

例3．“HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門者快速解決錯(cuò)誤”。單詞“快速”使其模糊，沒

有加進(jìn)錯(cuò)誤報(bào)告的定義也是其部完整。我不知道，你怎么驗(yàn)證這個(gè)需求。找一個(gè)自稱為HTML的入門者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤？

試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描述。如果沒有錯(cuò)誤，就不 會(huì)產(chǎn)生錯(cuò)誤報(bào)告”?，F(xiàn)在我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則留由設(shè)計(jì)人員決定。我們還指定了一個(gè)例外：如果沒有發(fā)現(xiàn)錯(cuò)誤，不產(chǎn)生錯(cuò)誤報(bào)告。

例4．“如果可能，主管號(hào)碼應(yīng)通過聯(lián)機(jī)校驗(yàn)，而不是通過主全體主管號(hào)碼列表校驗(yàn)”。真感到絕望，什么是“如果可能”：如果技術(shù)上可行？如果主全 體主管號(hào)碼列表可以聯(lián)機(jī)獲得？要避免象“應(yīng)該”的這類不確切的詞。客戶是需要這個(gè)功能性還是不需要。我曾看過一些需求說明書，采用諸如：應(yīng)，將，應(yīng)該/

將 要等一些詞描述優(yōu)先級(jí)的細(xì)微差別。但我更喜歡用“應(yīng)”清楚的說明需求的意圖，指明優(yōu)先級(jí)。這是修改后的：系統(tǒng)應(yīng)校驗(yàn)輸入的主管號(hào)碼而不通過聯(lián)機(jī)的主全體主 官號(hào)碼列表。如果在列表中沒有發(fā)現(xiàn)主管號(hào)碼，將會(huì)顯示一條錯(cuò)誤信息，也不接受指令。

在理解各個(gè)已完成的糟糕需求上，開發(fā)人員將會(huì)遇到的難題是：開發(fā)人員與客戶將會(huì)在審核需求，未達(dá)成共識(shí)前發(fā)生激烈的爭(zhēng)論。詳細(xì)檢查大的需求文檔 不是一件輕松的事情。我清楚有人做過，而且他們花在檢查上的每一分鐘都是值得的。相對(duì)于開發(fā)階段和用戶的抱怨電話，在這個(gè)階段修補(bǔ)缺陷是便宜的，編寫質(zhì)量需求的方針

編寫優(yōu)秀的需求是沒有公式化的方法的。這需要大量的經(jīng)驗(yàn)，要從你在過去的文檔中發(fā)現(xiàn)的問題學(xué)習(xí)。請(qǐng)?jiān)诮M織軟件需求文檔時(shí)，嚴(yán)格遵從這些方針。

句子和段落要短。采用主動(dòng)語(yǔ)氣。使用正確的語(yǔ)法，拼寫，標(biāo)點(diǎn)。使用術(shù)語(yǔ)，要保持一致性，并在術(shù)語(yǔ)表或數(shù)據(jù)字典中定義它們

要看需求是否被有效的定義，可以以開發(fā)人員的觀點(diǎn)看看。在內(nèi)心將“當(dāng)你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來。換句話說，你 是否需要SRS的編寫者的額外解釋幫助開發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細(xì)化。

需求編寫者還要努力正確地把握細(xì)化程度。要避免包含多個(gè)需求的長(zhǎng)的敘述段落。有幫助的提示是編寫?yīng)毩⒌目蓽y(cè)試的需求。如果你認(rèn)為一小部分測(cè)試可以驗(yàn)證一個(gè)需求的正確，那么它已經(jīng)正確的細(xì)化了。如果你預(yù)想到多種不同類的測(cè)試，幾個(gè)需求可能已擠到了一起，需要拆分開。

密切關(guān)注多個(gè)需求合成了單個(gè)需求。一個(gè)需求中的連接詞“和”/“或”建議幾個(gè)需求合并。不要在一個(gè)需求中使用“和”/“或”。

通篇文檔細(xì)節(jié)上要保持一致。我曾看見過多個(gè)需求說明書前后不一致。如：“對(duì)于紅色合法的顏色代碼應(yīng)是R”及“對(duì)于綠色合法的顏色代碼應(yīng)是G”就有可以以分散的需求分離開，而“產(chǎn)品應(yīng)能對(duì)來自語(yǔ)音編輯指示做出反應(yīng)”應(yīng)作為一個(gè)子系統(tǒng)，不應(yīng)作為單個(gè)的功能性需求。

避免在SRS中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會(huì)給文檔的維護(hù)增加困難。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。

如果你遵從了這些方針，你能夠盡早地經(jīng)常正式或非正式的審查需求，這些需求對(duì)于產(chǎn)品的構(gòu)造，系統(tǒng)測(cè)試以及最后的客戶滿意，都會(huì)成為好的奠基石。并且要記住，沒有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠(yuǎn)不知道你會(huì)得到什么。

第三篇：需求規(guī)格說明書編寫心得

需求規(guī)格說明書編寫心得

以下是本人總結(jié)的《需求規(guī)格說明書》編寫心得，由于人個(gè)水平有限，歡迎大家補(bǔ)充。

1.需求編寫依據(jù)

合同、招投標(biāo)文件、調(diào)研記錄以及項(xiàng)目經(jīng)理提供的已確定的需求規(guī)格說明書（內(nèi)部）等。

2.主動(dòng)與項(xiàng)目經(jīng)理的溝通

反復(fù)的溝通，才能深入把握項(xiàng)目的實(shí)際需求，獲得更多的資訊和資料。

3.項(xiàng)目背景

1)闡述目前遇到了什么樣的問題，并充分說明該問題的嚴(yán)重性和緊迫性，若能提供一些數(shù)據(jù)或運(yùn)用一些真實(shí)、典型的案例，不僅可以充分的說明該問題同時(shí)還能表明你對(duì)該項(xiàng)目的了解；

2)如何解決該問題；

3)為什么要提出這樣一個(gè)系統(tǒng)；

4)最后扼要概述該系統(tǒng)的長(zhǎng)遠(yuǎn)戰(zhàn)略意義。

這樣從邏輯上層層遞進(jìn)，不僅可以讓自己的思維嚴(yán)謹(jǐn)起來，也使自己寫出來的東西變得專業(yè)些。

4.系統(tǒng)總體概述

簡(jiǎn)單介紹系統(tǒng)的基本情況、特點(diǎn)、展示功能框架及闡述其優(yōu)勢(shì)。主要圍繞是什么，有什么樣的功能特點(diǎn)，能起到什么樣的作用。

5.術(shù)語(yǔ)與用詞

列出與系統(tǒng)有關(guān)的在文檔中一定會(huì)提到的專業(yè)術(shù)語(yǔ)，沒有提到的術(shù)語(yǔ)則不需要列出，否則會(huì)給讀者帶來一定的負(fù)擔(dān)。還有要統(tǒng)一表達(dá)方式，如“修改”，“編輯”，“用戶”，“員工”等等，以避免引發(fā)歧義。

另外，需求文檔不需要華麗的詞語(yǔ)，以客觀事實(shí)的原則，切忌摻和主觀思想，注意用詞準(zhǔn)確，精簡(jiǎn)表達(dá)其業(yè)務(wù)就可以。同時(shí)還需注意幾點(diǎn)：等等、很多等抽象詞盡量不使用；我認(rèn)為、以為等主觀詞語(yǔ)切忌出現(xiàn)，盡量避免口語(yǔ)化。

6.描述模塊

在編寫模塊時(shí)，通常包括模塊描述、重要業(yè)務(wù)及流程、功能需求定義、業(yè)務(wù)數(shù)據(jù)字典、原型界面圖等。

? 模塊描述

要明確指出建設(shè)了哪些功能，幫助用戶實(shí)現(xiàn)什么、目標(biāo)、基礎(chǔ)等

? 重要業(yè)務(wù)及流程

對(duì)該業(yè)務(wù)進(jìn)行認(rèn)真分析，得出該功能事項(xiàng)的有效規(guī)則，以激發(fā)該功能?？梢酝ㄟ^畫流程圖，快速幫助閱讀者理解，但一定要注意質(zhì)量，避免產(chǎn)生誤導(dǎo)。

? 功能需求定義

需求中每個(gè)功能點(diǎn)力求寫的清楚，一個(gè)需求文檔下來能清楚統(tǒng)計(jì)出功能有多少個(gè)，并指明什么用戶使用。一般情況下，要先寫簡(jiǎn)單的，權(quán)限少的角色。此文檔是設(shè)計(jì)的基礎(chǔ)，是系統(tǒng)驗(yàn)收的依據(jù)。

? 數(shù)據(jù)字典

寫出實(shí)體類的中英文屬性名稱、類型和說明（如是否為表主鍵）。

? 重要界面原型圖

該功能模塊的重要原型圖。

第四篇：《××項(xiàng)目軟件需求變更說明書》

軟件需求變更說明書

項(xiàng)目名稱： 長(zhǎng)益高速收費(fèi)數(shù)據(jù)分析系統(tǒng)一、概述

因湖南省高速公路聯(lián)網(wǎng)拆分系統(tǒng)軟件升級(jí)，導(dǎo)致長(zhǎng)益下屬收費(fèi)站入口和出

口交易數(shù)據(jù)、拆分?jǐn)?shù)據(jù)、代收拆分?jǐn)?shù)據(jù)無法獲取。而現(xiàn)階段省高管局監(jiān)控中心無法在上報(bào)報(bào)表日期內(nèi)提供拆分?jǐn)?shù)據(jù)，從而導(dǎo)致長(zhǎng)益高速收費(fèi)數(shù)據(jù)分析系統(tǒng)無法輸出相關(guān)報(bào)表。經(jīng)過深入了解和分析，在與業(yè)主方多次探討后，提出以下變更說明。

二、變更內(nèi)容

? MTC實(shí)收和流量

原始情況：

人工收費(fèi)系統(tǒng)出口站收費(fèi)數(shù)據(jù)和出口流量的導(dǎo)入，是由收費(fèi)站工作

人員從站級(jí)拆帳網(wǎng)下載的“收費(fèi)數(shù)據(jù)統(tǒng)計(jì)報(bào)表”并再錄入部分細(xì)分?jǐn)?shù)據(jù)，導(dǎo)入長(zhǎng)益收費(fèi)數(shù)據(jù)分析系統(tǒng)。

變更后：

收費(fèi)站工作人員在分析系統(tǒng)中MTC實(shí)收功能模塊中只錄入出口各車

型實(shí)收收入、各車型流量、免費(fèi)車流量、綠通車流量、系統(tǒng)外收入、綠通車減免金額、免費(fèi)車減免金額、手工票金額。

運(yùn)營(yíng)部工作人員在分析系統(tǒng)中MTC實(shí)收功能模塊中導(dǎo)入本路段各站

進(jìn)，其他路段出的代收流量的各車型估算流量。其中包括各車型流量、綠通車流量、免費(fèi)車流量。

? MTC實(shí)得

原始情況：

人工收費(fèi)系統(tǒng)實(shí)得數(shù)據(jù)的導(dǎo)入，是由收費(fèi)站工作人員從站級(jí)拆帳網(wǎng)

下載的“拆帳統(tǒng)計(jì)報(bào)表”，導(dǎo)入長(zhǎng)益收費(fèi)數(shù)據(jù)分析系統(tǒng)。

代收實(shí)得的導(dǎo)入，是由運(yùn)營(yíng)部工作人員從拆帳網(wǎng)下載的“長(zhǎng)張高速

公司名稱，版本號(hào)

2公路聯(lián)網(wǎng)收費(fèi)實(shí)際分配收入統(tǒng)計(jì)表”，導(dǎo)入長(zhǎng)益數(shù)據(jù)分析系統(tǒng)。

變更后：

運(yùn)營(yíng)部工作人員在分析系統(tǒng)中MTC實(shí)得功能模塊中導(dǎo)入估算MTC各

車型拆分收入。其中包括本路段各車型收入、系統(tǒng)外收入及代收業(yè)主各車型收入、系統(tǒng)外收入。

? 報(bào)表輸出

由于原始基礎(chǔ)數(shù)據(jù)的變更，所導(dǎo)致從數(shù)據(jù)模型上的建立發(fā)生了變化，從而將導(dǎo)致原長(zhǎng)益數(shù)據(jù)分析系統(tǒng)輸出報(bào)表無法根據(jù)原來基礎(chǔ)數(shù)據(jù)的數(shù)據(jù)輸出，需要轉(zhuǎn)換為估算的數(shù)據(jù)輸出，需要對(duì)所有的報(bào)表進(jìn)行修改。

需要修改的報(bào)表有以下：

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

? 公司－綠色通道車輛 公司－收費(fèi)站拆帳情況表 公司－單車收費(fèi)標(biāo)準(zhǔn)計(jì)算表 公司－流量對(duì)比表 公司－各類車流量收入比重對(duì)比圖 公司－各類車流量收入比重表 公司－實(shí)征率 公司－高速免費(fèi)車 公司－收費(fèi)車流量統(tǒng)計(jì) 公司－ETC收費(fèi)車與免費(fèi)車 公司－月流量分析 公司－ETC征費(fèi)情況 公司－月收入圖 公司－月收費(fèi)情況總表 公司-收費(fèi)車流量與收入統(tǒng)計(jì) 路勁-收入影響因素對(duì)比表 路勁-項(xiàng)目每月輸入及車流匯總表 路勁-各站每月收入及車流匯總表 路勁-歷年路費(fèi)收入圖 路勁-歷年次票車流量圖 路勁-日?qǐng)?bào) 省局-交通流量統(tǒng)計(jì)月報(bào)表 省局-綠色通道和免費(fèi)車公司名稱，版本號(hào)

? 省局-其他收入分項(xiàng)統(tǒng)計(jì)

? 三年同天對(duì)比-1月

? 三年同期對(duì)比-2月

? 三年同天對(duì)比-3月

? 三年同期對(duì)比-4月

? 三年同期對(duì)比-5月

? 三年同期對(duì)比-6月

? 三年同期對(duì)比-7月

? 三年同期對(duì)比-8月

? 三年同期對(duì)比-9月

? 三年同期對(duì)比-10月

? 三年同期對(duì)比-11月

? 三年同期對(duì)比-12月

? 周報(bào)-高速公路

? 周報(bào)-總表

? 周報(bào)-流量圖

? 周報(bào)-收入圖

? 周報(bào)-老路

? 月報(bào)-月收費(fèi)

? 月報(bào)-財(cái)務(wù)系統(tǒng)內(nèi)金額拆帳

? 月報(bào)-月度收費(fèi)情況

公司名稱，版本號(hào) 4

第五篇：如何寫軟件項(xiàng)目需求說明書

如何寫軟件項(xiàng)目需求說明書

進(jìn)入軟件開發(fā)行業(yè)也有一段時(shí)間了，大大小小項(xiàng)目也接觸了一些，對(duì)于怎么寫好項(xiàng)目需求文檔做一下總結(jié)，發(fā)表一下自己的看法。1 獲取需求：

作為需求方也就是甲方，通過語(yǔ)言描述或文檔的方式將需求（系統(tǒng)需要提供的功能）提交給開發(fā)人員（需求分析人員）。

獲得需求的方式可以有多種多樣：電話詢問、現(xiàn)場(chǎng)考察、聆聽用戶講解、閱讀用戶編制的相關(guān)文件(如招標(biāo)書)，其實(shí)這些方法都是GET方式，我們可以通過以下兩類技術(shù)手段來達(dá)到：GET(獲取)和PUSH(引導(dǎo)、反饋、激發(fā))相互結(jié)合的方式來得到我們真正的需求，而這兩個(gè)過程都是必須交互進(jìn)行的，一般我們可以篩選一名非常有經(jīng)驗(yàn)(包括談判技巧、深厚的業(yè)務(wù)和技術(shù)背景、人緣很好、勤奮努力)的人士擔(dān)任需求工程師，長(zhǎng)期在客戶那里工作。2 需求分析人員

（1）根據(jù)客戶提供的文檔或語(yǔ)言描述，將需求按功能劃分，以用例圖的方式表達(dá)系統(tǒng)提供的功能模塊及功能模塊之間的關(guān)系，完成用例圖后與客戶確認(rèn)大的功能模塊，并對(duì)每個(gè)功能模塊做進(jìn)一步的溝通詳細(xì)記錄用戶所提供的關(guān)鍵性的描述，此過程需要系統(tǒng)分析人員對(duì)客戶進(jìn)行引導(dǎo)。

（2）對(duì)每個(gè)功能模塊進(jìn)行詳細(xì)分析與描述，具體信息包括：用戶角色、功能說描述、IPO的方式進(jìn)行描述（即輸入項(xiàng)、輸出項(xiàng)、處理）、要提供必要的功能說明，如果使文檔更加直觀，更容易讓客戶理解，可以用UI的方式表達(dá)輸入輸出，配合必要的描述，這樣對(duì)于客戶更加容易理解，需要與客戶進(jìn)行大量的溝通確認(rèn)。

（3）編寫數(shù)據(jù)字典：在需求階段，很難使團(tuán)隊(duì)的思路一致，建立一個(gè)合適的機(jī)制是完全必要的，這就是數(shù)據(jù)字典，數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項(xiàng)以確?？蛻襞c開發(fā)小組是使用一致的定義和術(shù)語(yǔ)。分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。

（4）關(guān)于文檔具體表述的格式與形式，要根據(jù)所要表達(dá)的功能來確定，最重要的是把事情描述清楚,這事最終的目的；

(5)需求文檔確定后，設(shè)計(jì)人員根據(jù)這份需求文檔進(jìn)行系統(tǒng)的設(shè)計(jì)工作了。