導航:首頁 > 軟體問題 > 如何看待軟體需求變更

如何看待軟體需求變更

發布時間:2022-05-18 16:23:57

A. 什麼是需求變更

這對於ERP實施顧問來 說,正如晴天驚雷,這也是所有ERP顧問最感到恐怖的事情。因為有時候,用戶只是簡單的一句話,但是對於系統的調整來說工作量是非常大的。 一.需求變更:遷就or拒絕? 從 ERP項目立項開始,需求就是ERP實施顧問的心頭之痛。隨著對ERP的深入認識、項目環境的變動,企業內外部多種因素都可能使客戶對ERP的需求不斷改 變。如果不能有效處理這些需求變更,項目實施進度必將一再調整,上線日期也會隨之一再拖延,項目成員的士氣也將越來越低落,嚴重的還會直接導致ERP項目 失敗。 需求變更,本應是客戶的權力,但也是實施顧問的為難之處。如果確需變更,當然要滿足客戶需要。問題是不能讓變更權力濫用,把一些無 關痛癢的變更寵慣養成堂而皇之的變更。例如,我曾經在某ERP項目中屬於「謙虛型」,對於客戶提出的變更,無論大小都給予解決,客戶對此非常滿意。然而, 項目進度卻拖得很長,項目一再延期。相比之下,在另一個項目上我顯得稍有些「盛氣凌人」,對於客戶提出的需求變更,大多都不予理睬,客戶對此不是很滿意。 不過,該項目的進度控製得較好,基本能按期完成項目。 按後一種「盛氣凌人」的做法,對客戶的要求一概不理,自顧自地按照最初的需求和計劃 實施,很可能會由於沒有用戶的參與,使得ERP系統與用戶的需求相差甚遠,導致驗收通不過,收不回尾款而使公司利益受損。對於客戶來說,達不到需求的滿足 也浪費了投資。事實上,客戶不滿意,則項目就不算成功,實施顧問辛勤勞動最後就只能落得個「沒有功勞,只有苦勞」的份。 但按前一種「謙虛 型」做法,完全順著客戶的意見走,客戶滿意度就一定會高嗎?其實也不一定。由於需求變更會帶來工作量的大量增加,甚至可能會出現大量的無效勞動。而且,頻 繁變動的需求也會導致實施質量下降,留下許多隱患。因此,一味的遷就用戶將會使進度一拖再拖,實施方案一改再改,變更越來越多,士氣越來越疲,公司越來越 不滿意,用戶越來越急。 二.需求變更為什麼總是做不完? 在ERP實施過程中,實施顧問所要面對的將是一系列和多方面的考驗。經常發生而又最令人頭疼的恐怕就是需求變更了。客戶變更需求是ERP項目與生俱來的特性,也是一個無法避免的事實。需求變更的表現形式是多方面的,如客戶臨時改變想法、項目預算增加或減少、客戶對功能的需求改變等。它會導致ERP實施過程中成本增加、進度拖延等風險,而且越往後的變更產生的風險將越大。 以 筆者參與的多個ERP實施項目的實際經歷來看:需求變更泛濫是非常可怕的事,尤其是到了項目實施後期,客戶不斷對移交的ERP系統提出修改意見,甚至有時 剛剛重新完成的更改,客戶又要求改回去或改成另一種模式。需求變更越來越多,實施顧問只能疲於應付。「無底洞」是大部分實施顧問進行ERP項目的共同感 覺。 實施顧問作為項目的承擔者,在規定時間內利用有限資源保質保量的完成項目,讓客戶和公司都滿意是最終目標。但是讓客戶滿意就是不斷滿足客戶無窮無盡的需求嗎?我們分析一下出現需求變更的根源。 ERP實施最恐怖的事情:需求變更2 (1)合同簽訂馬虎,沒有真正明白客戶需求 簽訂合同時缺乏對客戶需求認真對待,導致需求描述不清,為後期的實施工作帶來困惑。ERP銷售顧問為使客 戶能夠快速的簽訂合同,往往草率決定和片面同意客戶提出的需求。當客戶提出新的需求時,往往是銷售顧問一看「應該」只是一個小小的修改,沒有太大的影響,所以直接答應能變更。 該問題的關鍵是合同簽署的太爛,沒有把需求明確再簽合同,而且也沒有把需求變更的流程寫入合同。如果在合同時把客戶需求弄清楚,後期就根本不需要頻繁的變更需求。簽訂合同時明確定義項目需求的范圍,可以為以後各項實施工作的開展奠定深厚的基礎。 (2)調研時沒有深入理解客戶需求 在erp上線前 的需求調研分析階段,項目組成員和客戶的深入交流是減少頻繁需求變更的關鍵階段之一。但是由於雙方的誤解通常使需求交流難以進行。更嚴重的是,實施顧問只 根據用戶提出的描述性、總結性的短短幾句話去制定實施方案,沒有真正挖掘和按客戶的需求去制定實施計劃。當客戶頭腦一熱或領導一拍腦袋提出新的需求時,實 施顧問往往也就不能區分客戶真正需求和鍍金需求。如果項目組對客戶需求的細節了解不充分,雙方對需求的理解就會產生差異,就會導致移交 ERP系統時才使問題暴露出來,客戶只能頻繁的提出需求變更。 (3)沒有明確的需求變更管理流程 沒有明確的需求 變更管理流程,就會使需求變更變得泛濫。並不是所有的變更都要修改,也不是所有變更都要立刻修改,需求變更管理的目的是為了決定什麼類型的變更需要修改和 什麼時候修改。比如ERP界面風格問題,就可以先不修改,或者規劃一下修改的時間待到以後進行優化。另外,對於核心模塊的修改沒有嚴格把關流程,有些小需 求看起來工作量不大,但是實際上實施顧問和開發顧問要耗費比較長的時間去完成這些銷售顧問或者客戶沒有考慮到的細節問題。 (4)沒有讓客戶知道需求變更的代價 對 變更的影響沒有評估是需求變更泛濫的根本原因。變更都是有代價的,應該要評估變更的代價和對項目的影響,要讓客戶了解需求變更的後果。如果客戶不知道需求 變更付出的代價,對實施顧問的辛苦就會難以體會。在評估代價過程中,可以請客戶一起做判斷:「我可以修改,但您能接受後果嗎?」。 三.如何有效控制需求變更? 需 求變更對項目成敗有重要影響,既不能一概拒絕客戶的變更要求,也不能一味地遷就客戶,所以實施需求變更之前必須做好控制。例如授權、審核、評估和確認,在 實施過程還要進行跟蹤和驗證。有句通俗的話說得非常好:「需求變更控制的目的不是控制變更的發生,而是對變更進行管理,確保變更有序進行。」 用戶需求的變更總是不可避免的,所以我們要以積極的心態去接受和控制用戶的需求,而不僅僅是埋怨。對待客戶頻繁的需求變更,應採取有效辦法應對,避免事態蔓延,不讓客戶養成隨意變更的毛病。 (1)合同約束 需求變更給ERP實施帶來的影響是有目共睹,所以在與用戶簽訂合同時,可以增加一些相關條款,如限定用戶提出需求變更的時間,規定何種情況的變更可以接受、拒絕或部分接受,還可以規定發生需求變更時必須執行變更管理流程。 雖然ERP項目合同很難在簽訂之初就能夠精確定義每項需求,單靠合同是幫不上忙的,但也不能忽視合同的約束力。有一個笑話,就是許多銷售顧問都開玩笑說他們都是清政府。為什麼是清政府?清政府的特點之一就是喪權辱國的條約太多。 (2)建立需求變更審批流程 要 明確需求變更審批環節、審批人員、審批事項、審批流程等。目的有兩個:一是將客戶下達變更的流程盡可能地規范化,減少張嘴就來的非必要、非緊急、非合理、 非高層領導意圖的「無效變更」。二是留下書面依據,為今後可能的成本變更和索賠准備好「變更賬」。凡未履行審批程序的「變更」,一律是無效變更不予受理。 有 效的需求變更流程應該包括確認變更、評估變更的價值、分析變更對項目的影響,以及提交給雙方高層進行評價以確定是否執行變更。變更請求必須有書面材料,當 用戶發現由於業務變化而引起的需求變更,需要提出書面申請。這樣對所有的變更,雙方的項目負責人都能做到心裡有數。而且用戶在遞交書面變更申請時比較慎 重,一般都在內部經過討論後進行,這樣減少了因用戶內部看法不同導致的反復變更。 ERP實施最恐怖的事情:需求變更3 (3)對於零星變更,集中研究、批量處理 每 周或每兩周甚至每月召開一次需求變更專題會議,集中研究處理這些零碎變更事項,主動控制好工作節奏,盡量避免由於處理零碎變更而影響項目運行的總體進度。 例如向客戶正式提交一份各階段需求變更的完成計劃,註明變更引起的時間、成本、工期的代價和增加的工作量。要求客戶配合需求變更計劃,確定變更時限,控制 變更規模,過時變更不候,離譜的變更不做,保大局棄小變。 (4)評估各種需求變更的影響 客戶的需求是永遠 不會滿足的,可能一天一個樣,為了達到控制頻繁的需求變更。需要將需求變更後產生的成本進行評估與量化,形成分析報告提交雙方領導。否則,一味的妥協只會 讓項目進一步惡化,實施顧問需要掌控客戶及公司的進度成本,把客戶的每一次需求變更進行成本分析。確認哪些需要收費變更,哪些可以免費配合客戶。這樣既可 以維護客戶關系,又不致造成公司無謂的損失。 (5)確認客戶是否接受變更的代價 要讓客戶認識到變更都是有代價的,要和客 戶一起判斷需求變更是否依然進行。例如,變更是沒有問題的,但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。一般來說,如果客戶 認為該變更是必須的(不是其上級領導拍腦袋提出的)就會接受這些後果,通過與客戶的協商,項目組可能會得到回報或者即使沒有回報也不會招致公司和客戶雙方 的埋怨。 如果客戶認為該變更雖然有必要但是可以暫緩,雙方簽署備忘錄後留待以後解決。如果客戶認為該變更可有可無,多數情況下會 取消變更。這樣即可防止頻繁變更,也讓客戶認識到不是所有的需求都需要變更,更不是所有的需求變更都需要立刻修改。客戶一般對ERP不甚了解,他們認為很 簡單的事情,但可能解決起來會很復雜。以筆者的經驗來看,一般來說用戶的鍍金需求可以延期解決甚至不考慮。用戶的新增需求如果不是影響到核心業務的實現, 也可以安排在現有功能的完善之後。 (6)每月變更記錄上報雙方領導 最後,實施顧問要將有關變更措施和記錄隨時抄報雙方最 高層留檔備案,可採取簡報、文件、抄報、抄送、會議等多種形式。掌握主動權,逐步讓不合理的隨意頻繁變更,成為客戶不好意思開口的尷尬事件,盡快形成正常 的項目執行氛圍和良好的工作習慣,也為可能受到變更所帶來的責任問題留下伏筆。

