那些年接到奇怪的需求，如何确定需求？

那些奇怪的需求

需求1

客户：做个百度几千块够不够？

程序员：不够的！

客户：一万够了吧?

程序员：不够的!

客户：就那么几个页面，我做一个淘宝也只才几千块，你是不是坑我?

程序员：你找到了可以做的麻烦介绍给我，我也想做一个。。。

需求2

需求3

领导:那个运维啊，你来把他的系统破解了，要不把他服务器黑了也行。给你一天时间，搞不搞得定。

常见的需求问题

1、 需求不明确

• 盲人摸象，各阶段人员只掌握了一段
• 初期阶段，业务还在摸索
• 各部门目标和kpi不一致，需求有冲突

2、需求理解不一致

客户：我家有三个小孩，我须要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。 项目经理：秋千这东西太简单了，就是一块板子，两边用绳子吊起来，挂在树上的两个枝子上。 设计师：这个无知的项目经理，两个树枝上挂上秋千哪还能荡漾起来吗？除非是把树从中截断再支起来，这样就满足要求了。

项目最重要的阶段是进行需求分析，明白真正的需求。项目需求指的是用户真正需要什么，而不是供应商假设用户需要什么和供应商能够供应什么。需求的准确定位就是要按用户要求，对目标系统提出完整、准确、清晰、具体要求。这对一个项目的成功来说非常重要，需求分析做得不好，就会造成需求不断变更，从而影响进度、费用，甚至会导致项目失败。

3、需求自身经常变动

• 尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
• 在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。

7、需求获取

1、需求来源

干系人

干系人（Stake holder）：对于系统有利益关系的个人，团队、组织和其他系统。

项目干系人包括但不限于：

• 投资方：系统的投资方
• 主管方：批准/管理系统的
• 最终用户：用户/系统受益方
• 操作方：操作/维护系统的
• 监管方：认证系统的
• 测试方：负责系统验收

示例：XX信贷管理系统

 投资方：    资金部
 主管方：信息化部
 用户代表：  市场部
 最终用户：  营业员
 监管方：    审计部
 测试方：    信息化部
 操作方：    信息化部

2、需求分类

软件需求的三个层次：

1. 业务需求

描述组织或客户的高层次目标，通常问题定义本身就是业务需求。业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自于高层，例如项目投资人、实际用户的管理者、市场营销部门或产品策划部门。

业务需求从总体上描述了为什么要开发系统 （why） ，希望达到什么目标。比如“希望实施CRM后公司的客户满意度达到80％以上”。

业务需求对之后的用户需求和功能需求起了限定作用，任何用户和功能需求都必须符合业务需求。

2. 用户需求

用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。

用户需求必须能够体现软件系统将给用户带来的业务价值 ，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要的。

用户需求可细分为：

• 基本型需求： 产品功能必须满足的用户需求。例如社交产品的加友功能；音乐产品的听歌功能。
• 期望型需求： 用户满意度随着此类需求的满足程度而线性提升或下降。当此类型需求越得到满足则用户满意度越高，反之则用户满意度越低。例如，音乐类产品的歌曲越多越好。
• 兴奋型需求： 是一种完全出乎用户意料的属性或功能。例如微信的摇一摇。
• 无差异型需求： 这类需求无论满足与否，用户满意度都不会受其影响，用户对此因素并不在意。例如产品的简介。
• 反向型需求： 用户没有此需求，提供后满意度适得其反。例如产品付费功能。

3. 功能需求

功能需求描述的是开发人员需要实现什么，是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。

这些需求记录在软件需求规格说明（Software Requirments Specification） 中。SRS完整地描述了软件系统的预期特性。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。

3、获取步骤

我们必须知道获取需求的具体步骤

1. 标识项目干系人：干系人列表
2. 与项目干系人交流：沟通计划
3. 收集需求：需求沟通纪要
4. 重要性排序：需求优先级
5. 选择需求：根据资源和约束，选择实现的需求
6. 记录需求：编写文档

软件研发是一个团队性工作，各个角色协同工作，共同把项目完成。每个阶段和角色的产出，又是下一阶段和角色的输入。比如作为架构师，会根据产品经理编写的功能需求说明书，进行整体系统架构设计，而开发人员，也会根据产品经理的需求说明书和架构师的概要设计，做详细的设计和开发。

8. 需求要素

1、角色、场景

一般来说每个业务活动是对用户使用场景的抽象（例如电商购物活动），每个业务活动可能包含多个场景（例如商品浏览、购物车、下单、支付），分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容：

1.明确活动执行角色

2.明确活动执行的前置条件

3.明确不同场景：

一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景

4.明确每个场景的执行步骤

5.业务规则和约束：

明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则，或与数据实体相关的数据规则（比如某个字段的长度）

2、业务流程

针对流程类需求必须进行业务流程分析。需求人员进行流程分析应遵循如下方法：

（1）业务流程确认

一个流程为一个业务事件，一般是外部角色发起或系统内部主动发起（比如时间事件或状态事件），发起后会触发一系列业务活动。

（2）角色及业务活动确认

