軟件項目需求調(diào)研方法及需求規(guī)格說明書的編寫課件

北京科創(chuàng)鑫源信息技術(shù)有限公司2014-11-6唐玉林1需求開發(fā)與需求管理——消除軟件開發(fā)百病之源1精選北京科創(chuàng)鑫源信息技術(shù)有限公司2014-11-6需求概述1需求分析3需求定義42需求管理5需求獲取2匯報內(nèi)容_需求概述2精選需求概述1需求分析3需求定義42需求管理5需求獲取2匯報內(nèi)容了解客戶、最終用戶、間接用戶客戶掏錢買軟件的用戶稱為客戶?？蛻粲肋h是本公司的座上客，是上帝?？蛻舨⒉灰蕾囄覀?，而我們卻依賴客戶。客戶不是我們工作的障礙，而是我們工作的目標(biāo)。我們并不因為服務(wù)于他而對他有恩，他卻因為給予我們服務(wù)于他的機會而有恩于我們。客戶不是我們要與之爭辯和斗智的人。從未有人曾在與客戶的爭辯中獲勝?？蛻羰前阉挠麕Ыo我們的人，因此我們的工作就是滿足這些欲望，從而使客戶和我們共同獲益。最終用戶真正操作軟件的用戶。即使最終用戶不是上帝，也算是“上帝”的“親戚”，同樣怠慢不得。間接用戶既不掏錢買該軟件產(chǎn)品，也不使用該軟件，但是它可能對軟件產(chǎn)品有很大的影響。3精選了解客戶、最終用戶、間接用戶客戶掏錢買軟件的用戶稱為客戶。最需求的層次需求的層次業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。用戶需求功能需求(非功能需求)描述用戶使用產(chǎn)品必須要完成的任務(wù)。定義開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。4精選需求的層次需求的層次業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品IEEE對需求的定義為：（1）用戶解決問題或達到目標(biāo)所需的條件或能力。--針對用戶（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文件文檔所需具有的條件或能力。--針對開發(fā)者需求的基本概念需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。國內(nèi)軟件業(yè)的通?。喝藗儾⒉徽嬲宄烤乖撟鍪裁矗珔s一直忙碌不停地開發(fā)。需求的重要性什么是需求5精選IEEE對需求的定義為：需求的基本概念需求是產(chǎn)品的根源，需求被動型被動地對待需求工程中的各項活動，能少干則少干，能偷懶則偷懶。他們認為需求是用戶的事情而不是自己的事情。開發(fā)過程中經(jīng)常發(fā)生需求變更，導(dǎo)致產(chǎn)品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)。主動型積極地開展需求工程中的各項活動。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責(zé)任。俗話說“良好的開端是成功的一半”，“主動型”需求工程是開發(fā)成功產(chǎn)品的必備條件。領(lǐng)先型是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求，導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費。需求工程做到這個份上，才能使產(chǎn)品立于不敗之地，長盛不衰。對待需求工程的三種態(tài)度6精選被動型被動地對待需求工程中的各項活動，能少干則少干，能偷懶則花時間了解用戶需求是確保項目成功的必要投入152050100需求設(shè)計編碼測試維護7精選花時間了解用戶需求是確保項目成功的必要投入152050100需求分析員需要的技能1、傾聽的技巧2、交談和提問的技巧3、分析能力4、協(xié)調(diào)能力5、觀察能力6、寫作能力7、組織能力8、建模能力9、人際交往能力10、創(chuàng)造力需求分析員必備的技能1、定義業(yè)務(wù)需求2、確定項目涉眾3、獲取需求4、分析需求6、編寫需求規(guī)格說明書7、為需求建模8、需求驗證9、優(yōu)先級劃分10、管理需求需求分析員的工作8精選需求分析員需要的技能1、傾聽的技巧需求分析員必備的技能1、定需求獲取2需求分析3需求定義49需求管理5需求概述1匯報內(nèi)容_需求獲取9需求獲取2需求分析3需求定義49需求管理5需求概述1匯報內(nèi)容

需求調(diào)研的內(nèi)容客戶想要什么?要這干什么?為什么這么想?會不會有別的想法?ThemeGalleryisaDesignDigitalContent&ContentsmalldevelopedbyGuildDesignInc.需求獲取

