公司内部需求分析培训PPT_第1页
公司内部需求分析培训PPT_第2页
公司内部需求分析培训PPT_第3页
公司内部需求分析培训PPT_第4页
公司内部需求分析培训PPT_第5页
已阅读5页,还剩25页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、软件需求冯冯 曦曦什么是需求?软件需求的层次和分类需求的重要性需求工程简介需要,要求,由需要而产生的要求。需要需要业务干系人(项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门)想要实现的愿景和目标最终用户想要完成的任务要求要求业务干系人附加在愿景和目标上的约束最终用户为顺利完成任务提出的约束自身影响自身影响企业的生存和发展企业的产值和利润员工的发展和收入利益链冲突冲突公司的综合实力和干系人的最终目标利润同成本不断变化的需求对系统建设的影响需求虽然由客户触发,但是需要结合自身综合考虑,合理规避风险,合理开发什么是软件需求?什么是软件需求?IEEE(电气和电子工程师协会)的

2、软件工程标准词汇表(1997年)中对需求的定义1. 用户解决问题或达到目标所需的条件或权能(Capability)2. 系统或系统部件要满足合同、标准、规范或其它正式文档所需具有的条件或权能3. 一种反映上面(1)或(2)所描述的条件或权能的文档说明。需求是客观的,它只告诉我们建设人员应该实现什么目标,而不会告诉我们怎么做,我们更不能凭借一点理解、想象和臆测而主观的去设计和开发。文档相当重要!为什么?文档不只是单单做为一个需求记录,文档的核心作用是做到需求的真实记录、保存,并指导后续产品开发,保证不会偏差太大。同时起到不同部门的沟通媒介作用,也可以对后续的需求变更进行预防。但是需求文档的质量必

