一文理解所有需求分析中的基本术语

一文理解所有需求分析中的基本术语_第1张图片

需求分析对产品开发成败至关重要,正因为如此,对需求进行详细定义和描述十分重要。然而不同体系往往对需求有不同的定义,也导致需求术语混乱,本周小编结合多年需求工作经验,详解不同术语的概念与区别:

 

业务(Business)

 “业务”从内容上划分,指“核心域”。

如,餐馆系统中订单和菜品的关系属于“业务知识”,折扣的计算规则属于“业务规则”。

 

 

一文理解所有需求分析中的基本术语_第2张图片

(选填) 图片描述

“业务”从范围上的划分,指“组织级别”。

如:“业务建模”是组织级别的建模、“业务用例”是组织为其他组织提供的服务,“业务流程”是组织内各个系统之间协作的流程。

 

 

一文理解所有需求分析中的基本术语_第3张图片

(选填) 图片描述

 

 

架构(Architecture)

维基百科中这样描述“架构”:

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。

 

归纳:架构是多个系统内部共有的抽象机制。

重点1:内部,系统提供的各种功能,不属于“架构”

重点2:共有,架构是一种复用机制。它独立于单个系统,围绕它可以组装成系统的家族

如:下图表达某个领域内部各种领域概念的关系。不管将核心域概念映射到哪些非核心域上(Android还是iOS,Vue还是React)得到系统,机制都可以存在。

 

 

一文理解所有需求分析中的基本术语_第4张图片

(选填) 图片描述

 

 

 

一文理解所有需求分析中的基本术语_第5张图片

(选填) 图片描述

 

 

业务架构

业务架构有两层含义:

一、组织内部机制。“业务”以“组织”理解。

二、系统内部的核心域机制。“业务”作“核心域”解。

 

 

用户(User)

用户是人,也可以是第三方支付系统”,而且用户是和系统有交互的人。用户和系统的交互分为主动交互与被动交互两种。

 

 

一文理解所有需求分析中的基本术语_第6张图片

(选填) 图片描述

 

需求分析时,“用户”存在的问题:

(1)随意推测“用户”

如下图。需求人员容易先入为主,认定流程中的人就是优化方案的“用户”,然后逐个调研。

 

 

删除一文理解所有需求分析中的基本术语_第7张图片

(选填) 图片描述

 

 

 

一文理解所有需求分析中的基本术语_第8张图片

(选填) 图片描述

 

(2)“用户”混淆了演员和观众

用例设计把软件看作一部电影,演员(Actor,执行者)在台上表演,观众(Stakeholder,涉众)在台下看,观众按照他们的地位坐好。

演员表演什么由观众口味决定,先照顾前排观众,再照顾后排观众。

用例使用“执行者”(Actor)和“涉众”(Stakeholder)代替了 “用户”,用来弥补“用户”这个词的混淆概念。

 

 

客户/用户需求

基于客户认知或直观要求,体现用户需求,常见的是一种理想状态。

如:我想要汽车外观时尚,性能卓越。

用户需求通常无法直接实现,因为用户对自己的需求常常是模糊的,设计时要借助原型(demo)、参照物等方法,使客户需求具体化。

 


 

 

市场需求

市场需求不等于客户需求,市场需求不但描述目标客户的诉求,还反应竞争对手针对此需求的表现

如,竞争对手如何实现?如果不实现被竞争对手替代的可能性有多大?如果实现我们是否如何做才能超越竞争对手?

市场需求是经过产品经理分析后的客户需求,体现了客户和竞争的情况。

 

 

产品需求

IPD把产品需求定义为“产品包需求”,因为我们给客户交付的不是孤立的产品,而是一个解决方案,同时客户是否购买一个产品不仅仅看产品本身,还关注品牌、服务、渠道等因素,产品需求应广而不深,需要把产品相关的方方面面都考虑清楚,而不是针对某一点定义的很精细,需要从客户购买决定的全过程思考。