需求調(diào)研的目的搞清客戶的要求找出要求的邏輯客戶想要的結(jié)果排除開發(fā)風(fēng)險，挖掘控制潛在的需求需求調(diào)研的內(nèi)容和目的10精選需求調(diào)研的內(nèi)容ThemeGalleryisaDes關(guān)于需求的漫畫客戶的描述與實際需求不一致需求人員的理解與客戶描述的不一致程序員實現(xiàn)的與需求表達的不一致。項目文檔嚴(yán)重缺失市場人員忽悠得天花亂墜。項目雙方投入巨大11精選關(guān)于需求的漫畫客戶的描述與實際需求不一致需求人員的理解與客戶冰山理論客戶心里想的100%客戶嘴里說的80%你聽到的60%你聽懂的40%開發(fā)實現(xiàn)的20%需要多次從多個角度與客戶、開發(fā)人員溝通、復(fù)述、確認12精選冰山理論客戶心里想的100%客戶嘴里說的80%你聽到需求獲取–聆聽需求13精選需求獲取–聆聽需求13精選首先，需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。其次，需求分析員應(yīng)當(dāng)確定需求調(diào)查的方式，例如：與用戶交談，向用戶提問題。向用戶群體發(fā)調(diào)查問卷。參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。從Internet上搜查相關(guān)資料。最后，需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等，撰寫需求調(diào)查計劃。要特別留意的是不要漏掉典型的用戶。

準(zhǔn)備調(diào)查

建議：養(yǎng)成收集日常問題的習(xí)慣，比如整理《日常問題歸集》文檔14精選首先，需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問執(zhí)行調(diào)查建議：每次調(diào)研后編寫《會議紀(jì)要》或《用戶需求調(diào)查單》準(zhǔn)備工作完畢后，需求分析員按照計劃執(zhí)行調(diào)查。在調(diào)查過程中隨時記錄（或存儲）需求信息。需求分析員與用戶面談時應(yīng)當(dāng)注意以下事項：如果與用戶約好了時間，切勿遲到或早退。要注意禮節(jié)，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。需求分析員應(yīng)事先了解用戶的身份、背景，以便隨機應(yīng)變。需求調(diào)查不象偵探推理那樣從蛛絲馬跡著手，應(yīng)該先了解宏觀問題，再了解細節(jié)問題。如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。當(dāng)雙方對某些問題的交流合乎邏輯地結(jié)束后，即可繼續(xù)討論問題表中的其它問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調(diào)查的力度。避免片面地聽取某些用戶的需求而忽視其它用戶的需求。15精選執(zhí)行調(diào)查建議：每次調(diào)研后編寫《會議紀(jì)要》或《用戶需求調(diào)查單》需求分析3需求獲取2需求定義416需求管理5需求概述1匯報內(nèi)容_需求分析16精選需求分析3需求獲取2需求定義416需求管理5需求概述1匯報內(nèi)為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠是正確的。誰都知道這不是真的。事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現(xiàn)的需求。需求分析是需求開發(fā)過程中最費腦子的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術(shù)性比較強，寫出來有學(xué)術(shù)味，故大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用，很有實用價值。需求分析的基本概念需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。17為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠是問題分析方法問答分析方法：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。問答分析最重要的問題：“是什么”、“為什么”、“不是什么”。其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎？需求是必要的嗎？需求可實現(xiàn)嗎？需求可驗證嗎？需求的優(yōu)先級確定了嗎？18問題分析方法問答分析方法：刨根究底地問，如果問題都被解答了，人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，所謂“一圖頂千言”就是這個道理。在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?/p>

恰當(dāng)?shù)厥褂脠D形符號：現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。

