需求收集真正的體現了需求的市場(chǎng)和用戶(hù)驅動(dòng)。訪(fǎng)談，調查表，頭腦風(fēng)暴，競爭對手和產(chǎn)品分析都是需求收集的方法。需求收集我們需要搞清楚用戶(hù)真正的需求，問(wèn)題背后的深層次問(wèn)題，這樣才可能為挖掘需求提供數據。需求收集的過(guò)程應該流程化，收集的需求應該分類(lèi)入庫的歸檔化。必須將需求收集活動(dòng)看做為一個(gè)結構化的流程或過(guò)程，以真正的促進(jìn)收集的過(guò)程和采集的數據的有效性。

　　收集的需求在論證分析中應該確定優(yōu)先級，而優(yōu)先級的確認應該引入價(jià)值工程，即我們應該認識到一個(gè)需求的重要性應該體現到它對產(chǎn)品價(jià)值的短期和長(cháng)期的增值上面。要理解這個(gè)，就必須要考慮收集的需求是普遍需求還是特殊需求，是核心業(yè)務(wù)對應需求還是輔助業(yè)務(wù)對應需求，是使用頻率高的需求還是偶爾使用的功能點(diǎn)需求。我們必須有清晰的頭腦來(lái)分析用戶(hù)急的是否就一定是優(yōu)先級高的需求。

　　用戶(hù)往往習慣了給我們提希望系統實(shí)現什么功能，這些需求往往是用戶(hù)已經(jīng)轉換后的需求而不是原始需求。當用戶(hù)遇到業(yè)務(wù)上的問(wèn)題的時(shí)候他們往往假設了一種實(shí)現方式，如果在需求收集過(guò)程中錯誤的把問(wèn)題的解當做需求，則我們就忽略掉了真正的原始需求。需求收集的重點(diǎn)應該在用戶(hù)真正面臨的問(wèn)題域和問(wèn)題場(chǎng)景的收集。

　　需求收集人員的業(yè)務(wù)背景和經(jīng)驗往往對需求收集有效性有很大的影響。需求收集的訪(fǎng)談過(guò)程不是簡(jiǎn)單的聽(tīng)用戶(hù)如何講，而是需求我們去引導用戶(hù)講出他們真正面臨的問(wèn)題。通過(guò)我們積極的溝通讓用戶(hù)把他們真實(shí)的想法真正的表達出來(lái)。

　　需求收集是整個(gè)軟件產(chǎn)品開(kāi)發(fā)的源頭，是確定產(chǎn)品方向和定位的重要活動(dòng)。需求收集活動(dòng)出現大的誤差將是方向性的重大錯誤。如果我們開(kāi)發(fā)出來(lái)的產(chǎn)品不能真正滿(mǎn)足用戶(hù)的需要和得到用戶(hù)的認可，那產(chǎn)品本身就不可能創(chuàng )造價(jià)值，及時(shí)這個(gè)產(chǎn)品有很好的質(zhì)量，易用性和功能等，這個(gè)產(chǎn)品仍然是失敗的。

　　需求分析和開(kāi)發(fā)

　　需求分析工作需要意識到是包含了業(yè)務(wù)分析和系統分析兩部分內容。對于業(yè)務(wù)分析包括了業(yè)務(wù)流程分析，組織結構和崗位角色分析，以外的對象分析，數據流分析，重點(diǎn)是描述現在。系統分析的內容重點(diǎn)是將需求轉換為系統可實(shí)現的軟件需求，因此必須要考慮到需求的可實(shí)現性，如果對于面向對象分析則重點(diǎn)在用例分析，業(yè)務(wù)對象建模，業(yè)務(wù)規則分析。系統分析最好是有軟件開(kāi)發(fā)經(jīng)驗的人和業(yè)務(wù)背景的人進(jìn)行，這里的一個(gè)重點(diǎn)就是要把軟件開(kāi)發(fā)中已經(jīng)成熟的分析模式和模型和實(shí)際的業(yè)務(wù)進(jìn)行匹配。

　　軟件產(chǎn)品要能夠適應需求的變化，不僅僅是軟件架構上的可擴展性考慮，更重要的是在需求分析階段就需要考慮軟件需求如何適應用戶(hù)需求的變化。對應用戶(hù)經(jīng)�？赡茏儎�(dòng)的需求點(diǎn)進(jìn)行抽象，引入一些標準的可配置的模型，如權限模型，工作流模型等。軟件需求對業(yè)務(wù)需求和用戶(hù)需求的一個(gè)處理要點(diǎn)就是會(huì )考慮到哪些經(jīng)常變化的需求需要轉換為靈活的可配置的需求。