3、须保证,要做到真实可靠,条理清晰,层次分明。2022-5-1业务需求表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要实现这个系统,即组织希望达到的目标。使用前景和范围文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求文档。具有以下特点:直觉,凌乱,片断,模糊,无条理,甚至是自相矛盾,用户需求用户需求(user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能

4、需求和非功能需求功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。我们需要在软件需求说明书(SNS)中尽可能详细的描述整个系统的行为,也就是功能需求。非功能需求是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性,包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。业务需求用户需求功能需求和非功能需求指导转化业务需求与用户需求之间不是一对一的关系,一个业务需求可能对应多个用户需求,一个用户需求可能满足多个业务需求。一个用户需求可能会涉及一个或多个功能需求,功能需求从开发人员的角度

5、描述系统行为,一个功能需求支持一个或多个用户需求,非功能需求支持功能需求。分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求对软件的开发有着重大的指导意义,绝不可以以偏概全,错误地去揣摩用户的心思。个人认为应该以业务需求为主线,以主线挖掘用户需求,再以挖掘出的用户需求去挖掘功能需求和非功能需求。2022-5-1在一般使用中,需求按照功能性功能性(行为的),非非功能性功能性(其它所有的行为),设计约束设计约束来分类。那么需求可以分成下面这些内容:n功能需求n性能需求n环境需求n可靠性需求n安全保密要求n用户界面需求n资源使用需求n成本消耗需求n开发进度需求n预先估计以后系统可能

6、达到的目标n执行期约束2022-5-1Rational统一过程(RUP)是Rational软件公司(现在Rational公司被IBM并购)创造的软件工程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件,是一种重量级过程(也被称作厚方法学),因此特别适用于大型软件团队开发大型项目。Rational很著名的工具就是Rose,一种面向对象的统一建模语言的可视化建模工具。功能性(Functional):特性、功能、安全性;可用性(Usability):人性化因素、帮助、文档;可靠性(Reliability):故障频率、可恢复性、可预测性;性能(Performance):响应时间、吞吐量、

7、准确性、有效性、资源利用率;可支持性(Supportability):适应性、可维护性、国际化、可配置性。“FURPS+”中的“+”是指一些辅助性的和次要的因素实现(Implementation):资源限制、语言和工具、硬件等;接口(Interface);强加于外部系统接口之上的约束;操作(Operation):对其操作设置的系统管理;包装(Packaging)例如物理的包装盒;授权(Legal):许可证或其他方式。使用“FURPS+”分类方案(或其他分类方案)作为需求范围的检查列表是有效的,可以避免遗漏系统某些重要方面。其中某些需求可以统称为质量属性(quality attribute)、质

8、量需求(quality requirement)或系统的“某属性”。这些需求包括:可用性、可靠性、性能和可支持性优点:2022-5-12022-5-1用户参与不足用户需求扩展有岐义的需求镀金问题过于抽象的需求忽略了用户分类不准确的计划模拟两可的需求不必要的特性过于精简的规格说明雾里看花需求说不清客户对需求永远只有朦胧的感觉隔靴搔痒需求说不准分析人员或客户的理解有误刻舟求剑需求说不全客户的需求总是不断的变动和增加讳疾忌医需求不重视守缺抱残需求分析方法 和工具缺乏2022-5-1ESPITI(欧洲软件过程改进培训倡议)所作的一个调查,3800个被调查者认为,软件开发的主要问题、次要问题和不是问题的

9、问题如图。一半以上的人认为,软件的二个最大问题是:1、需求规格说明2、管理客户需求相对而言,编码不是问题1、需求规格说明 4、软件和测试2、管理客户需求 5、项目管理3、建档6、编码问题的重要性依次降低2022-5-1修复的相对成本修复的相对成本需求阶段需求阶段0.1-0.20.1-0.2设计设计0.50.5维护维护2020验收测试验收测试5 5单元测试单元测试2 2编码编码1 1“ 需求开发需求开发可能是软件开发中最困难、最关键、最易出错以可能是软件开发中最困难、最关键、最易出错以及最需要沟通的方面及最需要沟通的方面 ”2022-5-12022-5-12022-5-1需求是产品的根源,需求工

10、作的优劣对产品影响最大。就像一条河流,如果源头被污染了,那么整条河流也就被污染了。(1)不含糊性:如果每一个需求只有唯一的一种解释,那它是不含糊的;(2)完整性:如果需求包括了功能、性能、时间响应要求、限制、接口等属性,不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求,是完整的;(3)可检验性:存在有限的、经济与技术都是可行的检验方法和程序,对需求的实现与否,进行检验,使得用户和组织通过该检验,确认需求被按照需求规格说明实现;(4)一致性:需求作为一种要求是一致的,不存在系统内相互冲突的需求要求;(5)可跟踪性:需求可追踪;(6)可使用性:可为产品的各阶段,特别是维护阶段,提供充分有

11、用的信息。2022-5-1需求工程是系统工程和软件工程的一个交叉分支,涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。提供用户在现实世界的需要和软件能力之间的桥梁。2022-5-1需求工程需求工程2022-5-12022-5-12022-5-1需求获取是需求工程的第一个环节,也是最重要并且比较困难的环节。它需要需求人员要有相关领域知识,并且擅长同客户交流和沟通,有比较敏锐的嗅觉,善于同客户凌乱的信息中采集到有用的部分,同时要有很好的大局观,把握好需求的层次,不遗漏也不过于陷入繁琐的需求无底洞。需求获取常见

12、问题需求获取常见问题缺乏领域知识,应用领域的问题常常是模糊的、不精确的;存在默认的知识,如难以描述的常识问题;存在多个知识源,且多知识源之间可能有冲突;客户可能的偏见,如不能提供或不想告知你所需要了解的事情。2022-5-1研究应用背景,建立初始的知识框架;根据获取的需要,采用必要的获取方法和技巧;先行确定获取的内容和主题,设定场景;分析用户的高(深)层目标,理解用户的意图;进行涉众分析,针对涉众的特点开展工作。2022-5-1n 在项目的范围之内n 所有为用户创建解决系统必须的信息 需求 通常体现为用户的观点、看法、目标或者问题 问题域特性 需要注意的是不要忽略系统的环境和约束n 获取的内容

13、不是一次得到的,而是逐步积累的2022-5-1n 涉众p 用户p 客户p 领域专家p 市场人员、销售人员等其他 用户替代源n 相关产品p原有系统p 竞争产品p 协作产品(和解系统存在p 接口的其他软件系统)n 硬数据p 登记表格、单据、报表等p 定量文档p 备忘录、日志等定性文档n 重要文档p 原有系统的规格说明p 竞争产品的规格说明p 协作产品的规格说明p 客户的需求文档(委托开p 发的规格说明、招标书)相关技术标准和法规n 相关法律、法规及规章制度p 行业规范、行业标准2022-5-12022-5-1n 传统方法传统方法 问卷调查、面谈、硬数据分析、文档检查、需求剥离等n 集体获取方法集体

14、获取方法 头脑风暴(Brainstorming)、专题讨论会(Workshop)、JAD (应用程序开发联系会议)等n 原型化方法原型化方法n 知识工程方法知识工程方法 任务分析(Task Analysis)、协议分析(Protocol Analysis)场记分析法、卡片分类法、分类表格技术和基于模型的知识获取n 基于上下文的方法基于上下文的方法 观察、民族志(Ethnography)和话语分析(ConversationAnalysis)2022-5-1n 务必让所有的涉众都表达出自己的意见。n 不要以抽象和模糊的需求作为结束。对抽象和模糊的需求,要进行细化,让真正的需求显露出来。n 使用多种方法表达需求信息。利用不同的分析技术为相同的需求进行建模,通过分析不同的关注点,考察需求是否完整。n 注意检查边界值和布尔逻辑。2022-5-1n 用户想不出更多的用例;n 用户想出的新用例都是导出用例(通过其他用例的结合可以推导出该用例);n 用户只是在重复已经讨论过的问题;n 新提出的特性、需求等都在项目范围之外;n 新提出的需求优先级都很低;n

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论