開發(fā)一般流程課件

WEB項目開發(fā)的一般流程—總綱需求分析的確定(最重要)架構(gòu)與設(shè)計架構(gòu)分析與設(shè)計業(yè)務(wù)邏輯分析業(yè)務(wù)邏輯設(shè)計界面設(shè)計開發(fā)環(huán)境搭建開發(fā)-測試-開發(fā)-測試培訓(xùn)文檔編寫WEB項目開發(fā)的一般流程—總綱需求分析的確定(最重要)開發(fā)的一般流程—需求分析為什么需求分析需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發(fā)計劃的一個復(fù)雜過程，在這個過程中，用戶的確是處在主導(dǎo)地位，需求分析工程師和項目經(jīng)理要負責整理用戶需求，為之后的軟件設(shè)計打下基礎(chǔ)。需求分析階段結(jié)束后，要求得到相關(guān)的需求文檔，需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟件開發(fā)的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟件系統(tǒng)的開發(fā)中,他的作用要遠遠大于程序設(shè)計.

開發(fā)的一般流程—需求分析需求分析的任務(wù)需求分析的任務(wù)就是解決“用戶要做什么”的問題,就是要全面地理解用戶的各項要求,并準確地表達所接受的用戶需求，并且能夠根據(jù)自己對用戶需求的理解，勸說并誘導(dǎo)客戶剔除不合理的需求。需求分析的任務(wù)需求分析的任務(wù)就是解需求分析過程需求分析過程

需求分析過程需求分析過程

需求開發(fā)過程域

需求開發(fā)過程域

需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。

需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》。

需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。

需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。

需求開發(fā)過程域

需求開發(fā)過程域需求管理過程域需求管理過程域

需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。

需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂需求管理過程域需求管理過程域需求開發(fā)過程中困難知識技能問題

行業(yè)知識是無邊無際的。俗話說“隔行如隔山”，需求分析員可能是某一領(lǐng)域的專家，但當他接手陌生的業(yè)務(wù)時，他該怎么辦？首先他要有勇氣做事，否則連實踐的機會都沒有。其次他應(yīng)當趕緊補習(xí)這一領(lǐng)域知識，不論是通過自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。如果可能的話，開發(fā)方最好請既懂軟件又懂應(yīng)用域知識的行家來幫忙。需求開發(fā)過程中困難知識技能問題需求開發(fā)過程中困難態(tài)度問題

相當多的開發(fā)人員習(xí)慣于被動地對待需求開發(fā)。每當遇到麻煩、挫折時，他們會發(fā)牢騷，找出一堆用戶的毛病。很多開發(fā)人員錯誤地以為：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應(yīng)當開發(fā)什么嗎？如果用戶說不清楚需求，或者經(jīng)常變更需求，這類問題是用戶產(chǎn)生的，應(yīng)當由他們自己負責。

用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設(shè)法解決的。可悲的是開發(fā)人員把這些問題當成了借口，不愿主動攻克問題，導(dǎo)致需求問題擴散到整個軟件開發(fā)過程，產(chǎn)生太多的后患。軟件企業(yè)的領(lǐng)導(dǎo)應(yīng)當給具有錯誤觀念的開發(fā)人員們洗腦：需求分析員的天職就是在有限的時間內(nèi)獲取準確而細致的用戶需求，如果做不到就是失職，不要找借口。

需求開發(fā)過程中困難態(tài)度問題

合作關(guān)系

如果需求分析員不能與用戶建立良好的合作關(guān)系，那么他們在需求開發(fā)過程中會很疲憊。倘若用戶不能很好地配合需求分析員，那并不表示他是個壞蛋。因為用戶有他自己的想法：我回答了你們的問題，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧

……。

需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡(luò)住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識，還要具備較強的交流、溝通能力。開發(fā)方與用戶的合作關(guān)系對需求開發(fā)而言是至關(guān)重要的。對于重大的、復(fù)雜的項目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關(guān)系，這樣風險太大。開發(fā)方和用戶方在開展需求開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權(quán)利與義務(wù)”，即以協(xié)議的方式確定合作關(guān)系?！昂迷挕焙汀俺笤挕倍颊f在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。

