我們應當怎麼做需求分析

2022-07-26 01:39:10 字數 1615 閱讀 2320

無體現出論是從東軟開發軟體還是作者自己開發軟體的經歷中都體現出提前做好全面徹底的需求分析的重要性。而且就像上課時提到的不能完全任由客戶提出需求,也就是不能說使用者提出什麼需求就完成什麼,應該就能力還有開發實際情況,還有社會情況綜合提出。這樣給出自己的建設性的意見,不僅能夠使開發過程更加得心應手,而且能夠在客戶心裡樹立權威。做需求調研不是形式主義而是要深入細節的調查,具體功能方面應該詳細詢問相關底層工作人員。另外強調的乙個重點就是需求分析不是一蹴而就的,它應當貫穿整個開發周期,不斷的分析確認的過程。

首先,從第一印象開始,要適時表達出自己的意見從而讓客戶覺得自己比較有見地。中國是乙個注重感情的國度,感情培養起來才好慢慢做事。在會議之前重要的是確定乙個負責人,這樣能夠有助於在場面比較複雜的時候讓其控制局面最終拍板決定。最後,與客戶方領導制訂出軟體目標,是相當重要但常常被我們忽視的乙個步驟。軟體資訊化管理不是包治百病的神藥。很多專案的失敗都歸因與專案目標不明確造成的專案範圍的失控。因此,這時討論專案目標,既重要又適時。總結為三點1)樹立良好的職業威信;2)進行詳細角色分析,將與會各方代表對號入座;3)從巨集觀上制訂目標與方案。在開發過程中努力去結識一些有助於我們順利完成工作的人,和領域專家搞好關係,對那些對我們懷有敵意的人也不要抱著針尖對麥芒的心理,應當盡量化干戈為玉帛。研討會也是一樣,不能夠指望一次性解決所有問題,應該多開小會,有針對的開小會。

其次,在接下來的需求調研上,我們經歷了,需求研討、迭代、需求捕獲、功能功能角色分析以及繪製用例圖。這時候我們的系統整體結構已經大概清晰,然後我們進行業務流程分析,將系統劃分為幾個模組,然後針對每個模組進一步繪製用例圖。在這個過程中,我們應該嘗試縮減低效模組,促成更高效的系統,方便操作的同時,能夠降低我們的工作量。簡單說就是清除低效環節、簡化業務瓶頸、整合可用資源,以及將繁瑣任務自動化。

然後,接下來在繪製用例圖之後要對用例進行說明,那些查詢、彙總與報表功能,需要我們描述的不是什麼操作流程,而更重要的是那些資料項、資料**、報**式、資料鏈結,以及使用者、使用頻率的說明。就是到了我們的查詢報表分析。之後要對子用例和拓展用例進行分析,只有不斷的分析細節才能防止一些必不可少的細節的疏漏。用例圖能夠清晰的展示系統的邊界還有實現的功能,但是不能夠動態的去描述系統所要實現的功能。行**還有狀態圖能夠有效的彌補這一弊端,但是在需求分析中,狀態圖並不是必須的,它僅僅出現在你認為需要對某個物件的狀態進行說明的時候。

再者,接下來就是業務領域分析,業務領域分析,就是對需求分析中涉及到的業務實體,以及它們相互之間關聯關係的分析。系統中涉及的表單、報表,都是存在於系統的靜態實體,它們中的大多數也最終以資料結構的形式持久化儲存於系統的資料庫中。因此,系統中應當有哪些實體,這些實體都有哪些屬性,被賦予了哪些行為,它們之間的相互關係是怎樣的,就成為了業務領域分析的重要內容,而業務領域分析也就成為了對系統進行的一種靜態分析。原文分析是在進行了用例分析還有流程分析以後對結果進行進一步的分析。在伊大師的這個思想中,我們應當與客戶代表形成一種統一的語言,一種混合語言。這種語言,既有軟體技術中的元素,又有業務領域中的術語,這樣才能有效消除隔閡,讓業務人員和技術人員更有效的交流。在設計軟體過程中往往忽略非功能方面的設計,所以應該早日讓構架師加入討論以實現系統效能,還有可靠性等構架層次問題的解決。

最終,在編寫需求規格說明書時注意不能脫離需求。在寫好需求列表,編寫出了需求規格說明書後,不代表需求分析就此結束了,它將延續到設計、開發,甚至測試階段。整個過程雖然辛苦,但是會為以後的開發工作避免很多誤區。

我們應當怎麼做需求分析

又到新年了,日曆又要從2011年翻到2012年了,這使我有太多的感慨,進而勾起了對太大往事的回憶。過去的10年,毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候,還在使用vb pb開發一些簡單的資料庫應用,而現在卻幾乎看不到它們的蹤影,換來的是諸如j2ee和.net這樣的大型web應用。而...

閱讀筆記 我們應當怎麼做需求分析

看了那篇長 如果說是本學期 軟體需求與分析 需要掌握哪些必要的內容的話,我想從宗旨角度這個方面來說。從宗旨角度,縱觀全文,應該講的就是以下的內容 首先,要了解客戶真正的需求。這一點,上課的時候,王老師已經講過,做需求分析,不僅要知道客戶的需求,而且要知道客戶為什麼有這個需求的原因。這個其實跟對待孩子...

我們怎麼做需求分析

乙個專案的開始便是為了滿足客戶的需求,有了需求才有了我們的供需關係。但是軟體與人之間的關係並不是如同人與人來的那麼清晰於簡單。人們對於乙個目標的軟體總是有不同的想法和思路。客戶和經理的交流和溝通並不能是他們完全的理解對方,而經理帶回專案交給開發團隊也並不是能夠完全的滿足顧客的想法。因為顧客經常也不知...