需求分析心得

一.團隊介紹

蕪湖動物園

二.團隊成員

艾浚樵江光旭劉慶劉明偉張樂平容振貴

三.指導老師

劉代波四.需求迭代過程

我們的專案一共經歷了3次需求文件迭代，這3次分別是為了不同的目的。

1.0版本是寫給指導老師看的，裡面是此專案最精準的樣貌；2.0-3.0是寫給課程老師看的，裡面是在課程老師的要求下增加了使用者管理與許可權管理。

我們一開始寫需求文件1.0的時候是套用了乙個模板寫的，這個需求文件1.0包括了我們絕大部分的功能需求，可以說是最貼近我們實際操作的版本，可是我們的課程要求我們增加一些其他方面的需求，如登陸介面的設計以及資料庫的建立等等，這是我們一開始沒有考慮清楚的，所以我們在需求分析2.0加入了登陸介面的設計以及只有三張表的資料庫，在與課程老師交流後我們發現三張表無法囊括我們的全部需求，於是我們將資料庫表的數量增加到了10張以上，也有了需求文件3.0。在這個過程中，我們對迭代開發過程有了更好的理解，結合我們學習的螺旋模型，我們也明白了這個過程的重要意義。

由於沒有以前的實踐經驗，而是只有課堂上老師教的一些書本知識。所以我們的需求文件1.0是開始於套用的往年學長們的乙個模板。需求文件1.0，也就是最初的版本，它包括了我們開發設計的絕大部分的功能需求與過程。

而到了往後，也就是迭代的需求文件版本，我們則根據課程要求或者是小組的討論去增加一些其他方面的需求，比如登陸介面的設計以及資料庫的建立等等。雖然我們一開始知道這些肯定是有的，但是我們的思考終究是稚嫩了一些，所以導致我們的資料庫表不滿足老師的要求，在我們的需求分析2.0中加入的資料庫表嚴重不足，在收到課程老師的指導之後，我們及時更正，去進一步挖掘專案的需求然後慢慢增加資料庫的規模。

隨著需求文件一代一代地更新，我們的文件逐漸趨於完全。而在這個過程中，我們是一直參與著這乙個迭代開發的過程，同時結合我們學習的螺旋模型，我們更加明白了這個過程的重要意義，這個過程對我們的益處的難以言盡的。

五.迭代過程中的重難點

需求的收集是個很繁瑣的過程，收集的不夠，開發過程中變化會很多，特別是你上了乙個演示版本後，開始其他人一點意見都沒，一看你的演示，就意見一大堆，所以在收集需求前要充分研讀老師下發的專案pdf。同時我們要從兩種角度去考慮需求，一種是使用者角度，另一種是開發者角度；從使用者角度分析使用者需要什麼功能，然後從開發者角度分析在軟體設計和實現的機器層面怎麼實現這些功能。

我們應該明白需求分析中最重要的部分：專案要解決哪些問題。例如我們的驅魔師ghostbuster專案，本質是為了解決使用者入住酒店查詢隱藏攝像頭從而保護隱私的問題，那麼我們就應該在需求分析中重點解決攝像頭的位置，攝像頭的型別，入住酒店的資訊，如何遮蔽攝像頭等問題，而不是過度關注怎樣把軟體設計得更加美觀。

在需求分析中，我們也應該關注本次專案分幾個階段進行實施。在開發初期，我們不可能將系統所有的功能都能完成的很好，反而我們應該像建造樓房一樣先打好地基才能進行添磚加瓦，即根據客戶或市場的需要來完善功能。在我們專案中，我們進行三次迭代，將專案模組化，分別實現「登陸與測試」、「wifi資料處理演算法」和「wifi資料定位與地圖」三大功能。通過對迭代再細分，將任務具體到成員，不僅能加快專案進度，還能通過每個小部分的實現提公升團隊的信心，從而在實現過程中更能適應需求的變化

六.獲得的幫助&&自學的過程

這是我們組的所有成員第一次參與專案設計，明白了需求文件的設計環節的重要星。通過這次需求分析，我們更加理解了需求在整個專案開發的過程中所起到怎樣重要的意義。通過這次需求分析的過程，我們深刻明白了需求在整個專案過程中的重要意義，因為它是我們專案開展的基礎。在這段時間裡我們聽老師講課之餘,也會在csdn社群閱讀相關課程知識,將需求列出來之後詢問老師是否合理.還有乙個就是組內的同學互幫互阻,形成了良好的氛圍.

七.心得與體會

從專案本身來說，使單機軟體變成了聯機軟體，不是說這樣不好，現在是個軟體確實都有聯機功能，但是此專案的出發點，或者說一開始的期望，就是乙個單純的小工具，無論利用課上的講的蘑菇群理論，還是其他什麼，作為乙個使用者，我只希望我進入乙個酒店，開啟這個軟體，就能告訴我這個房間裡是否有無線攝像頭，有的話大概在哪個方位，而不是要先輸入自己的手機號註冊登入，還要被獲取自己的位置資訊，手機資訊，上傳自己所在區域所能檢測到的所有wifi資料。這些個增加的東西無疑是脫離的專案本來的期望。

從課程角度來說，增加使用者管理，許可權管理，是為了讓我們能夠得到更好地鍛鍊，這一點無可厚非。但是所謂具體問題具體分析，在當初給定專案的時候，老師應該先了解此專案是單機還是聯機，是否真的需要使用者管理這種東西。

從個人來說，通過此專案的需求分析，我們確實了解到了需求分析對乙個專案起著引領的作用，如果需求分析出了問題，整個專案也就很容易出問題。在組員商討期間，在單機變聯機的問題上我們各抒己見，希望能給這個專案增加合理性；在聯機的使用者管理問題上，我們共同**，希望能夠滿足使用者需要；在聯機的許可權管理問題上，我們積極解決，希望能讓使用者有慾望進行許可權公升級。而這些，如果在專案僅僅是單機軟體的情況下，是不會得到體驗與鍛鍊。

在整個專案過程中，感到最滿意的就是增加的熱點地圖功能。有此功能存在，使得使用者登入註冊變得正常合理，使得手機使用者位置資訊，測試記錄資訊變得可以解釋。我們在脫離專案實際內容的要求下存活了下來，我們在第一次開發專案就經歷了難度比較大的需求偏差，確實得到了實際的鍛鍊。但是3.0版本，我們依舊無法解釋為什麼資料庫需要自己的手機資訊以及所在區域所能檢測到的所有wifi資料，總不能說這是為了資料庫設計能達到10張表吧。

在這個過程中，有小組的分工協作，共同討論，大家集思廣益、同心協力，對於需求分析刨根問底，可以說是乙個漫長而益處多多的過程，令人享受。小組分工協作在開發計畫中十分重要，在需求文件的撰寫過程中也是如此，我們集思廣益，仔細分析指導教師發給我們的**，寫出了需求分析1.0，後續又結合課程的需要寫出了需求文件的後兩個版本，可以說大家都獲益匪淺。

總之，此次的需求分析的編寫使得我們在遣詞造句方面，在社會規範方面，都穩穩的朝「工程」前進了一步。編寫過程中，我們見識過了別人寫的需求分析的樣子，看見了不同人不同要求，接觸到了powderdesigner軟體，勉強會畫用例圖了，已經會寫用例了。通過這個專案，我們都學到了很多.

需求分析心得

需求分析心得

需求分析心得

需求分析心得

相關推薦