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