B. 如何有效控制需求變更

需求變更對軟體開發項目成敗有重要影響,既不能一概拒絕客戶的變更要求,也不能一味地遷就客戶,所以實施需求變更之前必須做好控制。需求變更控制的目的不是控制變更的發生,而是對變更進行管理,確保變更有序進行。 (1)明確合同約束,建立需求基線 需求變更給軟體開發帶來的影響有目共睹,所以在與客戶簽訂合同時,可以增加一些相關條款,如限定客戶提出需求變更的時間,規定何種情況的變更可以接受、拒絕或部分接受,還可以規定發生需求變更時必須執行變更管理流程。雖然軟體開發合同很難在簽訂之初就能夠精確定義每項需求,單靠合同是幫不上忙的,但也不能忽視合同的約束力。 明確和樹立需求基線是需求變更的依據。在開發過程中,需求確定並經過評審後(客戶參與評審),建立第一個需求基線。此後每次變更並經過評審後,都要重新確定新的需求基線,做到小需求可以變更,但大方向要力保不頻繁變更。例如,對於項目中的需求,可以實行分級管理,以達到對需求變更的控制和管理。 (2)建立變更審批流程 在實踐中,人們往往不願意為小的需求變更去執行正規的需求管理過程,認為降低開發效率,浪費時間。正是這種觀念才使需求變更變得不可控,最終導致項目的失敗。因此,小的需求變更也要經過正規的需求管理流程,否則會積少成多,積重難返。 明確需求變更審批環節、審批人員、審批事項、審批流程。這么做的目的有兩個:一是將客戶下達變更的流程盡可能地規范化,減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的無效變更。二是留下書面依據,為今後可能的成本變更和索賠准備好「變更賬」。凡未履行審批程序的「變更」,一律是無效變更不予受理。 (3)分級管理變更,定時批量處理 軟體開發項目中,「客戶永遠是對的」和「客戶是上帝」並不完全正確,因為在已經簽定的項目合同中,任何新需求的變更和增加除了影響項目的正常進行以外,還影響到客戶的成本投入收益。因此,用戶不斷提出對項目進度有重大影響的需求對雙贏也並不是好事。 當遇到客戶提出需求,不及時處理可能會使項目不能驗收通過時,也不能一味拒絕不予開發。因此,當客戶堅持變更新需求時,可以建議客戶將新需求按重要和緊迫程度劃分檔次,作為需求變更評估的一項依據。例如,每周或每兩周甚至每月召開一次需求變更專題會議,集中研究處理這些零碎變更事項,主動控制好工作節奏,盡量避免由於處理零碎變更而影響項目進度。針對會議結果可向客戶正式提交一份需求變更計劃,註明變更引起的時間、成本、工期代價和增加工作量等。要求客戶配合需求變更計劃,確定變更時限,控制變更規模,過時變更不候,離譜變更不做,保大局棄小變。 (4)安排專職人員負責變更管理 有時開發任務較重,開發人員容易陷入開發工作中而忽略了與客戶的隨時溝通。因此,需要安排一名專職的需求變更聯絡人員,負責與客戶及時交流,跟蹤和匯報需求變更完成進度和情況。同時,可以成立項目變更控制小組,負責裁定接受哪些變更,小組由項目所涉及的多方人員共同組成,應該包括客戶方和開發方的決策人員在內。 (5)確認客戶是否接受變更的代價 要讓客戶認識到變更都是有代價的,要和客戶一起判斷需求變更是否依然進行。例如,變更是沒有問題的,但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。一般來說,如果客戶認為該變更是必須的(不是其上級領導拍腦袋提出的)就會接受這些後果。通過與客戶協商,這樣開發團隊即使沒有回報,也不會招致公司和客戶雙方的埋怨。 如果客戶認為該變更雖然有必要但是可以暫緩,雙方簽署備忘錄後留待以後解決。如果客戶認為該變更可有可無,多數情況下會取消變更。這樣即可防止頻繁變更,也讓客戶認識到不是所有的需求都需要變更。