建模分析法大家都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，可謂“一圖頂千言”。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄Ｇ‘?dāng)?shù)厥褂脠D形符號：現(xiàn)代建模工具很多，都有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型與文字有機結(jié)合，相輔相成。19人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采需求分析常用元素總體功能框圖流程圖用例圖狀態(tài)轉(zhuǎn)換圖原型界面圖需求分析常用工具WORDEXCELVISIOAxureRPProRationlRosePowerDesigner需求分析常用元素和工具數(shù)據(jù)模型圖20需求分析常用元素總體功能框圖流程圖用例圖狀態(tài)轉(zhuǎn)換圖原型界面圖總統(tǒng)功能框圖21總統(tǒng)功能框圖21總統(tǒng)功能框圖22總統(tǒng)功能框圖22功能框圖23功能框圖23審批流程圖24審批流程圖24業(yè)務(wù)流程圖25業(yè)務(wù)流程圖25用例圖26用例圖26狀態(tài)轉(zhuǎn)換圖采購方式狀態(tài)27狀態(tài)轉(zhuǎn)換圖采購方式狀態(tài)27原型界面（一）28原型界面（一）282929需求定義4需求獲取2需求分析330需求管理5需求概述1匯報內(nèi)容_需求定義30需求定義4需求獲取2需求分析330需求管理5需求概述1匯報內(nèi)內(nèi)容不完整格式不統(tǒng)一書寫不嚴(yán)謹照搬照抄需求太簡單描述不清晰Titleinhere需求規(guī)格說明書常見問題31精選內(nèi)容不完整格式不統(tǒng)一書寫不嚴(yán)謹照搬照抄需求太簡單描述不清晰T需求階段的文檔種類真實的記錄與用戶的交流情況，包括交流的時間、地點、與會人員、交流的主題等，以及每個人員的想法、建議、要求，邏輯上不需要嚴(yán)謹，重點是真實。采用自然語言（和應(yīng)用域術(shù)語）來表達用戶需求，其內(nèi)容相對于規(guī)格說明書而言比較粗略，不夠詳細。但具有較完整的邏輯。是用戶需求說明書的細化，更多地采用計算機語言和圖形符號來刻畫需求，是軟件系統(tǒng)設(shè)計的直接依據(jù)。《會議紀(jì)要》或《用戶需求調(diào)查單》《用戶需求說明書》《軟件需求規(guī)格說明書》32需求階段的文檔種類真實的記錄與用戶的交流情況，包需求規(guī)格說明書的格式1.引言1.1目標(biāo)1.2項目范圍1.3術(shù)語和縮略語2.系統(tǒng)概述2.1產(chǎn)品描述2.2產(chǎn)品功能2.3一般約束3.功能性需求分類3.1功能性需求分類方法3.2功能描述13.3功能描述23.3.1業(yè)務(wù)需求描述3.3.2用例圖（角色描述）3.3.3功能需求1）流程圖（審批或業(yè)務(wù)）2）功能描述3）主要數(shù)據(jù)元素4）原型界面

4.外部接口1.1用戶接口1.2軟件接口5.產(chǎn)品非功能性需求33需求規(guī)格說明書的格式1.引言3.3.1業(yè)務(wù)需求描述對象目的客戶、用戶、市場人員了解他們期望得到什么樣的產(chǎn)品項目經(jīng)理根據(jù)產(chǎn)品描述來估計項目的進度,工作量和所需資源開發(fā)團隊根據(jù)需求規(guī)格說明來了解需要開發(fā)什么樣的產(chǎn)品測試人員使用需求規(guī)格說明來開發(fā)測試計劃,測試用例和測試過程文檔編寫人員根據(jù)需求規(guī)格說明和用戶界面設(shè)計來編寫用戶手冊和幫助屏幕系統(tǒng)維護和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的每一部分的功能是什么培訓(xùn)人員根據(jù)需求規(guī)格說明和用戶文檔來編寫培訓(xùn)材料軟件需求要達到的目的34精選對象目的客戶、用戶、市場人員了解他們期望得到什么樣的產(chǎn)品項目什么是好的需求規(guī)格說明書1正確

需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實意圖，“正確”是《產(chǎn)品需求規(guī)格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行確認。2清楚

清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？文檔的語句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？3無二義性

“無二義性”是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。為了使需求無二義性，人們在寫《產(chǎn)品需求規(guī)格說明書》時措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。35精選什么是好的需求規(guī)格說明書1正確35精選4一致

“一致”（Consistent）是指《產(chǎn)品需求規(guī)格說明書》中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。5必要

《產(chǎn)品需求規(guī)格說明書》中的各項需求對用戶而言應(yīng)當(dāng)都是必要的?？梢园选氨匾北扔鳛椤把┲兴吞俊薄！氨匾蓖耙徊剑词恰爱嬌咛碜恪币词恰板\上添花”?！爱嬌咛碜恪憋@然是壞事，會導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求?！板\上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在《產(chǎn)品需求規(guī)格說明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級。6完備“完備”（Complete）是指《產(chǎn)品需求規(guī)格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產(chǎn)品需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預(yù)期的任務(wù)。什么是好的需求規(guī)格說明書36精選4一致什么是好的需求規(guī)格說明書36精選77可實現(xiàn)

