一.團隊介紹

團隊名稱：紅鯉魚與綠鯉魚與驢

專案名稱：慢阻肺居家護理系統

成員介紹：張君逸（PM），陳駿科，郭曉哲，楊燦萍，張洋

指導老師：楊貫中老師

二.需求迭代過程

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

1.0版本是基於上一屆學長的慢阻肺家庭護理的需求文件進行的一個修繕後的版本，他們裡面是對專案的一個基本的概括，但是其實是不符合新的需求的，因為我們的任務要求和他們已經不一樣了，相較之前已經有了嶄新的角色管理和功能；2.0版本是在第一次和老師以及助教開會頭腦風暴之後得到的，這一個版本加入了諸如醫生，家屬等角色以及其他的功能；3.0版本其實是一個持續的迭代過程，我們將新版本的需求文件按照快速原型法得到了一個原型，然後用這個原型再次和老師展開會議，探討專案的合理性，然後反覆地按照老師提出的要求進行修改和迭代工作。

我們一開始寫需求文件1.0的時候是套用了一個模板寫的，這個需求文件1.0包括了我們絕大部分的功能需求，可以說是最貼近我們實際操作的版本，可是老師要求我們增加一些其他方面的需求，如醫生這個角色，以及文章的點贊收藏評論功能。這是我們一開始沒有考慮清楚的，所以我們在需求分析2.0加入了這些新的設計，再然後我們用2.0版本的需求文件製作了一個原型，並把它作為新的會議的主題和老師彙報，老師和助教利用這個原型更好地理解了我們對於需求的確認程度，然後提出了修改意見幫助我們把原本方向不太正確的需求理解修改好，這最終也促成了我們的3.0版本。在這個過程中，我們對迭代開發過程有了更好的理解，結合我們學習的螺旋模型，我們也明白了這個過程的重要意義。

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

三.迭代過程中的重難點

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

需求的模糊性

製作的原型的重點介面展示：

需求的變化性：其實一開始並沒有那麼多的角色設計：醫生，家屬等等，也沒有對文章的點贊評論收藏等諸多功能。但是在和老師的開會討論之後，我們發現產生了新的需求和變化需求，所以我們添加了這些更多的角色，這裡體現了使用者反饋的作用，對於新的變化需求有比較高的反饋有助於最終產品的成功。

新增角色：醫生的用例圖

四.老師同學的互助過程

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

同樣也感謝仲勇傑助教和楊貫中老師在整個需求文件的獲取過程中給我們的諸多幫助和解惑，還抽出時間配合我們展開了多次的會議，對我們的需求文件提出了諸多的意見和修改方向。

成員參與情況統計：

五.心得與體會

在真正進入需求分析之前，我們感覺這一過程並不容易。畢竟需求具有模糊性、隱蔽性以及多變性。

需求分析的整個過程需要團隊所有人都參與進來，多次開會討論、多次與專案老師、專案甲方進行溝通，才能得出最終的結果。專案需求是在不斷變更的，因此每一次的討論都是對上一次結果的重塑，且現在所完成的需求文件也可能並不是最終實現的專案的需求。因此要做好不斷討論、不斷更改的準備。

需求分析，是將整個專案“拆碎”、“嚼爛”，從甲方希望實現的專案功能出發，考慮操作性、工作量、技術性等因素，提出細緻的需求，再從需求中提取出確定的需求用例。而提取出需求用例、完成需求文件、完成 UML 用例圖，實際上又是對需求的再一次檢驗。在完成這些工作時，我們仍然會遇到許多不同的問題，它們關係著專案中不同角色的許可權、功能、角色之間的關係等。因此，在整個過程中，團隊的所有人都對專案進行了深度的剖析，對後續的實現有極大的意義。

學習軟體工程這門課程已經有半個學期了。在我們看來，軟體工程與其說是一門課程，不如說是一門思想，是一個如何去分析和處理問題的過程。應該說其範疇已經遠遠不止侷限於該門課程，而是成為了一個綜合的一個能夠解決問題的思想集合。

所謂的需求獲取，那就是一個談判，辯論，交流的過程，已經不是單純的寫寫程式碼就能解決的問題了。這門課程教告訴了我們在完成一個實際專案時的一般程式及過程，這是一份非常具有實際意義的教學內容。

當我們在畢業之後，這是我們實際要運用的一項非常有用的技能，而且不僅僅侷限於軟體工程的範疇，即使是從事與其它行業，也是要從需求獲取開始。

真正開始之後，由於和四位相處融洽的成員一起討論原型並進行分工設計，所以實際上雖然任務重，但過程卻充滿了輕鬆和歡樂的氣氛。

這一點啟示我，作為PM，應當在合適的時候調節團隊內的氣氛。當氣氛融洽時，即使時間緊、任務重，團隊成員也能享受在其中，同時，還保證了工作效率（人在輕鬆愉快的心境下，主觀願意完成該任務，工作效率會更高）。一個好的團隊，必定是發揮了團隊中每個人的優勢，在開發團隊中，不是你技術能力強，你就是最有價值的人，我相信在開發團隊裡沒有一個從頭到尾都能支援的能人，不是不沒，是我是覺得不可能存在，也許我麼說有些人不服，其實我這麼說也有我的理由，一個人也許有機會經歷團隊中的每個環節，並且都能深入，但絕對不是一個機會，如果有，那就是一個人的開發，一個人的開發我想也不能叫團隊，有時候，一個人什麼都能做，多了一個人，什麼都做不好，但面對大的專案，不得不進行團隊合作。

我們需求的分析、原型的設計實際上經過了幾次的迭代，其實每一次修改之後，我們都希望這就是最後一次的更改了。因為每一次的更改，都意味著要從頭梳理一遍，以確定之前所完成的是完整的、無缺漏的，繁複的工作使得我們不希望多次修改。

但我們明白這一過程是不可缺失的。只有專案開始的初始階段，將需求分析完善、原型設計儘自己所能達到使用者的需求，後續的開發過程才會順利；而不是到了開發階段，還要針對之前未完成的部分進行修改，從而耽誤了整體的進度，也進行了更多、更無用的重複工作。

最終的3.0版本的需求文件目錄展示：

總結一下我得到的某些方法論上的思想：

1.身為PM，應當對本組的工作進行規劃，安排好每一步需要完成的工作，確保專案的進度；其次，作為專案的成員，在進行需求分析的時候，要充分了解到需求的模糊性和變化性，一定要儘可能的瞭解到使用者的清晰需求；最後，一個團隊內良好的氣氛對於工作的完成起著不可或缺的作用，作為PM，我應當在整個過程中儘量營造和諧、輕鬆的氣氛，使得在時間緊、任務重的時候，大家也可以高效率的完成工作。

2.不斷進行需求驗證，避免後期開發的不穩定性；

3.軟體工程的創新工程，做中學目的是讓我們將所學習的知識運用到實際專案中，不僅鍛鍊程式碼能力，更考驗團隊的交流配合，要求我們細化分工，不斷了解業務流程，確認最終任務的執行，在專案開發中，互相討論，確保統一的設計風格；

4.需求產生在不斷的探究、交流與驗證中，我們在開發的同時要兼顧需求的變化，同時從業務、使用者、系統三個層次，兼顧功能性與非功能性需求，掌握需求，從而達到專案的成功！