C. 如何正確對待需求的變更

軟體需求是軟體項目最難把握的問題,同時又是關系項目成敗的關鍵因素,因此對於需求分析和需求變更的處理十分重要。 軟體需求變更會給項目帶來巨大的風險,會導致項目的成本費用增加、開發周期延長、產品質量下降及團隊工作效率下降等不良後果,因而需求變更在軟體開發項目中應該盡量避免。然而由於政府對特定軟體的相關要求、用戶部門市場戰略的調整、工業界的發展等因素都可能帶來需求的變更,而這些因素往往不可避免。在軟體開發過程中如果只有一條真理的話,那一定是:需求的變化是永恆的,需求不可能是完備的。因而,對於需求變更應該正確的對待,盡量將其負面影響降低到最低。 2、減少需求變更 正如前文所說,需求變更往往是不可避免的。通常是項目負責人員花費了大量的氣力避免需求變更,可最後需求變更總是會出現。但是這並不意味著項目開發人員不應該做這方面的工作,項目開發人員對於需求變更的正確態度應該和軟體測試的態度一樣,在需求並更發生之前盡量減少需求變更,以將需求變更帶來的風險降低到最低。項目開發人員切忌在項目設計之前試圖消除需求變更,這樣做往往費力不討好。 相比於需求開發人員而言,客戶可能對需求變更認識不足,認為他們出錢,程序員或軟體開發公司就要為它服務,因此客戶對需求變更往往將需求變更視為兒戲,隨個人喜好隨意變更需求。因此,在需求人員同用戶代表或用戶部門主管人員接觸時,就應該向他們挑明態度,和他們協商好,特別是應該讓他們清楚軟體的定價應該與軟體的功能相關,以及需求隨意變更所帶來的風險的承擔者應該由客戶和項目開發者共同承擔。通過這樣做,讓客戶在需求分析之前就盡量對他們所需要的功能有個整體的了解和確定的思路,而不是等到程序員開始編碼了,才提出以前原本在需求分析時就可以提出的需求。 讓客戶明白減少需求變更的重要性後,需求分析人員應該採取合適的方法同客戶交流,幫助他們明確他們的需求。需求分析人員和客戶的關系不應該僅僅是記錄人員和需求提供者,他們的關系應該更多的是戰略合作夥伴關系。雖然需求分析人員和客戶存在著服務商和顧客的關系,但是他們有著一個共同的目標:開發出適合客戶需求的軟體,因此需求分析人員除了記錄客戶提出的需求以外,還應和用戶討論,提出一些建議,使用合適的工具幫助客戶提出需求。在需求分析時,盡量多的召集需求研討會,邀請開發人員和客戶共同協商探討,在研討會上允許任意的提出需求,並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能,這樣能夠盡量使得需求完備。在需求開發時,開發人員採用原型的方法啟發客戶思考功能需求也不失為一個好辦法。 雖然需求不可能是完備的,但是在項目開始設計時盡量使得需求完備還是應該的,也是值得的。 3、規範文檔 需求文檔作為客戶和開發人員的介面在整個項目開發過程中起著舉足輕重的作用。需求文檔應該按照一定的格式和規范書寫,而且應該具備完整性、一致性、基線控制、歷史記錄等特性。文檔書寫完畢以後應該交給客戶審閱,在客戶滿意的基礎上確定基線。一個完整規范的需求文檔不僅能夠有助於設計人員和編碼人員完成項目開發,更重要的是它作為一個階段性的成果可以供軟體需求變更時參考。 需求變更發生後,也應該生成相應的文檔,並且這些文檔的書寫也應該採用規范的形式書寫。需求變更文檔也應該包含基線以供下一次修改參考,還應包含歷史記錄以供開發人員和客戶清楚當前的文檔內容的新舊以及歷史文檔的情況,以備以後查看。 4、設計良好的體系結構 開發軟體就如同建造一座房屋,軟體體系結構則如同建房屋時的規劃。兩層高的家庭住宅和幾十層高的商業大廈建造時的規劃必然不同,同樣,大型軟體和小軟體採用的體系結構也必然有所區別。因此,設計一個合理的體系結構對於項目的成敗也是十分關鍵的。 體系結構的建立一般位於需求分析結束之後,軟體設計之前。軟體體系結構的設計是從結構的角度對整個系統進行分析,選擇合適的構件,安排構件間的相互作用以及他們之間的約束,形成一個系統框架以滿足用戶需求。在設計軟體體系結構時,不僅應該想到如何完成滿足現在已經提出的用戶需求,同時也應適當地考慮到需求的變更。 採用有彈性和可擴展的軟體體系結構設計可以有效地降低需求變更引起的風險和維護代價,能夠在項目范圍未發生變化的前提下很好地適應需求的變化。體系結構的靈活和可擴展性設計使得開發者可以在這種體系結構上面進行各個功能層的組合和分離,也可以將各個功能層分布在各個不同的伺服器上共同提供服務,因而能夠快速的對需求變更作出響應,並且對已經開發好的系統產生盡可能少的影響。 體系結構的設計除了考慮到體系結構的靈活性和可擴展性以外,還應盡量採用鬆散耦合的結構,使得結構中的各個構件之間的關聯程度盡可能的少,這樣就能在需求發生變更時一個構件的變化對另一個構件產生盡可能少的影響。 現有的軟體體系結構很多,包括管道-過濾器結構、B/S結構(含C/S結構)、解釋器/虛擬機結構、黑板系統以及基於中間件技術的體系結構。在設計體系結構時,首先應該選出適合項目需求的系統結構,然後在從中挑選出那些擴展性比較好,構件之間耦合性比較小的體系結構。基於中間件技術的體系結構就是擴展性比較好的體系結構。採用中間件技術,中間件作為用戶界面和操作系統以及網路的連接點,向上為用戶提供服務,向下屏蔽操作系統和網路的細節。這種分層的思想能夠很好的適應操作系統和網路的變化,可擴展性十分的好。同時,可以在中間件中給出容易改變的介面或是為系統將來改變預留介面來實現功能上的需求變更。當然可擴展性比較好的體系結構遠不止基於中間件技術的體系結構這一種,具體的選擇和運用應該由設計人員根據實際需要考慮。 5、採用面向對象思想 需求是不穩定的,因而沒有不變的需求,然而需求之中卻有穩定的東西,這就是對象。世界都是由對象組成的,而對象都是持久的,例如動物、植物已經有相當長的時間。雖然對象也在變化,動物、植物也在不斷的進化。但對象在一個相當長的時期內都存在,動植物的存在時間肯定比任何一家企業長久。面向對象的開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象,以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多,因為企業的模式一旦變化,只需要將穩定的企業對象重新組織就行了。 面向對象(OO)技術的三大特徵保證了採用OO技術可以建立易於改變和加強可重用性的軟體系統。封裝可以把問題影響的范圍縮小,外部的變化要求對系統的影響可以限定到某個類層次或某些類層次中,從而改變系統的一部分相對簡單;繼承可以使改變基於原有技術基礎,很大程度上減少重復開發工作;多態的應用可以使開發和設計人員在相對統一的介面下更改系統的實現細節,從而改變系統的行為。 顯然,OO技術是一種增強軟體可維護性、健壯性以及保持設計穩定性的一種分析和設計方法,可以在一定程度上快速對需求變更進行反應,並可相對減少需求變更需要的成本。因此,在系統開發過程中應該盡量的採用面向對象的思維方式來構建系統和開發系統。 6、需求變更控制 正如前文所言,需求變更不可避免的會發生,那麼當需求變更發生後項目開發人員應該如何應對呢? 一般來講,需求的變更通常意味著需求的增加,需求的減少相對很少,而且處理也比較容易。當客戶提出新需求的時候,項目開發人員應該分析這些新需求對項目現階段帶來的風險,得出雙方實現變更需求的需要的成本,包括時間、人力、資源等等方面,再與客戶商討是否有必要進行變更和如何在最小代價下實現變更。 當客戶確實希望進行需求變更時,可以讓開發人員開發一個快速原型,讓用戶體驗一下,以確保客戶確確實實的希望添加這些需求。在客戶和項目開發人員共同確定了需求變更後,項目開發人員應該與客戶簽訂一份新的合同。 當客戶提出需求變更並且簽訂了合同後或是開發人員根據市場和國家政策作出的需求變更得到確證後,項目開發人員應該決定何時實施這些變更。對於那些對系統影響不大和一些優先權十分高的需求變更可以立即在項目中實施,而對於那些對於整個系統現階段的開發影響很大,而且又不是十分緊急的需求可以放在下一個版本中進行。無論是立即實施還是放在下一個版本中,都應該給新的需求一個充足的開發和測試時間,保證產品質量。 結論 在面對需求變更時,除了通過減少需求變更和規範文檔,從分析和設計的角度通過採用合理的分析和設計方法適應需求變更以外,還應該改變我們設計的意識和對需求變更的理解,做好對需求變更的控制和管理,做到對需求變更的靈活應對,在一定程度上降低維護代價和提高用戶滿意度。

