篇一 :需求分析一点心得

需求分析一点心得

20xx年8月15日,我休假回到公司,四川分支crm行业部进行了四维分工,我分在了需求组。组长徐茜之前已经与我沟通过需求组具体的工作明细,但自己心里还是很担心,是否能做好这份新工作,毕竟自己以前都是做的开发工作,接触的都是代码,很少编写文档;不过我还是很高兴,新的工作具有挑战性,可以更好的锻炼自己各方面的能力;

首先我查看了一些以前同事写的需求分析文档,从中积累一些好的经验,比如如何描述需求要点,如何绘制流程图等;

然后给自己制定了工作要求,明确用户需求、不遗漏需求点、对需求进行分析、提出自己的意见和建议、输出需求规格说明书给开发人员;就这样我井井有序的开展着自己的新工作,本以为自己已经做的够细致了,几周下来还是出现了不少问题。需求规格说明书写的不够细、自己写的需求规格说明书开发人员看后理解的与需求原意不一致、测试上线开发点不齐全、设计需求时未考虑到后期的维护使维护工作增多、需求不能按照之前与用户指定的时间上线等;对于这些问题,自己进行了深入的思考,如何避免这些问题的出现;深思后发现大家好像缺乏沟通,需求的每一个环节没有贯穿起来,每个环节似乎都断开了,不像以前一个需求自己与用户沟通、自己开发、自己测试、上线,整个环节都在同一个人的掌控中,时间也是由自己安排;

…… …… 余下全文

篇二 :做需求分析一点心得

1、需求分析前的准备

在软件开发过程中,需求分析可以说是核心任务之一,就像一支将要远航的船队,要在指定时间内到达目录地,他们需要一条正确的航线,才能到达目的地,如果航线有误,他们将会误时到达,或是不回到原位将永远到达不了,这么重要的东西,但在国内很多团队中缺少,虽然我也做了一些,但在项目完成的时候,回头看看,其实我们做了很多不必要的事,浪费了很多时间、人力和物力,为保证在今后的开发中减少这些错误的发生,现将一些问题记录下来。

为了了解系统需求,先可以从概要式的需求着手,再细化需求,需求分析必须拟定文档,在写文档之前我们必须做好寻求分析的范围,总结为以下几点:

1.1要做一个什么样的系统

这个不说,我想做软件开发的人都知道,拟定这个后,一切才可以扩展开,比如我们要做一个B2C的商城,要卖母婴用品,知道了这些,我们就可以找现在网站有的B2C网站做参考,分析系统构架,系统功能等。

1.2系统将要在什么样的环境下进行

我上次经历的一个系统,就是要用asp.net重新发一个B2C商城,但有一些前提条件,以前公司有网站,是用java+MYSQL开发的,但我们开发的新系统必须兼容以前的数据,如客户信息,商品信息,还有一些资源信息,并且还要兼容Google,baidu收录的地址路径,还有与原ERP的通讯等条件,这样让我们的开发很受限制,这些需求就是这样,你无法改变,所以在设计新系统的同时你必须考虑,要花时间去了解以前系统的功能,接口等,如果不了解,等你把新系统开发完了才发现系统脱离了公司原有的业务流程,让公司无法运作,那就代表你开发的系统根本没有价值,我想这不是我们想要的结果。

…… …… 余下全文

篇三 :软件需求工程的学习心得

软件需求工程的学习心得

  

     随着社信息化京城的不断深入,计算机软件的需求越来越复杂,规模也越来越大。但软件危机问题提出了三十多年,至今仍无法很好的得到解决。究其原因,主要还是,主要是忽视了软件开发过程中的质量监控,以及在软件开发过程中,对需求的准确把握不能做到很好的定位。因此,这要求我们在这个过程中要准确把握需求的内容,并予以准确的定位。

需求工程作为软件工程生命周期的起点是软件开发后继阶段的基础。软件需求是软件开发的目标,也是其项目开发成功与失败的重要因素。有时候错误的需求分析很可能导致软件开发的全盘否定,需求错误的代价会随着项目的展开儿发生变化。如果需求错误能够及时的修复,那么其代价就会被限定在一定的范围之内。如果没有及时的发现,则很可能让整个软件的开发失去其本来应有的意义。

明白了正确的需求的重要性,还要注意一点就是把握软件在开发过程中应该有的功能性需求和非功能性需求。软件开发的前期要首先分析和撰写需求规格说明书,这也在一定程度上给我们一个机会去深究软件本身应该具备的功能性意义。采用合理化的需求分析模型,能够快速的开发出系统的概貌,有利于开发过程的顺利进行,其模型包括:瀑布模型,螺旋模型,RUP,迭代模型和敏捷方法等。这些方法能够准确的定位产品的生命周期,从而使开发过程不至于偏离方向。减少开发过程中走的弯路。

…… …… 余下全文

篇四 :需求分析知识点总结

一、二填空与判断

1.软件系统通过影响问题域,能够帮助人们解决问题称为解系统

