项目需求分析怎么写.docx
- 文档编号:11450089
- 上传时间:2023-03-01
- 格式:DOCX
- 页数:11
- 大小:21.90KB
项目需求分析怎么写.docx
《项目需求分析怎么写.docx》由会员分享,可在线阅读,更多相关《项目需求分析怎么写.docx(11页珍藏版)》请在冰豆网上搜索。
项目需求分析怎么写
项目需求分析怎么写
1.项目需求分析怎样写
项目需求分析的概念需求分析是指理解用户需求,就软件功能与客户达成全都,估量软件风险和评估项目代价,最终构成开发方案的一个简单过程。
(这个和我在微软体验到的又不太一样,微软的需求分析大多是市场人员和用户帮助小组的人去评估用户的接受程度,这一点也可以理解,由于公司的性质有根本差别)在这个过程中,用户的确是处在主导地位,需求分析工程师和项目经理要担任整理用户需求,为之后的软件设计打下基础。
需求分析阶段结束后,要求得到:
1.SRS文档(SystemRequirementSpecification);2.DRM文档;3.AcceptancePlan.从广义上理解:
需求分析包括需求的猎取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解:
需求分析指需求的分析、定义过程。
一、为什么要需求分析需求分析就是分析软件用户的需求是什么.假如投入大量的人力,物力,财力,时间,开发出的软件却没人要,那全部的投入都是徒劳.假如费了很大的精力,开发一个软件,最终却不满意用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(信任大家都有体会)比如,用户需要一个forlinux的软件,而你在软件开发前期忽视了软件的运转环境,忘了向用户询问这个问题,而想当然的认为是开发forwindows的软件,当你千辛万苦地开发完成向用户提交时才发觉出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.需求分析之所以重要,就由于他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家肯定要对需求分析具有足够的注重.在一个大型软件系统的开发中,他的作用要远远大于程序设计.二、需求分析的任务简言之,需求分析的任务就是处理"做什么"的问题,就是要全面地理解用户的各项要求,并精确 地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:
问题识别,分析与综合,制定规格说明,评审.问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应当达到的标准.这些需求包括:
功能需求(做什么),性能需求(要达到什么目标),环境需求(如机型,操作系统等),牢靠性需求(不发生毛病的概率),平安保密需求,用户界面需求,资源使用需求(软件运转是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估量以后系统可能达到的目标.分析与综合逐渐细化全部的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们能否满意需求,剔除不合理部分,添加需要部分.最终,综合成系统的处理方案,给出要开发的系统的具体规律模型(做什么的模型).制定规格说明书即编制文档,描述需求的文档称为软件需求规格说明书.请留意,需求分析阶段的成果是需求规格说明书(好象软考已经考过这个问题),向下一阶段提交.评审对功能的正确性,完整性和清楚性,以及其它需求赐予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
四、需求分析的方法需求分析的方法有许多.这里只强调原型化方法,其它的方法如:
结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不争论.原型化方法是非常重要的(是软考等常考的学问点).原型就是软件的一个晚期可运转的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建筑一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在牢靠性,界面的友好性或其他方面上存在缺陷.建筑这样一个系统的目的是为了调查某一方面的可行性,如算法的可行性,技术的可行性,或调查能否满意用户的需求等.如,为了调查能否满意用户的要求,可以用某些软件工具快速的建筑一个原型系统,这个系统只是一个界面,然后听取用户的看法,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型次要有三品种型(软考考过):
探究型,试验型,进化型.探究型:
目的是要弄清晰对目标系统的要求,确定所盼望的特性,并探讨多种方案的可行性.试验型:
用于大规模开发和实现前,考核方案能否合适,规格说明能否牢靠.进化型:
目的不在于改进规格说明,而是将系统建筑得易于变化,在改进原型的过程中,逐渐将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:
废弃策略,追加策略.废弃策略:
先建筑一个功能简洁而且质量要求不高的模型系统,针对这个系统反复进行修改,构成比较好的思想,据此设计出较完整,精确 ,全都,牢靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探究型和试验型属于这种策略。
追加策略:
先构造一个功能简洁而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充修改,逐渐追加新要求,进展成为最终系统。
进化型属于这种策略.。
2.项目需求分析怎样写
项目需求分析的概念需求分析是指理解用户需求,就软件功能与客户达成全都,估量软件风险和评估项目代价,最终构成开发方案的一个简单过程。
(这个和我在微软体验到的又不太一样,微软的需求分析大多是市场人员和用户帮助小组的人去评估用户的接受程度,这一点也可以理解,由于公司的性质有根本差别)在这个过程中,用户的确是处在主导地位,需求分析工程师和项目经理要担任整理用户需求,为之后的软件设计打下基础。
需求分析阶段结束后,要求得到:
1.SRS文档(SystemRequirementSpecification);2.DRM文档;3.AcceptancePlan.从广义上理解:
需求分析包括需求的猎取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解:
需求分析指需求的分析、定义过程。
一、为什么要需求分析需求分析就是分析软件用户的需求是什么.假如投入大量的人力,物力,财力,时间,开发出的软件却没人要,那全部的投入都是徒劳.假如费了很大的精力,开发一个软件,最终却不满意用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(信任大家都有体会)比如,用户需要一个forlinux的软件,而你在软件开发前期忽视了软件的运转环境,忘了向用户询问这个问题,而想当然的认为是开发forwindows的软件,当你千辛万苦地开发完成向用户提交时才发觉出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.需求分析之所以重要,就由于他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家肯定要对需求分析具有足够的注重.在一个大型软件系统的开发中,他的作用要远远大于程序设计.二、需求分析的任务简言之,需求分析的任务就是处理"做什么"的问题,就是要全面地理解用户的各项要求,并精确 地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:
问题识别,分析与综合,制定规格说明,评审.问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应当达到的标准.这些需求包括:
功能需求(做什么),性能需求(要达到什么目标),环境需求(如机型,操作系统等),牢靠性需求(不发生毛病的概率),平安保密需求,用户界面需求,资源使用需求(软件运转是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估量以后系统可能达到的目标.分析与综合逐渐细化全部的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们能否满意需求,剔除不合理部分,添加需要部分.最终,综合成系统的处理方案,给出要开发的系统的具体规律模型(做什么的模型).制定规格说明书即编制文档,描述需求的文档称为软件需求规格说明书.请留意,需求分析阶段的成果是需求规格说明书(好象软考已经考过这个问题),向下一阶段提交.评审对功能的正确性,完整性和清楚性,以及其它需求赐予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
四、需求分析的方法需求分析的方法有许多.这里只强调原型化方法,其它的方法如:
结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不争论.原型化方法是非常重要的(是软考等常考的学问点).原型就是软件的一个晚期可运转的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建筑一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在牢靠性,界面的友好性或其他方面上存在缺陷.建筑这样一个系统的目的是为了调查某一方面的可行性,如算法的可行性,技术的可行性,或调查能否满意用户的需求等.如,为了调查能否满意用户的要求,可以用某些软件工具快速的建筑一个原型系统,这个系统只是一个界面,然后听取用户的看法,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型次要有三品种型(软考考过):
探究型,试验型,进化型.探究型:
目的是要弄清晰对目标系统的要求,确定所盼望的特性,并探讨多种方案的可行性.试验型:
用于大规模开发和实现前,考核方案能否合适,规格说明能否牢靠.进化型:
目的不在于改进规格说明,而是将系统建筑得易于变化,在改进原型的过程中,逐渐将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:
废弃策略,追加策略.废弃策略:
先建筑一个功能简洁而且质量要求不高的模型系统,针对这个系统反复进行修改,构成比较好的思想,据此设计出较完整,精确 ,全都,牢靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探究型和试验型属于这种策略。
追加策略:
先构造一个功能简洁而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充修改,逐渐追加新要求,进展成为最终系统。
进化型属于这种策略.。
3.怎样写项目需求分析
要你对你做这个程序的目的有很深的熟悉~~
当然你的目的也就是用户的目的~~
一个软件的胜利与否~最根本的就是他能帮用户处理问题~
这就需要你和用户沟通,和分析用户为什么要做这个软件~~
由于用户可能完全不懂计算机~所以许多的东西用户的描述只是个也许~
所以你需要~晓得用户平常工作的范围~和平常用你的软件干了什么~
这样你就能很好的分析需求~~
做出来的东西也不会,与用户的要求有很大出入~~
完全个人发挥~可能不是太清晰~~
4.项目需求报告要怎样写
听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。
需求分析,不只仅是拿到客户的需求,更重要的是还需进行分析,了解细节,并就细节跟客户询问,猎取最具体的材料。
客户所能供应给你的只是他们想到的功能需求,许多问题并不在他们考虑的范围之内,假如作为项目担当方没有去做分析,简洁的根据功能要求去设计、规划,最终出来的系统是很难完全符合客户的业务流程的,这时,自然需要更改,被看成了需求的更改。
其实,都是缺乏分析所一手形成的。
问题等到系统出来了才被发觉,这样的系统本身就是先天不足的了。
听棠所说到的几点,感受特殊深:
“其实问题出在开头,客户需求只是软件需求分析的一部分,虽然是比较重要的一部分,但也不要只是去记客户的需求,而是要把客户的需求进行分析”
还有客户的需求本身会有冲突(这冲突是指在规律角度来讲),客户本身是意识不到的,只要在分析设计时,才会分析出这里的冲突,而这些问题,假如在期初时,软件担任人不分析,而是纯粹的“听从”客户要求去做,当暴露这些问题时,你怪客户也没用啊。
项目需求分析报告,在了解客户需求时,不要不动脑子,不要一味的点头说“IC”,其实在表面的业务里面可能包含着N多的细节,这些细节是需要你反问客户的,只要当你提的问题越多,最终猎取的需求最详细,才能让项目越顺当。
而且有许多问题,都是在你的反问中,客户也才开头思索原来没思索过的问题,客户也会找到一种合理的需求给你,有人会觉得这样了解客户需求不免太麻烦了。
至于一些在技术上会遇到问题的地方,也要告知客户,别以为到时候再说,客户是不关怀你的技术细节的,但你假如给他解释的话,他也会试着理解的。
客户的需求本身是无休止,由于他们本身也在变,但当你期初的分析合理,后面的变动也将在规律上变动,信任代价已经不会那么大了。
这其实也体现了系统的扩展性。
需求分析,是一个项目提出方和担当方相互沟通的过程,一方是系统的使用者,一方是系统的制造者,在系统制造过程中,只要双方相互协作,共同对系统进行设计才能最终达到使用的要求。
客户是业务上的熟识者,对业务流程有特别清楚的了解,但是,对于软件需求方面的描述是不了解的,他们所能供应的只是他们最终要达到的功能,但是,这其中包含的业务流程是特别简单的。
我们拿到客户需求后,应当依据功能、流程进行初步的设计,构造出业务流程图,再让客户进行评审,提出业务流程上不对的地方进行修改。
这样来回的沟通,最终才能取得较全面的需求,并削减后期的修改。
5.项目需求该怎样写
次要包括以下内容:
1、项目概要(扼要说明项目的内容、技术特点等,限100字)。
2、项目的目的、意义及必要性。
项目在全国(省、行业)科技与经济进展的地位和作用,要处理的关键技术、工艺。
项目的创新性和先进性分析,对专题的响应程度分析。
3、国际水平、现状及进展趋势。
4、国内相关产品与技术进展水平、现状。
说明相关产品与技术现状、进展趋势。
5、项目前期研制开发及技术预备状况。
进展该项目前期研发及相关技术预备工作状况,能否有阶段性成果等。
6、项目产业化实施方案。
1)实施方式、技术路线(自主开发、消化汲取、国际合作等),技术风险和学问产权状况。
2)与原有同类型产品技术、性能目标和参数对比。
3)项目开发内容与方式(包括次要研制开发、实施内容及考核目标)。
4)开发后产业化目标及生产力量状况。
7、项目进度支配与实施期限。
8、技术经济效益分析。
包括生产效益目标、生产成本分析、不确定性分析、项目的经济效益分析。
9、项目资金支配、资金来源与落实状况。
10、社会、经济效益分析。
包括能源利用效率分析、环境爱护和资源利用效益分析、促进产业进展作用分析,供应次要分析目标及演算方式,投资回收期,投资利润率;投资利税率,盈亏平衡点,净现率,内部收益率等。
11、项目申报单位及项目协作单位概况。
项目申报单位以及合作单位的技术力气和人员结构。
技术创新条件(创新机构与设备,试验检测条件,中试)及生产条件等。
财务基本情况,各自担当的次要工作或有关协议合同复印件。
项目次要担当人员的姓名,职称,职务,专业与特长。
12、其他需要说明的问题。
在其他条款中未能说明的状况,如:
能否涉及环境评估。
土地购置、消防评估等。
13、项目申报单位签章。
必需由项目申报单位法人代表签字,并加盖公章。
14、各地级以上市经贸局(经贸委)及当地财政部门作为项目掌管单位,担任项目的审核并盖章,省直单位的项目由所属,省资产运营公司,部份省属企业(集团)作为项目掌管单位,担任项目审核并盖章。
接受哦
6.项目需求报告要怎样写
听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。
需求分析,不只仅是拿到客户的需求,更重要的是还需进行分析,了解细节,并就细节跟客户询问,猎取最具体的材料。
客户所能供应给你的只是他们想到的功能需求,许多问题并不在他们考虑的范围之内,假如作为项目担当方没有去做分析,简洁的根据功能要求去设计、规划,最终出来的系统是很难完全符合客户的业务流程的,这时,自然需要更改,被看成了需求的更改。
其实,都是缺乏分析所一手形成的。
问题等到系统出来了才被发觉,这样的系统本身就是先天不足的了。
听棠所说到的几点,感受特殊深:
“其实问题出在开头,客户需求只是软件需求分析的一部分,虽然是比较重要的一部分,但也不要只是去记客户的需求,而是要把客户的需求进行分析”还有客户的需求本身会有冲突(这冲突是指在规律角度来讲),客户本身是意识不到的,只要在分析设计时,才会分析出这里的冲突,而这些问题,假如在期初时,软件担任人不分析,而是纯粹的“听从”客户要求去做,当暴露这些问题时,你怪客户也没用啊。
项目需求分析报告,在了解客户需求时,不要不动脑子,不要一味的点头说“IC”,其实在表面的业务里面可能包含着N多的细节,这些细节是需要你反问客户的,只要当你提的问题越多,最终猎取的需求最详细,才能让项目越顺当。
而且有许多问题,都是在你的反问中,客户也才开头思索原来没思索过的问题,客户也会找到一种合理的需求给你,有人会觉得这样了解客户需求不免太麻烦了。
至于一些在技术上会遇到问题的地方,也要告知客户,别以为到时候再说,客户是不关怀你的技术细节的,但你假如给他解释的话,他也会试着理解的。
客户的需求本身是无休止,由于他们本身也在变,但当你期初的分析合理,后面的变动也将在规律上变动,信任代价已经不会那么大了。
这其实也体现了系统的扩展性。
需求分析,是一个项目提出方和担当方相互沟通的过程,一方是系统的使用者,一方是系统的制造者,在系统制造过程中,只要双方相互协作,共同对系统进行设计才能最终达到使用的要求。
客户是业务上的熟识者,对业务流程有特别清楚的了解,但是,对于软件需求方面的描述是不了解的,他们所能供应的只是他们最终要达到的功能,但是,这其中包含的业务流程是特别简单的。
我们拿到客户需求后,应当依据功能、流程进行初步的设计,构造出业务流程图,再让客户进行评审,提出业务流程上不对的地方进行修改。
这样来回的沟通,最终才能取得较全面的需求,并削减后期的修改。
7.项目目标与任务需求分析应当怎样写
项目目标与任务需求分析=项目的目标和任务。
目标是详细可量化的,由目的而生,方案是达成目的的筹划,而任务就是方案中的每个完成点一般先有目的,再有方案,后有目标,用任务完成目标
项目目标(ProjectObjectives):
简洁地说就是实施项目所要达到的期望结果,即项目所能交付的成果或服务。
项目的实施过程实际就是一种追求预定目标的过程,因而,从肯定意义上讲,项目目标应当是被清晰定义,并且可以是最终实现的。
项目目标包括:
可测量的项目胜利标准。
项目可能有各种各样的运营,费用,进度,技术和质量目标。
项目目标可能还包括费用,进度和质量目标。
每一个项目目标都有属性,例如费用目标就有美元单位或人民币单位。
需求分析:
开发人员精确 地理解用户的要求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转换到相应的需求规格说明的过程。
基本任务:
⑴问题识别:
双方确定对问题的综合需求,这些需求包括功能需求,性能需求,环境需求,用户界面需求。
⑵分析与综合,导出软件的规律模型
⑶编写文档:
包括编写"需求规格说明书","初步用户使用手册","确认测试方案","修改完善软件开发方案"
8.项目需求分析是怎样的
项目需求分析是一个项目的开端,也是项目建设的基石。
在以往建设失败的项目中,80%是由于需求分析的不明确而形成的。
因而一个项目胜利的关键因素之一,就是对需求分析的把握程度。
在准绳上,需求阶段监理应敬重承建方的项目管理和项目分析力量;在详细的任务开展上,以不深化、不干扰承建方的自主权为主,除非在项目合作过程中发觉承建方的项目管理以及项目分析力量存在很大的差距和不足。
为了保证项目的胜利,监理方必需加强项目管理和项目分析工作,在详细的操作上可以坚持汲取、同化、贯彻的方法和手段。
其中,需求分析是一个项目的开端,也是项目建设的基石。
在以往建设失败的项目中,80%是由于需求分析的不明确而形成的。
因而一个项目胜利的关键因素之一,就是对需求分析的把握程度。
而项目的全体风险往往表现在需求分析不明确、业务流程不合理,用户不习惯或不情愿去用承建方的软件。
作为第三方的监理公司,必需提示承建方、客户方注重需求分析的重要性,采纳必要的手段和方法来进行需求调研,同时监理方也应深化详细的需求调研中去。
只要这样才能切切实实地把握用户的需求和方向,才能在将来的功能界定、开发范围上有发言权。
如何进行需求分析需求分析不象侦探推理那样需从蛛丝马迹着手,而是应当先了解宏观的问题,再了解细节的问题。
一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。
S={D1,D2,D3,…Dn}问题域Di由若干个问题(记为P)组成,每个问题对应于子系统中的一个软构件。
Di={P1,P2,P3,…Pm}问题Pj有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。
Pj={F1,F2,F3,…Fk}需求说明书应当对于那些只想了解宏观需求的领导,和需要了解细节的技术员都合适。
在写需求说明书时应当留意两个问题:
1。
最好为每个需求正文“为什么”,这样可让程序员了解需求的本质,以便选用最合适的技术来实现此需求。
2。
需求说明不行有二义性,更不能前后相冲突。
假如有二义性或前后相冲突,则要重新分析此需求。
重点监控需求分析由于项目的特别性和行业掩盖的宽阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做。
其缘由基本是由于以下状况形成的。
客户说不清晰需求有些客户对需求只要朦胧的感觉,当然说不清晰详细的需求。
例如全国各地的许多部门、机构、单位在进行应用系统以及网络建设时,客户方的办公人员大多不清晰计算机网络有什么用,更缺乏IT系统建设方面的专家和学问。
此时,用户就会要求软件系统分析人员替他们设想需求。
工程的需求存在肯定的客观性,为项目将来建设埋下了潜在的风险。
需求本身常常变动依据以往的历史阅历,随着客户方对信息化建设的熟悉和本人业务水平的提高,他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。
现实上,历史上没有一个软件的需求改动少于三次的!
所以必需接受“需求会变动”这个现实,在进行需求分析时要懂得防患于未然,尽可能地分析清晰哪些是稳定的需求,哪些是易变的需求,以便在进行系统设计时,将软件的核心建筑在稳定的需求上,同时留出变更空间。
询问监理方在需求分析的功能界定上担当一个两头、公正、公正的角色,所以也必需乐观参加到需求分析的预备中来,以便帮助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。
分析人员或客户理解有误软件系统分析人员不行能都是全才,更不行能是行业方面的专家。
客户表达的需求,不同的分析人员可能有不同的理解。
假如分析人员理解错了,可能会导致以后的开发工作劳而无功。
记得一则笑话,有个外星人间谍埋伏到地球刺探情报,它给上司写了一份报告:
“主宰地球的是汽车。
它们喝汽油,靠四个轮子滚动前进,嗓门极大,双眼在夜里能射出强光……好玩的是,车里住着一种叫作‘人’的寄生虫,这些寄生虫完全掌握了车。
”所以分析人员学问的专注性也会形成需求分析的误会和失败。
这时,询问监理公司就必需依据实际的项目需求调研方案,提示承建方加强业务了解程度和注意沟通技巧。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 需求 分析 怎么