《產(chǎn)品需求規(guī)格說明書》中的各項需求對開發(fā)方而言應(yīng)當(dāng)都是可實現(xiàn)的（Attainable）?！翱蓪崿F(xiàn)”意味著在技術(shù)上是可行的，并且滿足時間、費用、質(zhì)量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產(chǎn)品需求規(guī)格說明書》可是白紙黑字啊。經(jīng)過雙方確認的《產(chǎn)品需求規(guī)格說明書》相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)《產(chǎn)品需求規(guī)格說明書》中的內(nèi)容，那就是違約，可能會被罰款的。對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應(yīng)事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。8可驗證

《產(chǎn)品需求規(guī)格說明書》中的各項需求對用戶方而言應(yīng)當(dāng)都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。例如，摩天大樓的一項需求是“抗十二級臺風(fēng)”，這個需求看起來堂而皇之，但是如何驗證呢？當(dāng)摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風(fēng)來試驗？如果雙方都認可“采用計算機模擬十二級臺風(fēng)”等效于實際測試，那么這項需求就是“可驗證”的。什么是好的需求規(guī)格說明書37精選77可實現(xiàn)什么是好的需求規(guī)格說明書37精選什么是好的需求規(guī)格說明書9確定優(yōu)先級為什么要確定需求的“優(yōu)先級”？理論上講，軟件的所有需求都應(yīng)當(dāng)被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風(fēng)險降到最低。需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。10闡述“做什么”而不是“怎么做”

《產(chǎn)品需求規(guī)格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設(shè)計和實現(xiàn)階段的事情。國內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計、編程等工作從頭做到尾。所以他們在調(diào)查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調(diào)查、定義需求時想好了“怎么做”，當(dāng)然應(yīng)該寫下來，否則豈不浪費！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。38精選什么是好的需求規(guī)格說明書9確定優(yōu)先級38精選需求規(guī)格書缺陷檢查清單39精選需求規(guī)格書缺陷檢查清單39精選怎樣看到簽字不可能在項目初期就能明確所有的需求,需求肯定要隨時間的推移而發(fā)生變化.簽字不僅僅是儀式,更重要的是建立需求的基線.即當(dāng)時的需求最佳理解瞬間圖.需求基線定義好了以后,要將需求置于變更控制之下.用明確的協(xié)議來結(jié)束前期的需求開發(fā)活動,能幫助客戶和開發(fā)團隊形成合作伙伴關(guān)系,攜手走上項目成功之路.40精選怎樣看到簽字不可能在項目初期就能明確所有的需求,需求肯定要隨需求管理4需求獲取2需求分析341需求定義5需求概述1匯報內(nèi)容_需求管理41需求管理4需求獲取2需求分析341需求定義5需求概述1匯報內(nèi)1需求確認（評審和承諾）需求確認是指開發(fā)方和客戶方共同對《產(chǎn)品需求規(guī)格說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。

2需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。開評審會議時經(jīng)常會“跑題”，導(dǎo)致評審效率很低。有時話匣子一打開后關(guān)不上，大家越扯越遠，結(jié)果評審會議變成了聊天會議。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無關(guān)的東西。

開評審會議時經(jīng)常會發(fā)生爭議。適當(dāng)?shù)臓幾h有利于澄清問題，比什么東西都一致贊成要好。然而當(dāng)爭議變?yōu)闋幊硶r就壞事了，爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執(zhí)己見”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。

需求確認與評審421需求確認（評審和承諾）需求確認與評審423需求承諾需求承諾是指開發(fā)方和客戶方的責(zé)任人對通過了正式技術(shù)評審的《產(chǎn)品需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。需求承諾的“八股文”如下：本《產(chǎn)品需求規(guī)格說明書》建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該《產(chǎn)品需求規(guī)格說明書》開展。如果需求發(fā)生變化，我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等。甲方簽字

乙方簽字人們在作出承諾之前務(wù)必要認真閱讀文檔，一定要明白簽字意味著什么。

需求承諾433需求承諾需求承諾434

需求變更控制