合作關(guān)系

如果需求分析員不能與用戶建立良好的合作關(guān)系，那用戶在需求工程中的“權(quán)利”用戶在需求工程中的“權(quán)利”1.有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。2.有權(quán)要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。3.有權(quán)審查需求文檔，并對有爭議的需求作出決策。如果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。4.如果用戶想要變更需求，有權(quán)要求開發(fā)方對該變更將產(chǎn)生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶在需求工程中的“權(quán)利”用戶在需求工程中的“權(quán)利”用戶在需求工程中的“義務(wù)”用戶在需求工程中的“義務(wù)”1.以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。2.樂意接受需求分析員的采訪，在不泄漏機密的前提下盡可能地回答需求分析員的問題。3.在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關(guān)的材料。4.與需求分析員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。5.對專業(yè)性太深入的知識領(lǐng)域，用戶有義務(wù)組織開發(fā)人員進行簡單的培訓(xùn)。用戶在需求工程中的“義務(wù)”用戶在需求工程中的“義務(wù)”需求沒有做好的后果

需求沒有做好的后果如何準備調(diào)查需求需求分析員應(yīng)當確定需求調(diào)查的方式，例如：與用戶負責人交談，向用戶提問題。同未來此軟件的目標用戶交談，了解他們的目前的工作狀況.參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。從行業(yè)標準、規(guī)則中提取需求。如何準備調(diào)查需求需求分析員應(yīng)當確定需求調(diào)查的方式，例如：如何做好需求分析為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠是正確的。誰都知道這不是真的。事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現(xiàn)的需求。需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。需求分析是需求開發(fā)過程中最費腦子的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術(shù)性比較強，寫出來有學(xué)術(shù)味，故大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用（保你一學(xué)就會），很有實用價值?！皢柎鸱治龇ā北容^適合于用戶需求調(diào)查階段“建模分析法”比較適合于產(chǎn)品需求定義階段。如何做好需求分析為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是問答分析方法問答分析方法

問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。問答分析最重要的問題是：“是什么”,”做什么”和“為什么”。每個需求都應(yīng)當用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當然”的，那么應(yīng)當解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。

其它常見的問題有：

需求存在二義性嗎？

需求文檔的上下文有矛盾嗎？

需求完備嗎？

需求是必要的嗎？

需求可實現(xiàn)嗎？

需求可驗證嗎？

需求的優(yōu)先級確定了嗎？

問答分析方法問答分析方法建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然.在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?/p>

恰當?shù)厥褂脠D形符號：現(xiàn)代建模工具如Rose、Jude有非常豐富的圖形符號和文字標注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別分析決策當需求從四面八方收集來后，需求的沖突在所難免。對于那些難以達成共識的需求而言，經(jīng)常會發(fā)生“公說公有理，婆說婆有理”的現(xiàn)象。那么需求分析員究竟應(yīng)該聽誰的呢？如果一群人對需求有爭議，并不是誰聲音最響就聽誰的。根據(jù)生活經(jīng)驗，最保險的辦法是：先聽官兒大的或者威望高的，如果大家的職位和威望都差不多，那么采用“少數(shù)服從大多數(shù)”的原則。如果一個產(chǎn)品可以賣給幾類客戶，但是各類客戶都要求產(chǎn)品按照他們的喜好來開發(fā)。此時對需求的決策應(yīng)當以商業(yè)利益為導(dǎo)向，即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對較少的需求。當開發(fā)者想象中的產(chǎn)品與客戶所提的需求有沖突時，一般應(yīng)當尊重客戶的觀點。但是不要陷入“客戶總是對的”陷阱里，需求分析員應(yīng)當糾正明顯不合理的客戶需求。如果產(chǎn)品很復(fù)雜，雙方都不太明白需求，此時最好請開發(fā)人員快速構(gòu)造軟件的原型，雙方看著軟件原型再分析需求分析決策當需求從四面八方收集來后，需求的沖突在所難免。對于什么是好的需求規(guī)格說明書正確

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

