我們小組採用的是NABCD模型，分析專案需求。

彎路總要走的，最開始我們沒有意識到規範性的重要，帶著使用者（導師）的口頭需求和滿腔熱情開了第一次會議，結果討論出來的需求沒有條理不說，整理成文件後，在需求文件1.01版本中基本被推翻了。

N為Need

使用者是上帝，所以需求的核心是要實現使用者所有想要的，也就是在使用者角度的需求，在核心的需求中，不需要考慮實現方式、競爭力度等外在因素，只需要分析完成哪些功能才能拿到使用者所允諾的報酬。在我們的專案中，老師的需求就是：測量噪聲資料，上傳給伺服器，生成噪聲地圖。

解決了核心需求，就要從這些需求聯想創新點了，這些是使用者不會告訴我們的，只完成了核心需求的版本，使用者會說“可以，但是不好”，但是依舊不會告訴我們哪裡不好，還需要什麼。需要注意的是，這些創新點一定是跟核心需求相關聯的。我們一開始的彎路就是因為還沒有落實核心需求，就開始發散了。

A為Approach

有了需求，就要看我們的需求要用什麼招數來解決。這些招數包括技術上的（開發語言、技術水平、開發平臺等）、人脈上的（比如我們的專案是偏公益的，如何獲得足夠多的使用者）、成本上的（比如作為學生，我們能承擔起多高的開發成本）等等。

B為Benifit

產品的好處就和需求中的創新點息息相關了，要看我們的產品能給使用者帶來什麼好處。這是我們專案的一大重點，作為公益性質的專案，我們必須有足夠的理由說服使用者使用我們的產品，並提供給我們資料。我們的專案，既要滿足核心使用者——導師的需求，也就是他需要的資料，又要滿足實現過程中產生的使用者——app使用者的需求。

C為Competitors

產品的競爭是無法逃避的，既然是根據需求產生的產品，那絕不會只有我們要去滿足使用者的這個需求，如果我們是先進入市場的，那就要面臨如何不被後面的產品碾壓的問題，如果我們是後進入市場的，就要做到碾壓有先發優勢的產品，讓使用者放棄競品，改選我們。

D為Deliver

在這個專案的需求分析中，我們並沒有注重推廣這個元素。