2.需求分析的分类(功能需求、性能需求、质量属性、对外接口、约束

3. 对于寻找涉众的必要性通过分析不同复杂度的信息系统的涉众特点将信息系统分为(小型统统、组织及系统、战略信息系统、组之间系统

4.获取信息的方法(传统方法、集体获取方法、原型、模型驱动方法、认知方法、基于上下文方法

5.常见的涉众类别有(用户、客户、开发者、管理者、领域专家、政府力量、市场力量

6.需求获取方法利用面谈可获得的信息内容包括(事实和问题、被会见者的观点、被会见者的感受、组织和个人目标

7.原型的分类(①按照使用方式分类:演示、严格意义上的、试验、引示系统②按照媒介载体分类:样板、纸上向导 ③按照开发方式:演化式、抛弃式 ④按照构建技术:水平、垂直。。原型

8.需求开发的一些特性决定了需求开发过程只能是一个迭代式的增量过程,而且还不是一个简单的线性增量过程,它的各个活动之间存在这复杂的组织关系。

9.头脑风暴是一种特殊的群体面谈方式

10.面谈就是在需求获取活动中发生在需求工程师和用户之间的面对面的会见,它是一种使用问答格式,具有特定目的的直接会话,也是事件中最为广泛的需求获取方法之一。

…… …… 余下全文

篇五 :项目需求分析总结

需求分析是项目开发的基础,基础打的牢不牢直接关系到后面所有的工作,是项目实施成败的关键

总体上说,我们的需求分析是做了,但是做得很不够,我们做的需求只解决了我们能做出这样的项目,但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况:

客户本身说不清楚

文物网是这样,中彰国际更是这样,但是这不能怪客户,毕竟客户在软件方面的知识要少的多,也没有相关的经验,可能心里只有一个想要的软件的轮廓,于是可能会要求我们去替他们来完整这个轮廓的细节,而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求,就决定了这个需求的完整性和有效性。

软件开发网

需求自身经常变动

随着客户对这个项目越来越深刻的理解,那么可能他的需求也会随之改变,这些变化的可能性越大项目风险就会越大,我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求,哪些可能会是产生变动的需求,考虑到他的可变性,这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。 分析人员或客户理解有误

毕竟,不是每个分析人员都是专业而合格的,为避免这种情况的发生,需求分析必须要有审核制度,公司自己内部要审核一遍,客户再审一遍,提出意见,修改后双方共同评审签字,确认。

…… …… 余下全文

篇六 :需求分析总结报告

需求分析总结报告

组长:李威   2011118161

组员:胡立柱 2011118168

      徐新祥 2011118174

      张浩   2011118175

      范浩楠 2011118176

      王博   2011118177

一:引言

为使项目能够及时的交付以及能够保证项目开发进度,编写项目开发计划来实现该目的,使项目开发人员分工明确,定期完成相应文档和成果。

随着科技的发展,人们越来越多的应用到智能管理系统来对,一些大型设施(比如;图书馆,停车场,等)进行自动化管理,以便于减轻人力的投入。对于我们的成员来说,由于我们经常出入于图书馆中,所以,我们小组决定以一个小型的图书馆的只能管理系统完成我们的这次实践任务。

二:基本说明           

…… …… 余下全文

篇七 :需求分析思路总结

需求分析思路

需求说明书应该满足两方面阅读群体,想了解宏观需求的领导,和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题:

1、最好为每个需求注释,这样可让程序员了解需求的本质,以便选用最合适的技术来实现此需求。

2、需求说明不可有二义性,更不能前后相矛盾。如果有二义性或前后相矛盾,则要重新分析此需求。

一、需求的风险

由于项目的特殊性和行业覆盖的广阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。

1、客户说不清楚需求

有些客户对需求只有朦胧的感觉,当然说不清楚具体的需求。此时,用户就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性,为项目未来建设埋下了潜在的风险。

2、需求自身经常变动

随着客户方对信息化建设的认识和自己业务水平的提高,他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。所以必须接受“需求会变动”这个事实,在进行需求分析时要懂得防患于未然,尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求,以便在进行系统设计时,将软件的核心建筑在稳定的需求上,同时留出变更空间。

…… …… 余下全文

篇八 :需求分析总结报告 [模板]

文件编号:MAC-SWE-TMP-17 密级:■ 保密 □ 通用

需求分析总结报告 [模板]

Requirement Analysis Report [Template]

本程序属MAC公司所有,未经书面许可,

不得以任何形式复印或传播。

修 改 记 录

文件编号: 密级:■ 保密 □ 通用

需求分析总结报告

该报告由开发团队编制作为需求分析阶段的结论。其概述了需求分析的结果并建立开始概要设计的基线。建议内容如下:

1.引言 必填

1.1 编写目的

说明编写这份需求规格说明书的目的,并指出预期的读者。 1.2 背景

说明:

a) 待开发的软件系统的名称;

b) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络; c) 该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料

列出用得着的参考资料,如:

…… …… 余下全文