清楚

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

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

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

必要

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

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

《產(chǎn)品需求規(guī)格說明書》中的各項需求對用戶方而言應(yīng)當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。例如，摩天大樓的一項需求是“抗十二級臺風”，這個需求看起來堂而皇之，但是如何驗證呢？當摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風來試驗？如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試，那么這項需求就是“可驗證”的什么是好的需求規(guī)格說明書可驗證什么是好的需求規(guī)格說明書確定優(yōu)先級為什么要確定需求的“優(yōu)先級”？理論上講，軟件的所有需求都應(yīng)當被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風險降到最低。需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。什么是好的需求規(guī)格說明書確定優(yōu)先級什么是好的需求規(guī)格說明書闡述“做什么”而不是“怎么做”《產(chǎn)品需求規(guī)格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”。“怎么做”是系統(tǒng)設(shè)計和實現(xiàn)階段的事情。國內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計、編程等工作從頭做到尾。所以他們在調(diào)查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調(diào)查、定義需求時想好了“怎么做”，當然應(yīng)該寫下來，否則豈不浪費！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。什么是好的需求規(guī)格說明書闡述“做什么”而不是“怎么做”如何定義產(chǎn)品需求第一步：細化并分析用戶需求

需求分析員首先對《用戶需求說明書》進行細化，對比較復(fù)雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。例如采用Rational的Rose工具進行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。補充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當根據(jù)自身水平進行取舍。第二步：撰寫產(chǎn)品需求規(guī)格說明書

需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應(yīng)當撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。第三步：進行需求確認項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。需求評審之后，開發(fā)方和客戶方的責任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。如何定義產(chǎn)品需求第一步：細化并分析用戶需求需求文檔《用戶需求說明書》與《產(chǎn)品需求規(guī)格說明書》的主要區(qū)別與聯(lián)系前者主要采用自然語言（和應(yīng)用域術(shù)語）來表達用戶需求，其內(nèi)容相對于后者而言比較粗略，不夠詳細。后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，產(chǎn)品需求是軟件系統(tǒng)設(shè)計的直接依據(jù)。兩者之間可能并不存在一一影射關(guān)系，因為軟件開發(fā)商會根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當前狀況適當?shù)卣{(diào)整產(chǎn)品需求，例如用戶需求可能被分配到軟件的數(shù)個版本中。軟件開發(fā)人員應(yīng)當依據(jù)《產(chǎn)品需求規(guī)格說明書》來開發(fā)當前產(chǎn)品。需求文檔《用戶需求說明書》與《產(chǎn)品需求規(guī)格說明書》的主要區(qū)別需求確認（評審和承諾）需求確認（評審和承諾）需求確認是指開發(fā)方和客戶方共同對《產(chǎn)品需求規(guī)格說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。人們在交流的時候，經(jīng)常會發(fā)生“問非所求，答非所問”的事情，用戶表達的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求，那會導(dǎo)致后續(xù)的不少開發(fā)人員將錯就錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連高智商的外星人都不能避免：有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜里雙眼能射出強光?！腥さ氖牵嚴镒≈环N叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！辈徽撌菑?fù)雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少需求確認（評審和承諾）需求確認（評審和承諾）需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。

需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審需求承諾需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術(shù)評審的《產(chǎn)品需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。需求承諾的“八股文”如下：本《產(chǎn)品需求規(guī)格說明書》建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該《產(chǎn)品需求規(guī)格說明書》開展。如果需求發(fā)生變化，我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進度等。甲方簽字

乙方簽字人們在作出承諾之前務(wù)必要認真閱讀文檔，一定要明白簽字意味著什么。需求承諾需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術(shù)評需求跟蹤

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

需求跟蹤有兩種方式：

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

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

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