D. 談談如何應對軟體開發中的需求變更

看軟體開發到什麼程度, 以及需求變動的大小了
如果需求變動很大, 開發完成度很低, 可以考慮推到重來
如果只能採用"修改"的方式, 一般第一件事一定是背後里使勁罵人....

E. 如何正確對待軟體測試需求的變更

軟體需求是軟體項目最難把握的問題,同時又是關系項目成敗的關鍵因素,因此對於需求分析和需求變更的處理十分重要。 軟體需求變更會給項目帶來巨大的風險,會導致項目的成本費用增加、開發周期延長、產品質量下降及團隊工作效率下降等不良後果,因而需求變更在軟體開發項目中應該盡量避免。然而由於政府對特定軟體的相關要求、用戶部門市場戰略的調整、工業界的發展等因素都可能帶來需求的變更,而這些因素往往不可避免。在軟體開發過程中如果只有一條真理的話,那一定是:需求的變化是永恆的,需求不可能是完備的。因而,對於需求變更應該正確的對待,盡量將其負面影響降低到最低。 2、減少需求變更 正如前文所說,需求變更往往是不可避免的。通常是項目負責人員花費了大量的氣力避免需求變更,可最後需求變更總是會出現。但是這並不意味著項目開發人員不應該做這方面的工作,項目開發人員對於需求變更的正確態度應該和軟體測試的態度一樣,在需求並更發生之前盡量減少需求變更,以將需求變更帶來的風險降低到最低。項目開發人員切忌在項目設計之前試圖消除需求變更,這樣做往往費力不討好。 相比於需求開發人員而言,客戶可能對需求變更認識不足,認為他們出錢,程序員或軟體開發公司就要為它服務,因此客戶對需求變更往往將需求變更視為兒戲,隨個人喜好隨意變更需求。因此,在需求人員同用戶代表或用戶部門主管人員接觸時,就應該向他們挑明態度,和他們協商好,特別是應該讓他們清楚軟體的定價應該與軟體的功能相關,以及需求隨意變更所帶來的風險的承擔者應該由客戶和項目開發者共同承擔。通過這樣做,讓客戶在需求分析之前就盡量對他們所需要的功能有個整體的了解和確定的思路,而不是等到程序員開始編碼了,才提出以前原本在需求分析時就可以提出的需求。 讓客戶明白減少需求變更的重要性後,需求分析人員應該採取合適的方法同客戶交流,幫助他們明確他們的需求。需求分析人員和客戶的關系不應該僅僅是記錄人員和需求提供者,他們的關系應該更多的是戰略合作夥伴關系。雖然需求分析人員和客戶存在著服務商和顧客的關系,但是他們有著一個共同的目標:開發出適合客戶需求的軟體,因此需求分析人員除了記錄客戶提出的需求以外,還應和用戶討論,提出一些建議,使用合適的工具幫助客戶提出需求。在需求分析時,盡量多的召集需求研討會,邀請開發人員和客戶共同協商探討,在研討會上允許任意的提出需求,並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能,這樣能夠盡量使得需求完備。在需求開發時,開發人員採用原型的方法啟發客戶思考功能需求也不失為一個好辦法。 雖然需求不可能是完備的,但是在項目開始設計時盡量使得需求完備還是應該的,也是值得的。 3、規範文檔 需求文檔作為客戶和開發人員的介面在整個項目開發過程中起著舉足輕重的作用。需求文檔應該按照一定的格式和規范書寫,而且應該具備完整性、一致性、基線控制、歷史記錄等特性。文檔書寫完畢以後應該交給客戶審閱,在客戶滿意的基礎上確定基線。一個完整規范的需求文檔不僅能夠有助於設計人員和編碼人員完成項目開發,更重要的是它作為一個階段性的成果可以供軟體需求變更時參考。 需求變更發生後,也應該生成相應的文檔,並且這些文檔的書寫也應該採用規范的形式書寫。需求變更文檔也應該包含基線以供下一次修改參考,還應包含歷史記錄以供開發人員和客戶清楚當前的文檔內容的新舊以及歷史文檔的情況,以備以後查看。 4、設計良好的體系結構 開發軟體就如同建造一座房屋,軟體體系結構則如同建房屋時的規劃。兩層高的家庭住宅和幾十層高的商業大廈建造時的規劃必然不同,同樣,大型軟體和小軟體採用的體系結構也必然有所區別。因此,設計一個合理的體系結構對於項目的成敗也是十分關鍵的。 體系結構的建立一般位於需求分析結束之後,軟體設計之前。軟體體系結構的設計是從結構的角度對整個系統進行分析,選擇合適的構件,安排構件間的相互作用以及他們之間的約束,形成一個系統框架以滿足用戶需求。在設計軟體體系結構時,不僅應該想到如何完成滿足現在已經提出的用戶需求,同時也應適當地考慮到需求的變更。 採用有彈性和可擴展的軟體體系結構設計可以有效地降低需求變更引起的風險和維護代價,能夠在項目范圍未發生變化的前提下很好地適應需求的變化。體系結構的靈活和可擴展性設計使得開發者可以在這種體系結構上面進行各個功能層的組合和分離,也可以將各個功能層分布在各個不同的伺服器上共同提供服務,因而能夠快速的對需求變更作出響應,並且對已經開發好的系統產生盡可能少的影響。 體系結構的設計除了考慮到體系結構的靈活性和可擴展性以外,還應盡量採用鬆散耦合的結構,使得結構中的各個構件之間的關聯程度盡可能的少,這樣就能在需求發生變更時一個構件的變化對另一個構件產生盡可能少的影響。 現有的軟體體系結構很多,包括管道-過濾器結構、B/S結構(含C/S結構)、解釋器/虛擬機結構、黑板系統以及基於中間件技術的體系結構。在設計體系結構時,首先應該選出適合項目需求的系統結構,然後在從中挑選出那些擴展性比較好,構件之間耦合性比較小的體系結構。基於中間件技術的體系結構就是擴展性比較好的體系結構。採用中間件技術,中間件作為用戶界面和操作系統以及網路的連接點,向上為用戶提供服務,向下屏蔽操作系統和網路的細節。這種分層的思想能夠很好的適應操作系統和網路的變化,可擴展性十分的好。同時,可以在中間件中給出容易改變的介面或是為系統將來改變預留介面來實現功能上的需求變更。當然可擴展性比較好的體系結構遠不止基於中間件技術的體系結構這一種,具體的選擇和運用應該由設計人員根據實際需要考慮。 5、採用面向對象思想 需求是不穩定的,因而沒有不變的需求,然而需求之中卻有穩定的東西,這就是對象。世界都是由對象組成的,而對象都是持久的,例如動物、植物已經有相當長的時間。雖然對象也在變化,動物、植物也在不斷的進化。但對象在一個相當長的時期內都存在,動植物的存在時間肯定比任何一家企業長久。面向對象的開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象,以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多,因為企業的模式一旦變化,只需要將穩定的企業對象重新組織就行了。 面向對象(OO)技術的三大特徵保證了採用OO技術可以建立易於改變和加強可重用性的軟體系統。封裝可以把問題影響的范圍縮小,外部的變化要求對系統的影響可以限定到某個類層次或某些類層次中,從而改變系統的一部分相對簡單;繼承可以使改變基於原有技術基礎,很大程度上減少重復開發工作;多態的應用可以使開發和設計人員在相對統一的介面下更改系統的實現細節,從而改變系統的行為。 顯然,OO技術是一種增強軟體可維護性、健壯性以及保持設計穩定性的一種分析和設計方法,可以在一定程度上快速對需求變更進行反應,並可相對減少需求變更需要的成本。因此,在系統開發過程中應該盡量的採用面向對象的思維方式來構建系統和開發系統。 6、需求變更控制 正如前文所言,需求變更不可避免的會發生,那麼當需求變更發生後項目開發人員應該如何應對呢? 一般來講,需求的變更通常意味著需求的增加,需求的減少相對很少,而且處理也比較容易。當客戶提出新需求的時候,項目開發人員應該分析這些新需求對項目現階段帶來的風險,得出雙方實現變更需求的需要的成本,包括時間、人力、資源等等方面,再與客戶商討是否有必要進行變更和如何在最小代價下實現變更。 當客戶確實希望進行需求變更時,可以讓開發人員開發一個快速原型,讓用戶體驗一下,以確保客戶確確實實的希望添加這些需求。在客戶和項目開發人員共同確定了需求變更後,項目開發人員應該與客戶簽訂一份新的合同。 當客戶提出需求變更並且簽訂了合同後或是開發人員根據市場和國家政策作出的需求變更得到確證後,項目開發人員應該決定何時實施這些變更。對於那些對系統影響不大和一些優先權十分高的需求變更可以立即在項目中實施,而對於那些對於整個系統現階段的開發影響很大,而且又不是十分緊急的需求可以放在下一個版本中進行。無論是立即實施還是放在下一個版本中,都應該給新的需求一個充足的開發和測試時間,保證產品質量。 結論 在面對需求變更時,除了通過減少需求變更和規範文檔,從分析和設計的角度通過採用合理的分析和設計方法適應需求變更以外,還應該改變我們設計的意識和對需求變更的理解,做好對需求變更的控制和管理,做到對需求變更的靈活應對,在一定程度上降低維護代價和提高用戶滿意度。

