需求工程论文校园网站.docx
- 文档编号:4763280
- 上传时间:2022-12-08
- 格式:DOCX
- 页数:6
- 大小:20.59KB
需求工程论文校园网站.docx
《需求工程论文校园网站.docx》由会员分享,可在线阅读,更多相关《需求工程论文校园网站.docx(6页珍藏版)》请在冰豆网上搜索。
需求工程论文校园网站
需求工程论文
软工1003班
U201017976
程志
需求风险分析
软工1003u201017976程志
一、中文摘要:
在软件项目的开发过程中,项目风险几乎无处不在。
如何有效地识别、控制和管理风险,对项目的 成功起着至关重要的影响。
本文在结合自己多年从事软件项目开发工作的基础上,针对需求分析引起的项目风险进行探讨总结,整理出其预防措施,期望为以后软件项目进行风险预防、控制等提供参考
二、英文摘要:
Combiningmanyyearsoftheexperienceandunderstandinginsoftwarerequirementsanalysisaimingattheexistingproblemsofrequirementsanalysisinsoftwarecompanies,someideasandmethodswithreferencevalueforreducingtheriskofsoftwarerequirementanalysisareproposed.
三、正文:
1、需求分析的基本内容:
需求分析就是对需求方或用户方进行系统的调查,在完全弄清楚用户对新系统的要求后,使用统一的、规范的图表和书面语言表达出来。
需求分析是软件定义时期的最后一个阶段,他的任务是准确的回答“系统是做什么的?
”这个问题。
需求分析的结果是系统开发的基础,关系到工程的失败成功与否,以及软件产品的质量。
因此软件需求分析在软件开发过程中起到了至关重要的作用,必须使用行之有效的方法对需求分析过程进行监督与审核。
2、需求风险的表现:
在应用软件开发过程中,由于软件需求本身的隐含性、用户与开发者之间的沟通障碍,以及需求随着时间、用户的变化而变更等原因,可能使需求分析偏离实际需求而最终导致软件开发的失败,这种可能性称为需求风险。
需求分析是软件开发过程中最初始、最基础的工作,也是最重要的工作之一,其成败将直接并最终决定软件开发的成败,并且呈倍增效应。
因此,需求分析工作往往面临着一些潜在的风险。
而这些风险主要表现在以下这些方面:
(1)用户不能正确表达自身的需求。
在实际开发过程中,常常碰到用户对自己真正的需求并不是十分明确的情况,他们认为计算机是万能的,只要简单的说说自己想干什么就是把需求说明白了,而对业务的规则、工作流程却不愿多谈。
这种情况往往会增加需求分析工作难度,分析人员需要花费更多的时间和精力与用户交流,搞清用户的真实需求。
(2)业务人员配合力度不够。
有的用户日常工作繁忙,他们不愿意付出更多的时间和精力向分析人员讲解业务,这样会加大分析人员的工作难度和工作量,也可能导致因业务需求不足而使系统无法使用。
(3)用户需求的不断变更。
由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因,需求在项目的整个生命周期都可能发生变化,因此,软件开发的过程实际上是同变化做斗争的过程,需 求变化是每个开发人员、项目管理人员都会遇到的问题,也是最头痛的问题,一旦发生了需求变化,就不得不修改设计、重写代码、修改测试用例、调整项目计划等等。
(4)需求的完整程度。
需求如何做到没有遗漏?
这是一个大问题,大的系统要想穷举需求几乎是不可能的,即使小的系统,新的需求也总会不时地冒出来。
一个系统很难确定明确的范围并把所有需求一 次性提出来,这会导致开发人员在项目进展中去不断完善需求,造成返工的可能性很大,会给开发人员带来挫折感,降低他们完成项目的信心。
(5)需求的细化程度。
虽然国家标准有需求说明的编写规范,但具体到某一个需求上,很难给出一个具体的指标,并没有定论。
需求越细,周期越长,可能的变化越多,对设计的限制越严格,对需求的共 性提取要求也越高,相反,需求越粗,开发人员在技术设计时不清楚的地方就越多,影响技术设计。
(6)需求描述的多义性。
需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解;另一方面是指同一渎者能用不同的方式来解释某个需求说明。
多义性会使用户和开发人员等项目参与者产生不同的期望,也会使开发、测试人员为不同的理解而浪费时间,带来不可避免的后果便是返工重做。
(7)忽略了用户的特点分析。
分析人员往往容易忽略系统用户的特点,系统是由不同的人使用其不同的特性,使用频繁程度有所差异,使用者受教育程度和经验水平不尽相同。
如果忽略这些的话,将会导致有的用户对产品感到失望。
(8)需求开发的时间保障。
为了确保需求的正确性和完整性,项目负责人往往坚持要在需求阶段花费较多的时间,但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑,需求开发人员也会被需求的复杂和善变折腾得筋疲力尽,他们也希望尽快结束需求阶段。
3、需求风险控制:
很多项目在确定需求时都面临着一些不确定性和混乱。
当在项目早期容忍了这些不确定性,并且在项目进展过程当中得不到解决,这些问题就会对项目的成功造成很大威胁。
如果不控制与需求相关的风险因素,那么就很有可能产生错误的产品或者与用户期望不符的结果。
下面按需求工程中获取、分析、编写规格说明、验证和管理等阶段进行分析,推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。
3.1、需求获取:
(1)明确产品范围。
项目成员要尽快对产品功能达成一个清晰的共识,在项目早期写一份项目视图与范围将业务需求涵盖在内,并将其作为新的需求及修改需求的指导。
(2)确定需求分析的时间。
一般需求开发工作应占全部工作量的15%。
分析人员在分析过程中应记录实际需求开发的工作量,以便改进将来项目的工作计划。
(3)需求规格说明的完整性和正确性。
为确保需求是客户真正需要的,要以用户的任务为中心,使用实例技术获取需求。
根据不同的使用情景编写需求测试用例,建立原型,使需求对用户来说更加直观,同时获取用户的反馈信息。
(4)明确非功能性需求。
需求分析人员在分析过程中常注重产品的功能性要求,而容易忽略产品的非功能性的需求。
因此应注意产品性能、使用性、完整性、可靠性等质量特性,并编写非功能需求文档和验收标准。
(5)避免需求二义性。
如果不同的用户对产品有不同的意见,那最后必将使有些用户会不满意。
因此应确定出主要的用户,并采用产品代表的方法来确保用户代表的积极参与,确保在需求决定权上有正确的人选。
(6)尽可能挖掘用户隐含的期望要求。
未加说明的需求客户可能会有一些隐含的期望要求,要尽量识别并记录这些假设。
在分析过程中应提出大量的问题来提示客户以充分表达他们的想法、主意和应关注的一切。
(7)产品升级的需求。
对已有产品进行升级或重做的项目中,需求分析人员有时很有可能将已有的产品作为需求说明的来源,通过现有产品的逆向工程来获取需求。
但是,逆向工程对收集需求是一种既不充分也不完整的方法。
可能导致新系统会有一些与现有系统同样的缺陷。
因此通过逆向工程中收集的需求编写的文档,必须通过用户评审来确保其正确性。
(8)给出期望的解决办法。
在某些业务领域中,用户推荐的解决方法往往掩盖了用户的实际需求,导致业务处理的低效。
因此分析人员应尽力从客户叙说的解决方法中提炼出其本质核心。
(9)建立良好的沟通渠道。
项目建设之初就要和项目各干系方约定好沟通的渠道和方式,项目建设过程中多和项目各干系方交流和沟通,注意培养和锻炼自身的沟通技巧。
3.2、需求分析:
(1)划分需求优先级。
划分出每项需求、特性或使用实例的优先级并安排在特定的产品版本或实现步骤中。
评估每项新需求的优先级并与已有的工作主体相对比以做出相应的决策。
(2)特性分析。
对每项需求进行可行性分析以确定是否能按计划实现,运用项目状态跟踪的办法来管理那些落后于计划安排的需求,尽早采取措施纠正。
(3)对于不熟悉的技术、方法、语言、工具或硬件平台,要明确那些高风险的需求并留出一段充裕时间从错误中学习、实验及测试原型。
3.3、领域专家全程参加:
领域专家由于既有丰富的行业知识"又有深厚的开发功底"是联系用户和开发者的最佳桥梁&其全程参与"可以保证需求及变更始终处于控制之中"是降低需求风险的最有效手段之一。
3.4、采用迭代开发的方法:
由于需求变更是客观的,永恒的"所以传统的瀑布法已不能满足这种需要。
快速原型法实际上是一种迭代方法"其模型在功能上等价于最终产品的一个子集"根据客户的需要开发出一个最初的原型"一个可以演示的产品"以在很短的时间内解决用户最迫切的需要。
完成这个产品只是实现部分最重要的功能"一步一步地迭代"最终达到用户的需求目标。
因此"在每一次开发时"留有二次开发接口"使得需求发生变更时"可以通过二次开发来实现。
3.5、实施需求变更管理:
(1.建立需求基线。
需求基线是需求变更的依据。
在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。
此后每次变更并经过评审后,都要重新确定新的需求基线。
(2.制订简单、有效的变更控制流程,并形成文档。
在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。
(3.成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。
CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。
(4.需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。
(5.需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
(6.妥善保存变更产生的相关文档。
**除以上方法外,需求分析人员还可采用如下措施管理软件需求变更:
A.人员之间相互协作
B.人员之间充分交流
C.安排专职人员管理需求变更
D.采用合同约束
E.区别对待开发过程中的各种情况
F.采用适当的开发模型
H.让用户参与需求评审
4、总结:
在应用软件项目开发过程中!
需求分析是最初始%最基础的!
然而却是最重要的工作之一,其成功与否直接影响了软件开发的成败"由于需求的隐含性,以及需求的永恒变更等原因会导致需求难以凝固!
需求风险时时存在"需求分析实质上是一种需求工程,包括需求开发和需求管理两部分,前者发现需求,后者使需求变更处于掌控之中"科学的需求分析应使需求明确、完整、一致、可测试、可跟踪、可修改,这就需要采取相应的方法和手段来实现,以此减少软件开发过程之中的风险。
参考文献:
1、DeanLeffingwell,DonWidrig.软件需求管理统一方法【M】.北京;机械工业出版社,2002-9-11
2、李师贤、张骆玲,需求分析常见问题及对策研究【J】.系统工程与电子技术
3、RobertC.Martin著.邓辉译,敏捷软件开发原则、模式与实践【M】清华大学出版社,2003
4、《软件需求》,KarlE.Wiegers著,陆丽娜王忠民王志敏译,机械工业出版社,2000。
5、《统一软件开发过程》,IvarJacobson,JamesRumbaugh,GradyBooch著,周伯生译,机械工业出版社,2002年1月
需求工程课程实践感想:
通过这次的实践,我了解到自己对于软件的认识还不足,以前以为拿到任务就可以开始写代码,对于文档这一块是可有可无,但是现在我认识到,这种做法只是软件行业当中的“手工作坊”,而对于大型项目的开发,需求的准确定义对于软件是否成功起着举足轻重的作用。
另一方面,需求工程是一门并不简单的科目,在工程当中,需求并不能十分准确的定义,有时候会出现很多的漏洞,而且有些问题是不能仅仅靠需求工程师的来解决的,它需要各个环节的人员集体出力,甚至连提出需求的客户也要参与进来,一份成功的需求定义,必定是集结了众人的心血。
最后,在这次的实践过程当中,两个队员之间的配合也是很重要的,一个人对于资料的收集很可能会出现很大的欠缺,而不能很成功的完成实践当中的任务。
论文的撰写也很好的考验了一个人对于资料的收集,以及很好的考察了一个人对于需求工程的了解,所以这次的实践,对于我们来说是一次很好的锻炼!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 工程 论文 校园 网站