本次專案可以說是該專案成員第一次參與到乙個相對完整的專案當中，團隊最後的目標是在規定的時間內完成對專案的構建，而理解專案的需求其實算得上是我們所面對的較為困難的任務之一。
我們從理解需求分析，直到清楚專案的需求，費了不少功夫，一直在不斷調整權衡我們的需求和實現難度，然而就是在這樣的過程中，我們對需求分析的重要性有了更深層次的認識。
我們小組的專案是實現乙個基於wifi的人體動作識別系統，主要是利用csi來收集特定wifi 環境下因人類活動干擾產生的資料，將資料進行預處理後再加以分析，從而獲取人類活動的相關資訊，以到將人類動作還原的目的。
進行需求分析過程：
需求獲取與分析階段
首先通過已有資料分析專案所需實現功能：
我們通過閱讀專案指導老師下發的檔案，對這個專案究竟要做什麼有了大概的了解，然後針對一些細節的和不清楚的地方和老師進行交流，但是在和老師交流之後，我們仍然還會出現其他存在的問題，這也說明了需求具有模糊性和隱蔽性的特點。
於是通過我們小組多次討論分析，決定先根據自己的理解作出原型。
通過完成原型進一步明確需求：
我們結合相關**和大多數系統的通用功能，分析總結出了我們的專案應該具備的主要功能，如使用者登入註冊，使用者管理等通用功能以及專案的核心功能檢視動作資訊。然後做出了第一版原型。
在小班討論課上展示原型後，胡老師對我們的專案產生了一些疑問，覺得我們所做出的原型中，其他的功能如登入註冊，使用者反饋，使用者管理等很多，但是有關專案本身的核心內容並不多，只有檢視動作資料等功能，而且這些功能並沒有什麼實際的用處，使用者並不能通過這些資料知道他作出了什麼動作，動作的模擬也比較簡陋，不能將使用者的動作真實的模擬出來。我們針對老師的建議，對原型和專案本身的內容作出了改進，然後又與專案指導老師進行交談，最後作出了第二版原型，在第二版原型中我們具體劃分了三類使用者，不同的使用者類別具有相應的許可權和實現的功能。這說明需求具有多樣性和變化性，我們需要根據不同的用例具體分析。
制定規格說明書
基於之前對專案的理解以及記錄下來的需求，我們首先結合規格需求模板對三個層次的需求（業務需求，使用者需求，系統需求）進行規格說明。這一步驟是在初步確定需求後與原型設計同步進行的，由一部分組員製作原型，一部分組員制定規格說明書，然後交換互相修改。在編寫需求規格的過程中，也在不斷地對需求進行綜合考量與改動，
需求驗證與變更
在編寫完需求規格說明之後，通過進一步進行有效性、一致性、完備性及現實性檢查，對專案需求進一步驗證與完善。並且結合原型與指導老師的意見，我們多次討論，對需求進行改進。
遇到的困難及解決過程:
1. 該系統所面向的使用者不明確
起初我們對該項目的目標客戶不明確，導致在需求分析方面不知道從**下手。
當製作原型時，就必須要針對使用該系統的不同人群進行劃分與相應功能實現，而通過對系統的用例進行分析，並結合不同使用者在其具體場景下對動作識別的使用，我們終於對需求有了更多更完善的想法。
3. 驗收方式
由於我們的專案是需要基於乙個條件非常嚴苛的實驗室下進行，這就意味著驗收這個環節對我們來說是乙個非常困難的事情，我們很難在驗收時提供這樣乙個環境，也很難保證結果會與平常的實驗保持一致。
於是在第二次討論前，我們收集了很多專案相關的資料，我們得知專案本身就是乙個難以實現實時監測的系統，在和老師不斷交流溝通後，老師也同意了暫時先不考慮實時監控的問題，讓我們先做出相應的演算法即可。
收穫與總結
1. 感受需求特性
在本次需求分析及規格說明完成過程中，我們深刻地感受到需求所具有的的四個特性：模糊性、隱蔽性、多樣性、變化性。我們需要針對不同的特性合理地制定需求獲取策略。
2. 原型與需求相互促進
在製作原型過程中，我們真實地做到了原型開發的五個步驟：快速分析、構造原型、執行原型、評價原型、修改。並且在原型開發過程中，我們明確了並完善系統需求，確定實現目標，同時也提公升了我們小組的交流協作，挖掘與分析資訊的能力。
3. 解決問題
我們的專案是偏向於演算法一點的，主要是通過對wifi訊號資料的處理，分析出人體動作，所以並沒有太多的可展示的核心功能，所以才有小班老師提出的那些問題。
4. 明確需求
我們在需求分析中遇到的最大的困難就是需求不明確的問題，只能根據自己對專案的理解作出判斷和設計。這也說明需求的獲取與分析是乙個困難且複雜的過程，我們需要明確好獲取與分析步驟，找到合適的方法獲取需求。
5. 敏捷開發
由於需求具有變化性，導致我們整個前期過程幾乎都會有一些需求的調整，但是我們需要適應變化，這也是為了更好地實現系統。
6. 審美提公升
提公升審美，做出美觀的使用者介面。作為工科生，審美還是非常重要的。在設計原型時，雖然已經知道了系統需要哪些功能，但是進行的還是很緩慢，問題在於使用者介面的美觀，我們做出的介面總是看起來不太美觀，所以開發專案不僅要技術還有審美。
7. 文件管理
「大部分開發人員都認為理解需求就好，不注意更新文件。這樣會影響後續開發和維護工作。」
如果專案組中有成員不熟悉文件，也就對專案當前開發進度及討論成果不了解，當與其他成員溝通後，耗費一定的時間成本。需求變更記錄文件也極為重要。需求變更影響到專案開發、專案測試、專案驗收。如果需求變更沒有及時調整，都會影響到整個專案進度。
在專案處於各個階段都需要嚴格管理文件版本，保持版本庫的文件是最新的。
8. 團隊溝通
「團隊間溝通順暢有序，只有這樣，概念完整性才能被正確貫徹到各處。」
巴比倫塔的教訓也說明了合理有效的溝通對於專案管理與實施及其重要。所以在該專案實施過程中，我們小組盡量保證每週都有例會，保證專案成員都能同步了解最新資訊。
9. 合理的進度安排
「當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。(這種行為就像使用汽油滅火)」。
在本次需求分析的階段，我們專案小組也感受到進度安排的重要性。如果當前進度沒有實現，將會影響以後的進度，造成很大的災難。所以，一定要注意進度安排，合理規劃好專案開發時間。
當然這並不意味著需求分析就徹底結束了，在我們這次類似與敏捷開發的過程中，需求分析近乎均勻地貫穿於專案的整個生命週期，整體需求也將會一直有著細微調整的。在接下來的時間裡，我們會認真、仔細、嚴謹地去對待，設計階段的同時考慮需求的變化性，只有更加靈活才能夠在需求發生變化時方便地去修改。
「一切都將運作良好，每項任務僅花費它所「應該」花費的時間。」
我常想，每個人都有良好的希望，或者說有夢想，但是夢想歸夢想，現實歸現實。腳踏實地，認清現實，是做好任何事情的基本要求。
需求分析心得
李俊傑最近做些需求分析的工作，主要基於現有需求抽象分析，合併歸類，積累如下心得體會供參考 n抽象 從紛繁複雜的表象中抽取出有規律的東西，即透過現象看本質，所謂本質，就是規律性東西，就是在一定條件下不變的規則，也就是需求中要分析出那些是 不變的 那些是 變化的 換句話說，是從偶然性中發現其必然性。n如...
需求分析心得
一.團隊介紹 蕪湖動物園 二.團隊成員 艾浚樵 江光旭 劉慶 劉明偉 張樂平 容振貴 三.指導老師 劉代波四.需求迭代過程 我們的專案一共經歷了3次需求文件迭代，這3次分別是為了不同的目的。1.0版本是寫給指導老師看的，裡面是此專案最精準的樣貌 2.0 3.0是寫給課程老師看的，裡面是在課程老師的要...
需求分析心得
一.團隊介紹 蕪湖動物園 二.團隊成員 艾浚樵 江光旭 劉慶 劉明偉 張樂平 容振貴 三.指導老師 劉代波 四.需求迭代過程 我們的專案一共經歷了3次需求文件迭代，這3次分別是為了不同的目的。1.0版本是寫給指導老師看的，裡面是此專案最精準的樣貌 2.0 3.0是寫給課程老師看的，裡面是在課程老師的...