去年四月份即许诺为女儿写个学习工具（妞妞加油站，有搞成系列的想法），却由于一个软件项目的开发工作一拖再拖，直到年底才腾出个把礼拜搞了个七七八八，正好赶上闺女的考试。小试了几刀，感觉效果还是比较明显，有兴趣的家长可以down一下试试。CSDN上传了一下，名字是“小学语文学习加油站（家长版）”，DelphiXE+Firebird，Ribbon2010风格，自动生成拼音，支持多音字，能按每一课、每单元、全书生成资料或测试卷子，区分了生字、多音字、成语、文言文、古诗、作家作品等单项知识，单纯从语文基础知识学习来看，应该能满足要求了。

由于我是一个自由软件人，经常会接一些朋友之间帮忙的活儿，年届四十时，经常会小小自满一下，一般数据库项目哥都见过了，还有什么需求难得倒哥？孰不知，就是这个小小工具软件让我开始重新审视需求这两个字，让我意识到，需求的整理和落实是需要用户和技术人员共同来“回炉”、“淬火”、“锻造”的，而其中“回炉”竟是最令人头大，却又是最重要的一部分。

先说问题，谈到小学语文，我的理解就是从拼音－词语－句子－作文这样一个过程来螺旋上升的，当初在软件设计时，第一个目标就放在生字和词语上，嘴里还念叨着，把生字、生词都写会了，至少能拿到五十分罢。正是因为这个想法，让我实实在在体味了一下回炉的痛苦。

教训之一、需求的理解切忌闭门造车、自编自演。

有了先前的想法，我的工作路子就很明显了，把字词句堆到数据库里，然后再模仿孩子的的考卷用Word输出来就得了。这不，板砖马上就不请自来了：

孩子：我们上课又不是一下子把一本书学完，每次都写那么多，作业怎么办？

老师：其实我们最头疼的工作主要是重复劳动太多，别的不说，就拿输个拼音来说罢，虽然word里面有注音的工具，但效率还是不高。常常是这边录入那边还录...

我：每次出个卷子要么得选内容选半天，要么就一下出来五六张纸，孩子做完还好说，孩子不做，那纸不就浪费了？

我明白过来设计上出了偏差的时候，已经基本写完了“词语”、“字”两部分。咬咬牙、跺跺脚，一边儿调整数据结构，一边儿重新梳理需求，所幸，我的技术设计框架抗击打能力较强，才最终没有淹没在闺女的唾沫之下。

心得：技术设计上必须不折不扣地坚持继承等OO思想，必须着眼重用、扩展的“通用”思想，那样子的程序，才不会怕“变”，才会耐“变”。当然，在编程之中，时时地通过重构来规范自己的代码，使之沿续这种设计思想，落实这种设计思想就是程序员良好的职业养成了。

教训之二、需求的落实必须坚决屏弃“补丁”思想，更多把功夫下在专业知识的学习上。

补丁历来是用来救火的不得已手段，在时间能力允许的范围内，还是不要用补丁罢。否则，补丁必然会越打越多，直到影响到程序本身的乳壮。这个感悟是在我遇到了近义词反义词、成语、造句时体会到的。当时，“词语”一部分设计中我仅考虑了成语，其它几部分虽然也有考虑，但重视不够，心里想着：顶多就是再建一两个从表嘛。等到我拿到老师用的《语文XX详解》，我才意识到自己又犯了一个错误，首先，最优的录入方案应该是在录入时即进行勾选，哪个词是成语，哪个词可以用来造句，哪个词的近义词是什么，反义词是什么，另起几个窗体，再进行勾选，是绝对的费时费力。其次，加入几个从表，就需要在界面上加入几个按钮，增加了软件操作的繁琐不说，也加大了软件使用的难度。

又是一番的咬牙跺脚之后，把开发工作停下，静下心来研究了《语状》、《详解》等多本学习参考工具书后，对数据库进行了新一轮的重构。

心得：遇到问题后，不要急于下手改动，而要再次细细咀嚼需求，“回炉”后再“淬火”，补充专业知识，从全局来把握改动范围，这样才能真正做到有的放矢，从根本上避免补了旧洞又添新坑的尴尬。

罗里罗嗦写了一堆的教训，实际上收获也是不少。结合新结束的一个项目，也一并把较为成功的经验分享一下，祝愿我们的程序员在龙年真正滴龙腾虎跃，大展拳脚，更希望中国的软件公司越来越赚钱，为IT人提供越来越多彩的舞台：）

说到需求分析，最直接的有两点是必须做到的：一是吃透需求；二是把用户需求落实好。

吃透需求

吃透需求，除了专业上要搞清楚流程、弄明白计算机要做哪些事以外，笔者管见，还要跟用户的操作习惯、用户个性要求做一个良好的平衡，要细抠每一个细节，严格控制每一个大环节。这样子说起来有些拗口，那就举两个简单的例子来说罢：

