把自己想成，今天coding這個動作由其他人完成。 在這樣條件下你要怎麼做？ 團隊合作時，文件是用來溝通 自己做時，文件是用來釐清思路跟回憶。 這兩者的文件資訊密度跟內容就會不同。 ==== 如果是團隊合作，通常會走下面這樣。 這個只能算是 MRD (Market Requirements Document) 用商業語言描述需求項目。 簡單說法就是，業務、行銷都看得懂，寫得出來。 你需要是PRD (Product Requirements Docuement) 用技術語言描述相關規格細節。 你說的需求變更可能就是這塊沒講清楚。事後就會一直改。 例如說付款 接受那些方式? 信用卡：接受哪幾家信用卡? 信用卡：用哪些方式串? 跟誰串? ===>連帶延伸到網路功能，走無線還是有線 硬幣：接受哪幾款硬幣? 上面每個都是文字描述，但就需要技術經驗跟概念。 有經驗的工程師就能推估出要怎麼做，給出更細的Design Document。 以上提供參考。 ※ 引述《icetofux ()》之銘言： : 我目前從事販賣機的軟體開發，需求主幹很簡單： : 1.用戶選定商品、檢查商品庫存。 : 2.提示付款、依據使用者付款方式檢查付款是否成功。 : 3.投放商品。 : 4.控管存放庫的溫度。 : 主幹的描述跟流程圖可以很快的寫出來，但問題在於細節的實施，比方說步驟2.，付款方式百百種，而且常常開發到一半就需要增減某種付款方式；又比方步驟4.，不同商品可能有不同的控管邏輯。 : 只要遇到需求變更，就得修改文件重畫流程圖，導致後來我也養成便宜行事的壞習慣，先把程式寫完，出版後再來按code寫規劃文件。 : 雖然目前也沒遇到什麼太大的問題，但違背了先畫流程圖跟寫規格書的原則，心裡總是留一根刺。 : 想向各位先進請教，像這種情形有沒有什麼好的建議或改善方向呢？ : 謝謝。 -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 61.230.192.176 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1678441921.A.AC0