公司内部需求分析培训PPT

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2014/8/22,#,软件需求,冯 曦,什么是需求？,软件,需求的层次和分类,需求的重要性,需求工程简介,字面的含义,需要，要求，由需要而产生的要求。,需要,业务干系人,(,项目投资人、购买产品的客户、,实际用户的管理者、市场营销部门或产品策划部门,),想要实现的愿景和目标,最终,用户想要完成的任务,要求,业务干系人附加在愿景和目标上的约束,最终用户,为顺利完成任务提出,的约束,自身影响,企业的生存和发展,企业的产值和利润,员工的发展和收入,利益链,冲突,公司的综合实力和干系人的最终目标,利润同成本,不断变化的需求对系统建设的影响,需求虽然由,客户,触发,但是,需要结合,自身综合考虑,合理规避风险,合理开发,什么是软件需求？,IEEE,（电气和电子工程师协会）的软件工程标准词汇表（,1997,年）中对需求的定义,1.,用户解决问题或达到目标所需的条件或权能,(Capability),2.,系统或系统部件要满足合同、标准、规范或其它正式文档所需具有的条件或权能,3.,一种反映上面,(1),或,(2),所描述的条件或权能的文档说明。,需求是客观的，它,只,告诉我们建设人员应该实现什么目标，而不会告诉我们怎么做，我们更不能凭借一点理解、想象和臆测而主观的去设计和开发。,文档相当重要！为什么？文档不只是单单做为,一,个需求记录，,文档的核心作用是,做到需求的真实记录、保存，并,指导后续产品,开发，,保证不会偏差太大,。同时起,到不同部门的沟通,媒介作用，,也可以对后续的需求变更进行预防,。但是需求文档的质量必须保证，要做到真实可靠，条理清晰，层次分明。,2024/9/20,软件需求的层次,业务需求,表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么,要实现这个系统，,即组织希望达到的目标。使用前景和,范围文档,来记录业务需求，这份文档有时也被称作项目轮廓图或市场,需求文档。具有,以下特点：直觉，凌乱，片断，模糊，无条理，甚至是自相矛盾，,用户需求,用户需求（,user requirement,）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件,响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。,功能需求和非功能需求,功能需求（,functional requirement,）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。我们需要在软件需求说明书（,SNS),中尽可能详细的描述整个系统的行为，也就是功能需求。,非功能需求,是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。,业务需求,用户需求,功能需求和非功能需求,指导,转化,业务需求与用户需求之间不是一对一的关系，一个业务需求可能对应多个用户需求，一个用户需求可能满足多个业务需求,。一个用户需求可能会涉及一个或多个功能需求，功能需求从开发人员的角度描述系统行为，一个功能需求支持一个或多个用户需求，非功能需求支持功能需求。,分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求对软件的开发有着重大的指导意义，绝不可以以偏概全，错误地去揣摩用户的,心思。个人认为应该以业务需求为主线，以主线挖掘用户需求，再以挖掘出的用户需求去挖掘功能需求和非功能需求。,2024/9/20,软件需求的,分类,在一般使用中，需求按照,功能性,（行为的,），,非,功能性,（其它所有的行为,），,设计约束,来,分类,。那么需求可以分成下面这些内容：,功能需求,性能需求,环境需求,可靠性需求,安全保密要求,用户界面需求,资源使用需求,成本消耗需求,开发进度需求,预先估计以后系统可能达到的,目标,执行,期约束,2024/9/20,在统一过程（,UP,）中，需求按照“,FURPS+,”模型进行分类。,Rational,统一过程,(RUP),是,Rational,软件公司（现在,Rational,公司被,IBM,并购）创造的,软件工程方法,。,RUP,描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目,。,Rational,很著名的工具就是,Rose,，一种面向对象的统一建模语言的可视化建模工具。,功能性,（,Functional,）：特性、功能、安全性；,可用性（,Usability,）：人性化因素、帮助、文档；,可靠性（,Reliability,）：故障频率、可恢复性、可预测性；,性能（,Performance,）：响应时间、吞吐量、准确性、有效性、资源利用率；,可支持性（,Supportability,）：适应性、可维护性、国际化、可配置性。,“FURPS+”,中的“,+,”是指一些辅助性的和次要的,因素,实现,（,Implementation,）：资源限制、语言和工具、硬件等；,接口（,Interface,）；强加于外部系统接口之上的约束；,操作（,Operation,）：对其操作设置的系统管理；,包装（,Packaging,）例如物理的包装盒；,授权（,Legal,）：许可证或其他方式。,使用“,FURPS+”,分类方案（或其他分类方案）作为需求范围的检查列表是有效的，可以避免遗漏系统某些重要方面。,其中某些需求可以统称为质量属性（,quality attribute,）、质量需求（,quality requirement,）或系统的“某属性”。这些需求包括：可用性、可靠性、性能和可支持性,优点：,2024/9/20,需求很难,2024/9/20,糟糕的需求,用户参与不足,用户需求扩展,有岐义的需求,镀金问题,过于抽象的需求,忽略了用户分类,不准确的计划,模拟两可的,需求,不必要的特性,过于精简的,规格说明,需求的不确定性,雾里看花,需求说不清,客户对需求永远只有朦胧的感觉,隔靴搔痒,需求说不准,分析人员或客户的理解有误,刻舟求剑,需求说不全,客户的需求总是不断的变动和增加,讳疾忌医,需求不重视,守缺抱残,需求分析方法,和工具缺乏,2024/9/20,软件开发中的问题分类,ESPITI(,欧洲软件过程改进培训倡议）所作的一个调查，,3800,个被调查者认为，软件开发的主要问题、次要问题和不是问题的问题如图。,一半以上的人认为，软件的二个最大问题是：,1,、需求规格说明,2,、管理客户需求,相对而言，编码不是问题,1,、需求规格说明,4,、软件和测试,2,、管理客户需求,5,、项目管理,3,、建档,6,、编码,问题的重要性依次降低,2024/9/20,修复的相对成本,需求阶段,0.1-0.2,设计,0.5,维护,20,验收测试,5,单元测试,2,编码,1,需求错误的代价,“,需求开发,可能是软件开发中最困难、最关键、最易出错以及最需要沟通的方面,”,2024/9/20,2024/9/20,2024/9/20,良好的需求,需求,是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,。,（,1,）不含糊性：如果每一个需求只有唯一的一种解释，那它是不含糊的；,（,2,）完整性：如果需求包括了功能、性能、时间响应要求、限制、接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求，是完整的；,（,3,）可检验性：存在有限的、经济与技术都是可行的检验方法和程序，对需求的实现与否，进行检验，使得用户和组织通过该检验，确认需求被按照需求规格说明实现；,（,4,）一致性：需求作为一种要求是一致的，不存在系统内相互冲突的需求要求；,（,5,）可跟踪性：需求可追踪；,（,6,）可使用性：可为产品的各阶段，特别是维护阶段，提供充分有用的信息。,需求很重要,需求要怎么做？,引入需求工程,科学开发，合理管理,2024/9/20,什么是需求工程,需求工程是系统工程和软件工程的一个交叉分支,，涉及,到软件系统的,目标,、软件系统提供的,服务,、软件,系统的,约束,和软件系统运行的,环境,。它还,涉及,这些因素和系统的精确规格说明以及系统,进化之间,的关系。提供,用户在现实世界的需要,和,软件,能力,之间的,桥梁,。,2024/9/20,需求工程,=,需求开发,+,需求管理,需求工程,2024/9/20,需求工程基本活动示意图,2024/9/20,需求工程与系统工程的关联,2024/9/20,需求获取,需求获取是需求工程的第一个环节，也是最重要并且比较困难的环节。它需要需求人员要有相关领域知识，并且擅长同客户交流和沟通，有比较敏锐的嗅觉，善于同客户凌乱的信息中采集到有用的部分，同时要有很好的大局观，把握好需求的层次，不遗漏也不过于陷入繁琐的需求无底洞。,需求获取常见问题,缺乏领域知识,应用领域的问题常常是模糊的,、不,精确的；,存在默认的知识,如难以描述的常识问题；,存在多个知识源,且多知识源之间可能有冲突；,客户可能的偏见，如不能提供或不想告知你,所需要,了解的事情。,2024/9/20,需求获取子活动,研究应用背景，建立初始的知识框架；,根据获取的需要，采用必要的获取方法和技巧；,先行确定获取的内容和主题，设定场景；,分析用户的高（深）层目标，理解用户的意图；,进行涉众分析，针对涉众的特点开展工作。,2024/9/20,需求获取内容特点,在项目的范围之内,所有为用户创建解决系统必须的信息, 需求,通常体现为用户的观点、看法、目标或者问题, 问题域特性,需要注意的是不要忽略系统的环境和约束,获取的内容不是一次得到的，而是逐步积累的,2024/9/20,需求获取来源,涉众, 用户, 客户, 领域专家, 市场人员、销售人员等,其他,用户,替代源,相关产品,原有,系统, 竞争产品, 协作产品（和解系统存在,接口,的其他软件系统）,硬数据, 登记表格、单据、报表等,定量文档, 备忘录、日志等定性文档,重要文档, 原有系统的规格说明, 竞争产品的规格说明, 协作产品的规格说明, 客户的需求文档（委托开,发的规格说明、招标书）,相关技术标准和法规, 相关法律、法规及,规章制度, 行业规范、行业标准,2024/9/20,需求获取的活动过程,2024/9/20,需求获取技术,传统方法, 问卷调查、面谈、硬数据分析、文档检查、需求剥离等,集体获取方法, 头脑风暴（,Brainstorming,）、专题讨论会（,Workshop,）、,JAD,（应用程序开发联系会议）等,原型化方法,知识工程方法, 任务分析（,Task Analysis,）、协议分析（,Protocol Analysis,）,场记分析法、卡片分类法、分类表格技术和基于模型的知,识获取,基于上下文的方法, 观察、民族志（,Ethnography,）和话语分析（,Conversation,Analysis,）,2024/9/20,防止需求遗漏,务必让所有的涉众都表达出自己的意见。,不要以抽象和模糊的需求作为结束。对抽象,和模糊,的需求，要进行细化，让真正的需求,显露出来,。,使用多种方法表达需求信息。利用不同的,分析技术,为相同的需求进行建模，通过分析不同,的关注,点，考察需求是否完整。,注意检查边界值和布尔逻辑。,2024/9/20,结束获取活动的判断条件,用户想不出更多的用例；,用户想出的新用例都是导出用例（通过,其他用例,的结合可以推导出该用例）；,用户只是在重复已经讨论过的问题；,新提出的特性、需求等都在项目范围之外；,新提出的需求优先级都很低；,用户提出的新功能都属于后继版本，而非,当前,版本,2024/9/20,2024/9/20,获取结果,肯定会产生获取笔录（,Elicitation Notes,）, 用户需求、问题域知识和约束, 可能具有组织差、冗余、遗漏、自相矛盾等,诸多问题, 可以包括文字记录、录音、摄像等各种形式,可能会产生两份定义明确的正式文档, 项目前景和范围文档, 用例文档,2024/9/20,问题：,结合自身的精力谈谈如何有效的采集客户需求？,你的经历中客户的需求具有什么特点？,谈谈目前项目中需求的影响？,谢谢您的支持！,