一般会涉及:价格、渠道、包装、性能、易用性、保证、服务、社会接受程度、品牌等;

 

 

设计需求

设计需求是“设计+需求”,到了设计需求阶段,设计和需求已经融合在一起了,设计在承载需求了。

设计需求定义时要在深度上下功夫,细化到能够通过设计来实现,并且能落实到具体的物理模块来承载。

设计需求是通过产品需求分解而来,分解后就形成了与此产品需求相对应的设计需求清单。

 

 

规格

规格是需求的具体说明。需求和规格本来就是一体化的,因此才会有《产品需求规格说明书》。

如:“OA要支持IE浏览器” 是需求,规格是:“需要支持Ie6、Ie7、Ie8”。“声音要达到120分贝~190分贝”,这本身就需求+规格。

 

 

特性

软件行业经常提到特性这个词。特性就是产品需求,更精确说特性是产品需求中与其他产品有明显差异的个性化需求。

产品需求常分为3类:BSA(Basic、Satisfied、Attractive),分别为基本需求、最好满足的需求、更具有吸引力的需求;特性为:A的需求。

 

 

测试需求

测试需求通常是研发中产品需求、设计需求定义不清,开发人员就进行设计和开发了,测试人员无法从需求中找出测试点,将需求细化到能提炼出测试点的颗粒度。

 

 

内部需求

产品需求定义时更关注外部客户的需求,其实产品还有内部客户,也要关注内部客户的需求。

例:制造、客服就是内部客户,设计时没有考虑制造的要求,导致制造效率低下、良品率低,就会影响产品市场表现;

制造部门的需求、客服部门的需求,就是内部需求,需要在产品开发前期识别,成为产品需求和设计需求的一部分,并在设计开发中实现。

 

 

外部需求

外部需求是客户、渠道、合作商、用户等,外部关联单位的需求。

分析时要通过销售过程,详细分析产品从生产线下来到客户手中经过的所有环节,各环节产生的需求称外部需求

外部需求要重点关注,一个环节不满足就无法转化为实实在在的商业利益。

 

 

业务需求

业务需求是从客户的业务发展、财务、战略出发,体现了客户高层的要求,涉及产品整体宏观上的要求。

如:ERP产品让库存周转率提高50%。

业务需求体现客户经营需要,具体业务需求需要通过产品需求、设计需求去细化和实现。

 

 

功能

说起功能(Function)这个词时,研究对象一般是系统,功能是一种需求。

功能需求描述系统作为一个整体为其他系统提供的服务,把其他系统给它的输入变成其他系统所需要的输出。

 “功能需求”不够精确。

如:如果以自助柜员机(ATM)为研究对象,

“取现金”是“功能”,“登录”也是功能,“计算手续费”也是“功能”,到底“功能”有多大?

用例要严谨得多:在用例中:

“取现金”是一个用例,“登录”是用例中的一个回合,“计算手续费”是一个步骤。

 

 

模块

模块(Module)。指出的研究对象一般是系统。模块表示系统的组成部分。这个词与功能一样不够准确,不清楚模块是一个控件?一个类?若干个类形成的组件?

 

 

功能&模块

“功能”是系统对外提供的服务,“模块”是系统的内部结构。

如:完成某个“功能”需要若干“模块”的协作,而某个“模块”也会参与完成若干“功能”,下图可以看出“模块6”被反复用了多次。因此不能将“功能”和“模块”直接映射,否则系统内部将出现大量冗余。

 

 

一文理解所有需求分析中的基本术语_第9张图片

(选填) 图片描述

 

 

功能包

功能包描述若干功能的集合。

 

 

一文理解所有需求分析中的基本术语_第10张图片

(选填) 图片描述

 

最后,产品经理学习资料已经为你打包好了,等你来拿哦!

一文理解所有需求分析中的基本术语_第11张图片

(选填) 图片描述

 

你可能感兴趣的:(需求分析)