軟件需求分析方法完整參考模板

1/58軟件需求分析方法軟件需求分析（SoftwareReguirementAnalysis）是研究用戶需求得到的東西，完全理解用戶對(duì)軟件需求的完整功能，確認(rèn)用戶軟件功能需求，建立可確認(rèn)的、可驗(yàn)證的一個(gè)基本依據(jù)。軟件需求分析是一個(gè)項(xiàng)目的開端，也是項(xiàng)目實(shí)施最重要的關(guān)鍵點(diǎn)。據(jù)有關(guān)的機(jī)構(gòu)分析結(jié)果表明，我們?cè)O(shè)計(jì)的軟件產(chǎn)品存在不完整性、不正確性等問題80％以上是需求分析錯(cuò)誤所導(dǎo)致的，而且由于需求分析錯(cuò)誤造成根本性的功能問題尤為突出。因此，一個(gè)項(xiàng)目的成功軟件需求分析是關(guān)鍵的一步。一、軟件需求分析理論如果我們用數(shù)學(xué)方法來描述軟件需求分析，可以將一個(gè)應(yīng)用軟件定義為S，可能應(yīng)用軟件涉及功能性問題非常廣，我們用抽象化理論分析，可以劃分為各個(gè)功能域，可以用D1、D2、…Dn表示，那么，我們可以用一個(gè)表達(dá)式描述為S={D1，D2，D3，…Dn}

但是，功能域Di依然存在著有若干個(gè)問題P1、P2、P3、…Pm組成，并且每個(gè)功能對(duì)應(yīng)于子系統(tǒng)中的一個(gè)軟構(gòu)件，我們可以表示為

Di={P1，P2，P3，…Pm}

同樣，功能Pj有若干個(gè)行為F1、F2、F3、…Fk，每個(gè)行為對(duì)應(yīng)于軟構(gòu)件中的實(shí)現(xiàn)方法Pj={F1，F(xiàn)2，F(xiàn)3，…Fk}一個(gè)軟件包含了所有功能的集合，同時(shí)包含了實(shí)現(xiàn)所有功能的所有方法和算法描述。需求分析是依據(jù)于用戶需求，經(jīng)過需求問題識(shí)別，進(jìn)行分析、消化與綜合，制訂規(guī)格說明，評(píng)審，分為四個(gè)階段，形成用戶需求與設(shè)計(jì)同步，設(shè)計(jì)滿足用戶需求目標(biāo)。需求分析方法始終貫穿著吸收、同化、貫徹方法和手段，用商業(yè)化行為解決需求與實(shí)現(xiàn)中存在的矛盾，解決用戶需求與商業(yè)化產(chǎn)品融通，解決規(guī)范與個(gè)性化追求。二、軟件需求分析目標(biāo)軟件需求分析的主要實(shí)現(xiàn)目標(biāo)：1）對(duì)實(shí)現(xiàn)軟件的功能做全面的描述，幫助用戶判斷實(shí)現(xiàn)功能的正確性、一致性和完整

性，促使用戶在軟件設(shè)計(jì)啟動(dòng)之前周密地、全面地思考軟件需求；2）了解和描述軟件實(shí)現(xiàn)所需的全部信息，為軟件設(shè)計(jì)、確認(rèn)和驗(yàn)證提供一個(gè)基準(zhǔn)；3）為軟件管理人員進(jìn)行軟件成本計(jì)價(jià)和編制軟件開發(fā)計(jì)劃書提供依據(jù)；需求分析的具體內(nèi)容可以歸納為六個(gè)方面：軟件的功能需求，軟件與硬件或其他外部系統(tǒng)接口，軟件的非功能性需求，軟件的反向需求，軟件設(shè)計(jì)和實(shí)現(xiàn)上的限制，閱讀支持信息。軟件需求分析應(yīng)盡量提供軟件實(shí)現(xiàn)功能需求的全部信息，使得軟件設(shè)計(jì)人員和軟件測(cè)試人員不再需要需求方的接觸。這就要求軟件需求分析內(nèi)容應(yīng)正確、完整、一致和可驗(yàn)證。此外，為保證軟件設(shè)計(jì)質(zhì)量，便于軟件功能的休整和驗(yàn)證，軟件需求表達(dá)無岔意性，具有可追蹤性和可修改性。2.1、

軟件功能需求軟件的功能需求是整個(gè)需求分析最主要、最關(guān)鍵和最復(fù)雜的部分，它描述軟件的各種可能的條件下，對(duì)所有可能輸入的數(shù)據(jù)信息，應(yīng)完成那些具體功能，產(chǎn)生什么樣的輸出。描述軟件功能需求是應(yīng)注意下面幾點(diǎn)：1）功能需求的完整性和一致性對(duì)功能的描述應(yīng)包含與功能相關(guān)的信息，并應(yīng)具有內(nèi)在的一致性（即各種描述之間不矛盾、不沖突）。應(yīng)注意以下幾點(diǎn)：（1）

給出觸發(fā)功能的各種條件（如：控制流、運(yùn)行狀態(tài)、運(yùn)行模式等）；（2）

定義各種可能性條件下的所有可能的輸入（包括合法的輸入空間和非法的輸入空間）；（3）

給出各種功能間可能的相互關(guān)系（如各個(gè)功能間的控制流、數(shù)據(jù)流、信息流，功能運(yùn)行關(guān)系：順序、重復(fù)、選擇、并發(fā)、同步）；（4）

給出功能性的主要級(jí)別（如：基本功能、可由設(shè)計(jì)者選擇逐步實(shí)現(xiàn)的功能、可由設(shè)計(jì)者改變實(shí)現(xiàn)的功能等）；（5）

盡可能不使用“待定”這樣的詞。所有含有待定內(nèi)容的需求都不是完整的文件，如果出現(xiàn)待定的部分，必須進(jìn)行待定部分內(nèi)容說明，落實(shí)負(fù)責(zé)人員、落實(shí)實(shí)施日期。2）功能描述的無岔意性和可追蹤性需求功能描述的無岔意性、可追蹤性和規(guī)范化：（1）

功能描述必須清晰地描述出怎樣輸入到怎樣輸出，并且輸入、輸出描述應(yīng)對(duì)應(yīng)有數(shù)據(jù)流描述、控制流描述圖，這些描述必須與其它地方描述一致；（2）

可以用語言、方程式、決策表、矩陣或圖等對(duì)功能的描述。如果選用語言描述必須使用結(jié)構(gòu)化的語言，描述前必須說明該步驟（或子功能）的執(zhí)行是順序，選擇，重復(fù)，還是并發(fā)，然后說明步驟邏輯。整個(gè)描述必須單入單出。（3）

描述時(shí)，每一個(gè)功能名稱和參照編號(hào)必須唯一，且不要將多個(gè)功能混在一起進(jìn)行描述，這樣便于功能的追蹤和修改。（4）

功能描述應(yīng)注意需求說明和程序設(shè)計(jì)的區(qū)別。需求設(shè)計(jì)僅僅是軟件的功能設(shè)計(jì)，它給出軟件運(yùn)行的的外部功能描述，以及為了實(shí)現(xiàn)這一外部功能必須做哪些事情（采用和種數(shù)據(jù)結(jié)構(gòu)，定義多個(gè)模塊，接口間的接口等）是設(shè)計(jì)階段的事情，功能描述不應(yīng)涉及到那些細(xì)節(jié)問題，以避免給軟件設(shè)計(jì)帶來不必要的約束。2.2、

軟件與硬件或其他外部系統(tǒng)接口軟件與硬件或其它外部系統(tǒng)接口包括下述內(nèi)容：（1）

人機(jī)接口：說明輸入、輸出的內(nèi)容、屏幕安排、格式等要求；（2）

硬件接口：說明端口號(hào)，指令集，輸入輸出信號(hào)的內(nèi)容與數(shù)據(jù)類型，初始化信號(hào)源，傳輸通道號(hào)和信號(hào)處理方式。（3）

軟件接口：說明軟件的名稱、助記符、規(guī)格說明、版本號(hào)和來源；（4）

通訊接口：指定通訊接口和通訊協(xié)議等描述。2.3、

軟件的非功能性需求軟件非功能性需求是指軟件性能指標(biāo)，容限等功能以外的需求。一般指下述內(nèi)容：（1）

時(shí)間需求：輸入、輸出頻率，輸入、輸出響應(yīng)時(shí)間，各種功能恢復(fù)時(shí)間等；（2）

處理容限、精度、采樣參數(shù)的分辨率，誤差處理等；（3）

可靠性的MTBF要求，可維護(hù)性、安全性要求等。（對(duì)可能的不正常的輸入給以正常響應(yīng)是可靠性的重要內(nèi)容，這屬于功能性需求。）2.4、

軟件反向需求軟件的反向需求描述軟件在那些情況下不能做什么。這一條是隨軟件實(shí)際要求而定。有兩類情形需要采用反向需求的形式。第一種情況：某些用戶需求適宜采用反向形式說明，如數(shù)據(jù)安全性要求屬于這類形式。第二種情況：對(duì)一些可靠性和安全性要求較高的軟件，有些必須描述軟件不能做些什么。如控制點(diǎn)火時(shí)序，我們必須交代清楚在那些情況下不能點(diǎn)火，否則會(huì)造成故障。2.5、

軟件設(shè)計(jì)和實(shí)現(xiàn)上的限制軟件設(shè)計(jì)和實(shí)現(xiàn)上的限制主要指對(duì)軟件設(shè)計(jì)者的限制。如軟件運(yùn)行環(huán)境的限制（選擇計(jì)算機(jī)類型，使用配置，操作系統(tǒng)的限制等）、設(shè)計(jì)工具的限制（使用語言、執(zhí)行的標(biāo)準(zhǔn)）和保密要求等。2.6、