需求發(fā)生變更的起因主要有：隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。市場發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場需求，因此要變更需求。提出需求變更的動機是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項目開發(fā)小組而言，變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。需求變更控制的目的：如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來的壞處大于好處，那么拒絕變更。需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個問題最好的辦法是事先建立“游戲規(guī)則”。如果事先沒有“游戲規(guī)則”的話，開發(fā)方需要一些社交技巧來減緩矛盾。例如建議在開發(fā)該產(chǎn)品新版本時修改需求。需求變更控制444需求變更控制需求變更控制44需求變更單的內(nèi)容變更來源變更內(nèi)容及其理由變更的影響客戶意見需求變更評審需求變更單45需求變更單的內(nèi)容變更來源變更內(nèi)容及其理由變更的影響客戶意見需5

需求跟蹤需求跟蹤的目的是建立與維護“需求－設(shè)計－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。

需求跟蹤有兩種方式：

正向跟蹤。檢查《產(chǎn)品需求規(guī)格說明書》中的每個需求是否都能在后繼工作成果中找到對應(yīng)點。

逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對應(yīng)關(guān)系。

需求跟蹤465需求跟蹤需求跟蹤46讓我們?yōu)轫椖砍晒ε?，享受成功帶來的幸福?7讓我們?yōu)轫椖砍晒ε?，享受成功帶來的幸福?7歡迎各位領(lǐng)導(dǎo)、專家提出寶貴建議感謝您的關(guān)注48

北京科創(chuàng)鑫源信息技術(shù)有限公司唐玉林48精選歡迎各位領(lǐng)導(dǎo)、專家提出寶貴建議感謝您的關(guān)注48北京科此課件下載可自行編輯修改，此課件供參考！部分內(nèi)容來源于網(wǎng)絡(luò)，如有侵權(quán)請與我聯(lián)系刪除！此課件下載可自行編輯修改，此課件供參考！

北京科創(chuàng)鑫源信息技術(shù)有限公司2014-11-6唐玉林50需求開發(fā)與需求管理——消除軟件開發(fā)百病之源50精選北京科創(chuàng)鑫源信息技術(shù)有限公司2014-11-6需求概述1需求分析3需求定義451需求管理5需求獲取2匯報內(nèi)容_需求概述51精選需求概述1需求分析3需求定義42需求管理5需求獲取2匯報內(nèi)容了解客戶、最終用戶、間接用戶客戶掏錢買軟件的用戶稱為客戶?？蛻粲肋h是本公司的座上客，是上帝。客戶并不依賴我們，而我們卻依賴客戶。客戶不是我們工作的障礙，而是我們工作的目標(biāo)。我們并不因為服務(wù)于他而對他有恩，他卻因為給予我們服務(wù)于他的機會而有恩于我們?？蛻舨皇俏覀円c之爭辯和斗智的人。從未有人曾在與客戶的爭辯中獲勝。客戶是把他的欲望帶給我們的人，因此我們的工作就是滿足這些欲望，從而使客戶和我們共同獲益。最終用戶真正操作軟件的用戶。即使最終用戶不是上帝，也算是“上帝”的“親戚”，同樣怠慢不得。間接用戶既不掏錢買該軟件產(chǎn)品，也不使用該軟件，但是它可能對軟件產(chǎn)品有很大的影響。52精選了解客戶、最終用戶、間接用戶客戶掏錢買軟件的用戶稱為客戶。最需求的層次需求的層次業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。用戶需求功能需求(非功能需求)描述用戶使用產(chǎn)品必須要完成的任務(wù)。定義開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。53精選需求的層次需求的層次業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品IEEE對需求的定義為：（1）用戶解決問題或達到目標(biāo)所需的條件或能力。--針對用戶（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文件文檔所需具有的條件或能力。--針對開發(fā)者需求的基本概念需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。國內(nèi)軟件業(yè)的通?。喝藗儾⒉徽嬲宄烤乖撟鍪裁?，但卻一直忙碌不停地開發(fā)。需求的重要性什么是需求54精選IEEE對需求的定義為：需求的基本概念需求是產(chǎn)品的根源，需求被動型被動地對待需求工程中的各項活動，能少干則少干，能偷懶則偷懶。他們認為需求是用戶的事情而不是自己的事情。開發(fā)過程中經(jīng)常發(fā)生需求變更，導(dǎo)致產(chǎn)品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)。主動型積極地開展需求工程中的各項活動。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責(zé)任。俗話說“良好的開端是成功的一半”，“主動型”需求工程是開發(fā)成功產(chǎn)品的必備條件。領(lǐng)先型是需求工程的最高境界。開發(fā)者發(fā)掘了連用戶自己都沒有意識到的需求，導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費。需求工程做到這個份上，才能使產(chǎn)品立于不敗之地，長盛不衰。對待需求工程的三種態(tài)度55精選被動型被動地對待需求工程中的各項活動，能少干則少干，能偷懶則花時間了解用戶需求是確保項目成功的必要投入152050100需求設(shè)計編碼測試維護56精選花時間了解用戶需求是確保項目成功的必要投入152050100需求分析員需要的技能1、傾聽的技巧2、交談和提問的技巧3、分析能力4、協(xié)調(diào)能力5、觀察能力6、寫作能力7、組織能力8、建模能力9、人際交往能力10、創(chuàng)造力需求分析員必備的技能1、定義業(yè)務(wù)需求2、確定項目涉眾3、獲取需求4、分析需求6、編寫需求規(guī)格說明書7、為需求建模8、需求驗證9、優(yōu)先級劃分10、管理需求需求分析員的工作57精選需求分析員需要的技能1、傾聽的技巧需求分析員必備的技能1、定需求獲取2需求分析3需求定義458需求管理5需求概述1匯報內(nèi)容_需求獲取58需求獲取2需求分析3需求定義49需求管理5需求概述1匯報內(nèi)容

