现在平时写的一些非规范文档有些乱、时间长了自己都有些看不懂。
主要的开发文档就是Functional spec 和 Technical Spec。
Functional Spec 映射需求到功能性,
Technical Spec 映射功能到实现。

以后随手写一些文档的时候也依照这些要求,相对规范,比较容易将来整理形成正式文档。
内容大于形式,注重实效。一份内容,一份模版,需要的时候找一个熟悉这部分内容的人,很快攒出一份文档出来。

关键在内容的组织上,而不是模版形式本身。
如果把需求,功能,实现在不同层面上讲清楚,层次清晰,详略得当。需要业务知识、技术知识、项目经验、分析能力、表达能力。

这些都是要在开发用的上的文档,内容一定要详实,体现问题的前提假设、实际问题、解决问题的思路,以及可能会出现的问题。FS,TS只不过要体现问题的不同层面,层次把握也很重要。
文档里面可以适当的给出一些图示,图示给人以更好的直观印象,表达能力强于文字描述;但图一定要规范,要有文字解释,避免的误解。没有解释的图很容易误解,既是是规范的UML也是一样的。表达能力强的方式对理解者的要求比较高,抽象的层次相对高了,还是那句老话,问题本身的复杂度不会因表达的方式而简化,而且更高的抽象层次往往需要理解者有更多的专业知识才能正确理解,否则误解难以避免。

空洞的套话、忽悠的话对开发没意义,没必要的都不要。
评论
发表评论

您还没有登录,请登录后发表评论

Godlikeme
搜索本博客
其他分类
存档
最新评论