公司内部需求分析培训ppt课件.ppt

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