閱讀支持信息這部分內(nèi)容是為了更好的幫助我們理解用戶需求，也是為了使需求便于修改和追蹤。其本身并不是對(duì)需求的描述，但它影響到需求分析的可讀性，也屬于需求分析的一個(gè)重要部分。一般目錄、需求背景信息、內(nèi)容索引、交叉引用表、注釋等均屬于這個(gè)部分的內(nèi)容。三、軟件需求分析人員組織軟件需求分析其根本性問題是理解用戶功能需求，由此軟件需求分析實(shí)際上是與客戶間交流過程完成的目標(biāo)。要求我們組織適當(dāng)?shù)膮⑴c人員進(jìn)行交流活動(dòng)。需求分析是一個(gè)綜合團(tuán)隊(duì)的工作，是在需求分析理論的指導(dǎo)下，對(duì)用戶需要進(jìn)行漸進(jìn)方式逐步深化；通過不斷變化方式形成具體約束；努力實(shí)現(xiàn)需求功能目標(biāo)形成特色效果的商業(yè)化產(chǎn)品。需求分析是一個(gè)商業(yè)行為，完全是一個(gè)商業(yè)化操作，要求有商業(yè)、技術(shù)等結(jié)合的團(tuán)隊(duì)共同合作，解決需求和設(shè)計(jì)的同步，設(shè)計(jì)符合需求。項(xiàng)目涉及內(nèi)容，項(xiàng)目大小都需要我們考慮參加軟件需求分析工作團(tuán)退的人數(shù)，配置合理的參與人員。一般我們必須有商務(wù)活動(dòng)人員，項(xiàng)目管理人員，設(shè)計(jì)技術(shù)人員等參加，而且要求組織人員必須明確負(fù)責(zé)范圍，以及明確工作目標(biāo)，保證實(shí)施的有效性。四、軟件需求分析方法為了保證項(xiàng)目的正常實(shí)施，并且能夠順利的完成，我們必須加強(qiáng)項(xiàng)目管理和重視項(xiàng)目分析工作。我們只有從實(shí)際出發(fā)，切切實(shí)實(shí)地把握用戶需求，把握用戶需求目標(biāo)，把握用戶將來功能界定，保證我們開發(fā)工作正確性方向。4.1、重點(diǎn)監(jiān)控軟件需求分析辦法由于軟件項(xiàng)目的特殊性和行業(yè)覆蓋的廣闊性，以及需求分析的高風(fēng)險(xiǎn)性，軟件需求分析的重要性是不言而喻的，同時(shí)需求分析又的的確確難做。其原因基本是由于以下情況造成的。4.1.1、客戶說不清楚需求有些客戶對(duì)需求只有朦朧的感覺，當(dāng)然說不清楚具體的需求。例如全國各地的很多部門、機(jī)構(gòu)、單位在進(jìn)行應(yīng)用系統(tǒng)以及網(wǎng)絡(luò)建設(shè)時(shí)，客戶方的辦公人員大多不清楚計(jì)算機(jī)網(wǎng)絡(luò)有什么用，更缺乏IT系統(tǒng)建設(shè)方面的專家和知識(shí)。此時(shí)，用戶就會(huì)要求軟件系統(tǒng)分析人員替他們?cè)O(shè)想需求。工程的需求存在一定的主觀性，為項(xiàng)目未來建設(shè)埋下了潛在的風(fēng)險(xiǎn)。4.1.2、需求自身經(jīng)常變動(dòng)根據(jù)以往的歷史經(jīng)驗(yàn)，隨著客戶方對(duì)信息化建設(shè)的認(rèn)識(shí)和自己業(yè)務(wù)水平的提高，他們會(huì)在不同的階段和時(shí)期對(duì)項(xiàng)目的需求提出新的要求和需求變更。事實(shí)上，歷史上沒有一個(gè)軟件的需求改動(dòng)少于三次的！所以必須接受“需求會(huì)變動(dòng)”這個(gè)事實(shí)，在進(jìn)行需求分析時(shí)要懂得防患于未然，盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求，以便在進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)，將軟件的核心建筑在穩(wěn)定的需求上，同時(shí)留出變更空間。咨詢監(jiān)理方在需求分析的功能界定上擔(dān)任一個(gè)中間、公平、公正的角色，所以也必須積極參與到需求分析的準(zhǔn)備中來，以便協(xié)助客戶方和承建方來界定“做什么”、“不做什么”的系統(tǒng)功能界限。4．1．3、分析人員或客戶理解有誤軟件系統(tǒng)分析人員不可能都是全才，更不可能是行業(yè)方面的專家?？蛻舯磉_(dá)的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯(cuò)了，可能會(huì)導(dǎo)致以后的開發(fā)工作勞而無功。記得一則笑話，有個(gè)外星人間諜潛伏到地球刺探情報(bào)，它給上司寫了一份報(bào)告：“主宰地球的是汽車。它們喝汽油，靠四個(gè)輪子滾動(dòng)前進(jìn)，嗓門極大，雙眼在夜里能射出強(qiáng)光……有趣的是，車?yán)镒≈环N叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！彼苑治鋈藛T知識(shí)的專一性也會(huì)造成需求分析的誤解和失敗。這時(shí)，咨詢監(jiān)理公司就必須根據(jù)實(shí)際的項(xiàng)目需求調(diào)研計(jì)劃，提醒承建方加強(qiáng)業(yè)務(wù)了解程度和注重溝通技巧。4.2、有效性軟件需求分析三步法根據(jù)以往的工程經(jīng)驗(yàn)，需求分析工作方法，應(yīng)該定位在“三個(gè)階段”（也稱“三步法”）。4.2.1、“訪談式Visitation”階段這一階段是和具體用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢(shì)，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對(duì)具體的職能部門以及各委辦局，最好能指定本次項(xiàng)目的接口人。實(shí)現(xiàn)手段：訪談、調(diào)查表格輸出成果：調(diào)查報(bào)告、業(yè)務(wù)流程報(bào)告4.2.2、“誘導(dǎo)式Inducement”階段這一階段是在承建方已經(jīng)了解了具體用戶方的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等等具體實(shí)際、客觀的信息基礎(chǔ)上，結(jié)合現(xiàn)有的硬件、軟件實(shí)現(xiàn)方案，做出簡單的用戶流程頁面，同時(shí)結(jié)合以往的項(xiàng)目經(jīng)驗(yàn)對(duì)用戶采用誘導(dǎo)式、啟發(fā)式的調(diào)研方法和手段，和用戶一起探討業(yè)務(wù)流程設(shè)計(jì)的合理性、準(zhǔn)確性、便易性、習(xí)慣性。用戶可以操作簡單演示的DEMO，來感受一下整個(gè)業(yè)務(wù)流程的設(shè)計(jì)合理性、準(zhǔn)確性等等問題，及時(shí)地提出改進(jìn)意見和方法。實(shí)現(xiàn)手段：拜訪（誘導(dǎo)）、原型演示輸出成果：調(diào)研分析報(bào)告、原型反饋報(bào)告、業(yè)務(wù)流程報(bào)告4.2.3、“確認(rèn)式Afirm”階段這一階段是在上述兩個(gè)階段成果的基礎(chǔ)上，進(jìn)行具體的流程細(xì)化、數(shù)據(jù)項(xiàng)的確認(rèn)階段，這個(gè)階段承建方必須提供原型系統(tǒng)和明確的業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表，并能清晰地向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計(jì)目標(biāo)。用戶方可以通過審查業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表以及操作承建方提供的DEMO系統(tǒng)，來提出反饋意見，并對(duì)已經(jīng)可接受的報(bào)告、文檔簽字確認(rèn)。實(shí)現(xiàn)手段：拜訪（回顧、確認(rèn)），提交業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表；原型演示系統(tǒng)輸出成果：需求分析報(bào)告、數(shù)據(jù)項(xiàng)、業(yè)務(wù)流程報(bào)告、原型系統(tǒng)反饋意見（后三者可以統(tǒng)一歸入需求分析報(bào)告中，提交用戶方、監(jiān)理方進(jìn)行確認(rèn)和存檔）整體來講，需求分析的三個(gè)階段是需求調(diào)研中不可忽視一個(gè)重要的部分，三個(gè)階段或者說三步法的實(shí)施和采用，對(duì)用戶和承建方都同樣提供了項(xiàng)目成功的保證。當(dāng)然在系統(tǒng)建設(shè)的過程中，特別在采用迭代法的開發(fā)模式時(shí)，需求分析的工作需一直進(jìn)行下去，而在后期的需求改進(jìn)中，工作則基本集中在后兩個(gè)階段中。五、軟件需求分析工具我們根據(jù)用戶需求，通過反復(fù)討論、分析，最終明確一個(gè)唯一性的用戶需求，這個(gè)結(jié)果其實(shí)就是我們的軟件需求分析報(bào)告。一般我們采用Word、PowerPoint、Visio、ProntPage、Excel等Office工具，同時(shí)可能采用一些開發(fā)工具，如VC或BC等，同樣也會(huì)使用一些圖形工具，如Potoshop、調(diào)色板等畫圖工具。使用各種工具表達(dá)軟件需求分析，其具體表達(dá)手段可以分為：

效果圖描述。主要是用戶UI界面的描述反映用戶需求功能；

邏輯圖描述。根據(jù)用戶需求功能，使用抽象化理論，以及需求分析理論，對(duì)用戶需求功能進(jìn)行全面的分析，建立功能性邏輯關(guān)系圖，流程邏輯關(guān)系圖等；

關(guān)系圖表描述。主要是對(duì)信息關(guān)系、數(shù)據(jù)庫表格、接口函數(shù)等描述；

工程數(shù)學(xué)描述。分析用戶需求，分析用戶需求信息，運(yùn)用工程數(shù)學(xué)進(jìn)行算法推導(dǎo)，進(jìn)行合理化需求分析推導(dǎo)；

甘地圖描述。主要是軟件項(xiàng)目工作安排，開發(fā)周期預(yù)估；

