需求分析小结.docx

需求分析小结

第一篇：需求分析小结需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键项目经理博客总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：客户本身说不清楚文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题：a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。第二篇：需求分析个人小结需求分析个人小结在本次城市公交管理查询系统开发中，我负责的是需求分析这一项目的工作。城市公交查询系统是为了使人们更好地使用城市公交系统，提供了公交线路查询、公交站点查询、以及周边生活查询（站点附近餐饮等）,地图查询（周围站点）,意见反馈的功能。本软件需求说明书的主要目的是明确用户需求，确定所要开发的系统范围。该文档主要读者包括本软件开发小组的成员。此软件需求说明书主要涉及到城市公交查询系统中按路线查询公交,按站点查询公交（站站查询）按地点查询公交,周边生活查询（站点附近餐饮等）,地图查询（周围站点）,意见反馈的功能需求、特性需求等内容。在开发此软件时，我们采用了常州公交查询app以及沈阳城市公交管理系统作为模版，并对学校周边的广大人群进行了走访调查，确定了6个前台功能模块：线路查询，站点查询，公交换乘模块，周边生活查询，地图查询功能；以及后台管理模块。但是由于是第一次设计软件，经验不足，完成后发现生活查询与地图查询功能之间存在功能重复的问题，而且后台管理模块设计的过于粗浅，并不能实施很有效的管理。对于管理员的工作并没有区分明了，在第二个版本中，将将后台管理系统分为了账号管理模块，公交线路管理模块，公交站牌附近地图管理模块。在第一个版本的需求说明书中，我并没有严格区分游客登录与账户登录，后来经过老师提醒加以改进。而用户反馈模块开始时并没有，后来考虑到与用户的互动加以添加，并且设置了实时消息滚动栏，对用户留言进行播放。这是我第一次参与系统计划开发，并且担当了需求分析这一工作