　　用戶(hù)都不清楚自己要什么或者說(shuō)用戶(hù)的需求經(jīng)常變動(dòng)更應該促進(jìn)我們去改進(jìn)需求分析和開(kāi)發(fā)的過(guò)程。在這個(gè)時(shí)候系統分析員的開(kāi)發(fā)經(jīng)驗和業(yè)務(wù)背景將起到很重要的作用。需求的一種變更對于軟件開(kāi)發(fā)往往是一種必然的情況，只是如何把它變更的范圍控制住，如何實(shí)現需求的變更不是要修改設計和編碼，而是通過(guò)靈活的配置來(lái)實(shí)現的。

　　收集來(lái)的用戶(hù)需求如何轉換為需求規格說(shuō)明書(shū)，中間的一個(gè)重要過(guò)程就是需求分析和開(kāi)發(fā)。這樣正好體系一些需求分析工作的重點(diǎn)內容，通過(guò)識別需求的優(yōu)先級以更好的安排項目資源和進(jìn)度，有的放矢。通過(guò)對原始需求的分類(lèi)，合并，抽象以提取通用的需求模型。通過(guò)識別非功能性需求以增加整個(gè)系統的健壯性，性能和易用性。通過(guò)對需求模塊單元的劃分，流程和規則的描述，功能點(diǎn)分析為項目進(jìn)度計劃安排和進(jìn)度跟蹤創(chuàng )造條件。因此我們將需求分析是一種業(yè)務(wù)和系統的模式匹配，如果才能夠匹配好就是需求分析的責任。

　　需求管理

　　應該首先看到需求管理的目的首先為項目管理服務(wù)，結構化的需求管理使項目管理真正做到可視化，另外需求管理為用戶(hù)服務(wù)，通過(guò)有效的需求管理能夠更好的滿(mǎn)足用戶(hù)的需求，提升用戶(hù)滿(mǎn)意度。最后需求管理為后續項目提供支持數據和依據，因為需求管理的內容是結構化和文檔化的，這些是內容是項目重要的過(guò)程資產(chǎn)。

　　要管理需求，則我們的需求必須是結構化和文檔化的，否則就談不上需求管理。因此需求管理必然會(huì )涉及到配置管理相關(guān)工作。同時(shí)為了量化的說(shuō)明需求管理的有效性，我們的需求本身又必須是可度量的，需求功能點(diǎn)的粒度應該在一定范圍內。需求規格說(shuō)明書(shū)是需求管理的重要對象，必須文檔化，而且會(huì )在整個(gè)軟件開(kāi)發(fā)生命周期中被多次使用到。

　　需求全生命周期的管理的一個(gè)重點(diǎn)就是需求的狀態(tài)管理，用戶(hù)提出來(lái)的需求就是是否實(shí)現了，現在處在哪個(gè)環(huán)節都需要依靠需求的狀態(tài)管理和跟蹤來(lái)實(shí)現。因此需求分析階段需求功能點(diǎn)的條目化就是需求狀態(tài)管理的一個(gè)重點(diǎn)，而需求狀態(tài)跟蹤的過(guò)程正好就是我們對項目進(jìn)度和狀態(tài)的跟蹤過(guò)程。如果項目管理的狀態(tài)監控的好，則需求狀態(tài)管理也可以做好，同時(shí)拆分后的需求狀態(tài)管理為我們增量和迭代開(kāi)發(fā)提供了基礎，有了這個(gè)才可能真正做好項目掙值管理，才可以更好的應用掙值中的0-100原則。

　　需求的變更控制重要性體現在真正的使甲乙雙方對范圍的承諾有共同的重視。當有了共同基準依據的時(shí)候才能夠真正的體現用戶(hù)滿(mǎn)意度上面，同時(shí)需求變更真正的體現出項目計劃的嚴肅性，保證項目計劃的受控和嚴格執行。需求老發(fā)生變動(dòng)，項目老延期都是需求變更沒(méi)有做好的一種表現形式。對于已經(jīng)開(kāi)發(fā)完成的軟件產(chǎn)品，我們更需要有結構化的需求變更流程，將變更的影響分析影響植入到流程中，這樣才可以保證整個(gè)軟件產(chǎn)品的穩定性。