其它方法描述。保證完整性合理性的有效描述。六、軟件需求分析評(píng)估軟件需求分析評(píng)估是為了檢查我們進(jìn)行軟件需求分析工作，保證軟件需求分析工作正確性、完整性、有效性、合理性、可確認(rèn)性、可實(shí)施性，完全保證用戶所需求的功能。6.1、組織結(jié)構(gòu)與責(zé)任管理我們對(duì)組織結(jié)構(gòu)與責(zé)任管理的評(píng)估主要有：參與人員任務(wù)和責(zé)任界面的明確；安排計(jì)劃按時(shí)完成狀況；相互間的協(xié)調(diào)能力狀況。6.2、滿足用戶需求的功能我們進(jìn)行需求分析的目的是完整、準(zhǔn)確地描述用戶的需求，跟蹤用戶需求的變化，將用戶的需求準(zhǔn)確地反映到系統(tǒng)的分析和設(shè)計(jì)中，并使系統(tǒng)的分析、設(shè)計(jì)和用戶的需求保持一致。需求分析的特點(diǎn)是需求的完整性、一致性和可追溯性。完整性：是準(zhǔn)確、全面的描述用戶的需求。一致性：是通過分析整理，剔除用戶需求矛盾的方面，規(guī)范用戶需求?？勺匪菪裕河袃蓚€(gè)方面的含義，整理和規(guī)范的需求，其一，需要不斷的和用戶進(jìn)一步交流，保持和用戶最新的需求一致。其二，和系統(tǒng)分析（設(shè)計(jì)）保持一致。因此在需求分析之前我們必須建立需求分析技術(shù)層面的基本框架，從技術(shù)上保證需求分析的要求，在此基礎(chǔ)上我們進(jìn)行的需求分析才能滿足項(xiàng)目對(duì)需求分析的要求。6.3、保證可實(shí)施性我們必須以用戶軟件需求為依據(jù)，以求實(shí)的態(tài)度詳細(xì)的、準(zhǔn)確的、完整的編寫軟件需求分析，避免空想世界，空中樓閣的想法；避免無邏輯性、無核心的描述；避免無量化思維，無實(shí)際空間概念。6.4、需求分析評(píng)價(jià)指標(biāo)主要有這么幾個(gè)指標(biāo)：功能性、完整性、正確性、邏輯性、表現(xiàn)性、合理性，可實(shí)施性等。6.5、工作周期評(píng)價(jià)人員投入，以及費(fèi)用支出的合理性問題。正確制定工作周期，保證軟件項(xiàng)目的順利完成。6.6、需求不確定更改與可確認(rèn)保證可確認(rèn)需求功能是實(shí)現(xiàn)用戶需求的基本保證，如果不可確認(rèn)的、不確定更改存在，將會(huì)阻礙軟件實(shí)現(xiàn)，或者軟件設(shè)計(jì)存在著不完整性缺陷，或者存在著不可實(shí)施性問題，我們必須區(qū)分是功能性障礙問題，還是未來性問題。如果不能夠明確是未來性問題，則必須調(diào)整功能需求，化解不確定更改的問題。因此，判斷不確定性更改是一個(gè)非常重要的問題。、如何進(jìn)行軟件需求分析作者：曹偉來源：2003年3月10日進(jìn)入社區(qū)

需求的定義包括從用戶角度（系統(tǒng)的外部行為），以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求。

關(guān)鍵的問題是一定要編寫需求文檔。我曾經(jīng)目睹過一個(gè)項(xiàng)目中途更換了所有的開發(fā)者，客戶被迫與新的需求分析者坐到一起。系統(tǒng)的分析人員說：“我們想與你談?wù)勀愕男枨蟆！笨蛻舻牡谝环磻?yīng)便是：“我已經(jīng)將我的要求都告訴你們前任了，現(xiàn)在我要的就是給我編一個(gè)系統(tǒng)”。而實(shí)際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會(huì)談?dòng)涗浕蛞恍┝闼榈奈凑淼膶?duì)話，你就確信你已明白用戶的需求，那完全是自欺欺人。

需求的另外一種定義認(rèn)為需求是“用戶所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開發(fā)工作的說明”。有些需求分析專家拓展了這個(gè)概念：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點(diǎn)、功能及屬性等”。這些定義強(qiáng)調(diào)的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)計(jì)、構(gòu)造的。而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性：

需求是指明必須實(shí)現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對(duì)系統(tǒng)的約束。

從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個(gè)清晰、毫無二義性的“需求”術(shù)語存在，真正的“需求”實(shí)際上在人們的腦海中，這個(gè)人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語言的描述整理出相關(guān)的需要再進(jìn)一步和客戶核對(duì)。系統(tǒng)分析員和客戶需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識(shí)。

任何文檔形式的需求（例如如下將要描述的需求規(guī)格說明書）僅是一個(gè)模型，一種描述。2．需求分析的任務(wù)開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，將最終會(huì)給系統(tǒng)帶來極大損害的部分，并且以后再對(duì)它進(jìn)行修改也極為困難。

目前，國內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個(gè)系統(tǒng)并立運(yùn)行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。

對(duì)于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個(gè)大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對(duì)于我們開發(fā)人員來說，并沒有編寫出客戶認(rèn)可的需求文檔，我們?nèi)绾沃理?xiàng)目于何時(shí)結(jié)束？而如果我們不知道什么對(duì)客戶來說是重要的，那我們又如何能使客戶感到滿意呢？

然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當(dāng)然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價(jià)，這些血的教訓(xùn)正在國內(nèi)的軟件開發(fā)者身上發(fā)生。

近來，我遇到一個(gè)開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計(jì)算機(jī)輔助軟件。不幸的是，當(dāng)他們開發(fā)完這個(gè)工具后，發(fā)現(xiàn)這個(gè)工具不能打印出源代碼文件，使用者當(dāng)然希望有這個(gè)功能。結(jié)果這個(gè)小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構(gòu)思準(zhǔn)確，如果我們沒有編寫文檔，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了。

相反的情況，我曾見一個(gè)要集成到“錯(cuò)誤跟蹤系統(tǒng)”中的簡單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時(shí)發(fā)現(xiàn)簡單的一張需求清單竟是如此有用。他們依據(jù)需求對(duì)系統(tǒng)進(jìn)行測(cè)試時(shí)，此系統(tǒng)不僅非常清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯(cuò)誤。

事實(shí)上，需求文檔在開發(fā)過程中一直起指導(dǎo)作用。3．需求分析過程

可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適，如圖4-1所示：

圖4-1需求工程域的層次分解示意圖

需求開發(fā)可進(jìn)一步分為：問題獲取、分析、編寫規(guī)格說明和驗(yàn)證四個(gè)階段。這些子項(xiàng)包括軟件類產(chǎn)品中需求收集、評(píng)價(jià)、編寫文檔等所有活動(dòng)。需求開發(fā)活動(dòng)包括以下幾個(gè)方面：

確定產(chǎn)品所期望的用戶類別。

獲取每個(gè)用戶類的需求。

了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。

分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。

將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件組件。

了解相關(guān)質(zhì)量屬性的重要性。

商討實(shí)施優(yōu)先級(jí)的劃分。

將所收集的用戶需求編寫成文檔和模型。

評(píng)審需求規(guī)格說明，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚。

需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的合同”。這種合同都包含在編寫的需求文檔與模型中?？蛻舻慕邮軆H是需求成功的一半，開發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中。通常的需求管理活動(dòng)包括：

定義需求基線（迅速制定需求文檔的主體）。

評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。

以一種可控制的方式將需求變更融入到項(xiàng)目中。

使當(dāng)前的項(xiàng)目計(jì)劃與需求一致。

估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾，這種承諾具體體現(xiàn)在項(xiàng)目解決方案上。

讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤。

在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況。

以上幾點(diǎn)說明是我總結(jié)了成功實(shí)施項(xiàng)目后系統(tǒng)分析人員的經(jīng)驗(yàn)，同時(shí)也根據(jù)國內(nèi)外的其他系統(tǒng)實(shí)施的相關(guān)成功經(jīng)驗(yàn)，進(jìn)行了總結(jié)。4．需求的類型

下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義。

軟件需求包括三個(gè)不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。

1．業(yè)務(wù)需求（businessrequirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說明。

2．用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本說明中予以說明。

3．功能需求(functionalrequirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。

在軟件需求規(guī)格說明書（SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對(duì)一個(gè)大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）。

作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對(duì)用戶和開發(fā)人員都極為重要。

下面以一個(gè)字處理程序?yàn)槔齺碚f明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”，該產(chǎn)品的包裝盒封面上可能會(huì)標(biāo)明這是個(gè)滿足業(yè)務(wù)需求的拼寫檢查器。而對(duì)應(yīng)的用戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”。同時(shí)，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯(cuò)詞的操作；顯示提供替換詞的對(duì)話框以及實(shí)現(xiàn)整個(gè)文檔范圍的替換。

從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測(cè)試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說明你究竟想開發(fā)什么。項(xiàng)目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對(duì)項(xiàng)目成功也至關(guān)重要，但它們并非本書所要討論的。5．需求分析的原則不重視需求過程的項(xiàng)目隊(duì)伍將自食其果。需求工程中的缺陷將給項(xiàng)目成功帶來極大風(fēng)險(xiǎn)，這里的“成功”是指推出的產(chǎn)品能以合理的價(jià)格、及時(shí)地在功能、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風(fēng)險(xiǎn)。

不適當(dāng)?shù)男枨筮^程所引起的一些風(fēng)險(xiǎn):

1.無足夠用戶參與

客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費(fèi)那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因?yàn)殚_發(fā)人員感覺與用戶合作不如編寫代碼有意思；二是因?yàn)殚_發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實(shí)際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在項(xiàng)目早期直接參與到開發(fā)隊(duì)伍中，并一同經(jīng)歷整個(gè)開發(fā)過程。

系統(tǒng)人員在實(shí)踐過程中，也有些感覺，在實(shí)施一家公司的項(xiàng)目時(shí)，若無足夠的用戶參與，系統(tǒng)人員獲得的需求是片面的，不完整的，這樣系統(tǒng)在需求之初就埋下風(fēng)險(xiǎn)。

2.用戶需求的不斷增加

在開發(fā)中若不斷地補(bǔ)充需求，項(xiàng)目就越變?cè)烬嫶笠灾鲁^其計(jì)劃及預(yù)算范圍。計(jì)劃并不總是與項(xiàng)目需求規(guī)模與復(fù)雜性、風(fēng)險(xiǎn)、開發(fā)生產(chǎn)率及需求變更實(shí)際情況相一致，這使得問題更難解決。實(shí)際上，問題根源在于用戶需求的改變和開發(fā)者對(duì)新需求所作的修改。

要想把需求變更范圍控制到最小，必須一開始就對(duì)項(xiàng)目視圖、范圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給予明確說明，并將此說明作為評(píng)價(jià)需求變更和新特性的參照框架。說明中包括了對(duì)每種變更進(jìn)行變更影響因素分析的變更控制過程，有助于所有風(fēng)險(xiǎn)承擔(dān)者明白業(yè)務(wù)決策的合理性，即為何進(jìn)行某些變更，相應(yīng)消耗的時(shí)間、資源或特性上的折中。

