产品需求分析(上) – 理论流程
工学软件需求第8课软件需求分析概述课件
第8章 软件需求分析概述
1 需求分析的根本任务 建立分析模型
建模的目的 通过软件建模，帮助我们按照实际情况或按照我们
的需要的模式对系统进行可视化，提供一种详细说明系 统的结构或者行为的方法，给出一个指导系统构造的模 板。对所有做出的决定实施文档化。
24
第8章 软件需求分析概述
1 需求分析的根本任务
此种情况出现时，可能会影响需求分析人员建立全面的理 解，因此需要采用自底向上的方法进行提炼。例如将每个业务 事件中的类进行提炼，抽取出共性的部分，建立针对整个系统 的全局领域模型。
19
第8章 软件需求分析概述
1 需求分析的过程中消除需求矛盾
(3)消除矛盾
在分析过程中，显然可能会发现有些需求是相互矛盾 的、冲突的，由于是将收集的信息放在一个预先定义的 结构中发现这些矛盾的，因此对矛盾的影响范围会有直 观的了解，也能够知道它影响那些层面。寻找相应的人 员，通过进一步需求获取来消除矛盾。
20
第8章 软件需求分析概述
1 需求分析的根本任务 建立分析模型
❖ 建立分析模型 – 将复杂的系统分解成为简单的部分以及它们之间的联系， 确定本质特征 – 和用户达成对信息内容的共同理解 – 分析的活动主要包括识别、定义和结构化，它的目的是 获取某个可以转换为知识的事物的信息
❖ 创建解决方案 – 将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找 解决方案 – 创建解决方案的过程是创造性的 – 帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关系 这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案 的正确性。
7
第8章 软件需求分析概述
1 需求分析的根本任务
15
第8章 软件需求分析概述
需求分析是什么
需求分析所谓"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。
可以说，在软件工程当中的"需求分析"就是确定要计算机"做什么"，要达到什么样的效果。
可以说需求分析是做系统之前必做的。
在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
需求分析是软件工程中的一个关键过程。
在这个过程中，系统分析员和软件工程师确定顾客的需要。
只有在确定了这些需要后，他们才能够分析和寻求新系统的解决方法。
需求分析阶段的任务是确定软件系统功能。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤。
但在近十年内，越来越多的人认识到，需求分析是整个过程中最关键的一个部分。
假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件项目无法在规定的时间里完工。
需求分析是一项重要的工作，也是最困难的工作。
该阶段工作有以下特点:1.功能需求2.性能需求3.可靠性和可用性需求4.出错处理需求5.接口需求6.约束7.逆向需求8.将来可能提出的要求逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、E-R图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
修正计划根据在分析过程中获得的对系统的更深入的了解，可以比较准确地估计系统的成本和进度，修正以前定制的开发计划。
传统方法–面向过程(自上向下分解)–信息工程(数据驱动)(数据流分析结构化分析方法)–面向对象(对象驱动)步骤首先调查组织机构情况包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
需求分析(流程图+数据字典)
2 需求分析调查重点 业务流程调查（业务流程图 TFD图） 数据流程调查（数据流程图 DFD图） 数据字典（DD）
4
业务流程调查
业务或业务活动是对组织或企业的一切专业工作和 活动的总称。
业务流程图就是将业务处理过程中的每一个步骤用 一个完整的图形串起来。它描述了系统内各单位、 人员之间的业务处理过程及其之间的关系。
– 1 数据项 – 2 数据结构 – 3 数据流 – 4 处理逻辑 – 5 数据存储
7.4.1 数据项的定义
数据项又称数据元素，是数据的最小单位。 在数据字典中，数据项的描述包括：
数据流程图的逐层扩展 数据流程图分层应遵循的原则
2．检查数据流程图的正确性 3．提高数据流程图的可理解性
数据流程图的逐层扩展
最上层的数据流程图应概括地反映信息系统最主要的逻辑功 能、外部实体和数据存储，并且能让用户一看就明白这个系 统的主要功能、外部实体以及与环境的主要联系是什么。
表、库存台帐等。
2.3 数据流程图的绘制
数据流程图的绘制采取自顶向下逐层分解的办法 首先，画出顶层（第一层）数据流程图。顶层数据流程图只有
一张，说明系统总的输入、输出和处理功能。 其次，再对顶层数据流程图中的处理功能进行逐层分解，形
成多级数据流程图。 画下层的数据流图时，分解上层图中的数据处理。一般沿着输
数据流程调查：把数据在组织（或原系统）内 部的流动情况抽象地独立出来，舍去具体组织机 构、信息载体、处理工作、物资、材料等物质要 素，单从数据流动过程来考查实际业务的数据处 理模式。（概念）
数据流程图：是一种能全面地描述信息系统逻辑 模型的主要工具，它可以用少数几种符号综合地 反映出信息在系统中的流动、处理和存储情况。
第讲需求分析建模
对象
抽象（映射） 模型
系统
模型应用
系统
模型构造的过程
逻辑模型
物理模型
(本质模型、概念模型) (实施模型、技术模型)
现 描述重要的业务功 行 能，无论系统是如 系 何实施的。 统
描述现实系统是如何 在物理上实现的。
目 标
描述新系统的主要业 务功能和用户新的需
描述新系统是如何实 施的（包括技术）。
系 求，无论系统应如何
规 约
数据流图
E-R图
(DFD)
数据字典
（DD）
规 约
状态变迁图 (STD图)
控制规约
分析模型的构成元素
• 数据字典(DD)
– 模型核心，包含了所有数据对象的描述的中心库。
• E-R图(ERD)
– 表示数据对象以及相互的关系，用于数据建模。
• 数据流图(DFD)
– 指明数据在系统中移动时如何被变换; – 描述对数据流进行变换的功能; – DFD中每个功能的描述包含在加工规约(小说明)。 – 用于功能建模。
• 状态变迁图(STD)
– 指明作为外部事件的结果,系统将如何动作。用于行
数据建模
• 最常用的表示概念性数据模型的方法，是 实体联系方法（Entity-Relationship Approach）
• ER图描述现实世界中的实体，而不涉及这 些实体在系统中的实现方法。
⑴ Entities
E-R图元素
Ｄ
控制
配置
面板
系统
用户命令 和数据
配置请求
配置信息
与用户
• DFD没有提供显式的处理顺序，过程或顺 序式隐含在DFD中的，显式的推迟到系统 设计时。
人事工资管理系统的顶层DFD(概图)
产品需求文档PRD
第二阶段第二章：三大需求文档-产品需求文档PRD都可以尽管来吐槽哈也可以第一时间与我们互动答疑官方网站：粉丝群：243978361互联网产品经理终身定制服务平台第一阶段：互联网基础第一章：互联网历史及发展趋势第二章：互联网产品及产品经理第三章：互联网思维第二阶段：产品需求第一章：需求分析与管理第二章：三大需求文档第三阶段：以用户为中心的产品设计第一章：用户体验第二章：交互设计第三章：视觉设计第四阶段：Scrum敏捷项目管理第五阶段：产品运营第六阶段：产品经理实战第一章：产品经理基础实战第二章：产品经理高级实战第三章：面试实战互联网产品经理终身定制服务平台产品需求文档(Product Requirement Document，PRD),该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
互联网产品经理终身定制服务平台作用：一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的与业性。
利于开发过程中开发人员评估工作量，利于大家对各功能点跟踪，利于测试时对产品功能全覆盖。
意义：是对MRD文档的内容的技术化和指标化，贯穿产品生命周期，质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
读者：PM、RD、QA、UI、UE……重点：对产品产品功能和性能（即“产品需求”）的详细专业说明互联网产品经理终身定制服务平台不同互联网公司使用不同的文档类型，如阿里巴巴、腾讯、雅虎等，使用的是FRD(MRD+PRD)文档MRD侧重客户、用户、市场需求的定义，通过原型的形式加以形象化，PRD侧重产品流程、功能和性能的说明，PRD文档是对MRD文档进行指标化和技术化的。
举例：•MRD：给客人烧一桌荤素搭配、富有营养的菜；（做一款什么样的产品更具有市场？）•PRD：原料、操作步骤、数量、营养成分等；(产品具体如何做？)互联网产品经理终身定制服务平台•写给谁？–写给自己——P1•思维和思想的沉淀•沟通、协调、规划的备案和验证–写给战友——P2•开发、测试、UED、运营、财务、市场等团队战友–写给老大——P3•主管、高层。
需求分析入门
需求
几个概念：
需求规格说明书 系统用例图 系统用例文档
需求
系统用例图
需求
系统用例图
Actor系统执行者 ：定义了系统的边界。
系统外，必须和系统有交互。 责任的边界，而非物理的边界。 直接与系统交互。 有意义的交互。 可能的任何事物：时间、人、外部系统… 有意义的目标 价值结果由系统生成 执行者可见，可感知
需求 – 例子：UC-存款-ATM
分支流程
卡不可识别：
系统退卡并提示错误信息。 系统提示将可能产生跨行交易费，并继续。 系统提示错误 用户重新录入 …
非本银行卡：
用户录入密码错误：
系统发现假钞：
后置条件
系统已成功保存存款金额，并退卡。
商业规则
总结
愿景：问题->机会->目标->愿景->涉众 分析：涉众利益->业务建模->严肃的创造力 需求：找Actor->找Use Case ->细化用例-> 写用例文档 分析 设计
需求
前置条件 前置条件是基本流程和分支流程都必须满足的条件 前置条件必须是用例开始执行前的条件，而不是用例开始 后第一步需要检查的条件 触发事件
包括用户执行用例的入口，如菜单、链接、URL 如果是系统执行的用例，需要说明触发的事件 描述本UC的期望的主成功场景 清晰准确的描述分支流程进入的条件 根据满足的条件按步骤描述交互流程 业务上的出错信息也属于分支流程 经常谈及的替换流程建议也是写在这里
需求分析流程轿车
1.1.需求分析✧引导就座–客户经过接待，并适当问候后，则引导入座让其放松压力；–探询客户对饮品的选择，用推车放置饮料并以托盘方式呈送（提供2种以上饮料）；–饮品应置于客户右侧约20厘米处，茶水杯上的长安标识需面向客户可视方向；–就客户从事的行业、当日天气、社会时事议题等诸多方面话题进行寒暄，引导客户的关注点，营造轻松氛围，逐步引导进入购车方面话题。
✧探询重点–通过轻松谈话来了解客户性格特点和兴趣爱好，并找到共同话题；–多用开放式问题询问客户；探询技巧（参考话术）1)用车经历?话术：①先生您以前都用过哪些车呢？②您对XX车感觉怎么样？哪些方面是您觉得比较好的？哪些是您觉得不太满意的？分析：客户如果用过其它车，问客户对车的感觉可探询客户的需求，因为他觉得好的东西他希望能保持，那就是客户的需求。
2)有没有了解过长安汽车的车型?话术：先生，您应该了解过长安汽车吧，您喜欢长安汽车的哪个特色？分析：探询客户是否己看过?并试探客户对产品配置的关注重点?3)参考车型?话术：买车是大事，您现在都在参考哪些车型呢。
毕竟我是搞这行的，我提供您一些购车建议。
分析：了解客户的参考车型后，要挖掘客户为什么针对那些车在参考比较。
4)购车原因、用途?话术：先生您真厉害，年纪轻轻就有能力买车了。
您买车是家用还是有其它用途？分析：在获取这些信息前，记得用赞美来铺垫。
5)预算?话术：先生能请教一下您要选择什么价位的车吗？分析：让客户自己选择，一定要让客户有自己做决定的感觉。
6)对新车的要求?话术：①您也有这么长的驾龄了，对于新车您有些什么要求吗？②车是耐用消费品，将来要长时间的使用，不知道您对您的座驾会有哪些要求。
分析：客户一般都是带着基本的期望来看车的，了解客户对新车最基本的要求能做到心中有数，在产品介绍环节更有针对性。
7)购车时间、使用地点?话术：先生，您什么时候要用到车呢？分析：让客户觉得你在关心他，而且可以有效的刺探客户的诚意。
需求分析的原理
需求分析的原理
需求分析的原理是为了确定产品或服务的功能和特性，并确保满足用户的需求。
通过需求分析，可以将用户的需求转化为具体、明确的产品或服务要求，为后续的设计和开发提供指导。
在需求分析过程中，需要采取以下原理：
1. 明确需求：需求分析的第一步是确保对用户的需求有清晰的理解。
要与用户进行沟通，了解他们的期望、问题和希望得到满足的情况。
通过访谈、调查、问卷调查等方法，收集用户的需求，确保有准确的需求基础。
2. 分解需求：将整体需求分解为可管理和实现的小模块。
这种拆分可以使需求更具体明了，并确定每个需求的优先级和相关性。
3. 确定需求的关联性：需求之间可能存在关联性，相互之间可能会影响。
通过分析需求之间的关联性，可以确保最终产品或服务的整体逻辑和功能的完整性。
4. 提出优先级：在需求分析过程中，应根据重要性和急迫性确定需求的优先级。
这有助于决定哪些需求先实现，哪些需求可以推迟或移除。
5. 结果确认：需求分析的最终目标是合理地将用户期望转化为产品或服务的功能和特性。
因此，在需求分析过程的每个阶段，都要与用户进行确认和验证，以确保需求的准确性和有效性。
需求分析的原理可以帮助项目团队设计出符合用户需求的产品或服务。
通过合理地分析和管理需求，可以提高产品或服务的质量，减少项目的风险，并最终满足用户的期望。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
好几个朋友让我分享一下产品需求分析，我想了好久也没发现有什么可说的。
这主要是我在工作中很少把需求分析当成规范性的操作流程，通常我都是在脑海里直接判断需求，而且在绝大多数的公司里，也没有规范的需求分析标准，常常都是由诸多因素直接影响并决定了需求。
出现这样的情况，也是职业属性决定的，因为产品类的工作带有很多主观性因素。
既然要讲产品需求分析，那么就先要知道这在产品实现过程中处于哪个环节。
无论是新产品还是迭代产品，首先由想法产生需求，然后需求汇集并分析，放弃掉不需要的，暂缓不紧急的，然后整理出需要下一步执行的，最终形成产品需求文档并实施。
在汇集分析之前，需求的产生来自各个方面，由不同的人产生想法并表述反馈给产品经理，因此产生需求，主要来自公司内部(老板、其他部门或同事)、产品经理自己(策划、挖掘
通过上面的梳理，我们就清晰的认识到，产品需求分析实际上就是需求决策。
无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里的需求分析，就是决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓。