我目前從事販賣機的軟體開發，需求主幹很簡單：
1.用戶選定商品、檢查商品庫存。
2.提示付款、依據使用者付款方式檢查付款是否成功。
3.投放商品。
4.控管存放庫的溫度。
主幹的描述跟流程圖可以很快的寫出來，但問題在於細節的實施，比方說步驟2.，付款方式百百種，而且常常開發到一半就需要增減某種付款方式；又比方步驟4.，不同商品可能有不同的控管邏輯。
只要遇到需求變更，就得修改文件重畫流程圖，導致後來我也養成便宜行事的壞習慣，先把程式寫完，出版後再來按code寫規劃文件。
雖然目前也沒遇到什麼太大的問題，但違背了先畫流程圖跟寫規格書的原則，心裡總是留一根刺。
想向各位先進請教，像這種情形有沒有什麼好的建議或改善方向呢？
謝謝。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.14.208 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1678411089.A.624.htmlSHANGOYANYI1樓泳道圖 03/10 09:39
→ leolarrel2樓問GPT 03/10 10:40
→ abccbaandy3樓修改規格本來就很平常阿...便宜行事是你們的問題吧？ 03/10 11:09
→ abccbaandy4樓不過我也沒碰過的照"規定"走的，一堆出張嘴就改的XD 03/10 11:10
f267243095樓所以你寫的東西最好要有擴充彈性 03/10 11:25
→ lazarus11216樓找一個SA來做，PG兼SA 文件很容易會脫節 03/10 12:07
→ lazarus11217樓寫完code後你會沒動力修文件 03/10 12:07
→ lazarus11218樓或是你只寫文件，讓PG來看文件改這樣 03/10 12:10
我工作的場合編制沒有這麼齊全，所以工程師被要求從文件到產品都得做。
→ lazarus11219樓看能抵擋幾次需求變更而PG還不爆炸XD 03/10 12:12
→ DrTech10樓正常不會先畫流程圖吧，會先寫人與系統互動流程的文字。正 03/10 12:14
所以流程圖並不是必要的嗎？以前學寫程式都一直被灌輸要先畫出流程圖，再按照流程圖寫程式。
→ DrTech11樓式一點的說法是 use case。改文字比改圖方便多了 03/10 12:14
→ DrTech12樓很多圖根本是形式，重點是流程紀錄清楚比較重要。等到專案 03/10 12:16
→ DrTech13樓快結束，或沒事做時，才會根據合規要求，補各種說明文件與 03/10 12:16
→ DrTech14樓圖。 03/10 12:16
MoonCode15樓好讚喔 是做什麼國家的需求 很好奇 03/10 13:47
APTON16樓不考慮狀態圖嗎？ 03/10 14:38
remember6917樓PM的需求情境跟業務範圍是否完整 設計的範圍才比較 03/10 16:12
→ remember6918樓聚焦 03/10 16:12
→ remember6919樓如果開發只依照你4點的需求主幹往下直接開發 那沒問 03/10 16:13
→ remember6920樓題才是問題吧XD 03/10 16:13
→ jackflu21樓樓上有講跟沒講一樣XD 03/10 17:31
sp06343922樓Gherkin 03/10 17:35
jej23樓幾百年前的做法供你參考 03/10 18:15
→ jej24樓把需求的use case寫出來 03/10 18:15
→ jej25樓然後畫Active Diagram(就是上面說的泳道圖) 03/10 18:16
→ jej26樓然後再把DFD或是class Diagram畫出 03/10 18:16
→ jej27樓就可以開始coding了 03/10 18:16
→ jej28樓當然有些比較雞巴的地方 03/10 18:16
→ jej29樓會要求你維護sequence Diagram 03/10 18:16
→ jej30樓現在這世代的做法應該也差不多吧 03/10 18:16