现在功能知道了，框架知道了，逻辑有了，终于推进到了交互层。如果包含前台与后台页面，建议从前台开始写。先将页面流程图画出来，让别人有个大致的了解。然后逐页进行说明，可以按照页面流程图的顺序来，一点点展开。单个页面可以采用从左到右，从上到下的顺序，一点点写，在说明该页面之前，可以先阐述下这一页面的提供什么功能，主要用来做什么？然后再对页面进行结构说明。
对于交互说明，可以把一个页面拆解成，元素（字段）、规则和操作三部分。
我曾经尝试过用这样的方式区隔他们，在Axure中将效果图标注上元素说明。比如，如何读取，显示字数和文字是否有限制，表单的默认值是什么，页面无数据会是什么等等。
因为元素说明要配上图才更容易说明，规则就不同了，写上来就能够通过文字看明白。
规则说明包括，是哪个角色访问进这个页面，他从什么页面进入此页面，如果有列表，那么列表排序规则是什么，默认如何排，是否有缓存，分页功能的规则是如何定义的等等。不仅如此在业务方面也会涉及到，如果拿订餐来说，单日订餐是否有份数限制，如需预定要要提前多久等等，这些也是规则的一部分。
当元素与规则阐述好之后，就需要来撰写操作环节，因为一般操作都会把用户带入新的页面任务中，所以放在后面写，这样就可以衔接之后的页面。
OK，先观察一下，抛开导航而言，有什么是可以操作的呢？排序是不是一个？点击地图可以查看线路是一个，抢单按钮很明显是一个，图上没有的，其实还有一个查看更多的操作。
现在可操作的地方已确定，接下来就逐个去规定操作细则吧！比如操作完之后的流程是什么，登录吗？登录成功之后呢，去到哪里，有什么反馈，什么节点做什么判断，如果信息错误，那么错误提示是什么等等。
撰写可操作规则时，实际上就是去想，当你点下这个按钮之后的一系列流程与页面，将他们都列举出来。所有可以定义的内容都要定义，所有操作都像慢动作一样，需要逐帧解释。
其实写到这里正文部分已经结束了，点、线、面都被你写到文档中，这时候你可以召集小伙伴们来，再碰一次需求了，一份比较完整的需求文档就搞定了，为什么说是比较完整，因为毕竟我还是个菜鸟，不知道这其中是否有疏漏之处，如果有，请大神指教，我愿意学习一下。