需求跟蹤的目的是建立與維護“需求－設(shè)計－編程－測試需求變更控制需求發(fā)生變更的起因主要有：隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。市場發(fā)生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。提出需求變更的動機是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項目開發(fā)小組而言，變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。需求變更控制的目的：如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來的壞處大于好處，那么拒絕變更。需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個問題最好的辦法是事先建立“游戲規(guī)則”：開發(fā)方與客戶方達成“事不過三”的約定（符合中國人的習(xí)慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發(fā)方有權(quán)拒絕，除非客戶愿意補償開發(fā)方的損失。需求變更控制需求發(fā)生變更的起因主要有：WEB項目開發(fā)的一般流程—分析與設(shè)計之架構(gòu)分析與設(shè)計架構(gòu)分析與設(shè)計邏輯架構(gòu)3層架構(gòu)、n層架構(gòu)…MVC…Model1orModel2…物理架構(gòu)Web服務(wù)器的分布數(shù)據(jù)庫服務(wù)器的分布…技術(shù)解決方案的確定Java/.NETOpenSource/商業(yè)…WEB項目開發(fā)的一般流程—分析與設(shè)計之架構(gòu)分析與設(shè)計架構(gòu)分析WEB項目開發(fā)的一般流程—分析與設(shè)計之業(yè)務(wù)邏輯分析業(yè)務(wù)邏輯分析根據(jù)需求分析業(yè)務(wù)邏輯有哪些人會使用本系統(tǒng)他們會使用本系統(tǒng)做什么通常他們使用本系統(tǒng)的步驟是什么樣的會有哪些明顯的類來支撐本系統(tǒng)的運行會有哪些不同的提示會返饋給用戶…本階段與需求的確定密切相關(guān)，通常在確定需求的時候就會進行相關(guān)的分析WEB項目開發(fā)的一般流程—分析與設(shè)計之業(yè)務(wù)邏輯分析業(yè)務(wù)邏輯分WEB項目開發(fā)的一般流程—分析與設(shè)計之業(yè)務(wù)邏輯設(shè)計業(yè)務(wù)邏輯設(shè)計根據(jù)需求的分析來確定具體的類確定類的屬性確定類的接口（方法）確定類之間的關(guān)系確定用戶操作流程在設(shè)計上的反映進行數(shù)據(jù)庫的設(shè)計不同的項目步驟可能不盡相同…WEB項目開發(fā)的一般流程—分析與設(shè)計之業(yè)務(wù)邏輯設(shè)計業(yè)務(wù)邏輯設(shè)WEB項目開發(fā)的一般流程—分析與設(shè)計之界面設(shè)計界面設(shè)計設(shè)計系統(tǒng)的界面風格顏色、style設(shè)計系統(tǒng)的具體“模擬”界面能夠從頭走到尾方便進行需求的確定方便JSP程序員的開發(fā)…WEB項目開發(fā)的一般流程—分析與設(shè)計之界面設(shè)計界面設(shè)計WEB項目開發(fā)的一般流程—開發(fā)環(huán)境搭建開發(fā)環(huán)境搭建開發(fā)工具的確定配置管理工具的確定測試工具的確定文件服務(wù)器/配置服務(wù)器等的確定…WEB項目開發(fā)的一般流程—開發(fā)環(huán)境搭建開發(fā)環(huán)境搭建WEB項目開發(fā)的一般流程—開發(fā)開發(fā)-測試-開發(fā)-測試按照設(shè)計進行開發(fā)迅速開發(fā)原型進行迭代開發(fā)提早進行測試單元測試黑盒測試性能測試易用性測試…WEB項目開發(fā)的一般流程—開發(fā)開發(fā)-測試-開發(fā)-測試WEB項目開發(fā)的一般流程—總綱需求分析的確定(最重要)架構(gòu)與設(shè)計架構(gòu)分析與設(shè)計業(yè)務(wù)邏輯分析業(yè)務(wù)邏輯設(shè)計界面設(shè)計開發(fā)環(huán)境搭建開發(fā)-測試-開發(fā)-測試培訓(xùn)文檔編寫WEB項目開發(fā)的一般流程—總綱需求分析的確定(最重要)開發(fā)的一般流程—需求分析為什么需求分析需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發(fā)計劃的一個復(fù)雜過程，在這個過程中，用戶的確是處在主導(dǎo)地位，需求分析工程師和項目經(jīng)理要負責整理用戶需求，為之后的軟件設(shè)計打下基礎(chǔ)。需求分析階段結(jié)束后，要求得到相關(guān)的需求文檔，需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟件開發(fā)的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟件系統(tǒng)的開發(fā)中,他的作用要遠遠大于程序設(shè)計.