F. 軟體項目管理實踐之如何控制需求變更

需求變更的控制關鍵在於建立建立相應的控制組織、變更控制和跟蹤系統以及規范變更流程,主要有:
1、建立組織。項目啟動時,需要盡可能的與客戶溝通,建立正式的對變更進行控制的組織,成員包括雙方高層(掛名)、甲乙雙方的項目負責人、相關的需求負責人等。如果客戶認為無需單獨設置這樣的正式組織,也會要求客戶指定項目的負責人,每個相關的業務科室指定一名需求負責人,這樣做的目的是如出現變更可以很快的臨時組建一個對變更負責的組織,並且可以找到相應的負責人;
2、建立變更控制和跟蹤系統。建立該系統的目的是統一管理需求變更和跟蹤變更的狀態,便於項目組測試人員、開發人員、系統分析員以及PM相互之間的溝通和交流;經比較和選型,可以選用了JIRA作為變更控制和跟蹤系統;
3、規范流程。甲乙雙方的項目組成立後,根據角色定義,確定變更流程。
1)變更申請。系統界面如按鈕的位置、欄位的位置的細微調整,不涉及到業務規則,對基線基本沒有影響的變更,由測試人員直接在變更控制系統中提出;其他如操作風格的較大變化、業務規則的變化等,均要求客戶提出電子和書面的需求變更單;
2)變更評估。由項目組組織人員對變更進行變更的合理性分析,變更替換方案分析,工作量的估算以及涉及什麼模塊、影響什麼模塊等影響分析;
3)變更決策。根據上節確定的溝通策略,與客戶溝通交流,確定變更的處理方式;
4)變更實施。由測試人員在變更控制系統中填寫變更信息(狀態:待處理),由系統分析員填寫處理方法和影響分析後交由開發人員實施(狀態:處理中);
5)變更驗證。測試人員根據變更控制系統的變更狀態反饋(狀態:已解決),待相應的版本發布後,對變更進行驗證測試,這時候特別要注意的是記錄該變更的修改是否引起了該模塊或其他模塊產生缺陷。通常,測試人員根據系統分析員在變更控制系統中標注的影響模塊,逐一進行回歸測試,以確保不影響原有模塊的前提下變更已正確實施;內部測試完畢後,如系統已上線,則由客戶相關負責人在模擬生產環境中進行驗收測試;
6)溝通歸檔。變更驗證後,測試人員關閉變更(狀態:已關閉),項目經理告知客戶已測試完畢,溝通發布時間並說明那些模塊可能有影響以及發現問題的反饋途徑和方式。

