對于前端來講，需求分3類：
1. 需求文檔。包括整個產品的邏輯，詳細的交互圖，整體流程圖等。
2.UI設計圖。要按照一定的規范來出設計圖。
3.后臺接口。
一、需求文檔
整體的APP實現方向有一個大致的說明，說明這個APP或者某個大的模塊主要是追對什么設計的，方便開發時更詳細的理解需求。
按具體功能對界面進行劃分，分成具體幾個功能模塊并說明每個功能模塊由那些界面組成。
對每個功能點進行詳細的功能描述，包括可能出現的邏輯結構的描述。
針對整體的功能，要有一個詳細的交互圖，方便對整個產品進行詳細的了解。
對每個功能模塊出一套流程圖，將每個界面或是功能點能夠串起來，方便設計與優化。
二、UI設計圖
要有一套完整的設計規范。例如一級標題是什么顏色，字體的大小，要統一給一個規范，這樣既方便UI設計，也方便前端代碼整合。
詳細的標注。詳細的標注是指大到每個界面的寬高，小到每個控件的寬高、顏色，要有詳細的標注，若寬高相同的布局可以只標注一個，但是標注要詳細，完整。例如：一個控件不能只給距離左邊的距離和寬，同樣要給出距離頂部的距離及高度。
特殊布局的控件要給出不同設備上適配比例或者顯示寬高，否則容易造成開發App與設計稿不一致的情況出現。
字體、顏色規范。跟第一點相似，就是把APP中常用的字體及常用的顏色統一給一套規范，設計圖也一并嚴格按照此規范設計，這樣就可以定義全局的顏色分類，每次用哪個取哪個即可，也不會出現改一次APP色調，動好多地方的顏色設置，只需修改統一的顏色即可，即縮短了工作量又避免遺落修改的錯誤。
設計圖稿要嚴格按照設計時間出圖。且一旦出圖只允許做小幅度的調整，定稿之后盡量不要做大幅度的修改，以免進行重復的工作量，若有大幅度的修改，請提交給下一版本，避免循環開發沒有結點。
三、接口設計
請求網址，前面的一部分是固定的，每個接口改變的是后面的方法名和請求的參數。
也可以雙方規定一些錯誤代碼，例如111111代表成功，222222代表token失效，3333333代表參數出錯等等，這樣有的時候就可以直接定位是因為前端請求出錯，還是后臺的方法出錯，省去尋找錯誤的時間。
后臺字段一旦與前端確定，輕易不要修改，如有修改請及時告知前端，避免因字段更改造成界面數據顯示的錯誤。
若時間允許可出一份詳細的接口文檔，包括接口的地址，用途，請求參數（必須 or 非必須），返回參數，返回格式都寫在一個文檔中，這樣就可以直接看文檔，省去很多交流推脫的時間。
四、數據庫設計 （分為后臺做的和前端需要做的）
- 后臺要做的，這關系到一些表與表的關聯，邏輯刪除，真實刪除，邏輯修改等等。
2 如果有一些變動性很小又會經常用到的數據，前端可會用數據庫或是本地存儲來存一些必要的信息。主要是根據實際的數據來進行存儲，不會有復雜的功能，只有基本的增刪改查。
