jmp指令流程图怎么写_人人都能用语文4-如何写软件需求文档？

经历了一次很有意义的同行评审，我们项目组都在，还请了一个外部专家来进行需求文档的审核。

软件需求文档是什么？它是指在研究用户要求的基础上，完成可行性分析和投资效益分析以后，由软件工程师或分析员编写的说明书。它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。它的作用是作为用户和软件开发人员达成的技术协议书，作为着手进行设计工作的基础和依据，系统开发完成以后，为产品的验收提供了依据。

外部专家请做这个项目的同事花一些时间讲一下目前已经写完的需求文档。

对着文档一个字一个字读没什么用，外部专家请他用1-2分钟讲一下系统的概述，介绍的不错，但觉得没听明白。外部专家就讲，如何做系统概述呢？

可以用这样的思路：这是一个什么系统，运行在什么样的环境下，与外部的设备或者软件是什么关系，收什么数据，发什么数据，有显示吗？一般写报告的时候会画一个图，把这个软件突出显示，讲的时候讲明白它与周围的关系。

确实写的好的与写的不好的就有差距，写的好的是几句话就点明了，内行人士大概就有谱了，写的不好的，虽然写很多很丰富，但是实际该表达的不清晰，不知道这个软件的定位是什么。

更神奇的是，一个项目我虽然接触过很多，但没有人实际上给讲清楚过，看文档也并不清晰。通过外部专家提出这些问题，让我知道了该看什么，然后实际干这个活的人也能很清晰的表达了，一讲大家就明白了。所以想要内部人能更好地学习和沟通，需要写到好的层次，这样才是团队的开发水平的提升。

除了系统的概述之外，接下来就是将软件需求本身了。

具体怎么把要一个东西，写成清晰的文字需求，有既有的标准做参考，借鉴前人的智慧，一些条目和应该做的事，已经有经验了。

比如有一节叫“状态与方式”，是讲这个软件最基本的工作流程和工作模式，最好有流程图来表示，同类的流程可以合并叙述，这样很容易梳理清楚需求有几类，是什么层次关系。如果有多种工作模式，比如正常、维护等，分开来画图和叙述。这个对于软件设计人员来讲，是可以看出来架构的，这个是最核心最基本的，

还有具体的需求条目怎么写，很重要的两个方面是写关系和写条件约束。

关系可以通过画图来表示，形成一些自己公司的规则，比如流程图怎么画、结构图怎么画、实线、虚线都表示什么意思，可以有内部通用的方式，甚至可以写需求编制规则，什么样功能的软件的图推荐用什么样的。

约束条件的写法就更多样了，比如软件的维护状态不开放某一些功能，就可以把这个写下来，这就是重要的约束。

对于软件来讲，有程序，在运行过程中要执行的(一般指占用CPU的)，这个大部分人都会记得写这部分的需求。但软件还有一部分是数据，比如一些配置文件，是静态的，运行时不改变，就是会读取它里面的一些信息，使软件功能实现。这些数据也要做好说明。

但实际应用中，在需求层面可能写不到这么细，我具体每一个配置文件很难对应上一个功能。那需求就要以功能为核心，顺带提一下实现的方式，把有静态配置文件这件事说到。等到写下一层次的文档(即设计文档时)，再把配置文件的分工和结构写细致写清楚。

写需求文档其实是一个必需的过程，但不是必需的文档，目前的项目要求有的比较僵化，这是面临的客观环境，如果代码量很小，需要两三个人的小团队就可以做完，那口头沟通的效果比写大篇幅的需求文档要高很多，后期补需求文档就成了不得不完成的一个负担。

但需求文档，落实到纸面，而且用心去写，会大幅提高对项目的理解力和表达力，对于大团队协作和保留组织资产，有非常重要的意义。这就是架构，总体的设计，分活派活，组织领导的很重要的积累。

听完这次的同行评审，总结了这些感受，为《人人都能用语文》又增添了一章，结合工作实际，很有意义的一章。