通過以上幾種手段,如執行實施到位,基本可以有效的把變更置於控制之下。
最後,值得一提的是,變更實施或者系統缺陷修復涉及到多方面的人員,可能牽涉軟體系統中的多個模塊,處理和驗證的流程復雜,溝通等管理成本高昂,如果變更和質量控制不好,會直接影響項目的進度和成本。

G. 如何進行軟體需求分析

軟體需求分析免費下載

鏈接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

提取碼:qoyw

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等,是開發人員經過深入細致的調研和分析,准確理解用戶和項目的功能、性能、可靠性等具體要求,將用戶非形式的需求表述轉化為完整的需求定義,從而確定系統必須做什麼的過程。

H. 需求變更對項目的影響及如何降低需求變更管理

1. 需求變更對項目的影響:當客戶提出新需求的時候,需求人員應該分析這些需求對項目帶來的風險,得出雙方實現變更需求需要的成本,包括時間、人力、資源等等方面。變更都是有代價的,在評估代價對於項目的影響中,要讓客戶了解變更的後果。變更之後面臨的最大問題就是項目延期,和客戶一起做判斷:「我可以做修改,但您能接受後果嗎?」。這樣會出現三種可能:客戶接受延期,項目組按照客戶要求進行修改;客戶不接受延期,並願意將變更取消或者延到下個合同處理;客戶不接受延期,但要求在合同要求完成時間點完成,這種情況很有可能項目失敗。(第三種情況是在軟體項目中出現最多,並且最讓項目經理頭疼,但是由於這個情況的分析很復雜,推薦項目經理參閱林銳博士的《如何管理軟體企業》第二版,書中有詳細闡述。)2. 需求變更管理不能降低需求變更,但能夠控制和管理需求變更,需求變更管理是對變更的需求進行科學的管理,並規范流程。需求變更的表現形式是多方面的,如老闆臨時改變想法、項目預算增減、客戶對功能的需求改變等。在軟體項目中,變更可能來自客戶方、供應商等,也可能來源於項目組內部。雖然需求變更的表現形式千差萬別,但究其根本不外乎以下幾種原因: 業務不熟悉,范圍沒有圈定就開始細化; 缺乏需求開發(需求調研、分析)能力; 流程不規范,缺乏需求變更管理流程,沒有建立需求基線等; 沒有區分好合同外的變更。項目經理必須面對這個現實:需求變更是不可避免的。項目經理應該做的,是如何針對可知的變更的來源進行預防,是如何在發生需求變更的情況下盡量減少其對項目的影響。

