需求设计入门

  我正式参加的第一个项目是移动渠道运营，由于公司人手不够，老大将渠道资源的大模块交给我一个人来负责，由于之前的详细设计极为粗略，库表设计也没有，所以一切就得自己来搞定了。

开发过程中与客户进行过2次粗略的交互，可由于我是新手，对移动业务很是不熟悉，他们的需求我难以全部消化。两个月后一期开发完毕，昨天在现场与客户测试的时候，发现很多地方都没想到，虽然界面和已实现的功能他们颇为满意，可还是提出很多他们需要的功能以及需要修改的功能。客户的素质颇高，只是希望我尽快考虑他们的需求，添加一些他们迫切要求的功能。还好，老大没有批评我。

经历这次事情，感觉需求与详细设计是多么的重要。出现这样的问题，我分析了一下，有以下原因：

1.  前期与客户交流不够，只是粗略的沟通，很多细节问题都没有涉及到；

2. 自己对移动业务不熟悉，造成对客户的要求不能完全理解，出现偏差；

3. 设计的实现方式自己还是欠缺，比如如何设计一个高效的库表系统，库表之间如何关联等；

解决的方法依次如下：

1.. 前期沟通一定要充分，在开发过程中哪儿有问题，需及时和客户进行确认，万不可按照自己的主观臆断行事；

2..多阅读客户方提供的业务资料，通过阅读以及与客户的沟通，做到尽可能熟悉客户方的业务需要，这样对开发有很大帮助，提高软件的实用性；

3. 数据库设计方面，多与公司的前辈沟通，参考公司以前做的系统，并结合业务需要。全面的模拟整个使用环境，考虑到在使用中可能出现的各种问题；

4. 从用户的角度出发进行分析。比如设计一个票据领用登记归还的模块，那首先得领用登记吧，得做个领用登记的页面和功能，需要个领用主表和，明细表；领完了得查询吧，这段时间谁领了多少票吧？好，得提供查询功能；票领完了发现领多了或者没用完，得归还吧？ok，加个回收登记的功能。可要回收那肯定是有领用记录才行，所以还是先得查询。库表设计方面，可以设计成四张表，分别是领用主表、领用明细、归还主表、归还明细；可这样的话关联也太多了，归还主表得记录领用记录主键；归还明细得记录领用记录主键。不可取。何不就设计成两张表呢，一个是主表，一个是明细表，主表字段有领用id、领用人、领用部门、领用原因、归还原因等基本信息；明细表字段有 明细id、领用id(外键)、发票类型、领用数量、领用日期、归还数量、归还日期等。这样存领用的时候归还字段均为空；归还的时候直接先查出领用id，然后直接把归还信息存入不就行了吗？

 

注：我是个刚毕业半年的新手，啥也不懂，都是刚开始学，这是小弟积累的一点点经验。希望能给和我一样的新手有所帮助，我这里面肯定有不对的地方，还望高手看到后能给予指点啊，小弟不胜感激！