软件需求开发存在问题及对策.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件需求开发存在问题及对策

软件需求开发存在问题及对策   软件开发包含需求、设计、编码和测试等4个阶段,其中需求是最关键的一个输入。据统计,不成功的项目中有30%~40%的问题是由需求造成的。大量研究表明,需求阶段发现和纠正错误的代价是软件开发各阶段中成本最低的。   如何正确地获取用户的需求,围绕其进行管理,以便最终交付给用户符合其期望的产品是需求工程的任务。需求工程的研究产生了如CMM(能力成熟度模型)、UML(统一建模语言)、RUP(Rational统一建模过程)、CASE(用例)等管理方法和开发工具,软件思想家温伯格(GeraldM.Weinberg)指出,CMM只是一种标准,UML也只是一种记录需求的工具,而不是捕获需求的方法,需求的管理主要还是靠经验。准确而有效获取用户需求、精确表述用户需求并得到用户认可,是软件项目开发成功的最重要的因素之一。      一、什么是需求?      1997年IEEE软件工程标准词汇表对软件需求的定义为:用户解决问题或达到目标所需的条件或能力。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。需求分为需求开发和需求管理,而需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。如何帮助用户提出准确的需求、理解和分析用户环境是需求获取的过程。为问题涉及的信息、功能及行为建立模型并将用户需求精确化、完全化是需求分析的过程,最终形成需求规格说明书是编写规格说明书的过程,将需求说明书交付用户并得到用户认可是需求验证的过程。需求获取、分析、编写需求规格说明和需求验证并不遵循线性的顺序,这些活动是相互隔开、增量和反复地进行。      二、需求开发四步骤      1.需求获取   需求获取可采取如下办法:(1)成立需求分析小组,划分任务,细化侧重点,为获取用户需求做好准备工作;(2)访谈用户获取问题,了解功能需求,还需要注意非功能需求。访谈用户前,首先要了解和划分用户的类型,针对用户的情况可以划分组别,详细描述出其个性特点及任务情况。其次,就要选择好每类的代表,对其进行访谈和调研。每次的交流都需要有记录,对于交流的结果还可以分类,以便于后续的分析活动开展。   2.需求分析   调研人员对于收集的需求信息要做进一步的分析和整理。这是一个需求分析人员消化用户资料的过程。这个过程主要通过建立模型来描述用户的需求,实际上是抽象图形化的过程。一般用图形表示系统的整体结构,用原型等方式向用户提供可视化的界面,用系统可性行分析来说明软件的效果和效率,用UML描述系统的需求及内部关系。   3.编写需求规格说明书   需求规格说明书也称为功能规格说明、需求协议或系统规格说明,它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。它是开发设计的蓝本,也是系统测试和用户文档的依据。   4.需求验证   需求验证是为了确保需求说明书准确无误、完整地表达必要的质量的一种方式。客户、分析人员、设计人员、测试人员等利益相关人员经过多次评审后的需求说明书就可作为需求管理的基线。用户和开发方对软件项目内容的描述是以需求规格说明书作为基础,它是软件验收时合同双方确认的重要依据。      三、需求开发中存在的困难以及对策      1.需求获取   问题一:用户对于自己的需求不太清楚或工作繁忙无暇理清需求。第一种情况是,他们认为计算机是万能的,对于自己的业务规则、工作流程都不愿多谈。针对这种情况,其对策是需求分析人员一定要深入用户工作场地,仔细查看用户的资料和报表,与不同层面的用户交流,且要多了解用户实际工作的场景。   还有一种情况就是业务人员配合力度不够。他们不愿意付出更多的时间向分析人员讲解业务。面对这种用户,其对策是:需求分析人员改变沟通技巧,讲清楚软件需求的重要性,抓住关键点,向其咨询,以用例和模型的方式向其演示,达到用户和分析人员互相理解。   问题二:用户与需求分析人员缺乏有效沟通,双方误解需求。软件用户与开发人员缺乏有效沟通方法,交流上存在障碍,用户与开发人员存在知识背景差异,都从自己的角度,使用自己的专业术语或语言表达方式来描述和理解问题,使得双方并不能够很好地达成共识。一般说来,用户不太容易从计算机的角度去理解自己的需求问题。从而使需求描述的不一致,不规范,多义性。   上述问题对策为,分析人员需要花更多的时间去了解系统用户的特点,多学习用户行业的专业术语,用用户看得懂的语言来表达需求的内容。其次,分析人员除了需要过硬的专业知识,还要具备较强的沟通能力。如果能在用户方找到既对生产过程了解,又懂计算机知识的行家来为开发人员与用户牵线架桥则是最好不过的事情。   问题三:用户的需求不断变更。随着客户对项目的理解越来越深刻,对过去提出

文档评论(0)

189****7685 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档