把自己想成，今天coding这个动作由其他人完成。 在这样条件下你要怎麽做？ 团队合作时，文件是用来沟通 自己做时，文件是用来厘清思路跟回忆。 这两者的文件资讯密度跟内容就会不同。 ==== 如果是团队合作，通常会走下面这样。 这个只能算是 MRD (Market Requirements Document) 用商业语言描述需求项目。 简单说法就是，业务、行销都看得懂，写得出来。 你需要是PRD (Product Requirements Docuement) 用技术语言描述相关规格细节。 你说的需求变更可能就是这块没讲清楚。事後就会一直改。 例如说付款 接受那些方式? 信用卡：接受哪几家信用卡? 信用卡：用哪些方式串? 跟谁串? ===>连带延伸到网路功能，走无线还是有线 硬币：接受哪几款硬币? 上面每个都是文字描述，但就需要技术经验跟概念。 有经验的工程师就能推估出要怎麽做，给出更细的Design Document。 以上提供参考。 ※ 引述《icetofux ()》之铭言： : 我目前从事贩卖机的软体开发，需求主干很简单： : 1.用户选定商品、检查商品库存。 : 2.提示付款、依据使用者付款方式检查付款是否成功。 : 3.投放商品。 : 4.控管存放库的温度。 : 主干的描述跟流程图可以很快的写出来，但问题在於细节的实施，比方说步骤2.，付款方式百百种，而且常常开发到一半就需要增减某种付款方式；又比方步骤4.，不同商品可能有不同的控管逻辑。 : 只要遇到需求变更，就得修改文件重画流程图，导致後来我也养成便宜行事的坏习惯，先把程式写完，出版後再来按code写规划文件。 : 虽然目前也没遇到什麽太大的问题，但违背了先画流程图跟写规格书的原则，心里总是留一根刺。 : 想向各位先进请教，像这种情形有没有什麽好的建议或改善方向呢？ : 谢谢。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.230.192.176 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1678441921.A.AC0.html