流程图中的每个泳道都必须对应到角色，每个角色对应多个业务活动。需求人员在确认业务活动时一定要保证活动的粒度，一个业务活动一定是由一个角色完成且每个业务活动都是有价值的。

（3）业务活动间关系及数据确认

确定所有业务活动的前后关系，并明确流程间传递的数据实体。

（4）流程整体瓶颈分析

一般若某个角色业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求人员应想办法分散工作量提出流程优化建议。

3、数据实体

针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件数据实体和展现数据实体，接口类需求需要分析接口传递数据实体，具体分析包含如下内容：

1.明确数据实体

确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。

2.明确所有数据实体间关系

实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。

3.明确数据实体字段

针对新增数据或改造数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式（人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式）。

4.数据权限分析

需要分析不同角色在数据权限方面的差异，若涉及纵向多级用户，要说明对于集团/省/地市用户的数据隔离。

4、功能性需求

系统功能分析是结合系统现状和上述分析进一步明确实现相应用户场景的系统功能，主要还包含内容如下：

1.功能列表

分析得出实现上述业务活动对应的功能/接口列表，并明确新增功能、改造功能；

2.功能/接口关联影响分析

实现某个业务活动需要新增或改造的功能对其它关联功能/接口的影响分析。比如改造请购池受理功能，可能会影响采购项目创建功能；采购项目创建功能修改一个字段取值范围，会影响项目统计分析和同步ES系统接口。

3.系统交互原型分析

需求人员应遵循界面规范，并与研发沟通确定系统交互原型，帮助研发或用户更好的理解需求场景。

在交互原型中应包含如下内容：

• 原型界面的名称、入口，原型间关联关系和使用角色
• 页面内容、格式及排序方法
• 操作要点：比如交互的信息提示、界面规则和约束（比如界面以不同颜色显示不同的校验结果）。

4.算法分析：

在系统功能交互时涉及比较复杂的算法，需要单独对算法进行分析。

5、 非功能性需求

包含需求的可行性分析、健壮性分析、可扩展性分析、执行效率分析，可行性分析从以下几个方面进行：

1.技术可行性 系统交互实现方式与研发确认是否可行，需求人员在与研发沟通过程中需要不断积累哪些功能实现在技术层面很难支撑。

2.时间可行性 根据用户的上线时间要求分析是否可满足要求。

3.合法合规可行性 分析用户需求是否满足国家法规或公司法规要求。

4.数据安全性分析 用户需求是否满足信息系统安全要求。

9. 案例：电商订单系统

1、概述

电商所有模块中，订单系统是非常核心的一个子系统，决定了整个流程能不能顺畅的执行，起着承上启下的作用，其他模块都是围绕订单系统进行构建的。订单系统出问题，或者功能流程设计不完善、不准确，将会造成整个电商系统整体或局部业务流转不顺畅，甚至导致项目的失败。

订单系统的作用是：管理订单类型、订单状态，收集关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作。订单系统业务的基本模型涉及用户、商品（库存）、订单、付款。订单基本流程是下订单-->减库存，这两步必须同时完成，不能下了订单不减库存（超卖），或者减了库存没有生成订单（少卖）。

下面我们从需求分析的角度，来看一看B2C电商中先款后货模式下的订单系统设计的过程。

2、角色

一个订单系统，涉及到的角色包括：

实体角色：

• C端用户
• B端商户
• 电商平台
• 配送商
• 第三方平台

系统关系：

3、场景(用例)

从用户的角度，我们看到的用户场景如下：

用例图：

4、功能

订单系统业务架构：

（1）订单服务

该模块的主要功能是用户日常使用的服务和页面，主要有订单列表、订单详情、在线下单等，还包括为公共业务模块提供的多维度订单数据服务。

（2）订单逻辑

订单系统的核心，起着至关重要的作用，在订单系统负责管理订单创建、订单支付、订单生产、订单确认、订单完成、取消订单等订单流程。还涉及到复杂的订单状态规则、订单金额计算规则以及增减库存规则等。在4节核心功能设计中会重点来说。

（3）底层服务

信息化建设达到一定程度的企业，一般会将公司公共服务模块化，比如：产品，会构建对应的产品系统，代码、数据库，接口等相对独立。但是，这也带来了一个问题，比如：订单创建的场景下需要获取的信息分散在各个系统。

如果需要从各个公共服务系统调用：一是会花费大量时间，二是代码的维护成本非常高。因此，订单系统接入所需的公共服务模块接口，在订单系统即可完成对接公共系统的服务。

5、实体

6、流程

流程是指从平台角度出发，将订单从创建到完成的整个流转过程进行抽象，从而形成了一套标准流程规则。每个流程触发的条件又可分为系统触发和人工触发两种场景。

下面以一个通用B2C商城的订单系统为例，根据其实际业务场景，其订单流程可抽象为5大步骤：订单创建>订单支付>订单生产>订单确认>订单完成。 如下图：

往期推荐：

• 今天跟大家聊一聊软件架构（图文并茂）

如果觉得内容不错的话，希望大家可以帮忙点赞转发一波，这是对我最大的鼓励，感谢🙏🏻

END