產(chǎn)品開發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù)。插入補(bǔ)丁代碼使模塊違背強(qiáng)內(nèi)聚、松耦合的設(shè)計(jì)原則，特別是如果項(xiàng)目配置管理工作不完善的話，收回變更和刪除特性會(huì)帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個(gè)更為健壯的結(jié)構(gòu)，并能更好地適應(yīng)它。這樣設(shè)計(jì)階段需求變更不會(huì)直接導(dǎo)致補(bǔ)丁代碼，同時(shí)也有利于減少因變更導(dǎo)致質(zhì)量的下降。

3.模棱兩可的需求

模棱兩可是需求規(guī)格說明中最為可怕的問題。它的一層含義是指諸多讀者對(duì)需求說明產(chǎn)生了不同的理解；另一層含義是指單個(gè)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明。

模棱兩可的需求會(huì)使不同的風(fēng)險(xiǎn)承擔(dān)者產(chǎn)生不同的期望，它會(huì)使開發(fā)人員為錯(cuò)誤問題而浪費(fèi)時(shí)間，并且使測(cè)試者與開發(fā)者所期望的不一致。一位系統(tǒng)測(cè)試人員曾告訴我，她所在的測(cè)試組經(jīng)常對(duì)需求理解有誤，以致不得不重寫許多測(cè)試用例并重做許多測(cè)試。

處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊(duì)伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評(píng)審者從不同的角度對(duì)需求說明給予解釋，但每個(gè)評(píng)審人員都真正了解需求文檔，這樣二義性就不會(huì)直到項(xiàng)目后期才被發(fā)現(xiàn)，那時(shí)再發(fā)現(xiàn)的話會(huì)使得更正代價(jià)很大。

4.不必要的特性

“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認(rèn)為這些功能性很有用，以致在其上耗費(fèi)的努力“白搭”了。開發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識(shí)的思路，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時(shí)限內(nèi)的技術(shù)可行性之間求得平衡，開發(fā)人員應(yīng)努力使功能簡單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主張。

同樣，客戶有時(shí)也可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本。為了將“畫蛇添足”的危害盡量減小，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能。

5.過于精簡的規(guī)格說明

有時(shí)，客戶并不明白需求分析有如此重要，于是只作一份簡略之至的規(guī)格說明，僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項(xiàng)目進(jìn)展中去完善，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況。但在大多數(shù)情況下，這會(huì)給開發(fā)人員帶來挫折（使他們?cè)诓徽_的假設(shè)前提和極其有限的指導(dǎo)下工作），也會(huì)給客戶帶來煩惱（他們無法得到他們所設(shè)想的產(chǎn)品）。

6.忽略了用戶分類

大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同。如果你不能在項(xiàng)目早期就針對(duì)所有這些主要用戶進(jìn)行分類的話，必然導(dǎo)致有的用戶對(duì)產(chǎn)品感到失望。例如，菜單驅(qū)動(dòng)操作對(duì)高級(jí)用戶太低效了，但含義不清的命令和快捷鍵又會(huì)使不熟練的用戶感到困難。

7.不準(zhǔn)確的計(jì)劃

據(jù)統(tǒng)計(jì)，導(dǎo)致需求過程中軟件成本估計(jì)極不準(zhǔn)確的原因主要有以下五點(diǎn)：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。

對(duì)不準(zhǔn)確的要求所提問題的正確響應(yīng)是“等我真正明白你的需求時(shí)，我就會(huì)來告訴你”?；诓怀浞中畔⒑臀唇?jīng)深思的對(duì)需求不成熟的估計(jì)很容易為一些因素左右。要作出估計(jì)時(shí)，最好還是給出一個(gè)范圍。未經(jīng)準(zhǔn)備的估計(jì)通常是作為一種猜測(cè)給出的，聽者卻認(rèn)為是一種承諾。因此我們要盡力給出可達(dá)到的目標(biāo)并堅(jiān)持完成它。6．需求分析人員和用戶的合作關(guān)系

優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求基礎(chǔ)之上的。而高質(zhì)量的需求來源于客戶與開發(fā)人員之間有效的交流與合作。通常，開發(fā)人員與客戶或客戶代理人，如市場人員間的關(guān)系反而會(huì)成為一種對(duì)立關(guān)系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產(chǎn)生摩擦，在這種情況下，不會(huì)給雙方帶來一點(diǎn)益處。

只有當(dāng)雙方參與者都明白要成功自己需要什么，同時(shí)也應(yīng)知道要成功合作方需要什么時(shí)，才能建立起一種合作關(guān)系。由于項(xiàng)目壓力與日漸增，所有風(fēng)險(xiǎn)承擔(dān)者有著一個(gè)共同的目標(biāo)這一點(diǎn)容易被遺忘。其實(shí)大家都想開發(fā)出一個(gè)既能實(shí)現(xiàn)商業(yè)價(jià)值，又能滿足用戶需要，還能使開發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)品。

軟件客戶需求權(quán)利書列出了十條關(guān)于客戶在項(xiàng)目需求工程實(shí)施中與分析人員、開發(fā)人員交流時(shí)的合法要求。每一項(xiàng)權(quán)利都對(duì)應(yīng)著軟件開發(fā)人員、分析人員的義務(wù)。而軟件客戶需求義務(wù)書也列出了十條關(guān)于客戶在需求過程中應(yīng)承擔(dān)的義務(wù)。如果愿意，可以將其作為開發(fā)人員的權(quán)利書。

客戶有如下權(quán)利：

1：要求分析人員使用符合客戶語言習(xí)慣的表達(dá)

需求討論應(yīng)集中于業(yè)務(wù)需要和任務(wù)，故要使用業(yè)務(wù)術(shù)語，你應(yīng)將其教給分析人員，而你不一定要懂得計(jì)算機(jī)的行業(yè)術(shù)語。

2：要求分析人員了解客戶的業(yè)務(wù)及目標(biāo)

通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業(yè)務(wù)任務(wù)和怎樣才能使產(chǎn)品更好地滿足你的需要。這將有助于開發(fā)人員設(shè)計(jì)出真正滿足你的需要并達(dá)到你期望的優(yōu)秀軟件。為幫助開發(fā)人員和分析人員，可以考慮邀請(qǐng)他們觀察你或你的同事是怎樣工作的。如果新開發(fā)系統(tǒng)是用來替代已有的系統(tǒng)，那么開發(fā)人員應(yīng)使用一下目前的系統(tǒng)，這將有利于他們明白目前系統(tǒng)是怎樣工作的，其工作流程的情況，以及可供改進(jìn)之處。

3：要求分析人員編寫軟件需求規(guī)格說明

分析人員要把從你和其他客戶那里獲得的所有信息進(jìn)行整理，以區(qū)分開業(yè)務(wù)需求及規(guī)范、功能需求、質(zhì)量目標(biāo)、解決方法和其它信息。通過這些分析就能得到一份軟件需求規(guī)格說明。而這份軟件需求規(guī)格說明便在開發(fā)人員和客戶之間針對(duì)要開發(fā)的產(chǎn)品內(nèi)容達(dá)成了協(xié)議。軟件需求規(guī)格說明書可以用一種你認(rèn)為易于翻閱和理解的方式組織編寫。要評(píng)審編寫出的規(guī)格說明以確保它們準(zhǔn)確而完整地表達(dá)了你的需求。一份高質(zhì)量的軟件需求規(guī)格說明能有助于開發(fā)人員開發(fā)出真正需要的產(chǎn)品。

4：要求得到需求工作結(jié)果的解釋說明

分析人員可能采用了多種圖表作為文字性軟件需求規(guī)格說明的補(bǔ)充。因?yàn)槿绻ぷ髁鞒虉D那樣的圖表能很清楚地描述出系統(tǒng)行為的某些方面。所以需求說明中的各種圖表有著極高的價(jià)值。雖然它們不太難于理解，但是你很可能對(duì)此并不熟悉。因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發(fā)工作結(jié)果和符號(hào)的意義，及怎樣檢查圖表有無錯(cuò)誤及不一致等。

5：要求開發(fā)人員尊重你的意見

如果用戶與開發(fā)人員之間不能相互理解，那關(guān)于需求的討論將會(huì)有障礙，共同合作能使大家“兼聽則明”。參與需求開發(fā)過程的客戶有權(quán)要求開發(fā)人員尊重他們并珍惜他們?yōu)轫?xiàng)目成功所付出的時(shí)間。同樣，客戶也應(yīng)對(duì)開發(fā)人員為項(xiàng)目成功這一共同目標(biāo)所作出的努力表示尊重與感激。

6：要求開發(fā)人員對(duì)需求及產(chǎn)品實(shí)施提供建議，拿出主意

通常，客戶所說的“需求”已是一種實(shí)際可能的實(shí)施解決方案，分析人員將盡力從這些解決方法中了解真正的業(yè)務(wù)及其需求，同時(shí)還應(yīng)找出已有系統(tǒng)不適合當(dāng)前業(yè)務(wù)之處，以確保產(chǎn)品不會(huì)無效或低效。在徹底弄清業(yè)務(wù)領(lǐng)域內(nèi)的事情后，分析人員有時(shí)就能提出相當(dāng)好的改進(jìn)方法。有經(jīng)驗(yàn)且富有創(chuàng)造力的分析人員還能提出增加一些用戶并未發(fā)現(xiàn)的很有價(jià)值的系統(tǒng)特性。

7：描述產(chǎn)品易使用的特性

你可以要求分析人員在實(shí)現(xiàn)功能需求的同時(shí)還要注重軟件的易用性。因?yàn)檫@些易用特性或質(zhì)量屬性能使你更準(zhǔn)確、高效地完成任務(wù)。例如，客戶有時(shí)要求產(chǎn)品要“用戶友好”或“健壯”或“高效率”，但這對(duì)于開發(fā)人員來說，太主觀了并無實(shí)用價(jià)值。正確的應(yīng)是：分析人員通過詢問和調(diào)查了解客戶所要的友好、健壯、高效所包含的具體特性。

8：調(diào)整需求，允許重用已有的軟件組件

