无论需求大小、是否是一句话，只要我们能基于这句话产生疑问，通过不断设问圈定需求范围，再针对每个问题的答案给出解决方案，问题就能迎刃而解。
—————— BEGIN ——————
测试同学通过此篇了解需求的来源，在需求评审时候多问几个为什么
今天的思考，源于一位同学和我分享的面试题。
原题描述如下：
有一个类似京东的商城在运行，该商城没有商家入驻功能，没有促销功能。
目前计划开发促销模块，支持满赠、满减、打折，三种类型的促销，你认为开发该功能，有哪些重要的产品逻辑要考虑到，请试着梳理。
简单说，就是让你设计三个模块：满赠、满减、打折。
看到这个问题，我的第一反应是：这需求描述的不清楚啊……
为什么要做这三个模块？目的是什么？要达到什么效果？具体什么场景？如何运营？等等，啥都没说，就一句话丢过来让做，这不扯么。
后来转念一想，毕竟是面试题，这些疑问，估计面试官是想让我们自己提出来，再自己圆回来，以此判断我们的思考全面性。
但话说来，日常工作中，确实也会经常遇到这种所谓“一句话需求”，可能老板一个点子：我们要上打折功能，就让你去开干了，留下一脸黑人问号的你，心里不断diss这不靠谱的老板。
不过正如上面说的，这也许正是老板对你的考验。
01
那遇到这样的问题，应该如何思考呢？
今天就来说说我的解决思路：
首先要做的，就是搞清楚概念定义。
以面试题为例，满赠、满减、打折，这三个词，太过抽象，直接去思考解决方案只会导致天马行空，没有章法。
因此我们需要通过自问自答的方式，明确以下几个定义，把题目范围缩小：
1）满赠
要明确满的是什么？赠的是什么？怎么赠？三大问题。
满的可以是钱，可以是商品数量；赠的可以是商品，可以是虚拟商品，也可以是促销特权（如优惠券，抵扣券等）；赠的方式可以是下单即赠，可以是二次兑换。
2）满减
要明确满的是什么？减的是什么？怎么减？三大问题。
满的可以是钱，可以是商品数量；减的可以是钱，可以是服务（比如运费）；减的方式可以是付款立减，可以是买后返利。
3）打折
要明确怎么折的问题——是直接金钱扣减，还是基于折扣券来打。
以上问题明确后，才能接下来给解决方案。
02
我们假设一种情况：
-
满赠：满的是金钱，赠的是实体商品，赠的方式是下单即赠，也就是订单增加赠送商品，赠送商品价格为0。
-
满减：满的是金钱，减的金钱，减的方式是下单直接减钱。
-
打折：满的是金钱，减的是折扣金钱，减的方式是下单直接减钱。
在此基础上，接下来要考虑的是将三种促销逻辑抽象化，讲清楚他们之间的逻辑关系。
首先，每种促销，都是一类配置项，都要配置：触发条件，触发动作，关联实体三个参数。
-
满赠——触发条件：满XX元。触发动作：增加N件总价为0的Y商品。关联实体：Y商品
-
满减——触发条件：满XX元。触发动作：减YY元。关联实体：无
-
打折——触发条件：满XX元。触发动作：乘以M折。关联实体：无。
进一步思考，每种促销，是否都要支持多条配置项共同发挥作用；如果是，那就还要考虑支持阶梯价格。
03
接下来，就是要将商品SKU，和促销配置项做关联，实现具体的促销策略。
关联时，需要考虑层级关系：
-
一个SKU，关联一种促销的多个配置项时，应该如何处理？
-
一个SKU，关联多种促销的一个配置项时，应该如何处理？
-
一个SKU，关联多种促销的多个配置项时，应该如何处理？
简单来讲，要确认是否可以逻辑叠加，叠加后有哪些限制条件。
比如满赠后是否还可以再满减，满减了是否还能打折，打折是基于减后的钱还是减前的钱来折，打折后是否还能满减等等。
最后，还要考虑完成促销后的售后问题：
假设用户退货怎么退钱？这就要涉及拆单问题。
假设用户买了后折扣力度又增大了要投诉如何给用户补差价问题。
当然，这些特殊情况有考虑会有加分，不考虑也没太大问题，大的促销逻辑搞清楚即可。
说到这儿，你是否心里更有数了。
其实无论需求大小、是否是一句话，只要我们能基于这句话产生疑问，通过不断设问圈定需求范围，再针对每个问题的答案给出解决方案，问题就能迎刃而解。
http://www.bcbxhome.com/bcbx/forum.php?mod=viewthread&tid=88
(出处: 编测编学软件测试)