項目計劃軟件根據描述的具體操作方法及步驟

申請免費試用、咨詢電話：400-8352-114

　　泛普軟件針對需求做出分析，隨后應用于產品并提出方案。需求分析的模型正是產品的原型樣本，優(yōu)秀的需求管理提高了這樣的可能性：它使最終產品更接近于解決需求，項目計劃軟件提高了用戶對產品的滿意度，從而使產品成為真正優(yōu)質合格的產品。從這層意義上說，需求管理是產品質量的基礎。

　　項目計劃軟件根據上面描述的具體方法及步驟，由于需求分析的參與人員、業(yè)務模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風險,應引起項目相關干系人的注意。這些風險主要表現如下：

　　1)用戶不能正確表達自身的需求

　　在實際開發(fā)過程中，常常碰到用戶對自己真正的需求并不是十分明確的情況，他們認為計算機是萬能的，只要簡單的說說自己想干什么就是把需求說明白了，而對業(yè)務的規(guī)則、工作流程卻不愿多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花費更多的時間和精力與用戶交流，幫助他們梳理思路，搞清用戶的真實需求。從另一方面來看，他們對于計算機的理解肯定不是很到位，而我們如何引導，正確梳理出正確的需求就需要先從工作業(yè)務流程出發(fā)，而不是先從計算機方面來考慮問題。

　　2)業(yè)務人員配合力度不夠

　　有的用戶日常工作繁忙，他們不愿意付出更多的時間和精力向分析人員講解業(yè)務，這樣會加大分析人員的工作難度和工作量，也可能導致因業(yè)務需求不足而使系統(tǒng)無法使用。針對此類問題我們一般的做法是在項目開始階段先確定好一個與客戶溝通過的需求調研計劃，當然這樣還是經常會有變動，但相對來講從責任上來講，客戶也會有一定的壓力，因為如果不配合可能會導致系統(tǒng)進度的延誤，其實這也不是客戶希望看到的。

　　3)用戶需求的不斷變更

　　由于需求識別不全、業(yè)務發(fā)生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發(fā)生變化，因此，我們要認識到，軟件開發(fā)的過程實際上是同變化做斗爭的過程，需求變化是每個開發(fā)人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發(fā)生了需求變化，就不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等等，需求的變化就像是萬惡之源，為項目的正常的進展帶來不盡的麻煩。針對這類需求變更的問題，個人認為是影響進度的最大的敵人，目前我們的做法是每次根據客戶的需求整理出一個書面的文件，由客戶簽字確認。當然這里還有一個很重要的問題就是不是每個需求都是必須做的，我們要學習如何拒絕客戶。

　　4)需求的完整程度

　　需求如何做到沒有遺漏?這是一個大問題，大的系統(tǒng)要想窮舉需求幾乎是不可能的，即使小的系統(tǒng)，新的需求也總會不時地冒出來。一個系統(tǒng)很難確定明確的范圍并把所有需求一次性提出來，這會導致開發(fā)人員在項目進展中去不斷完善需求，先建立系統(tǒng)結構再完成需求說明，造成返工的可能性很大，會給開發(fā)人員帶來挫折感，降低他們完成項目的信心。

　　5)需求的細化程度

　　需求到底描述到多細，才算可以結束了?雖然國家標準有需求說明的編寫規(guī)范，但具體到某一個需求上，很難給出一個具體的指標，可謂仁者見仁，智者見智，并沒有定論。需求越細，周期越長，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求也越高，相反，需求越粗，開發(fā)人員在技術設計時不清楚的地方就越多，影響技術設計。

　　6)需求描述的多義性

　　需求描述的多義性一方面是指不同讀者對需求說明產生了不同的理解;另一方面是指同一讀者能用不同的方式來解釋某個需求說明。多義性會使用戶和開發(fā)人員等項目參與者產生不同的期望，也會使開發(fā)、測試人員為不同的理解而浪費時間，帶來不可避免的后果便是返工重做。（泛普軟件最新資訊）