• 保持語句和段落的簡(jiǎn)短。
• 采用主動(dòng)語態(tài)的表達(dá)方式。
• 編寫具有正確的語法、拼寫和標(biāo)點(diǎn)的完整句子。
• 使用的術(shù)語與詞匯表中所定義的應(yīng)該一致。
• 需求陳述應(yīng)該具有一致的樣式,例如“系統(tǒng)必須??”或者“用戶必須??”,并緊跟一個(gè)行為動(dòng)作和可觀察的結(jié)果。例如,“倉庫管理子系統(tǒng)必須顯示一張所請(qǐng)求的倉庫中有存貨的化學(xué)藥品容器清單。”
• 為了減少不確定性,必須避免模糊的、主觀的術(shù)語,例如,用戶友好、容易、簡(jiǎn)單、迅速、有效、支持、許多、最新技術(shù)、優(yōu)越的、可接受的和健壯的。當(dāng)用客說“用戶友好”或者“快”或者“健壯”時(shí),你應(yīng)該明確它們的真正含義并且在需求中闡明用戶的意圖。
•
避免使用比較性的詞匯,例如:提高、最大化、最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。當(dāng)客戶說明系統(tǒng)應(yīng)該“
處理”、“支持”或“管理”某些事情時(shí),你應(yīng)該能理解客戶的意圖。含糊的語句表達(dá)將引起需求的不可驗(yàn)證。由于需求的編寫是層次化的,因此,可以把頂層不明
確的需求向低層詳細(xì)分解,直到消除不明確性為止。編寫詳細(xì)的需求文檔,所帶來的益處是如果需求得到滿足,那么客戶的目的也就達(dá)到了,但是不要讓過于詳細(xì)的
需求影響了設(shè)計(jì)。如果你能用不同的方法來滿足需求且這種方法都是可接受的,那么需求的詳細(xì)程度也就足夠了。然而,如果評(píng)審軟件需求規(guī)格說明的設(shè)計(jì)人員對(duì)客
戶的意圖還不甚了解,那么就需要增加額外的說明,以減少由于誤解而產(chǎn)生返工的風(fēng)險(xiǎn)。
•
編寫可測(cè)試需求文檔。需求文檔的編寫人員總是力求尋找到恰如其分的需求詳細(xì)
程度。一個(gè)有益的原則就是編寫單個(gè)的可測(cè)試需求文檔。如果你想出一些相關(guān)的測(cè)試用例可以驗(yàn)證這個(gè)需求能夠正確地實(shí)現(xiàn),那么就達(dá)到了合理的詳細(xì)程度。如果你
預(yù)想的測(cè)試很多并且很分散,那么可能就要將一些集合在一起的需求分離開。已經(jīng)建議將可測(cè)試的需求作為衡量軟件產(chǎn)品規(guī)模大小的尺度(Wilson
1995)。
•
文檔的編寫人員必須以相同的詳細(xì)程度編寫每個(gè)需求文檔。我曾見過在同一份軟件需求規(guī)格說明中,對(duì)需求的說明五花八門。例
如,“組合鍵C o n t r o l - S代表保存文件”和“組合鍵C o n t r o l -
P代表打印文件”被當(dāng)成兩個(gè)獨(dú)立的需求。然而,“產(chǎn)品必須響應(yīng)以語音方式輸入的編輯指令”則被作為一個(gè)子系統(tǒng),而并不作為一個(gè)簡(jiǎn)單的功能需求。文檔的編寫
人員不應(yīng)該把多個(gè)需求集中在一個(gè)冗長的敘述段落中。在需求中諸如“和”,“或”之類的連詞就表明了該部分集中了多個(gè)需求。務(wù)必記住,不要在需求說明中使用
“和/或”,“等等”之類的連詞。文檔的編寫人員在編寫軟件需求規(guī)格說明時(shí)不應(yīng)該出現(xiàn)需求冗余。雖然在不同的地方出現(xiàn)相同的需求可能會(huì)使文檔更易讀,但這
也造成了維護(hù)上的困難。需求的多個(gè)實(shí)例都需要同時(shí)更新,以免造成需求各實(shí)例之間的不一致。在軟件需求規(guī)格說明中交叉引用相關(guān)的各項(xiàng),在進(jìn)行更改時(shí)有助于保持它們之間的同步。讓獨(dú)立性強(qiáng)的需求在需求管理工具或數(shù)據(jù)庫中只出現(xiàn)一次,這樣可以緩和冗余問題。
================可有可無的分割線================
首先,應(yīng)重視需求分析的目的(意義),編寫目的明確,寫的詳細(xì),能確保文檔的質(zhì)量有所提高。
下面是一段需求分析意義的范例,希望對(duì)大家有所幫助。
1.6進(jìn)行需求分析的意義1. 本說明書將對(duì)用戶生產(chǎn)信息管理的業(yè)務(wù)、對(duì)系統(tǒng)要實(shí)現(xiàn)的主要功能、性能等需求進(jìn)行全面地闡述,以便幫助用戶判斷所要開發(fā)的軟件是否符合他們的要求。該說明書將在軟件開發(fā)目標(biāo)和需求方面為用戶和開發(fā)者之間創(chuàng)建一個(gè)共同的基礎(chǔ)和共識(shí)。
2. 由
于需求說明書要有用戶的審核、修改完善、認(rèn)定的過程,在這個(gè)過程中可以使用戶在軟件設(shè)計(jì)之前廣泛地征求各業(yè)務(wù)部門的意見、提出有關(guān)系統(tǒng)建設(shè)的建議、對(duì)自己
的需求和要求進(jìn)行周密地思考,并要把這些意見和建議反映到用戶需求說明書中。這樣就能減少事后重新設(shè)計(jì)、重新編碼和重新測(cè)試的返工行為。
3. 用戶需求的調(diào)查分析過程也是用戶對(duì)自己的業(yè)務(wù)和管理進(jìn)行總結(jié)和規(guī)范的過程,通過用戶需求說明書把用戶更加規(guī)范的管理反映到了軟件開發(fā)中,從而使用戶的管理更加完善和規(guī)范。
4. 需求說明書是開發(fā)者進(jìn)行軟件設(shè)計(jì)的依據(jù),軟件設(shè)計(jì)要依據(jù)本說明書將進(jìn)行系統(tǒng)分析、數(shù)據(jù)庫設(shè)計(jì)、模塊設(shè)計(jì)、接口設(shè)計(jì)、輸入輸出格式設(shè)計(jì)等。
5. 需求說明書使開發(fā)者在軟件進(jìn)行設(shè)計(jì)和開發(fā)之前,能夠充分了解和熟悉用戶的要求,并判斷這些要求是否有不能解決的技術(shù)問題,若有應(yīng)提出一個(gè)用戶認(rèn)可的代替解決方案。以免出現(xiàn)設(shè)計(jì)出的一個(gè)目標(biāo)不能在開發(fā)過程中實(shí)現(xiàn)的問題
6. 在需求調(diào)查和分析期間可以搜集有關(guān)系統(tǒng)開發(fā)的有關(guān)原始數(shù)據(jù)和代碼,以便在系統(tǒng)開發(fā)中建立開發(fā)環(huán)境時(shí)應(yīng)用
7. 在軟件開發(fā)方面為用戶和開發(fā)者提供一個(gè)標(biāo)準(zhǔn),為系統(tǒng)開發(fā)結(jié)束進(jìn)行確認(rèn)和驗(yàn)收提供一個(gè)雙方認(rèn)可的依據(jù)。
8. 便于軟件的維護(hù)和提高,為軟件維護(hù)和為今后對(duì)所開發(fā)的軟件進(jìn)行完善擴(kuò)充提供進(jìn)一步分析的基礎(chǔ)。
總之,用戶需求說明書的編寫是軟件工程中的非常關(guān)鍵的一個(gè)環(huán)節(jié),用戶說明書也是軟件工程中的非常重要的一個(gè)文檔。一個(gè)好的用戶需求說明書不但能夠提高軟件開發(fā)的效率、保障軟件開發(fā)的質(zhì)量,而且有利于系統(tǒng)的驗(yàn)收和以后軟件的維護(hù)及擴(kuò)充。
下面正式談一下我對(duì)需求文檔的一些寫作思路:
首先要對(duì)用戶機(jī)構(gòu)機(jī)構(gòu)有清晰的了解,寫出各機(jī)構(gòu)所涉及的業(yè)務(wù),畫出相應(yīng)業(yè)務(wù)的用例圖;之后提取出相應(yīng)的業(yè)務(wù)流程,畫出相應(yīng)的流程圖。通過業(yè)務(wù)流程,即可抽
象出系統(tǒng)需實(shí)現(xiàn)的功能。再將各業(yè)務(wù)(功能)涉及到對(duì)象(如人員,物品等)信息描述出來,根據(jù)提取出的信息將功能以IPO表(即輸入、處理、輸出表)的形式
進(jìn)行描述,逐項(xiàng)定量和定性地?cái)⑹鰧?duì)軟件所提出的功能要求,詳細(xì)的說明輸入什么量、經(jīng)怎樣的處理、得到什么輸出,并說明待開發(fā)軟件應(yīng)支持的終端數(shù)和應(yīng)支持的
并行操作的用戶數(shù)。需求文檔的主要部分就這樣完成了。
====================完全沒有必要的分割線=====================
引用topic:
http://www.javaeye.com/topic/178200