什么是综合项目需求分析.docx
- 文档编号:24018053
- 上传时间:2023-05-23
- 格式:DOCX
- 页数:8
- 大小:41.03KB
什么是综合项目需求分析.docx
《什么是综合项目需求分析.docx》由会员分享,可在线阅读,更多相关《什么是综合项目需求分析.docx(8页珍藏版)》请在冰豆网上搜索。
什么是综合项目需求分析
什么是项目需求分析?
需求分析是指理解顾客需求,就软件功能与客户达到一致,预计软件风险和评估项目代价,最后形成开发筹划一种复杂过程。
(这个和我在微软体验到又不太同样,微软需求分析大多是市场人员和顾客协助小组人去评估顾客接受限度,这一点也可以理解,由于公司性质有主线差别)在这个过程中,顾客确是处在主导地位,需求分析工程师和项目经理要负责整顿顾客需求,为之后软件设计打下基本。
需求分析阶段结束后,规定得到:
1.SRS文档(SystemRequirementSpecification);2.DRM文档;3.AcceptancePlan.从广义上理解:
需求分析涉及需求获取、分析、规格阐明、变更、验证、管理一系列需求工程。
狭义上理解:
需求分析指需求分析、定义过程。
一、为什么要需求分析
需求分析就是分析软件顾客需求是什么.如果投入大量人力,物力,财力,时间,开发出软件却没人要,那所有投入都是徒劳.如果费了很大精力,开发一种软件,最后却不满足顾客规定,从而要重新开发过,这种返工是让人痛心疾首.(相信人们均有体会)例如,顾客需要一种forlinux软件,而你在软件开发前期忽视了软件运营环境,忘了向顾客询问这个问题,而想固然以为是开发forwindows软件,当你千辛万苦地开发完毕向顾客提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
需求分析之因此重要,就由于她具备决策性,方向性,方略性作用,她在软件开发过程中具备举足轻重地位.人们一定要对需求分析具备足够注重.在一种大型软件系统开发中,她作用要远远不不大于程序设计.
二、需求分析任务
简言之,需求分析任务就是解决"做什么"问题,就是要全面地理解顾客各项规定,并精确地表达所接受顾客需求.
三、需求分析过程
需求分析阶段工作,可以分为四个方面:
问题辨认,分析与综合,制定规格阐明,评审.
问题辨认:
就是从系统角度来理解软件,拟定对所开发系统综合规定,并提出这些需求实现条件,以及需求应当达到原则.这些需求涉及:
功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障概率),安全保密需求,顾客界面需求,资源使用需求(软件运营是所需内存,CPU等),软件成本消耗与开发进度需求,预先预计后来系统也许达到目的.
分析与综合:
逐渐细化所有软件功能,找出系统各元素间联系,接口特性和设计上限制,分析她们与否满足需求,剔除不合理某些,增长需要某些.最后,综合成系统解决方案,给出要开发系统详细逻辑模型(做什么模型).
制定规格阐明书:
即编制文档,描述需求文档称为软件需求规格阐明书.请注意,需求分析阶段成果是需求规格阐明书(好象软考曾经考过这个问题),向下一阶段提交.
评审:
对功能对的性,完整性和清晰性,以及其他需求予以评价.评审通过才可进行下一阶段工作,否则重新进行需求分析。
四、需求分析办法
需求分析办法有诸多.这里只强调原型化办法,其他办法如:
构造化办法,动态分析法等(个人以为,对初学者不必深究这些办法,事实上我也从来没用过这些办法)在此不讨论.
原型化办法是十分重要(是软考等常考知识点).原型就是软件一种初期可运营版本,它实现了目的系统某些或所有功能.
原型化办法就是尽量快地建造一种粗糙系统,这系统实现了目的系统某些或所有功能,但是这个系统也许在可靠性,界面和谐性或其她方面上存在缺陷.建造这样一种系统目是为了考察某一方面可行性,如算法可行性,技术可行性,或考察与否满足顾客需求等.如,为了考察与否满足顾客规定,可以用某些软件工具迅速建造一种原型系统,这个系统只是一种界面,然后听取顾客意见,改进这个原型.后来目的系统就在原型系统基本上开发.
原型重要有三种类型(软考考过):
摸索型,实验型,进化型.摸索型:
目是要弄清晰对目的系统规定,拟定所但愿特性,并探讨各种方案可行性.实验型:
用于大规模开发和实现前,考核方案与否适当,规格阐明与否可靠.进化型:
目不在于改进规格阐明,而是将系统建造得易于变化,在改进原型过程中,逐渐将原型进化成最后系统。
在使用原型化办法是有两种不同方略:
废弃方略,追加方略.废弃方略:
先建造一种功能简朴并且质量规定不高模型系统,针对这个系统重复进行修改,形成比较好思想,据此设计出较完整,精确,一致,可靠最后系统.系统构造完毕后,本来模型系统就被废弃不用.摸索型和实验型属于这种方略。
追加方略:
先构造一种功能简朴并且质量规定不高模型系统,作为最后系统核心,然后通过不断地扩充修改,逐渐追加新规定,发展成为最后系统。
进化型属于这种方略.
五、需求分析20条法则(本节摘自软件工程专家网)
客户与开发人员交流需要好办法。
下面建议20条法则,客户和开发人员可以通过评审如下内容并达到共识。
如果遇到分歧,将通过协商达到对各自义务互相理解,以便减少后来磨擦(如一方规定而另一方不乐意或不可以满足规定)。
1、分析人员要使用符合客户语言习惯表达
需求讨论集中于业务需求和任务,因而要使用术语。
客户应将关于术语(例如:
采价、印花商品等采购术语)教给分析人员,而客户不一定要懂得计算机行业术语。
2、分析人员要理解客户业务及目的
只有分析人员更好地理解客户业务,才干使产品更好地满足需要。
这将有助于开发人员设计出真正满足客户需要并达到盼望先进软件。
为协助开发和分析人员,客户可以考虑邀请她们观测自己工作流程。
如果是切换新系统,那么开发和分析人员应使用一下当前旧系统,有助于她们明白当前系统是如何工作,其流程状况以及可供改进之处。
3、分析人员必要编写软件需求报告
分析人员应将从客户那里获得所有信息进行整顿,以区别业务需求及规范、功能需求、质量目的、解决办法和其她信息。
通过这些分析,客户就能得到一份“需求分析报告”,此份报告使开发人员和客户之间针对要开发产品内容达到合同。
报告应以一种客户以为易于翻阅和理解方式组织编写。
客户要评审此报告,以保证报告内容精确完整地表达其需求。
一份高质量“需求分析报告”有助于开发人员开发出真正需要产品。
4、规定得到需求工作成果解释阐明
分析人员也许采用了各种图表作为文字性“需求分析报告”补充阐明,由于工作图表能很清晰地描述出系统行为某些方面,因此报告中各种图表有着极高价值;虽然它们不太难于理解,但是客户也许对此并不熟悉,因而客户可以规定分析人员解释阐明每个图表作用、符号意义和需求开发工作成果,以及如何检查图表有无错误及不一致等。
5、开发人员要尊重客户意见
如果顾客与开发人员之间不能互相理解,那关于需求讨论将会有障碍。
共同合伙能使人们“兼听则明”。
参加需求开发过程客户有权规定开发人员尊重她们并爱惜她们为项目成功所付出时间,同样,客户也应对开发人员为项目成功这一共同目的所做出努力表达尊重。
6、开发人员要对需求及产品实行提出建议和解决方案
普通客户所说“需求”已经是一种实际可行实行方案,分析人员应竭力从这些解决办法中理解真正业务需求,同步还应找出已有系统与当前业务不符之处,以保证产品不会无效或低效;在彻底弄清业务领域内事情后,分析人员就能提出相称好改进办法,有经验且有创造力分析人员还能提出增长某些顾客没有发现很有价值系统特性。
7、描述产品使用特性
客户可以规定分析人员在实现功能需求同步还注意软件易用性,由于这些易用特性或质量属性能使客户更精确、高效地完毕任务。
例如:
客户有时规定产品要“界面和谐”或“健壮”或“高效率”,但对于开发人员来讲,太主观了并无实用价值。
对的做法是,分析人员通过询问和调查理解客户所要“和谐、健壮、高效所包括详细特性,详细分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案预期利益之间做出权衡,以保证做出合理取舍。
8、容许重用已有软件组件
需求普通有一定灵活性,分析人员也许发现已有某个软件组件与客户描述需求很相符,在这种状况下,分析人员应提供某些修改需求选取以便开发人员可以减少新系统开发成本和节约时间,而不必严格按原有需求阐明开发。
因此说,如果想在产品中使用某些已有商业惯用组件,而它们并不完全适合您所需特性,这时一定限度上需求灵活性就显得极为重要了。
9、规定对变更代价提供真实可靠评估
有时,人们面临更好、也更昂贵方案时,会做出不同选取。
而这时,对需求变更影响进行评估从而对业务决策提供协助,是十分必要。
因此,客户有权利规定开发人员通过度析给出一种真实可信评估,涉及影响、成本和得失等。
开发人员不能由于不想实行变更而随意夸大评估成本。
10、获得满足客户功能和质量规定系统
每个人都但愿项目成功,但这不但规定客户要清晰地告知开发人员关于系统“做什么”所需所有信息,并且还规定开发人员能通过交流理解清晰取舍与限制,一定要明确阐明您假设和潜在盼望,否则,开发人员开发出产品很也许无法让您满意。
11、给分析人员解说您业务
分析人员要依托客户解说业务概念及术语,但客户不能指望分析人员会成为该领域专家,而只能让她们明白您问题和目的;不要盼望分析人员能把握客户业务细微潜在之处,她们也许不懂得那些对于客户来说理所固然“常识”。
12、抽出时间清晰地阐明并完善需求
客户很忙,但无论如何客户有必要抽出时间参加“头脑高峰会议”讨论,接受采访或其她获取需求活动。
有些分析人员也许先明白了您观点,而过后发现还需要您解说,这时请耐心对待某些需求和需求精化工作过程中重复,由于它是人们交流中很自然现象,何况这对软件产品成功极为重要。
13、精确而详细地阐明需求
编写一份清晰、精确需求文档是很困难。
由于解决细节问题不但烦人并且耗时,因而很容易留下模糊不清需求。
但是在开发过程中,必要解决这种模糊性和不精确性,而客户恰恰是为解决这些问题作出决定最佳人选,否则,就只得靠开发人员去对的猜测了。
在需求分析中暂时加上“待定”标志是个办法。
用该标志可指明哪些是需要进一步讨论、分析或增长信息地方,有时也也许由于某个特殊需求难以解决或没有人乐意解决它而标注上“待定”。
客户要尽量将每项需求内容都阐述清晰,以便分析人员能精确地将它们写进“软件需求报告”中去。
如果客户一时不能精确表达,普通就规定用原型技术,通过原型开发,客户可以同开发人员一起重复修改,不断完善需求定义。
14、及时作出决定
分析人员会规定客户作出某些选取和决定,这些决定涉及来自各种顾客提出解决办法或在质量特性冲突和信息精确度中选取折衷方案等。
有权作出决定客户必要积极地对待这一切,尽快做解决,做决定,由于开发人员普通只有等客户做出决定才干行动,而这种等待会延误项目进展。
15、尊重开发人员需求可行性及成本评估
所有软件功能均有其成本。
客户所但愿某些产品特性也许在技术上行不通,或者实现它要付出极高代价,而某些需求试图达到在操作环境中不也许达到性能,或试图得到某些主线得不到数据。
开发人员会对此作出负面评价,客户应当尊重她们意见。
16、划分需求优先级
绝大多数项目没有足够时间或资源实现功能性每个细节。
决定哪些特性是必要,哪些是重要,是需求开发重要某些,这只能由客户负责设定需求优先级,由于开发者不也许按照客户观点决定需求优先级;开发人员将为您拟定优先级提供关于每个需求耗费和风险信息。
在时间和资源限制下,关于所需特性能否完毕或完毕多少应尊重开发人员意见。
尽管没有人乐意看到自己所但愿需求在项目中未被实现,但毕竟是要面对现实,业务决策有时不得不根据优先级来缩小项目范畴或延长工期,或增长资源,或在质量上寻找折衷。
17、评审需求文档和原型
客户评审需求文档,是给分析人员带来反馈信息一种机会。
如果客户以为编写“需求分析报告”不够精确,就有必要尽早告知分析人员并为改进提供建议。
更好办法是先为产品开发一种原型。
这样客户就能提供更有价值反馈信息给开发人员,使她们更好地理解您需求;原型并非是一种实际应用产品,但开发人员能将其转化、扩充成功能齐全系统。
18、需求变更要及时联系
不断需求变更,会给在预定筹划内完毕质量产品带来严重不利影响。
变更是不可避免,但在开发周期中,变更越在晚期浮现,其影响越大;变更不但会导致代价极高返工,并且工期将被延误,特别是在大体构造已完毕后又需要增长新特性时。
因此,一旦客户发现需要变更需求时,请及时告知分析人员。
19、遵循开发小组解决需求变更过程
为将变更带来负面影响减少到最低限度,所有参加者必要遵循项目变更控制过程。
这规定不放弃所有提出变更,对每项规定变更进行分析、综合考虑,最后做出适当决策,以拟定应将哪些变更引入项目中。
20、尊重开发人员采用需求分析过程
软件开发中最具挑战性莫过于收集需求并拟定其对的性,分析人员采用办法有其合理性。
也许客户以为收集需求过程不太划算,但请相信花在需求开发上时间是非常有价值;如果您理解并支持分析人员为收集、编写需求文档和保证其质量所采用技术,那么整个过程将会更为顺利。
“需求确认”意味着什么:
在“需求分析报告”上签字确认,普通被以为是客户批准需求分析标志行为,然而实际操作中,客户往往把“签字”看作是毫无意义事情。
“她们要我在需求文档最后一行下面签名,于是我就签了,否则这些开发人员不开始编码。
”
这种态度将带来麻烦,譬如客户想更改需求或对产品不满时就会说:
“不错,我是在需求分析报告上签了字,但我并没有时间去读完所有内容,我是相信你们,是你们非让我签字。
”
同样问题也会发生在仅把“签字确认”看作是完毕任务分析人员身上,一旦有需求变更浮现,她便指着“需求分析报告”说:
“您已经在需求上签字了,因此这些就是咱们所开发,如果您想要别什么,您应早些告诉咱们。
”
这两种态度都是不对。
由于不也许在项目初期就理解所有需求,并且毫无疑问地需求将会浮现变更,在“需求分析报告”上签字确认是终结需求分析过程对的办法,因此咱们必要明白签字意味着什么。
对“需求分析报告”签名是建立在一种需求合同基线上,因而咱们对签名应当这样理解:
“我批准这份需求文档表述了咱们对项目软件需求理解,进一步变更可在此基线上通过项目定义变更过程来进行。
我懂得变更也许会使咱们重新协商成本、资源和项目阶段任务等事宜。
”对需求分析达到一定共识会使双方易于忍受将来摩擦,这些摩擦来源于项目改进和需求误差或市场和业务新规定等。
需求确认将迷雾拨散,显现需求真面目,给初步需求开发工作画上了双方都明确句号,并有助于形成一种持续良好客户与开发人员关系,为项目成功奠定了坚实基本。
六、点评需求分析误区
要想说什么是好需求分析,不如说什么是不好需求分析,懂得什么是不好,自然也就懂得了什么是好。
如下就是某些不好状况:
(1)创意和求实
毋庸质疑,每个人都会为自己一种新Idea而激动万分,特别是当这个Idea受到某些主线不懂得你原本要干嘛人惊赞时。
但是请注意,当你激动得意时候,你也许已经忘了你原本是在描述一种需求,而不是在策划一种创意、创造一种概念。
诸多刚开始做需求分析人员都或多或少会犯这样错误,陶醉在自己新想法和新思路中,却违背了需求原始客观性和真实性原则。
永远别忘了:
需求不是空中楼阁,是实实在在一砖一瓦。
(2)解剖快感
几乎所有搞软件人,做需求分析时候,一上来就会把顾客告诉你规定,完完整整作个解剖,切开提成几种块,再细提成几种子块,然后再条分缕析。
可是当顾客困惑看着你辛辛苦苦做出来分析成果问你:
我想作一种数据备份任务,怎么做?
这时,你会发现,需要先后打开三个窗口才干完毕这个任务。
永远别忘了:
分解是必须,但最后目是为了更好组合,而不是为了分解。
(3)角度和思维
经常听到这样抱怨:
“顾客怎么可以提出这样苛刻规定呢?
”。
细细一理解,你会发现,顾客只但是是规定把一种需要两次点击功能,改成只有一次点击。
这样会导致需要变化需求、变化编码、甚至重新测试,增长工作量。
可是,如果换个角度来想想,这个功能,开发时候只用了几次、几十次,可是顾客每天都要用几百次甚至几千次几万次,改动一下就减少了一半工作量,对她来说,这样需求难道会苛刻吗?
永远别忘了:
没有任何需求是不对,不对只是你需求分析。
试着站在顾客思维角度想想,你需求分析就会更加贴近顾客,更加合理。
软件应当是以人为本。
(4)程序员逻辑
从程序员成长为系统分析员是一种普遍轨迹,但并不是一种好程序员就必然能成为一种好系统分析员。
某些程序员固化逻辑,使得她们在做需求分析时候往往钻进了某些牛角里面。
例如说1/0逻辑(或者是说黑白逻辑),以为不是这样就是那样,没有第三种状况。
可实际状况往往是,在一定期候是这样,其他时候是那样。
又例如穷举逻辑,喜欢上来就把所有一二三也许状况列举出来,然后一种一种分别解决,每个占用三分之一时间;可是实际状况往往是,三分之一状况占了99%比例,其他两种状况一年都不会遇到一次。
实际中尚有诸多这样例子,不一一列举了。
永远别忘了:
需求分析和程序设计不尽相似,合理、可行是才是重要。
跳出程序设计圈子,站在系统角度上来看问题,你结论会截然不同。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 什么是 综合 项目 需求 分析