開發(fā)的一般流程—需求分析需求分析的任務(wù)需求分析的任務(wù)就是解決“用戶要做什么”的問題,就是要全面地理解用戶的各項要求,并準確地表達所接受的用戶需求，并且能夠根據(jù)自己對用戶需求的理解，勸說并誘導(dǎo)客戶剔除不合理的需求。需求分析的任務(wù)需求分析的任務(wù)就是解需求分析過程需求分析過程

需求分析過程需求分析過程

需求開發(fā)過程域

需求開發(fā)過程域

需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。

需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》。

需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。

需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。

需求開發(fā)過程域

需求開發(fā)過程域需求管理過程域需求管理過程域

需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。

需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。需求變更控制是指依據(jù)“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂需求管理過程域需求管理過程域需求開發(fā)過程中困難知識技能問題

行業(yè)知識是無邊無際的。俗話說“隔行如隔山”，需求分析員可能是某一領(lǐng)域的專家，但當他接手陌生的業(yè)務(wù)時，他該怎么辦？首先他要有勇氣做事，否則連實踐的機會都沒有。其次他應(yīng)當趕緊補習(xí)這一領(lǐng)域知識，不論是通過自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。如果可能的話，開發(fā)方最好請既懂軟件又懂應(yīng)用域知識的行家來幫忙。需求開發(fā)過程中困難知識技能問題需求開發(fā)過程中困難態(tài)度問題

相當多的開發(fā)人員習(xí)慣于被動地對待需求開發(fā)。每當遇到麻煩、挫折時，他們會發(fā)牢騷，找出一堆用戶的毛病。很多開發(fā)人員錯誤地以為：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_發(fā)軟件，難道用戶不該告訴我們應(yīng)當開發(fā)什么嗎？如果用戶說不清楚需求，或者經(jīng)常變更需求，這類問題是用戶產(chǎn)生的，應(yīng)當由他們自己負責。

用戶說不清楚需求或者需求發(fā)生變更，這些都是常見的問題，并不是絕癥，是人們可以設(shè)法解決的?？杀氖情_發(fā)人員把這些問題當成了借口，不愿主動攻克問題，導(dǎo)致需求問題擴散到整個軟件開發(fā)過程，產(chǎn)生太多的后患。軟件企業(yè)的領(lǐng)導(dǎo)應(yīng)當給具有錯誤觀念的開發(fā)人員們洗腦：需求分析員的天職就是在有限的時間內(nèi)獲取準確而細致的用戶需求，如果做不到就是失職，不要找借口。

需求開發(fā)過程中困難態(tài)度問題

合作關(guān)系

如果需求分析員不能與用戶建立良好的合作關(guān)系，那么他們在需求開發(fā)過程中會很疲憊。倘若用戶不能很好地配合需求分析員，那并不表示他是個壞蛋。因為用戶有他自己的想法：我回答了你們的問題，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧

……。

需求分析員不是銷售人員，他們不可能象銷售人員那樣通過某些手段籠絡(luò)住用戶就能成功。出色的需求分析員不僅要有過硬的專業(yè)知識，還要具備較強的交流、溝通能力。開發(fā)方與用戶的合作關(guān)系對需求開發(fā)而言是至關(guān)重要的。對于重大的、復(fù)雜的項目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關(guān)系，這樣風險太大。開發(fā)方和用戶方在開展需求開發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權(quán)利與義務(wù)”，即以協(xié)議的方式確定合作關(guān)系。“好話”和“丑話”都說在前頭，這樣能減少今后的摩擦。如果條件允許的話，開發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。

合作關(guān)系

