- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
项目管理软件目的需求开发与管理
项目管理软件目的需求开发与管理
项目管理软件目的需求开发与管理
项目管理——软件目的需求开发与管理
需求开发与管理是软件项目中一项十分重要的工作,据调
查显示在众多失败的软件项目中,由于需求原因致使的约占到
45%,因此,需求工作将对软件项目可否最后实现产生至关重要
的影响。诚然这样,在项目开发工作中,好多人对需求的认识还
远远不够,从自己参加或接触到的一些项目来看,小到几十万元,
大到上亿元的软件项目的需求都或多多少的存在问题,有的是开发者自己不重视原因、有的是技术原因、有的是人员组织原因、
有的是交流原因、有的是系统原因,以上各种原因都表示做好软件需求开发是一项系统工作,而不是简单的技术工作,只有系统的认识和掌握需求的基本见解、方法、手段、评估标准、风险等
有关知识,并在实践中加以应用,才能真切做好需求的开发和管理工作。
本文将经过介绍对于软件需求的基本知识和个人在实质工作中
总结的一些经验,帮助读者认识软件需求,学习需求开发的一些基本方法,防范因需求原因此致使的项目失败。
什么是软件需求和需求工程
1.1软件需求的定义
在IEEE软件工程标准词汇表(1997年)中定义软件需求为:(1)用户解决问题或达到目标所需的条件或能力。
2)系统或系统零件要知足合同、标准、规范或其余正式规定文档所需拥有的条件或能力。
3)一种反应上面(1)或(2)所描绘的条件或权能的文档说明。实平时的讲,“需求”就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。
1.2需求工程的定义
需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开
发和需求管理两个部分。需求开发是指从情况收集、分析和谈论
到编写文档、评审等一系列产生需求的活动,分为四个阶段:情
况获得、分析、拟订规格说明和评审。这四个阶段不用然是依照
线性次序的,他们的活动是相互独立和频频的。需求管理是软件
项目开发过程中控制和保持需求约定的活动,它包括:改正控制、
版本控制、需求追踪、需求状态追踪等工作。
需求分析的风险
由于需求分析的参加人员、业务模式、投资、时间等客观要素的
影响和需求自己拥有主观性和可描绘性差的特点,因此,需求分析工作经常面对着一些潜藏的风险。这些风险主要表现在:
1)用户不能够正确表达自己的需求。在实质开发过程中,经常
碰到用户对自己真切的需求其实不是十分明确的情况,他们认为计算机是全能的,只需简单的说说自己想干什么就是把需求说理解了,而对业务的规则、工作流程却不愿多谈,也讲不清楚。这种
情况经常会增添需求分析工作难度,分析人员需要开销更多的时间和精力与用户交流,帮助他们梳理思路,搞清用户的真切需求。
2)业务人员配协力度不够。有的用户平时工作忙碌,他们不
愿意付出更多的时间和精力向分析人员解说业务,这样会加大分
析人员的工作难度和工作量,也可能致使因业务需求不足而使系统无法使用。
3)用户需求的不断改正。由于需求鉴识不全、业务发生变化、需求自己错误、需求不清楚等原因,需求在项目的整个生命周期都可能发生变化,因此,我们要认识到,软件开发的过程实质上
是同变化做斗争的过程,需求变化是每个开发人员、项目管理人员都会碰到的问题,也是最头痛的问题,一旦发生了需求变化,就不得不改正设计、重写代码、改正测试用例、调整项目计划等等,需求的变化就像是万恶之源,为项目的正常的进展带来不尽的麻烦。
4)需求的完满程度。需求怎样做到没有遗漏?这是一个大问题,大的系统要想穷举需求几乎是不能能的,即便小的系统,新的需求也总会时时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来,这会致使开发人员在项目进展中去不断完满需求,先成立系统构造再达成需求说明,造成返工的可能性很大,会给开发人员带来挫折感,降低他们达成项目的信心。
5)需求的细化程度。需求终究描绘到多细,才算能够结束了?诚然国家标准有需求说明的编写规范,但详细到某一个需求上,很难给出一个详细的指标,堪称仁者见仁,智者见智,并没有定
论。需求越细,周期越长,可能的变化越多,对设计的限制越严格,对需求的共性提取要求也越高,相反,需求越粗,开发人员在技术设计时不清楚的地方就越多,影响技术设计。
6)需求描绘的多义性。需求描绘的多义性一方面是指不相同读者对需求说明产生了不相同的理解;另一方面是指同一读者能用不
同的方式来解说某个需求说明。多义性会使用户和开发人员等项目参加者产生不相同的希望,也会使开发、测试人员为不相同的理解而浪费时间,带来不能防范的结果即是返工重做。
7)忽略了用户的特点分析。分析人员经常简单忽略了系统用
户的特点,系统是由不相同的人使用其不相同的特点,使用频频程度
有所差别,使用者受教育程
文档评论(0)