技术开发 频道

需求分析在项目开发中的重要性

【IT168 分析评论】

    谈什么呢,先谈需求分析,做了几年开发下来,发现需求分析是个很重要的问题,很多程序改了又改,甚至有同事说:“程序就是改出来的”,这其中很大一部分问题就是需求分析没做好或是做的有缺失,所以先把这个问题拿出来说说,既是对自己的一个总结,也希望对别人有所帮助!

    做需求分析,我的感觉是尽可能的减少信息传递的个体,先说下我对需求分析的理解,就是把客户的功能描述转化为软件员所能理解的功能描述,并在客户描述的基础上去除不合理的地方,补充系统缺失的地方,最后为系统的概要设计,详细设计提供准确,有效的数据基础。那么这边就有个信息传输的问题,例如一个企业要做个系统,他的老板把他的系统理解传递给手下经理,再由经理传递给科员,然后找软件公司,在来个来回,从前台人员传递给项目经理,再由项目经理传递给程序员,在这样一个信息传递中,每个人都有各自对系统的理解,那么就会产生偏差,误解,而如果把每一个人的偏差与误解累加起来,我们就会发现一个很恐怖的事情,那就是我们的系统可能与客户原始的初衷相差很远,甚至可能就是两种系统的理解,所以我个人感觉在条件允许的情况下尽可能地减少中间的信息传递,让信息损失与误差降低到最低!!

    还有一种情况是他的软件需求是由很多个人的集体意见构成的,那么这里就有主次,轻重之分了。比如一个办公自动化系统,信息发布的需求是由某个科长提出的,公文流转是由打印室提出的,文档管理是由档案室提出的,而且在提需求的过程中,有科员也有领导,那么在这里,我们就要区别对待了,首先要做的便是把所有人意见整理一下,把大家的共同意见先整理出来,因为这是我们必须要做的,而且是首要考虑的,然后,我们便是抓大头,如果某个科员和他的领导在需求方面有分歧,甚至南辕北辙,那么我们就是要把领导的需求放在首要位置,当然这建立在合理的基础上,优先考虑领导需求,把两份文档整理出来,那么系统的雏形也就差不多出来了。还有不要忘记,那就是确认,把整理好的需求与各个科室的领导再对下,最好是形成文档,那么这个需求相对完善了!

    还有一种情况也是我碰到过的,那就是客户对某个要求比较强硬,而这个需求在软件实现上有其不合理的地方,那么我们就要据理力争,虽说“客户是上帝”,但是我觉得维持一个公司的技术独立型,运营独立性很重要,我们不能被客户牵着鼻子走,而是我们引导客户实现他的系统功能,完善他的各项管理!

    而我遇到最多的便是小软件公司不负责任,说难听点就是忽悠人,但也不是说他乱做,而是仅实现功能地做,甚至我原来公司做个办公自动化系统就是照着别人的做,就差没把别人的代码拿过来换成自己公司的名称了,完全脱离需求实际,不需要的功能多做了,要的功能少做了或是彻底没做,结果呢就是改啊,拖啊,老板竟然还在那自鸣得意,认为照别人做是个不错的主意,而项目完不成便就是我们的责任,哎!而且很多公司认为只要实现功能就行了,对他们来说最重要的就是收到钱,完全不负责任。所以个人认为在做需求分析时,站在客户的角度设身处地的去思考系统这是很重要的,我们的客户不只是要一个实现功能的系统的,而是要一个给他带来效益的,科学的,合理的,人性化的系统,那么很多时候客户在系统中没有想到的,我们就要考虑到,这不是给自己找麻烦,而是保持一个系统完整性所必须的,我们提供的不只是个软件,而是一个精致的产品,一种优质的服务,甚至是一整套科学合理的完成某些工作的先进理念!而且在很多时候,用户体验是很重要的,而在我接触的公司基本就不考虑这个,在他们来说实现功能,收到钱比什么都重要,所以便一直就是小公司!

    关于需求分析的总结大体就到这了,当然还有很多其他的东西也是很重要的,例如在系统开发前我们必须做好功课,充分了解系统所在行业的行业背景,相关流程,甚至去下一些别人写的与系统有关的程序,“存在的都是合理的”,很多时候别人的系统是很值得借鉴的,注意,是借鉴而不是抄袭,我们要学的是思想。当然关于需求分析还有很多东西,说白了,这也是门学问,而我只是个学习者,还有很多不足,望各位不吝赐教!

0
相关文章