需求調(diào)研的內(nèi)容客戶想要什么?要這干什么?為什么這么想?會不會有別的想法?ThemeGalleryisaDesignDigitalContent&ContentsmalldevelopedbyGuildDesignInc.需求獲取

需求調(diào)研的目的搞清客戶的要求找出要求的邏輯客戶想要的結(jié)果排除開發(fā)風(fēng)險，挖掘控制潛在的需求需求調(diào)研的內(nèi)容和目的59精選需求調(diào)研的內(nèi)容ThemeGalleryisaDes關(guān)于需求的漫畫客戶的描述與實際需求不一致需求人員的理解與客戶描述的不一致程序員實現(xiàn)的與需求表達的不一致。項目文檔嚴(yán)重缺失市場人員忽悠得天花亂墜。項目雙方投入巨大60精選關(guān)于需求的漫畫客戶的描述與實際需求不一致需求人員的理解與客戶冰山理論客戶心里想的100%客戶嘴里說的80%你聽到的60%你聽懂的40%開發(fā)實現(xiàn)的20%需要多次從多個角度與客戶、開發(fā)人員溝通、復(fù)述、確認61精選冰山理論客戶心里想的100%客戶嘴里說的80%你聽到需求獲取–聆聽需求62精選需求獲取–聆聽需求13精選首先，需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。其次，需求分析員應(yīng)當(dāng)確定需求調(diào)查的方式，例如：與用戶交談，向用戶提問題。向用戶群體發(fā)調(diào)查問卷。參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。從Internet上搜查相關(guān)資料。最后，需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等，撰寫需求調(diào)查計劃。要特別留意的是不要漏掉典型的用戶。

準(zhǔn)備調(diào)查

建議：養(yǎng)成收集日常問題的習(xí)慣，比如整理《日常問題歸集》文檔63精選首先，需求分析員應(yīng)當(dāng)起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問執(zhí)行調(diào)查建議：每次調(diào)研后編寫《會議紀(jì)要》或《用戶需求調(diào)查單》準(zhǔn)備工作完畢后，需求分析員按照計劃執(zhí)行調(diào)查。在調(diào)查過程中隨時記錄（或存儲）需求信息。需求分析員與用戶面談時應(yīng)當(dāng)注意以下事項：如果與用戶約好了時間，切勿遲到或早退。要注意禮節(jié)，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。需求分析員應(yīng)事先了解用戶的身份、背景，以便隨機應(yīng)變。需求調(diào)查不象偵探推理那樣從蛛絲馬跡著手，應(yīng)該先了解宏觀問題，再了解細節(jié)問題。如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。當(dāng)雙方對某些問題的交流合乎邏輯地結(jié)束后，即可繼續(xù)討論問題表中的其它問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調(diào)查的力度。避免片面地聽取某些用戶的需求而忽視其它用戶的需求。64精選執(zhí)行調(diào)查建議：每次調(diào)研后編寫《會議紀(jì)要》或《用戶需求調(diào)查單》需求分析3需求獲取2需求定義465需求管理5需求概述1匯報內(nèi)容_需求分析65精選需求分析3需求獲取2需求定義416需求管理5需求概述1匯報內(nèi)為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠是正確的。誰都知道這不是真的。事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現(xiàn)的需求。需求分析是需求開發(fā)過程中最費腦子的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術(shù)性比較強，寫出來有學(xué)術(shù)味，故大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用，很有實用價值。需求分析的基本概念需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。66為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠是問題分析方法問答分析方法：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。問答分析最重要的問題：“是什么”、“為什么”、“不是什么”。其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎？需求是必要的嗎？需求可實現(xiàn)嗎？需求可驗證嗎？需求的優(yōu)先級確定了嗎？67問題分析方法問答分析方法：刨根究底地問，如果問題都被解答了，人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，所謂“一圖頂千言”就是這個道理。在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?/p>

