前言

• 我覺得整個專案規劃的流程大概是：
  1. 規劃專案每個步驟的時間
  2. 確認業主需求
  3. 規劃文件(API文件、ER model等等…)
  4. 跟業主說明與討論
  5. 開始開發API
  6. 給業主DEMO

確認需求部分在很前面也很重要，如果沒確認好事可能會影響到後面的規劃不符合預期而浪費時間，所以這裡介紹一下。

初始情境：

• 今天業主希望有一個系統來管理她擁有的寶可夢， 要有一個簡單的CRUD。
• 每隻寶可夢有不同的等級、性格、技能或特性。
• 每種不同的寶可夢可能有自己的進化等級。
• 進化的方式只有透過等級、而且即使等級下降也不會有退化的情形。

業主希望達到的：

• 純做API開發，不要求前端畫面,業主會打你的api，但如果有畫面會加分（非必須）。
• 必須用laravel開發API。
• 不管要新增什麼功能、或是修改什麼功能都盡量還是要重新規劃文件然後跟業主確認過後才新增(這部分其實也符合真實情況，不能自以為的覺得業主想要什麼功能，還是要多溝通)。
• 雖然是練習但還是盡量不要開天窗，模擬真實情況。

確認需求細節：

以上是業主需求的簡單描述，但後續針對這個部分我們有在去做一些詳細的確認：

• 關於性格、特性、技能可以讓使用者在新增寶可夢的時候，我們是透過選項的方式讓使用者去選擇，但如果使用者要新增我們要有一隻API是可以讓他做新增的。
• 每隻寶可夢只可以有一個性格和特性及1~4個技能。
• 技能不讓使用者新增，且每一種寶可夢能學的技能是不一樣的（比如皮卡丘可以學衝浪,但比雕可能不行）。
• 技能只會根據種族做變化不會根據等級。
• 我們寶可夢的進化只能透過等級，不會有其他的進化判定。
• 寶可夢進化後不會有退化的機制。
• 寶可夢不會有經驗值的部分，都是透過直接去修改等級。

小總結

• 主要這個部分我比較想要強調的是， 我自己發生一個問題就是,當我看到業主需求之後，自己對於不確定的東西常常理所當然的認為就是這樣，沒有確認。

  比如說：我就一開始就自以為的覺得每一隻寶可夢就是一個技能，沒有意識到多個技能的可能， 或是沒有退化的機制等等…

• 這個確認需求的前輩們有特別提醒，當你今天需求沒有確認好的時候，很可能會造成deadline一到，結果不是業主想要的，或是多開了一些功能搞得自己很趕，甚至差點開天窗。