我们是按照优先级来编写功能设计说明书的。我们并不会把功能设计说明书都编写完毕后才开始编码。而是，我们先把优先级为一的详细功能设计编写出来，就开始开发。二级的功能编写会在开发人员进行一级功能编码的时候并行。
功能详细设计说明书由业务开发组的组长来编写，属于系统类功能或公共类的功能，都归给公共代码人员来编写，需要复杂的算法，高性能，高安全，高数据量，需求一直未确定最终解决方案的未来未知变化的接口，也都由公共代码人员来编写。所以，一个开发团队，有高技术的公共代码人员，有深刻理解业务的业务开发组组长，有普通的coding人员。业务开发组的组长一般由熟悉客户业务，编码经验较多但技术能力一般、踏实细心负责适合团队管理的人担任。
功能设计说明书，根据每个功能点详细展开描述。一般一个功能点由一个EXCEL文档来详细描述。
EXCEL文档第一个sheet中是版本信息，每次修改都有变更记录。第二个sheet是页面布局。我们通常会用PPT或开发工具建立个界面草图，然后贴上去。第三个sheet是页面上面的每个字段的说明，如默认值、不可为空、输入约束、主键唯一、输入长度、参照录入等等。第四个sheet，如果有必要，可以用VISIO画出业务流程图。第五个sheet是关于运行要求，如易用性、安全性、性能、数据量、并发性，这几个特性都分为高中低三个等级。另外，对运行的操作系统、内存都做了最低要求。一个功能，必须考虑它的用户的计算机水平，否则功能很实用，但就操作不习惯，客户非要改成客户习惯的方法，我们经常会面临这样的要求。与其那样让客户赶着我们，还不如我们自己提前在设计的时候就要求我们自己。我们在需求调研的阶段会调研客户的信息化现状，如IT维护人员能力，信息化应用能力，客户老板对信息化认知理解，最终用户信息化操作能力。
我经常看见不少客户没有IT维护人员，不知道有服务器这一说法，更不知道什么是SQLSERVER，也不知道备份。对于信息化的理解就是上套软件，装个XP还不知道WINDOWS要升级(很多上网的机器连XP SP2都不装，什么防火墙放木马的都没有)，就知道装个瑞星杀毒，天天抱怨机器超慢。一看机器，也确实是老了，2002年的机器，128M内存。而且操作者打字和鼠标都不灵光，让他双击或鼠标右键，他根本不理解。跟他电话里说打开某个功能菜单，他很莫名其妙电脑中怎么会有菜单?如果你的软件是基于.net的，他连.net 运行时都不知道到哪里去下载。所以我们的软件需要在什么硬件上什么基础软件上运行，数据量多大仍然可以运行流畅，我们的软件要达到的易用操作程度，要达到的易用维护程度等等，我们必须在设计期考虑到。
很多做软件开发的，尤其不注重这方面，所以我在这里重点强调啰嗦一下。大家不要耻笑用户，大家的工资都是他们给咱们的，而不是老板。用户不是计算机高手，他们不懂双击、滚动、鼠标右键很正常。我们的衣食父母，我们要好好对待。我们不要和我们的钱作对。
EXCEL功能设计文档到此，其实还缺一块。就是数据操作流程。
我们先不编写数据操作流程。我们会先交给测试组的人员来校验这个功能点的详细设计，是否和需求流程和需求要求吻合，不符合的地方就整改。
整改后的功能设计文档，算是和需求说明文档一致，设计正确。这时候才涉及到具体的实现说明。
我们会让公共代码人员出界面输入输出和业务流程图中整理出数据结构。我们为什么不让业务开发组的组长来整理表结构，就是由于业务开发组的组长熟知业务却对技术并不精通。数据结构很影响未来的性能、扩展，所以应该由公共代码人员来设计表结构，并且建立视图和存储过程。
公共代码人员为了考虑性能和扩展，表结构的设计可能就被打散成多个表，而不是业务开发组长自然理解的存储结构。所以公共代码人员建立了视图，保证在视图的层面上让业务代码开发组的人看到的是一个自然的业务实体数据结构，根本无须理解内部的表结构之间的关联关系。而且有存储过程来保证如何无须知道表之间的关联关系就可以增删改数据。
从这种分工配合来看，我们采取的是从后到前的开发方法。先有数据层，有基础表结构、视图、存储过程，然后基于视图和存储过程进行业务流程代码开发，最终由普通的业务开发人员进行界面拖控件绘制界面。所以业务开发人员既不熟悉业务，也不熟悉技术。
文章来源于领测软件测试网 https://www.ltesting.net/