需求通常要有一定的靈活性。分析人員可能發(fā)現(xiàn)已有的某個(gè)軟件組件與你描述的需求很相符。在這種情況下，分析人員應(yīng)提供一些修改需求的選擇以便開發(fā)人員能夠在新系統(tǒng)開發(fā)中重用一些已有的軟件。如果有可重用的機(jī)會(huì)出現(xiàn)，同時(shí)你又能調(diào)整你的需求說明，那就能降低成本和節(jié)省時(shí)間，而不必嚴(yán)格按原有的需求說明開發(fā)。所以說，如果想在產(chǎn)品中使用一些已有的商業(yè)常用組件，而它們并不完全適合你所需的特性，這時(shí)一定程度上的需求靈活性就顯得極為重要了。

9：獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)

每個(gè)人都希望項(xiàng)目獲得成功。但這不僅要求你要清晰地告知開發(fā)人員關(guān)于系統(tǒng)“做什么”所需的所有信息，而且還要求開發(fā)人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設(shè)和潛在的期望。否則，開發(fā)人員開發(fā)出的產(chǎn)品很可能無法讓你滿意。

客戶有下列義務(wù)：

1：給分析人員講解你的業(yè)務(wù)

分析人員要依靠你給他們講解的業(yè)務(wù)概念及術(shù)語。但你不能指望分析人員會(huì)成為該領(lǐng)域的專家，而只能讓他們真正明白你的問題和目標(biāo)。不要期望分析人員能把握你們業(yè)務(wù)的細(xì)微與潛在之處，他們很可能并不知道那些對(duì)于你和你的同事來說理所當(dāng)然的“常識(shí)”。

2：抽出時(shí)間清楚地說明并完善需求

客戶很忙，經(jīng)常在最忙的時(shí)候還得參與需求開發(fā)。但無論如何，你有義務(wù)抽出時(shí)間參與“頭腦風(fēng)暴”會(huì)議的討論，接受采訪或其它獲取需求的活動(dòng)。有時(shí)分析人員可能先以為明白了你的觀點(diǎn)，而過后發(fā)現(xiàn)還需要你的講解。這時(shí)，請(qǐng)耐心一些對(duì)待需求和需求的精化工作過程中的反復(fù)，因?yàn)樗侨藗兘涣髦械暮茏匀坏默F(xiàn)象，何況這對(duì)軟件產(chǎn)品的成功極為重要。

3：準(zhǔn)確而詳細(xì)地說明需求

編寫一份清晰、準(zhǔn)確的需求文檔是很困難的。由于處理細(xì)節(jié)問題不但煩人而且又耗時(shí)，故很容易留下模糊不清的需求。但是，在開發(fā)過程中，必須得解決這種模糊性和不準(zhǔn)確性。而你恰是為解決這些問題作出決定的最佳人選。不然的話，你就只好靠開發(fā)人員去正確猜測(cè)了。在需求規(guī)格說明中暫時(shí)加上待定（tobedetermined,TBD也可采用漢語拼音略寫“DQD：待確定”）的標(biāo)志是個(gè)不錯(cuò)的辦法。用該標(biāo)志可指明了哪些需要進(jìn)一步探討、分析或增加信息的地方。不過，有時(shí)也可能因?yàn)槟硞€(gè)特殊需求難以解決或沒有人愿意處理它而注上TBD標(biāo)志。盡量將每項(xiàng)需求的內(nèi)容都闡述清楚，以便分析人員能準(zhǔn)確的將其寫進(jìn)軟件需求規(guī)格說明中。如果你一時(shí)不能準(zhǔn)確表述，那就得允許獲取必要的準(zhǔn)確信息這樣一個(gè)過程。通常使用所謂的原型技術(shù)。通過開發(fā)的原型，你可以同開發(fā)人員一起反復(fù)修改，不斷完善需求定義。

4：及時(shí)地作出決定

正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個(gè)用戶提出的處理方法或在質(zhì)量特性沖突和信息準(zhǔn)確度中選擇折衷方案等。有權(quán)做出決定的客戶必須積極地對(duì)待這一切，盡快做處理、做決定。因?yàn)殚_發(fā)人員通常只有等你做出了決定才能行動(dòng)，而這種等待會(huì)延誤項(xiàng)目的進(jìn)展。

5：尊重開發(fā)人員的需求可行性及成本評(píng)估

所有的軟件功能都有其成本價(jià)格，開發(fā)人員最適合預(yù)算這些成本（盡管許多開發(fā)人員并不擅長評(píng)估預(yù)測(cè)）。你所希望的某些產(chǎn)品特性可能在技術(shù)上行不通，或者實(shí)現(xiàn)它要付出極為高昂的代價(jià)。而某些需求試圖在操作環(huán)境中要求不可能達(dá)到的性能或試圖得到一些根本得不到的數(shù)據(jù)，開發(fā)人員會(huì)對(duì)此作出負(fù)面的評(píng)價(jià)意見，你應(yīng)該尊重他們的意見。有時(shí)，你可以重新給出一個(gè)在技術(shù)上可行、實(shí)現(xiàn)上便宜的需求，例如，要求某個(gè)行為在“瞬間”發(fā)生是不可行的，但換種更具體的時(shí)間需求說法（“在50ms以內(nèi)”,但若沒有準(zhǔn)確的技術(shù)分析不能輕易下結(jié)論），這就可以實(shí)現(xiàn)了。

6：劃分需求優(yōu)先級(jí)別

大多數(shù)項(xiàng)目沒有足夠的時(shí)間或資源來實(shí)現(xiàn)功能性的每個(gè)細(xì)節(jié)。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發(fā)的主要部分。只能由你來負(fù)責(zé)設(shè)定需求優(yōu)先級(jí)，因?yàn)殚_發(fā)者并不可能按你的觀點(diǎn)決定需求優(yōu)先級(jí)。開發(fā)者將為你確定優(yōu)先級(jí)提供有關(guān)每個(gè)需求的花費(fèi)和風(fēng)險(xiǎn)的信息。當(dāng)你設(shè)定優(yōu)先級(jí)時(shí)，你幫助開發(fā)者確保在適當(dāng)?shù)臅r(shí)間內(nèi)用最小的開支取得最好的效果。在時(shí)間和資源限制下，關(guān)于所需特性能否完成或完成多少應(yīng)該尊重開發(fā)人員的意見。盡管沒有人愿意看到自己所希望的需求在項(xiàng)目中未被實(shí)現(xiàn)，但畢竟是要面對(duì)這種現(xiàn)實(shí)的。業(yè)務(wù)決策有時(shí)不得不依據(jù)優(yōu)先級(jí)來縮小項(xiàng)目范圍或延長工期，或增加資源，或在質(zhì)量上尋找折衷。

7：評(píng)審需求文檔和原型

正如我們將在第14章討論的，無論是正式的還是非正式的方式，對(duì)需求文檔進(jìn)行評(píng)審都會(huì)對(duì)軟件質(zhì)量提高有所幫助。讓客戶參與評(píng)審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評(píng)審也給客戶代表提供一個(gè)機(jī)會(huì)，給需求分析人員帶來反饋信息以改進(jìn)他們的工作。如果你認(rèn)為編寫的需求文檔不夠準(zhǔn)確，就有義務(wù)盡早告訴分析人員并為改進(jìn)提供建議。通過閱讀需求規(guī)格說明，很難想象實(shí)際的軟件是什么樣子的。更好的方法是先為產(chǎn)品開發(fā)一個(gè)原型。這樣你就能提供更有價(jià)值的反饋信息給開發(fā)人員，幫助他們更好地理解你的需求。必須認(rèn)識(shí)到：原型并非是一個(gè)實(shí)際產(chǎn)品，但開發(fā)人員能將其轉(zhuǎn)變、擴(kuò)充成功能齊全的系統(tǒng)。

8：需求出現(xiàn)變更要馬上聯(lián)系

不斷的需求變更會(huì)給在預(yù)定計(jì)劃內(nèi)完成高質(zhì)量產(chǎn)品帶來嚴(yán)重的負(fù)面影響。變更是不可避免的，但在開發(fā)周期中變更越在晚期出現(xiàn)，其影響越大。變更不僅會(huì)導(dǎo)致代價(jià)極高的返工，而且工期也會(huì)被迫延誤，特別是在大體結(jié)構(gòu)已完成后又需要增加新特性時(shí)。所以一旦你發(fā)現(xiàn)需要變更需求時(shí)，請(qǐng)一定立即通知分析人員。

9：應(yīng)遵照開發(fā)組織處理需求變更的過程

為了將變更帶來的負(fù)面影響減少到最低限度，所有的參與者必須遵照項(xiàng)目的變更控制過程。這要求不放棄所有提出的變更，對(duì)每項(xiàng)要求的變更進(jìn)行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項(xiàng)目中。

10：尊重開發(fā)人員采用的需求工程過程

軟件開發(fā)中最具挑戰(zhàn)性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認(rèn)為需求過程不太劃算，但請(qǐng)相信花在需求開發(fā)上的時(shí)間是“很有價(jià)值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質(zhì)量所采用的技術(shù)，那么整個(gè)過程將會(huì)更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關(guān)的活動(dòng)。

系統(tǒng)分析人員在開發(fā)過程中可能會(huì)遇到以下問題，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導(dǎo)致不理想的產(chǎn)品。故一定要確保需求開發(fā)中的主要參與者都了解并接受他們的義務(wù)。如果遇到分歧，通過協(xié)商以達(dá)成對(duì)各自義務(wù)的相互理解，這樣能減少今后的摩擦。7．需求文檔

需求開發(fā)的最終成果是：客戶和開發(fā)小組對(duì)將要開發(fā)的產(chǎn)品達(dá)成一致協(xié)議。協(xié)議綜合了業(yè)務(wù)需求、用戶需求和軟件功能需求。就像我們?cè)缦人吹降?，?xiàng)目視圖和范圍文檔包含了業(yè)務(wù)需求，而使用實(shí)例文檔則包含了用戶需求。你必須編寫從使用實(shí)例派生出的功能需求文檔，還要編寫產(chǎn)品的非功能需求文檔，包括質(zhì)量屬性和外部接口需求。只有以結(jié)構(gòu)化和可讀性方式編寫這些文檔，并由項(xiàng)目的風(fēng)險(xiǎn)承擔(dān)者評(píng)審?fù)ㄟ^后，各方面人員才能確信他們所贊同的需求是可靠的。

你可以使用以下三種方法編寫軟件需求規(guī)格說明：

用好的結(jié)構(gòu)化和自然語言編寫文本型文檔。