I. 為什麼在軟體開發過程中需求變更是不可避免的

我想說,你知道啥是你說說的需求么?
舉個例子說:
某家公司開發一款OA系統,首先他們公司有什麼財務部啊,人事部啊,等等。
需求方真的是不可能一下子都想的那麼全,他軟體要啥功能。這是其一;
其二:在初步的需求上完成以後,需求方對OA 肯定有了更進一步的了解,這時候或許才能在上次的基礎上明確需求的。

這個需求變更肯定是不不可避免的。實在想不通的話,你就想想你自己要做一款軟體,你能一下把你的所有的需求和開發商說的明明白白的嗎?你敢確定你提出需求後永遠不變么?

希望可以幫到你!

J. 軟體開發,需求變更怎麼辦

對於開發的時間周期、變更需求的後費用的添加、或者是設備使用等環節加以限定即可。

閱讀全文

與如何看待軟體需求變更相關的資料

熱點內容
電腦上怎麼下載班智達的軟體 瀏覽:760
無痕跡消除圖片軟體 瀏覽:365
免費小票軟體 瀏覽:591
華為在哪裡設置軟體停止運行 瀏覽:478
用電腦鍵盤調節聲音大小 瀏覽:916
自動刷軟體賺錢 瀏覽:814
古裝連續劇免費版 瀏覽:969
工免費漫畫 瀏覽:652
手機軟體專門儲存文件 瀏覽:1154
uos如何用命令安裝軟體 瀏覽:925
有線耳機插電腦麥克風 瀏覽:313
侏羅紀世界3在線觀看完整免費 瀏覽:651
單個軟體怎麼設置名稱 瀏覽:379
鳳凰網電腦版下載視頻怎麼下載視頻怎麼下載 瀏覽:1036
明白之後如何免費獲得無人機 瀏覽:467
如何解禁軟體菜單 瀏覽:464
副路由器連接電腦視頻 瀏覽:1009
內置wifi電視如何裝軟體 瀏覽:699
手機換零免費雪碧 瀏覽:1213
國行蘋果如何下載美版軟體 瀏覽:833