求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
老菜鸟侃需求分析的“再回炉”
 

作者:wolf1860 ,发布于2012-11-19

 

去年四月份即许诺为女儿写个学习工具(妞妞加油站,有搞成系列的想法),却由于一个软件项目的开发工作一拖再拖,直到年底才腾出个把礼拜搞了个七七八八,正好赶上闺女的考试。小试了几刀,感觉效果还是比较明显,有兴趣的家长可以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:统计分析,哥要去涮羊肉了。就不再细写

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

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

 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练
 
分享到
 
 

相关文章

需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   

相关培训课程
软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践

成功案例
北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...