建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退鼈兊年P(guān)系。

編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上精確的形式化邏輯語言來定義需求。

由于形式化規(guī)格說明具有很強(qiáng)的嚴(yán)密性和精確度，因此，所使用的形式化語言只有極少數(shù)軟件開發(fā)人員才熟悉，更不用說客戶了。雖然結(jié)構(gòu)化的自然語言具有許多缺點(diǎn)，但在大多數(shù)軟件工程中，它仍是編寫需求文檔最現(xiàn)實(shí)的方法。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說明已經(jīng)為大多數(shù)項(xiàng)目所接受。圖形化分析模型通過提供另一種需求視圖，增強(qiáng)了軟件需求規(guī)格說明。

軟件需求規(guī)格說明不僅是系統(tǒng)測(cè)試和用戶文檔的基礎(chǔ)，也是所有子系列項(xiàng)目規(guī)劃、設(shè)計(jì)和編碼的基礎(chǔ)。它應(yīng)該盡可能完整地描述系統(tǒng)預(yù)期的外部行為和用戶可視化行為。除了設(shè)計(jì)和實(shí)現(xiàn)上的限制，軟件需求規(guī)格說明不應(yīng)該包括設(shè)計(jì)、構(gòu)造、測(cè)試或工程管理的細(xì)節(jié)。許多讀者使用軟件需求規(guī)格說明來達(dá)到不同的目的：

客戶和營銷部門依賴它來了解他們所能提供的產(chǎn)品。

項(xiàng)目經(jīng)理根據(jù)包含在軟件需求規(guī)格說明中描述的產(chǎn)品來制定規(guī)劃并預(yù)測(cè)進(jìn)度安排、工作量和資源。

軟件開發(fā)小組依賴它來理解他們將要開發(fā)的產(chǎn)品。

測(cè)試小組使用軟件需求規(guī)格說明中對(duì)產(chǎn)品行為的描述制定測(cè)試計(jì)劃、測(cè)試用例和測(cè)試過程。

軟件維護(hù)和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的某部分是做什么的。

產(chǎn)品發(fā)布組在需求規(guī)格說明和用戶界面設(shè)計(jì)的基礎(chǔ)上編寫客戶文檔，如用戶手冊(cè)和幫助屏幕等。

培訓(xùn)人員根據(jù)需求規(guī)格說明和用戶文檔編寫培訓(xùn)材料。

軟件需求規(guī)格說明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開發(fā)者和客戶不能作任何假設(shè)。如果任何所期望的功能或非功能需求未寫入軟件需求規(guī)格說明，那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。

我見過有一個(gè)項(xiàng)目突然接到測(cè)試人員發(fā)出的錯(cuò)誤災(zāi)難的報(bào)告。結(jié)果是他們測(cè)試的是老版本的軟件需求規(guī)格說明，而他們覺得錯(cuò)誤的地方正是產(chǎn)品所獨(dú)有的特性。他們的測(cè)試工作是徒勞的，因?yàn)樗麄円恢痹诶习姹镜能浖枨笠?guī)格說明中尋找錯(cuò)誤的系統(tǒng)行為。

在編寫軟件需求規(guī)格說明，希望讀者牢記以下的建議：

對(duì)節(jié)、小節(jié)和單個(gè)需求的號(hào)碼編排必須一致。

在右邊部分留下文本注釋區(qū)。

允許不加限制地使用空格。

正確使用各種可視化強(qiáng)調(diào)標(biāo)志（例如，黑體、下劃線、斜體和其它不同字體）。

創(chuàng)建目錄表和索引表有助于讀者尋找所需的信息。

對(duì)所有圖和表指定號(hào)碼和標(biāo)識(shí)號(hào)，并且可按號(hào)碼進(jìn)行查閱。

使用字處理程序中交叉引用的功能來查閱文檔中其它項(xiàng)或位置，而不是通過頁碼或節(jié)號(hào)。

為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質(zhì)量標(biāo)準(zhǔn)，必須唯一確定每個(gè)軟件需求。這可以使你在變更請(qǐng)求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達(dá)到這一目的，用單一的項(xiàng)目列表是不夠的，因此，我將描述幾個(gè)不同的需求標(biāo)識(shí)方法，并闡明它們的優(yōu)點(diǎn)與缺點(diǎn)?？梢赃x擇最適合你的方法。

(1)序列號(hào)最簡單的方法是賦予每個(gè)需求一個(gè)唯一的序列號(hào)，例如SRS-13。當(dāng)一個(gè)新的需求加入到商業(yè)需求管理工具的數(shù)據(jù)庫之后，這些管理工具就會(huì)為其分配一個(gè)序列號(hào)（許多這樣的工具也支持層次化編號(hào)）。序列號(hào)的前綴代表了需求類型，例如SRS代表“軟件需求說明”。由于序列號(hào)不能重用，所以把需求從數(shù)據(jù)庫中刪除時(shí)，并不釋放其所占據(jù)的序列號(hào)，而新的需求只能得到下一個(gè)可用的序列號(hào)。這種簡單的編號(hào)方法并不能提供任何相關(guān)需求在邏輯上或?qū)哟紊系膮^(qū)別，而且需求的標(biāo)識(shí)不能提供任何有關(guān)每個(gè)需求內(nèi)容的信息。

(2)層次化編碼這也許是最常用的方法。如果功能需求出現(xiàn)在軟件需求規(guī)格說明中第3.2部分，那么它們將具有諸如這樣的標(biāo)識(shí)號(hào)。標(biāo)識(shí)號(hào)中的數(shù)字越多則表示該需求越詳細(xì)，屬于較低層次上的需求。即使在一個(gè)中型的軟件需求規(guī)格說明中，這些標(biāo)識(shí)號(hào)也會(huì)擴(kuò)展到許多位數(shù)字，并且這些標(biāo)識(shí)也不提供任何有關(guān)每個(gè)需求目的的信息。如果你要插入一個(gè)新的需求，那么該需求所在部分其后所有需求的序號(hào)將要增加。刪除或移去一個(gè)需求，那么該需求所在部分其后所有需求的序號(hào)將要減少。但其他地方的引用將混亂，對(duì)于這種簡單的層次化編號(hào)的一種改進(jìn)方法是對(duì)需求中主要的部分進(jìn)行層次化編號(hào)，然后對(duì)于每個(gè)部分中的單一功能需求用一個(gè)簡短文字代碼加上一個(gè)序列號(hào)來識(shí)別。例如，軟件需求規(guī)格說明可能包含“第3.2.5部分—編輯功能”，并將此部分編寫成子模塊文檔，然后配置管理。

有時(shí)，你覺得缺少特定需求的某些信息。在解決這個(gè)不確定性之前，可能必須與客戶商議、檢查與另一個(gè)系統(tǒng)的接口或者定義另一個(gè)需求。使用“待確定”（tobedetermined,TBD或采用漢語拼音略寫DQD）符號(hào)作為標(biāo)準(zhǔn)指示器來強(qiáng)調(diào)軟件需求規(guī)格說明中這些需求的缺陷。通過這種方法，你可以在軟件需求規(guī)格說明中查找所要澄清需求的部分。記錄誰將解決哪個(gè)問題、怎樣解決及什么時(shí)候解決。把每個(gè)TBD編號(hào)并創(chuàng)建一個(gè)TBD列表，這有助于方便地跟蹤每個(gè)項(xiàng)目。

在繼續(xù)進(jìn)行構(gòu)造需求集合之前，必須解決所有的TBD問題，因?yàn)槿魏芜z留下來的不確定問題將會(huì)增加出錯(cuò)的風(fēng)險(xiǎn)和需求返工。當(dāng)開發(fā)人員遇到一個(gè)TBD問題或其它模糊之處時(shí)，他可能不會(huì)返回到原始需求來解決問題。多半開發(fā)者對(duì)它進(jìn)行猜測(cè)，但并不總是正確的。如果有TBD問題尚未解決，而你又要繼續(xù)進(jìn)行開發(fā)工作，那么盡可能推遲實(shí)現(xiàn)這些需求，或者解決這些需求的開放式問題，把產(chǎn)品的這部分設(shè)計(jì)得易于更改。

編寫優(yōu)秀的需求文檔沒有現(xiàn)成固定的方法，最好是根據(jù)經(jīng)驗(yàn)進(jìn)行。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術(shù)編寫風(fēng)格和使用用戶術(shù)語而不是計(jì)算機(jī)專業(yè)術(shù)語的方式得以改進(jìn)。

你在編寫優(yōu)秀的需求文檔時(shí)，希望讀者還需牢記以下幾點(diǎ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)求的倉庫中有存貨的庫存清單?！?/p>

為了減少不確定性，必須避免模糊的、主觀的術(shù)語，例如，用戶友好、簡單、有效、、最新技術(shù)、優(yōu)越的、可接受的等。當(dāng)用客說“用戶友好”或者“快”時(shí)，你應(yīng)該明確它們的真正含義并且在需求中闡明用戶的意圖。

避免使用比較性的詞匯，定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。當(dāng)客戶說明系統(tǒng)應(yīng)該“處理”、“支持”或“管理”某些事情時(shí)，你應(yīng)該能理解客戶的意圖。由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細(xì)分解，直到消除不明確性為止。

文檔的編寫人員不應(yīng)該把多個(gè)需求集中在一個(gè)冗長的敘述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個(gè)需求。務(wù)必記住，不要在需求說明中使用“和/或”，“等等”之類的連詞。8．需求分析的過程

需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個(gè)必不可少的結(jié)果是對(duì)項(xiàng)目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發(fā)者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設(shè)計(jì)系統(tǒng)，否則，對(duì)需求定義的任何改進(jìn)，設(shè)計(jì)上都必須大量的返工。把需求獲取集中在用戶任務(wù)上—而不是集中在用戶接口上—有助于防止開發(fā)組由于草率處理設(shè)計(jì)問題而造成的失誤。

需求獲取、分析、編寫需求規(guī)格說明和驗(yàn)證并不遵循線性的順序，這些活動(dòng)是相互隔開、增量和反復(fù)的。當(dāng)你和客戶合作時(shí)，你就將會(huì)問一些問題，并且取得他們所提供的信息（需求獲?。?。同時(shí)，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯(lián)系。然后，你可以使客戶信息結(jié)構(gòu)化，并編寫成文檔和示意圖。下一步，就可以讓客戶代表評(píng)審文檔并糾正存在的錯(cuò)誤。這四個(gè)過程貫穿著需求開發(fā)的整個(gè)階段。