如果需求分析員不能與用戶建立良好的合作關(guān)系，那用戶在需求工程中的“權(quán)利”用戶在需求工程中的“權(quán)利”1.有權(quán)要求開發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。2.有權(quán)要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。3.有權(quán)審查需求文檔，并對有爭議的需求作出決策。如果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。4.如果用戶想要變更需求，有權(quán)要求開發(fā)方對該變更將產(chǎn)生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶在需求工程中的“權(quán)利”用戶在需求工程中的“權(quán)利”用戶在需求工程中的“義務(wù)”用戶在需求工程中的“義務(wù)”1.以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。2.樂意接受需求分析員的采訪，在不泄漏機密的前提下盡可能地回答需求分析員的問題。3.在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關(guān)的材料。4.與需求分析員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。5.對專業(yè)性太深入的知識領(lǐng)域，用戶有義務(wù)組織開發(fā)人員進行簡單的培訓(xùn)。用戶在需求工程中的“義務(wù)”用戶在需求工程中的“義務(wù)”需求沒有做好的后果

需求沒有做好的后果如何準備調(diào)查需求需求分析員應(yīng)當確定需求調(diào)查的方式，例如：與用戶負責人交談，向用戶提問題。同未來此軟件的目標用戶交談，了解他們的目前的工作狀況.參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。從行業(yè)標準、規(guī)則中提取需求。如何準備調(diào)查需求需求分析員應(yīng)當確定需求調(diào)查的方式，例如：如何做好需求分析為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是上帝，用戶永遠是正確的。誰都知道這不是真的。事實上，很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現(xiàn)的需求。需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖。需求分析是需求開發(fā)過程中最費腦子的工作。分析方法大體有兩類：“問答分析法”和“建模分析法”。后者技術(shù)性比較強，寫出來有學(xué)術(shù)味，故大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用（保你一學(xué)就會），很有實用價值。“問答分析法”比較適合于用戶需求調(diào)查階段“建模分析法”比較適合于產(chǎn)品需求定義階段。如何做好需求分析為了得到用戶的金錢，企業(yè)不得不鼓吹：用戶就是問答分析方法問答分析方法

問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。問答分析最重要的問題是：“是什么”,”做什么”和“為什么”。每個需求都應(yīng)當用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當然”的，那么應(yīng)當解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。

其它常見的問題有：

需求存在二義性嗎？

需求文檔的上下文有矛盾嗎？

需求完備嗎？

需求是必要的嗎？

需求可實現(xiàn)嗎？

需求可驗證嗎？

需求的優(yōu)先級確定了嗎？

問答分析方法問答分析方法建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然.在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?/p>

恰當?shù)厥褂脠D形符號：現(xiàn)代建模工具如Rose、Jude有非常豐富的圖形符號和文字標注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別分析決策當需求從四面八方收集來后，需求的沖突在所難免。對于那些難以達成共識的需求而言，經(jīng)常會發(fā)生“公說公有理，婆說婆有理”的現(xiàn)象。那么需求分析員究竟應(yīng)該聽誰的呢？如果一群人對需求有爭議，并不是誰聲音最響就聽誰的。根據(jù)生活經(jīng)驗，最保險的辦法是：先聽官兒大的或者威望高的，如果大家的職位和威望都差不多，那么采用“少數(shù)服從大多數(shù)”的原則。如果一個產(chǎn)品可以賣給幾類客戶，但是各類客戶都要求產(chǎn)品按照他們的喜好來開發(fā)。此時對需求的決策應(yīng)當以商業(yè)利益為導(dǎo)向，即哪一類客戶出錢最多就先滿足他們的需求，以后再做那些獲利相對較少的需求。當開發(fā)者想象中的產(chǎn)品與客戶所提的需求有沖突時，一般應(yīng)當尊重客戶的觀點。但是不要陷入“客戶總是對的”陷阱里，需求分析員應(yīng)當糾正明顯不合理的客戶需求。如果產(chǎn)品很復(fù)雜，雙方都不太明白需求，此時最好請開發(fā)人員快速構(gòu)造軟件的原型，雙方看著軟件原型再分析需求分析決策當需求從四面八方收集來后，需求的沖突在所難免。對于什么是好的需求規(guī)格說明書正確

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

