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