案例1：我在做一个车辆管理的软件时，牵涉到一个车辆档案的模块，档案中涉及“车型”这个字段的录入，就很是下了些功夫。原因是车型的分类数量较多，又有“大客车”、“运输车”、“小轿车”、“旅行车”这种概略分类。说白了，从数据表现形式看，这是一个树形结构。这样，录入的解决方案就有了一些“细抠”的余地：1.做成一个下拉框带着树的形式，供用户选择。（复杂点儿的话，可以在合适的位置加上一个检索文本框，提高选择速度）；2.做成一个类似浏览器URL框中的数据敏感样式，用户输入一个字符就显示与录入字符相吻合的待选车型，用户再选择。

我在处理这个问题时，先采用了方案1。实施第一个单位时，因为管理车辆档案的是一位老职工，不喜欢打字，就喜欢一个一个选。这当然符合他的意愿，于是你好我好，皆大欢喜。但在实施第二个单位时，就遇到问题了。这次的直接使用人是一个小伙子，五笔字打滴飞快。倾向的方式自然是第二种，速度又快，又不容易出错。

合理的解决方案当然是在系统设置里面设置一个类似“数据录入－常量录入方式－（1）选择（2）录入选择混合模式”的选项。

案例2: 做《小学语文学习系统》时，拼音输入是老师和家长所关注的“大”问题，试想：没有哪个用户愿意录个词或字后，再从Word里面拷贝一下拼音输入罢？（偷乐），更何况这个东东儿就是俄泡制出来自己用的（汗）。抠一个拼音模块出来是必须的了，但还要考虑两个问题，那就是用户的输入习惯和输入速度，键盘熟的要提供尽可能全的快捷键。所以设计中，“回车键”，类似于Word之类的快捷键就必须首选，因此，回车就要出拼音，按键就要出结果是一个基准目标。

仅仅有这些还不够，如果系统产生的多音字拼音有误呢？怎样快速更正？基于这种想法才有了快捷工具条上，快速获取拼音的两个文本框、一个按钮（默认的快捷键是Ctrl+Enter，一般人俄不告诉他）。这样，整个的录入才算是画了一个圆圈。

有兴趣的同志可以去看看俄这个最新劳动成果，Ribbon2010风格，是俄比较满意的作品哦。

下载链接：http://download.csdn.net/detail/last_wolf1860/3996547

综上两个例子，要吃透需求，就一定要亲临每个工作环节、每个工作台站，调研无有止境啊：）而那些抓不住重点，抠不了细节的同志一定作不了一个好的项目经理，用人滴同志要注意哈。

用户需求落实好

把用户需求落实好，这个题目有些大。先贤们早就把需求分了显、潜两类。显需求还好定量，潜需求就需要一定功力了。按照我做项目的经验，潜需求的分析应该是在吃透显需求的基础上，以程序员为主导、结合程序员的工程经验、以往工程中好的做法、成熟的技术，激发（诱导）用户产生的想法或称之为工作量的东东儿。这部分东西，有些人愿意再分成必做和可有可无两种，在俄看来，这种区分根本没有道理。必做的东西一定是显式的，而可有可无的东西才真正算得上是潜在的。潜需求的处理往往能够看出来一个项目经理的水准，您不信？且听俄再一一道来。

案例1：导入Excel数据

玩数据库的同行们，大多遇到过这个需求。我见过的有三种设计方案：

a. 只支持规范的Excel文件，也就是说，预先定好了Excel格式，别的一概不管。

b. 支持自定义Excel的列和数据表字段的对应关系。

c. 支持Excel自定义、规范Excel两种模式，可原地编辑Excel导入，支持行列对应关系的存储和载入、支持可扩展的Lookup字段

表面上来看，第三种方案似乎为最优案，实际上笔者却不这样认为。真正能够决定哪种方案的是：用户的Excel文档有多少？来源有多少？格式是否固定？Excel文档是用来导入历史数据还是上报数据？等等

如果用户只有几千条存在Excel表中的数据，不妨考虑一下第一种方案，我可从来认为，改Excel再排一下版，远比加上N个按钮，再教用户如何去形成对应关系要简单得多。告诉用户：“点一下按钮以后，这东西就OK了”。相信用户心里会更高兴。

第二、三种方案的区分原则也是如此。但由此引出的潜需求可大不相同了，如一些字段是后来规定，而历史数据中没有的怎么办？

提供一个小的解决思路：在编辑里面，允许批量修改数据，有兴趣的同志可以试试哦：）这个说大不大说小不小的功能，是必做的还是可有可无呢？

仁者见仁，我只是敢保证，如果你本身就是第一用户，答案会是什么。

案例2：统计分析，哥要去涮羊肉了。就不再细写

概而言之，需求分析的“再回炉”，就是程序员和客户的再磨合，是程序员对显需求的再咀嚼，再调研，是程序员对自己作品的再完善、再。。。。。鸡蛋里挑挑骨头。

如果这样，优秀的软件是不是就会出滴更多一些？钞票是否就会挣滴更多一些？这些课题留给同志们深究。俄还是抛砖引玉，引点儿思考也就达成本文的目的了。