由于軟件開發(fā)項(xiàng)目和組織文化的不同，對(duì)于需求開發(fā)沒有一個(gè)簡單的、公式化的途徑。下面列出了14個(gè)步驟，你可以利用它們指導(dǎo)你的需求開發(fā)活動(dòng)。對(duì)于需求的任何子集，一旦你完成了第十三步，那么你就可以很有信心地繼續(xù)進(jìn)行系統(tǒng)的每一部分的設(shè)計(jì)、構(gòu)造，因?yàn)槟銓㈤_發(fā)出一個(gè)好的產(chǎn)品:

1.定義項(xiàng)目的視圖和范圍。

2.確定用戶類。

3.在每個(gè)用戶類中確定適當(dāng)?shù)拇怼?/p>

4.確定需求決策者和他們的決策過程。

5.選擇你所用的需求獲取技術(shù)。

6.運(yùn)用需求獲取技術(shù)對(duì)作為系統(tǒng)一部分的使用實(shí)例進(jìn)行開發(fā)并設(shè)置優(yōu)先級(jí)。

7.從用戶那里收集質(zhì)量屬性的信息和其它非功能需求。

8.詳細(xì)擬訂使用實(shí)例使其融合到必要的功能需求中。

9.評(píng)審使用實(shí)例的描述和功能需求。

10.如果有必要，就要開發(fā)分析模型用以澄清需求獲取的參與者對(duì)需求的理解。

11.開發(fā)并評(píng)估用戶界面原型以助想像還未理解的需求。

12.從使用實(shí)例中開發(fā)出概念測(cè)試用例。

13.用測(cè)試用例來論證使用實(shí)例、功能需求、分析模型和原型。

14.在繼續(xù)進(jìn)行設(shè)計(jì)和構(gòu)造系統(tǒng)每一部分之前，重復(fù)6~13步。

需求獲取可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)及最需要交流的方面。需求獲取只有通過有效的客戶—開發(fā)者的合作才能成功。分析者必須建立一個(gè)對(duì)問題進(jìn)行徹底探討的環(huán)境，而這些問題與產(chǎn)品有關(guān)。為了方便清晰地進(jìn)行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對(duì)需求問題的全面考察需要一種技術(shù)，利用這種技術(shù)不但考慮了問題的功能需求方面，還可討論項(xiàng)目的非功能需求。確定用戶已經(jīng)理解：對(duì)于某些功能的討論并不意味著即將在產(chǎn)品中實(shí)現(xiàn)它。對(duì)于想到的需求必須集中處理并設(shè)定優(yōu)先級(jí)，以避免一個(gè)不能帶來任何益處的無限大的項(xiàng)目。

需求獲取是一個(gè)需要高度合作的活動(dòng)，而并不是客戶所說的需求的簡單拷貝。作為一個(gè)分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個(gè)可擴(kuò)充的問題有助于你更好地理解用戶目前的業(yè)務(wù)過程并且知道新系統(tǒng)如何幫助或改進(jìn)他們的工作。

需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟件解決方案中合理的特性。一個(gè)研究表明：比起不成功的項(xiàng)目，一個(gè)成功的項(xiàng)目在開發(fā)者和客戶之間采用了更多的交流方式。與單個(gè)客戶或潛在的用戶組一起座談，對(duì)于業(yè)務(wù)軟件包或信息管理系統(tǒng)（MIS）的應(yīng)用來說是一種傳統(tǒng)的需求來源。

在每一次座談?dòng)懻撝?，記下所討論的條目，并請(qǐng)參與討論的用戶評(píng)論并更正。及早并經(jīng)常進(jìn)行座談?dòng)懻撌切枨螳@取成功的一個(gè)關(guān)鍵途徑，因?yàn)橹挥刑峁┬枨蟮娜瞬拍艽_定是否真正獲取需求。進(jìn)行深入收集和分析以消除任何沖突或不一致性。盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執(zhí)行任務(wù)時(shí)作出決策的過程，并提取出潛在的邏輯關(guān)系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。

當(dāng)進(jìn)行需求獲取時(shí)，應(yīng)避免受不成熟的細(xì)節(jié)的影響。在對(duì)切合的客戶任務(wù)取得共識(shí)之前，用戶能很容易地在一個(gè)報(bào)表或?qū)υ捒蛑辛谐雒恳豁?xiàng)的精確設(shè)計(jì)。如果這些細(xì)節(jié)都作為需求記錄下來，他們會(huì)給隨后的設(shè)計(jì)過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發(fā)過程中，將會(huì)詳盡闡述他們的需求。

在一個(gè)逐次詳細(xì)描述過程中，重復(fù)地詳述需求，以確定用戶目標(biāo)和任務(wù)，并作為使用實(shí)例。然后，把任務(wù)描述成功能需求，這些功能需求可以使用戶完成其任務(wù)，也可以把它們描述成非功能需求，這些非功能需求描述了系統(tǒng)的限制和用戶對(duì)質(zhì)量的期望。雖然最初的屏幕構(gòu)思有助于描述你對(duì)需求的理解，但是你必須細(xì)化用戶界面設(shè)計(jì)。2009-59\o"Permalinkto如何寫需求分析報(bào)告（軟件需求說明書GB856T-88）"如何寫需求分析報(bào)告近來學(xué)校的一些科研項(xiàng)目又在申報(bào)了，一些學(xué)弟開始Q我一些軟件工程上書面的問題。大概的總結(jié)了下，寫到這里。本文涉及到的是需求分析部分的書寫，主要是根據(jù)國家標(biāo)準(zhǔn)文檔中的要求來的。在互聯(lián)網(wǎng)公司或者一些敏捷開發(fā)的公司里，其實(shí)大家都是秉承著重開發(fā)，重討論，而輕文檔的態(tài)度。這個(gè)輕文檔并不是指沒有文檔或者幾乎不做文檔，而是在嚴(yán)格的文檔流程中解脫出來，只把最最實(shí)際的部分寫出來。這個(gè)特征是有互聯(lián)網(wǎng)本身迭代周期短，版本發(fā)布快等特點(diǎn)決定的。而在實(shí)際的兼職項(xiàng)目的時(shí)候，同學(xué)們就要注意了，最重要的應(yīng)該就是在簽合同的時(shí)候一定要附上最清楚的一份需求分析，雖然這份需求說明可能不是按照某些標(biāo)準(zhǔn)文檔而來的，描述清楚每個(gè)功能達(dá)到的效果，而這個(gè)效果一定要讓客戶點(diǎn)頭確認(rèn)，而不能出現(xiàn)“應(yīng)該是”、“可能是”、“也許是”這樣的模糊回答。否則在項(xiàng)目后期就會(huì)比較難過了。在學(xué)校申請(qǐng)的項(xiàng)目和大型公司項(xiàng)目開發(fā)中，是重視文檔流程的，一部一部來。所以還是看情況來對(duì)待文檔的深度和標(biāo)準(zhǔn)。

一、目錄：目錄要用word的“引用”—>”目錄”，自動(dòng)生成目錄，一般都是要三級(jí)目錄。通常這部分基本都不需要改結(jié)構(gòu)，直接更新頁碼即可。二、內(nèi)容部分。國家標(biāo)準(zhǔn)軟件需求說明書G856T-88下載

1引言1.1編寫目的說明編寫這份軟件需求說明書的目的，指出預(yù)期的讀者。（這部分說明需求分析報(bào)告的概況，例如：本X需求分析報(bào)告是為S系統(tǒng)而編寫的。+S系統(tǒng)的兩句話概述。+本X報(bào)告旨在使U1（需求者）明確S系統(tǒng)的要求和細(xì)節(jié)，給U2(開發(fā)人員)了解需求實(shí)現(xiàn)的難度和困難，最終提供給U3（審核人、管理者）討論和審核，達(dá)到溝通效果）1.2背景說明：a．

待開發(fā)的軟件系統(tǒng)的名稱；b．

本項(xiàng)目的任務(wù)提出者、開發(fā)者、用戶及實(shí)現(xiàn)該軟件的計(jì)算中心或計(jì)算機(jī)網(wǎng)絡(luò)；c．

該軟件系統(tǒng)同其他系統(tǒng)或其他機(jī)構(gòu)的基本的相互來往關(guān)系。（這部分可以將a,b,c分為2部分，例子如下：1.2.1項(xiàng)目概況本需求分析報(bào)告所預(yù)期開發(fā)的軟件系統(tǒng)是:S。S是（不是則無）SS系統(tǒng)的某一個(gè)功能子模塊，S和S1、S2等系統(tǒng)之間的聯(lián)系，以及概述其他系統(tǒng)的狀態(tài)等等。1.2.2任務(wù)分配a.

任務(wù)提出者：xxxb.

軟件開發(fā)者：xxc.

產(chǎn)品使用者：xxd.

文檔編寫者：xxe.

預(yù)期產(chǎn)品使用者：xx）

1.3定義列出本文件中用到的專門術(shù)語的定義和外文首字母組詞的原詞組。（這部分很簡單，就是描述專業(yè)詞匯，比如1.XML(ExtensibleMarkupLanguage)即可擴(kuò)展標(biāo)記語言,它與HTML一樣,都是SGML(StandardGeneralizedMarkupLanguage,標(biāo)準(zhǔn)通用標(biāo)記語言)。2.Word2,解釋。。。）1.4參考資料列出用得著的參考資料，如：a．

本項(xiàng)目的經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書或合同、上級(jí)機(jī)關(guān)的批文；b．

屬于本項(xiàng)目的其他已發(fā)表的文件；c．