恰當(dāng)?shù)厥褂脠D形符號：現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。

建模分析法大家都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，可謂“一圖頂千言”。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄Ｇ‘?dāng)?shù)厥褂脠D形符號：現(xiàn)代建模工具很多，都有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型與文字有機結(jié)合，相輔相成。68人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采需求分析常用元素總體功能框圖流程圖用例圖狀態(tài)轉(zhuǎn)換圖原型界面圖需求分析常用工具WORDEXCELVISIOAxureRPProRationlRosePowerDesigner需求分析常用元素和工具數(shù)據(jù)模型圖69需求分析常用元素總體功能框圖流程圖用例圖狀態(tài)轉(zhuǎn)換圖原型界面圖總統(tǒng)功能框圖70總統(tǒng)功能框圖21總統(tǒng)功能框圖71總統(tǒng)功能框圖22功能框圖72功能框圖23審批流程圖73審批流程圖24業(yè)務(wù)流程圖74業(yè)務(wù)流程圖25用例圖75用例圖26狀態(tài)轉(zhuǎn)換圖采購方式狀態(tài)76狀態(tài)轉(zhuǎn)換圖采購方式狀態(tài)27原型界面（一）77原型界面（一）287829需求定義4需求獲取2需求分析379需求管理5需求概述1匯報內(nèi)容_需求定義79需求定義4需求獲取2需求分析330需求管理5需求概述1匯報內(nèi)內(nèi)容不完整格式不統(tǒng)一書寫不嚴(yán)謹照搬照抄需求太簡單描述不清晰Titleinhere需求規(guī)格說明書常見問題80精選內(nèi)容不完整格式不統(tǒng)一書寫不嚴(yán)謹照搬照抄需求太簡單描述不清晰T需求階段的文檔種類真實的記錄與用戶的交流情況，包括交流的時間、地點、與會人員、交流的主題等，以及每個人員的想法、建議、要求，邏輯上不需要嚴(yán)謹，重點是真實。采用自然語言（和應(yīng)用域術(shù)語）來表達用戶需求，其內(nèi)容相對于規(guī)格說明書而言比較粗略，不夠詳細。但具有較完整的邏輯。是用戶需求說明書的細化，更多地采用計算機語言和圖形符號來刻畫需求，是軟件系統(tǒng)設(shè)計的直接依據(jù)?！稌h紀(jì)要》或《用戶需求調(diào)查單》《用戶需求說明書》《軟件需求規(guī)格說明書》81需求階段的文檔種類真實的記錄與用戶的交流情況，包需求規(guī)格說明書的格式1.引言1.1目標(biāo)1.2項目范圍1.3術(shù)語和縮略語2.系統(tǒng)概述2.1產(chǎn)品描述2.2產(chǎn)品功能2.3一般約束3.功能性需求分類3.1功能性需求分類方法3.2功能描述13.3功能描述23.3.1業(yè)務(wù)需求描述3.3.2用例圖（角色描述）3.3.3功能需求1）流程圖（審批或業(yè)務(wù)）2）功能描述3）主要數(shù)據(jù)元素4）原型界面

