需求分析的基础知识（一文理解所有需求分析中的基本术语）

需求分析的基础知识（一文理解所有需求分析中的基本术语）架构（Architecture）如，餐馆系统中订单和菜品的关系属于“业务知识”，折扣的计算规则属于“业务规则”。“业务”从范围上的划分，指“组织级别”。如：“业务建模”是组织级别的建模、“业务用例”是组织为其他组织提供的服务，“业务流程”是组织内各个系统之间协作的流程。

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

业务（Business）

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

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

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

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

架构（Architecture）

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

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

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

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

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

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

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

业务架构

业务架构有两层含义：

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

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

用户（User）

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

需求分析时，“用户”存在的问题：

（1）随意推测“用户”

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

（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”被反复用了多次。因此不能将“功能”和“模块”直接映射，否则系统内部将出现大量冗余。

功能包

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