本文件中各處引用的文件、資料、包括所要用到的軟件開發(fā)標(biāo)準(zhǔn)。列出這些文件資料的標(biāo)題、文件編號(hào)、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。2任務(wù)概述2.1目標(biāo)敘述該項(xiàng)軟件開發(fā)的意圖、應(yīng)用目標(biāo)、作用范圍以及其他應(yīng)向讀者說明的有關(guān)該軟件開發(fā)的背景材料。解釋被開發(fā)軟件與其他有關(guān)軟件之間的關(guān)系。如果本軟件產(chǎn)品是一項(xiàng)獨(dú)立的軟件，而且全部內(nèi)容自含，則說明這一點(diǎn)。如果所定義的產(chǎn)品是一個(gè)更大的系統(tǒng)的一個(gè)組成部分，則應(yīng)說明本產(chǎn)品與該系統(tǒng)中其他各組成部分之間的關(guān)系，為此可使用一張方框圖來說明該系統(tǒng)的組成和本產(chǎn)品同其他各部分的聯(lián)系和接口。|（本模塊開發(fā)主要是為SS的整體服務(wù)，完成SS工作中的XX部分以及相關(guān)的工作。其涉及的范圍就是，從下達(dá)A、B命令后，到給出C結(jié)果的過程。具體描述：B1，來完成B11功能；B2，來完成B22功能；等等。本部分是（否）耦合在分詞工具包其他部分中的，主要為嵌入方式和先后方式相互交互。圖

圖1.該系統(tǒng)的組成同其他各部分的聯(lián)系和接口）2.2用戶的特點(diǎn)列出本軟件的最終用戶的特點(diǎn)，充分說明操作人員、維護(hù)人員的教育水平和技術(shù)專長，以及本軟件的預(yù)期使甩頻度。這些是軟件設(shè)計(jì)工作的重要約束（例如：二次開發(fā)和系統(tǒng)調(diào)用人員：具有很高的專業(yè)知識(shí)水平，理解XX的運(yùn)行機(jī)制?？梢詫?duì)開放代碼進(jìn)行閱讀和分析，以完成其系統(tǒng)獨(dú)特的需求，提供給這部分用戶開放API手冊(cè)和Debug版本的源代碼即可；預(yù)期這部分用戶會(huì)占本系統(tǒng)總用戶量的多大部分。xx使用者：具有一定的計(jì)算機(jī)操作能力和知識(shí)，了解xx領(lǐng)域的相關(guān)概念和用途。提供給這部分用戶操作手冊(cè)即可。預(yù)期這部分使用者主要是來簡單的xx操作。維護(hù)人員：具有較高的計(jì)算機(jī)專業(yè)水平，可以對(duì)常見的系統(tǒng)Bug進(jìn)行追蹤和分析，具有一定的測(cè)試能力。這部分用戶主要是采用了本系統(tǒng)之后的后期工作維護(hù)者。等等）2.3假定和約束列出進(jìn)行本軟件開發(fā)工作的假定和約束，例如經(jīng)費(fèi)限制、開發(fā)期限等。（這部分重要是對(duì)你有的技術(shù)力量、資金狀況、人力資源等情況的假設(shè)，以使得你可以在什么樣的情況和時(shí)間范圍內(nèi)完成工作。工期約束，經(jīng)費(fèi)約束，人員約束，地理約束，設(shè)備約束等幾個(gè)方面列舉說明。）3需求規(guī)定3.1對(duì)功能的規(guī)定用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項(xiàng)定量和定性地?cái)⑹鰧?duì)軟件所提出的功能要求，說明輸入什么量、經(jīng)怎樣的處理、得到什么輸出，說明軟件應(yīng)支持的終端數(shù)和應(yīng)支持的并行操作的用戶數(shù)。（例如：INPUT輸入PROCESS處理OUTPUT輸出LOAD負(fù)載量A預(yù)處理,做怎樣的動(dòng)作，AACCBBBBBBbvCCCCCccv表一、xx模塊IPO表對(duì)IPO表的簡單文字描述。）3.2對(duì)性能的規(guī)定3.2.1精度說明對(duì)該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。（例如：Xx目標(biāo)處理：1Byt–10M，包括左右邊界值。yy精度范圍：….ZZ的精度：由于xx的特殊性，本系統(tǒng)均采用xx型來進(jìn)行字符統(tǒng)計(jì)運(yùn)算，概率部分以及其他比率部分精度精確到0.0x%。）3.2.2時(shí)間特性要求說明對(duì)于該軟件的時(shí)間特性要求，如對(duì)：a．

響應(yīng)時(shí)間；b．

更新處理時(shí)間；c．

數(shù)據(jù)的轉(zhuǎn)換和傳送時(shí)間；d．

解題時(shí)間；等的要求。(這部分只要一一列舉就可以：由于xxx過程中，需要大量xxxx操作或怎樣，故xx解題時(shí)間占總時(shí)間的最大部分。其次就是xx轉(zhuǎn)換和存儲(chǔ)的開銷。其具體時(shí)間特性要求，如下：a．

xx響應(yīng)時(shí)間：xxms左右；b．

yy更新處理時(shí)間：yy；c．

zz數(shù)據(jù)的轉(zhuǎn)換和傳送時(shí)間：zz；d．

vv解題時(shí)間：vv。等等)3.2.3靈活性說明對(duì)該軟件的靈活性的要求，即當(dāng)需求發(fā)生某些變化時(shí)，該軟件對(duì)這些變化的適應(yīng)能力，如：a．

操作方式上的變化；b．

運(yùn)行環(huán)境的變化；c．

同其他軟件的接口的變化；d．

精度和有效時(shí)限的變化；e．

計(jì)劃的變化或改進(jìn)。對(duì)于為了提供這些靈活性而進(jìn)行的專門設(shè)計(jì)的部分應(yīng)該加以標(biāo)明。（這部分按列舉來即可，由于本模塊第一目的是用于xxx，其次則是xxxx。故本模塊的靈活性在于實(shí)際應(yīng)用者的不同。當(dāng)需求發(fā)生某些變化時(shí)，該軟件對(duì)這些變化的適應(yīng)能力。具體情況如下：f．

操作方式上的變化：采用集成運(yùn)行制和獨(dú)立運(yùn)行制兩種模式，集成運(yùn)行制是把本模塊嵌入到分詞工具包的主框架中，提供給用戶具有一定UI的可操作軟件；獨(dú)立運(yùn)行制是可以獨(dú)立運(yùn)行于后臺(tái)，并提供給各種程序調(diào)用的模式的工作方式，以增強(qiáng)其生命力。g．

運(yùn)行環(huán)境的變化：主采用Windows平臺(tái)的編譯版本運(yùn)行和調(diào)試，在時(shí)間允許的情況下，同步開發(fā)支持SUSELinux的服務(wù)器版本。；h．

同其他軟件的接口的變化：在盡量保證接口不出現(xiàn)變動(dòng)的情況下，允許接口的重載和再定義。但接口的命名規(guī)則是統(tǒng)一的；i．

精度和有效時(shí)限的變化：精度在必須調(diào)整的條件下，可以上下浮動(dòng)10個(gè)百分點(diǎn)；有效時(shí)限則依據(jù)現(xiàn)實(shí)的測(cè)試情況允許稍大范圍的變化。j．

計(jì)劃的變化或改進(jìn)：工作時(shí)間安排會(huì)存在必然的浮動(dòng)，這部分要協(xié)同分詞工具包課題設(shè)計(jì)組其他成員一同來進(jìn)行商定，前期的計(jì)劃可以稍微有些變動(dòng)，后期的安排盡量按照計(jì)劃執(zhí)行。等等）3.3輸人輸出要求解釋各輸入輸出數(shù)據(jù)類型，并逐項(xiàng)說明其媒體、格式、數(shù)值范圍、精度等。對(duì)軟件的數(shù)據(jù)輸出及必須標(biāo)明的控制輸出量進(jìn)行解釋并舉例，包括對(duì)硬拷貝報(bào)告（正常結(jié)果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報(bào)告的描述。（這部分可以把輸入輸出分為3.3.1輸入要求和3.3.2輸出要求，如下給出一個(gè)單元的例子。XXX輸出數(shù)據(jù)名稱：XXX輸出數(shù)據(jù)實(shí)際含義：用于XX,表示XXXX數(shù)據(jù)類型：Character(字符串)數(shù)據(jù)格式：XX數(shù)據(jù)約束：由于xxx,，大小在xx以內(nèi)）3.4數(shù)據(jù)管理能力要求說明需要管理的文卷和記錄的個(gè)數(shù)、表和文卷的大小規(guī)模，要按可預(yù)見的增長對(duì)數(shù)據(jù)及其分量的存儲(chǔ)要求作出估算。（根據(jù)實(shí)際系統(tǒng)要求列舉即可Name名稱Number數(shù)量Size大小Increase增長詞典xxxxxxxx并行執(zhí)行，其大小依據(jù)實(shí)際xx大文本而增長

）3.5故障處理要求列出可能的軟件、硬件故障以及對(duì)各項(xiàng)性能而言所產(chǎn)生的后果和對(duì)故障處理的要求。（包括軟件壓力，內(nèi)存不足，硬件損壞等，這部分可以根據(jù)百度到其常見故障。）3.6其他專門要求如用戶單位對(duì)安全保密的要求，對(duì)使用方便的要求，對(duì)可維護(hù)性、可補(bǔ)充性、易讀性、可靠性、運(yùn)行環(huán)境可轉(zhuǎn)換性的特殊要求等。（例如安全保密性：密鑰更換等；預(yù)期擴(kuò)展：擴(kuò)展兼容等；OS更換：Slackware轉(zhuǎn)SUSE等）4運(yùn)行環(huán)境規(guī)定4.1設(shè)備列出運(yùn)行該軟件所需要的硬設(shè)備。說明其中的新型設(shè)備及其專門功能，包括：a．

處理器型號(hào)及內(nèi)存容量；b．

外存容量、聯(lián)機(jī)或脫機(jī)、媒體及其存儲(chǔ)格式，設(shè)備的型號(hào)及數(shù)量；c．

輸入及輸出設(shè)備的型號(hào)和數(shù)量，聯(lián)機(jī)或脫機(jī)；d．

數(shù)據(jù)通信設(shè)備的型號(hào)和數(shù)量；e．

功能鍵及其他專用硬件（列舉說明即可）4.2支持軟件列出支持軟件,包括要用到的操作系統(tǒng)、編譯（或匯編）程序、測(cè)試支持軟件等。（操作系統(tǒng)和版本：xxxx支撐環(huán)境和版本：xxxx備用IDE環(huán)境和版本：xxxx與該軟件有關(guān)的軟件組件：xxxx后續(xù)可能擴(kuò)展環(huán)境：xxxx

）4.3接口說明該軟件同其他軟件之間的接口、數(shù)據(jù)通信協(xié)議等。(例如：a．用