4.外部接口1.1用戶接口1.2軟件接口5.產(chǎn)品非功能性需求82需求規(guī)格說明書的格式1.引言3.3.1業(yè)務(wù)需求描述對象目的客戶、用戶、市場人員了解他們期望得到什么樣的產(chǎn)品項目經(jīng)理根據(jù)產(chǎn)品描述來估計項目的進度,工作量和所需資源開發(fā)團隊根據(jù)需求規(guī)格說明來了解需要開發(fā)什么樣的產(chǎn)品測試人員使用需求規(guī)格說明來開發(fā)測試計劃,測試用例和測試過程文檔編寫人員根據(jù)需求規(guī)格說明和用戶界面設(shè)計來編寫用戶手冊和幫助屏幕系統(tǒng)維護和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的每一部分的功能是什么培訓(xùn)人員根據(jù)需求規(guī)格說明和用戶文檔來編寫培訓(xùn)材料軟件需求要達到的目的83精選對象目的客戶、用戶、市場人員了解他們期望得到什么樣的產(chǎn)品項目什么是好的需求規(guī)格說明書1正確

需求規(guī)格說明書應(yīng)當(dāng)正確地反映用戶的真實意圖，“正確”是《產(chǎn)品需求規(guī)格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行確認。2清楚

清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？文檔的語句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？3無二義性

“無二義性”是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導(dǎo)致人們誤解需求而開發(fā)出偏離需求的產(chǎn)品。為了使需求無二義性，人們在寫《產(chǎn)品需求規(guī)格說明書》時措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。84精選什么是好的需求規(guī)格說明書1正確35精選4一致

“一致”（Consistent）是指《產(chǎn)品需求規(guī)格說明書》中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。5必要

《產(chǎn)品需求規(guī)格說明書》中的各項需求對用戶而言應(yīng)當(dāng)都是必要的?？梢园选氨匾北扔鳛椤把┲兴吞俊??！氨匾蓖耙徊?，要么是“畫蛇添足”要么是“錦上添花”。“畫蛇添足”顯然是壞事，會導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求?！板\上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在《產(chǎn)品需求規(guī)格說明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級。6完備“完備”（Complete）是指《產(chǎn)品需求規(guī)格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產(chǎn)品需求規(guī)格說明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預(yù)期的任務(wù)。什么是好的需求規(guī)格說明書85精選4一致什么是好的需求規(guī)格說明書36精選77可實現(xiàn)

《產(chǎn)品需求規(guī)格說明書》中的各項需求對開發(fā)方而言應(yīng)當(dāng)都是可實現(xiàn)的（Attainable）。“可實現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時間、費用、質(zhì)量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產(chǎn)品需求規(guī)格說明書》可是白紙黑字啊。經(jīng)過雙方確認的《產(chǎn)品需求規(guī)格說明書》相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)《產(chǎn)品需求規(guī)格說明書》中的內(nèi)容，那就是違約，可能會被罰款的。對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應(yīng)事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。8可驗證

《產(chǎn)品需求規(guī)格說明書》中的各項需求對用戶方而言應(yīng)當(dāng)都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。例如，摩天大樓的一項需求是“抗十二級臺風(fēng)”，這個需求看起來堂而皇之，但是如何驗證呢？當(dāng)摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風(fēng)來試驗？如果雙方都認可“采用計算機模擬十二級臺風(fēng)”等效于實際測試，那么這項需求就是“可驗證”的。什么是好的需求規(guī)格說明書86精選77可實現(xiàn)什么是好的需求規(guī)格說明書37精選什么是好的需求規(guī)格說明書9確定優(yōu)先級為什么要確定需求的“優(yōu)先級”？理論上講，軟件的所有需求都應(yīng)當(dāng)被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風(fēng)險降到最低。需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。10闡述“做什么”而不是“怎么做”

《產(chǎn)品需求規(guī)格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設(shè)計和實現(xiàn)階段的事情。國內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計、編程等工作從頭做到尾。所以他們在調(diào)查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調(diào)查、定義需求時想好了“怎么做”，當(dāng)然應(yīng)該寫下來，否則豈不浪費！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。87精選什么是好的需求規(guī)格說明書9確定優(yōu)先級38精選需求規(guī)格書缺陷檢查清單88精選需求規(guī)格書缺陷檢查清單39精選怎樣看到簽字不可能在項目初期就能明確所有的需求,需求肯定要隨時間的推移而發(fā)生變化.簽字不僅僅是儀式,更重要的是建立需求的基線.即當(dāng)時的需求最佳理解瞬間圖.需求基線定義好了以后,要將需求置于變更控制之下.用明確的協(xié)議來結(jié)束前期的需求開發(fā)活動,能幫助客戶和開發(fā)團隊形成合作伙伴關(guān)系,攜手走上項目成功之路.89精選怎樣看到簽字不可能在項目初期就能明確所有的需求,需求肯定要隨需求