清楚

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

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

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

必要

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

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

《產(chǎn)品需求規(guī)格說明書》中的各項需求對用戶方而言應(yīng)當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。例如，摩天大樓的一項需求是“抗十二級臺風”，這個需求看起來堂而皇之，但是如何驗證呢？當摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風來試驗？如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試，那么這項需求就是“可驗證”的什么是好的需求規(guī)格說明書可驗證什么是好的需求規(guī)格說明書確定優(yōu)先級為什么要確定需求的“優(yōu)先級”？理論上講，軟件的所有需求都應(yīng)當被實現(xiàn)。但是在現(xiàn)實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級高的需求，后做（甚至放棄）優(yōu)先級低的需求，這樣可以將風險降到最低。需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。什么是好的需求規(guī)格說明書確定優(yōu)先級什么是好的需求規(guī)格說明書闡述“做什么”而不是“怎么做”《產(chǎn)品需求規(guī)格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”。“怎么做”是系統(tǒng)設(shè)計和實現(xiàn)階段的事情。國內(nèi)的很多軟件公司里，開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計、編程等工作從頭做到尾。所以他們在調(diào)查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調(diào)查、定義需求時想好了“怎么做”，當然應(yīng)該寫下來，否則豈不浪費！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說明書里面，記錄在其它文檔里就行了。什么是好的需求規(guī)格說明書闡述“做什么”而不是“怎么做”如何定義產(chǎn)品需求第一步：細化并分析用戶需求

需求分析員首先對《用戶需求說明書》進行細化，對比較復(fù)雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。例如采用Rational的Rose工具進行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《產(chǎn)品需求規(guī)格說明書》的附件。補充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當根據(jù)自身水平進行取舍。第二步：撰寫產(chǎn)品需求規(guī)格說明書

需求分析員按照指定的文檔模板撰寫《產(chǎn)品需求規(guī)格說明書》。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應(yīng)當撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》。第三步：進行需求確認項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《產(chǎn)品需求規(guī)格說明書》，盡最大努力使《產(chǎn)品需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。需求評審之后，開發(fā)方和客戶方的責任人對《產(chǎn)品需求規(guī)格說明書》作書面承諾。如何定義產(chǎn)品需求第一步：細化并分析用戶需求需求文檔《用戶需求說明書》與《產(chǎn)品需求規(guī)格說明書》的主要區(qū)別與聯(lián)系前者主要采用自然語言（和應(yīng)用域術(shù)語）來表達用戶需求，其內(nèi)容相對于后者而言比較粗略，不夠詳細。后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，產(chǎn)品需求是軟件系統(tǒng)設(shè)計的直接依據(jù)。兩者之間可能并不存在一一影射關(guān)系，因為軟件開發(fā)商會根據(jù)產(chǎn)品發(fā)展戰(zhàn)略、企業(yè)當前狀況適當?shù)卣{(diào)整產(chǎn)品需求，例如用戶需求可能被分配到軟件的數(shù)個版本中。軟件開發(fā)人員應(yīng)當依據(jù)《產(chǎn)品需求規(guī)格說明書》來開發(fā)當前產(chǎn)品。需求文檔《用戶需求說明書》與《產(chǎn)品需求規(guī)格說明書》的主要區(qū)別需求確認（評審和承諾）需求確認（評審和承諾）需求確認是指開發(fā)方和客戶方共同對《產(chǎn)品需求規(guī)格說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。人們在交流的時候，經(jīng)常會發(fā)生“問非所求，答非所問”的事情，用戶表達的需求，不同的開發(fā)人員可能有不同的理解。如果需求分析員誤解了需求，那會導(dǎo)致后續(xù)的不少開發(fā)人員將錯就錯、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯誤連高智商的外星人都不能避免：有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜里雙眼能射出強光?！腥さ氖牵嚴镒≈环N叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！辈徽撌菑?fù)雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少需求確認（評審和承諾）需求確認（評審和承諾）需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。

需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也