作者
標題 [請益] 一份好的設計規劃應該怎麼寫
時間 Fri Mar 10 09:18:04 2023
標題 [請益] 一份好的設計規劃應該怎麼寫
時間 Fri Mar 10 09:18:04 2023
我目前從事販賣機的軟體開發，需求主幹很簡單：
1.用戶選定商品、檢查商品庫存。
2.提示付款、依據使用者付款方式檢查付款是否成功。
3.投放商品。
4.控管存放庫的溫度。
主幹的描述跟流程圖可以很快的寫出來，但問題在於細節的實施，比方說步驟2.，付款方式百百種，而且常常開發到一半就需要增減某種付款方式；又比方步驟4.，不同商品可能有不同的控管邏輯。
只要遇到需求變更，就得修改文件重畫流程圖，導致後來我也養成便宜行事的壞習慣，先把程式寫完，出版後再來按code寫規劃文件。
雖然目前也沒遇到什麼太大的問題，但違背了先畫流程圖跟寫規格書的原則，心裡總是留一根刺。
想向各位先進請教，像這種情形有沒有什麼好的建議或改善方向呢？
謝謝。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.14.208 (臺灣)
※ 作者: icetofux 2023-03-10 09:18:04
※ 文章代碼(AID): #1a2eLHOa (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1678411089.A.624.html
推 : 泳道圖1F 03/10 09:39
謝謝，我來查一下這是什麼。→ : 問GPT2F 03/10 10:40
→ : 修改規格本來就很平常阿...便宜行事是你們的問題吧？不過我也沒碰過的照"規定"走的，一堆出張嘴就改的XD3F 03/10 11:09
推 : 所以你寫的東西最好要有擴充彈性5F 03/10 11:25
→ : 找一個SA來做，PG兼SA 文件很容易會脫節
寫完code後你會沒動力修文件
或是你只寫文件，讓PG來看文件改這樣6F 03/10 12:07
我工作的場合編制沒有這麼齊全，所以工程師被要求從文件到產品都得做。寫完code後你會沒動力修文件
或是你只寫文件，讓PG來看文件改這樣6F 03/10 12:07
→ : 看能抵擋幾次需求變更而PG還不爆炸XD9F 03/10 12:12
→ : 正常不會先畫流程圖吧，會先寫人與系統互動流程的文字。正10F 03/10 12:14
所以流程圖並不是必要的嗎？以前學寫程式都一直被灌輸要先畫出流程圖，再按照流程圖寫程式。→ : 式一點的說法是 use case。改文字比改圖方便多了
很多圖根本是形式，重點是流程紀錄清楚比較重要。等到專案快結束，或沒事做時，才會根據合規要求，補各種說明文件與圖。11F 03/10 12:14
※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:08:49很多圖根本是形式，重點是流程紀錄清楚比較重要。等到專案快結束，或沒事做時，才會根據合規要求，補各種說明文件與圖。11F 03/10 12:14
※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:09:49
※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:12:26
推 : 好讚喔 是做什麼國家的需求 很好奇15F 03/10 13:47
推 : 不考慮狀態圖嗎？16F 03/10 14:38
推 : PM的需求情境跟業務範圍是否完整 設計的範圍才比較
聚焦
如果開發只依照你4點的需求主幹往下直接開發 那沒問題才是問題吧XD17F 03/10 16:12
聚焦
如果開發只依照你4點的需求主幹往下直接開發 那沒問題才是問題吧XD17F 03/10 16:12
→ : 樓上有講跟沒講一樣XD21F 03/10 17:31
推 : Gherkin22F 03/10 17:35
推 : 幾百年前的做法供你參考
把需求的use case寫出來
然後畫Active Diagram(就是上面說的泳道圖)
然後再把DFD或是class Diagram畫出
就可以開始coding了
當然有些比較雞巴的地方
會要求你維護sequence Diagram
現在這世代的做法應該也差不多吧
至於需求變更 看你的案子
採用那種軟工手法
若是瀑布式 就要和使用者重談需求 勾稽需求 然後改文件
如果是使用scrum就下一個spint再說了23F 03/10 18:15
把需求的use case寫出來
然後畫Active Diagram(就是上面說的泳道圖)
然後再把DFD或是class Diagram畫出
就可以開始coding了
當然有些比較雞巴的地方
會要求你維護sequence Diagram
現在這世代的做法應該也差不多吧
至於需求變更 看你的案子
採用那種軟工手法
若是瀑布式 就要和使用者重談需求 勾稽需求 然後改文件
如果是使用scrum就下一個spint再說了23F 03/10 18:15
推 : 流程圖可以切割，主幹引用到細節
例如主幹跑到付款那段的時候，標示說請見付款細節，付款細節那邊有統一的interface的話，你對一種付款模式就是多一個付款模式的細節圖
溫度控制那邊也可以看看能不能使用類似的做法，只要主幹跟細節圖之間的關聯讓人可以很快找到的話，適度的切割沒什麼不對35F 03/10 18:30
例如主幹跑到付款那段的時候，標示說請見付款細節，付款細節那邊有統一的interface的話，你對一種付款模式就是多一個付款模式的細節圖
溫度控制那邊也可以看看能不能使用類似的做法，只要主幹跟細節圖之間的關聯讓人可以很快找到的話，適度的切割沒什麼不對35F 03/10 18:30
推 : 通常有需求之後我會畫流程圖或活動圖，當作確認需求跟文件紀錄42F 03/10 19:12
推 : Mermaid 畫流程圖很方便44F 03/10 19:13
→ : 你要先找到為什麼你說違背了你的原則，心裡會有刺的背後真正的原因，再來看怎麼處理
你說的原則是為了什麼，還是只是無意義的個人原則，xy問題45F 03/10 23:23
你說的原則是為了什麼，還是只是無意義的個人原則，xy問題45F 03/10 23:23
→ : 修改規格本來就很平常+149F 03/11 00:08
推 : 設計一套DSL(Domain Specific Languages),可用LUA修改
我個人喜歡這種 https://github.com/zevv/zForth
文章代碼(AID): #1VclyWaS (CompilerDev) [ptt.cc]50F 03/11 14:48
我個人喜歡這種 https://github.com/zevv/zForth
文章代碼(AID): #1VclyWaS (CompilerDev) [ptt.cc]50F 03/11 14:48
GitHub - zevv/zForth: zForth: tiny, embeddable, flexible, compact Forth scripting language for embedded systems
![[圖]]()
zForth: tiny, embeddable, flexible, compact Forth scripting language for embedded systems - GitHub - zevv/zForth: zForth: tiny, embeddable, flexible, ...
[分享] zForth - 看板 CompilerDev - 批踢踢實業坊
enthos (影斯作業系統) zForth: tiny, embeddable, flexible, compact Forth scripting language for embedded systems 之前想找一個易於修改的 VM 做為我的遊戲核心，發現這套系統易於了解和修改。 特別的地方是內建 bytecode 的 trace 功能。
enthos (影斯作業系統) zForth: tiny, embeddable, flexible, compact Forth scripting language for embedded systems 之前想找一個易於修改的 VM 做為我的遊戲核心，發現這套系統易於了解和修改。 特別的地方是內建 bytecode 的 trace 功能。
→ : 不同商品對應到不同的 bytecode, 容易更新.53F 03/11 14:49
→ : 你舉的例子哪裡需要改流程圖..隨便找個範例改吧54F 03/11 14:52
--