如何描述分析型应用的需求

[Qing]

先声明一下，这里的需求是指分析型应用的需求，区别于通常事务型系统的需求。后者，一般叫做《需求规格说明书》，就像描述一个零件一样，描述要做的系统的模样。在事务型系统里面，主要就是流程。通常也分成功能性需求和非功能性需求，前者就是定义流程的细节，后者定义一些性能、稳定性的要求。

 

这种需求其实是需求分析之后的结果，客户提出最初的业务问题，开发商跟客户一起定义解决这个业务的流程，定好了就按照那样去设计、实现，虽然也存在需求变更，但相对要稳定一些。比如开始设计一个营业受理流程，后面总不会去掉这个流程。

 

而在分析型系统需求描述中，这是难办的。记得以前经营分析系统的需求描述，是描述有哪些报表，有哪些cube，每个cube的维度和度量。这还是比较"事务型"的，报表是比较固定的，算是功能性需求的一种吧。而cube就灵活多了，为什么考虑这个维度而不考虑另一个维度，维度的层次划分，一开始能定义清楚吗？当然可以，如果对市场分析人员的分析需求有深入了解的化，是能够抽象出这种维度组合的。这就得看需求分析者对业务的了解了，不光是对业务流程，而是对分析业务问题的思路要了解。

 

如果是一个特定分析的需求，那就更不好描述了。比如说，客户的目的是如何提高主叫话务量，告诉你想"分析分析"，于是，可以立个项，叫做话务量营销专题。但这个需求怎么说呢？提高话务量当然不完全靠分析就能得出的，制定什么市场策略当然更重要，所以，此处的需求其实是为了帮助这个策略的制定。

 

它能够如同事务型系统那样，定义出流程吗？似乎这里面不存在流程。虽然之前在ttnn曾经讨论过"分析流"的想法，可惜那还停留在设想阶段。无法准确定义出最后提交物的规格，比如说是一个cube，有哪些维度度量，但没有分析结论，不是解决之道。关键是，会有很多新的分析角度会在过程中蹦出来，就像侦察案件一样，寻找蛛丝马迹。

 

去年，看到有一种《需求规格说明书》，但非常困惑的是，它并没有定义客户要分析的是什么，而是定义挖掘模型，描述模型的目标，分析的周期以及输入的变量等等。这有点像是事务型系统的需求书了，是需求分析的结果。但它并未体现出客户要得是什么，也许并非是挖掘模型，也许只是数据探索的结果。

 

最重要的是分析结论，使用一般统计，还是挖掘模型，那是设计层面的事情。什么叫做"分析结论"？可以将它定义成为"一种可以指导策略制定的业务规则"。

 

在这个定义下，就能区别哪些是结论，哪些不是。比如一张图表，显示每个地市的话务量对比，用柱状图展示出来。这不是结论，只是数据可视化，而描述成"xx和yy地市的话务量总是占全省话务量的45％，正负3％左右"，这是结论。

 

一个分析型需求，在描述的时候，是无法料定这个结论的。

 

所以，有必要有一份对客户分析型需求尽可能准确定义的文档，暂且管它叫做《业务需求书》吧。它的目的是将客户要分析什么东西定义准确。

 

其实客户要分析什么东西通常连自己都不知道，心里想的跟嘴里表达出来的东西也是有很大差别，而且跟客户的思维，是技术型还是业务型的有关系。比如有的客户会这么说，"我们下面要搞个xx营销活动，目标客户群是这样的，你给我分析分析"，这是业务型的思维。还有技术型的提法，会直接干预到你的分析过程，比如说，"你帮我统计这个数，区分xx、yy几个角度"。

 

可见，技术型的需求提法更加明确，但矛盾的地方在于，这也许根本就不是解决根本问题的路子。等从两个角度统计出来几个数，发过去一看，不能支持策略制定，于是还得细化。

 

从责任界定角度，满足这种技术型分析需求是比较清晰，实现起来不难。你告诉我从两个角度统计，我不会从第三个角度统计，但体现的价值稍微低了一些，要往高了走，还是你告诉我业务问题，我帮你找出支持你下一步决策的分析结论。

 

于是，《业务需求书》就是定义出这种分析需求。关于这份需求应当包括哪些内容，下次再谈。

 

 

[Qing]

上回说到对于分析应用，应当有一份《业务需求书》来说明客户需要分析的东西，这个东西可能还在他的脑海中，可能表达出来跟他自己心目中的想法并不一样。

 

这到让我又想起一个例子，所以在描述这份需求书之前，先说一说。

 

那是很久很久以前...春节前的事情了。有一次，客户传来一个需求，说是要分析手机用户话务量的自然增长率、弹性...一下子提出三个概念，叫的都是响当当的。于是，我们去找了相关资料。据说在经济学里面是有这些概念的，于是，照搬了一通。研究了半天，写了一些分析方法，折腾良久。上周参加了客户的会议，旁听了这段介绍，觉得就是一个概念偏差的很好的例子。我们这边，将这个概念绝对化，将客户提出的"名词 "理解成和教科书上一样的东东，而客户并不清楚这几个词的真实含义，可能只是从哪儿听到一耳朵这个词，觉得能够跟他自己的业务问题有点像，便拿过来用了。而我们将"弹性"之类的三个概念理解成为三种不同的含义，并且刻意找出了三种定义，但其实对于客户来说，他要表达的只是一个东西，就是"运营商的优惠活动对客户行为都会有什么样的影响？"。

 

我们在做这项分析的时候，没有编写业务需求书，只有依据一份会议纪要去做的，况且后面似乎也没什么客户沟通。因此，作出来的东西跟客户想象的不一样也是情理之中的。如果有一份这样的文档来准确表达客户的意思，当然会效果好些。当然，其实重点还是在沟通，要迅速交付，不要等到一个月之后才看结果。对于这种需求模糊的东西，就得以快制胜。

 

描述客户的原始需求，并非只是将客户的原话记录下来，那是会议纪要，而是要挖掘需求的本质。比如上面的例子，本质上是要分析优惠动作和客户行为变化有没有一种因果关系。其中，"因"可能是更加优惠的套餐，话费赠送，手机捆绑...，"果"——客户行为变化，可以简单地看作是话务量的升高或降低。这个需求只是希望你能找出这其中隐含的规律，而不是真的就去计算一种叫做"自然增长率"的指标。

 

关于这种分析型需求的本质，其实我在之前一篇文章《从独孤九剑谈起》中已经提到一些想法。将客户需求比作敌人的招数，要制敌，首先认清对方的招数，识别它的弱点。

 

这也是我从去年就开始思考的问题，目前已经初步归纳出了几种不同类型的分析需求，但尚未明晰，有些类型非常相似，不太容易区分。这里只是简单地提前预报几种。

 

有一种叫做"分门别类"的，这是客户在分析一种事物的初期常常需要的，将杂糅在一起的事物厘清楚。还有一种叫做"目标求解"，是指给定了一个目标限定条件，让你像求解多项式那样，求出一个值，比如给客户赠送多少分钟话务，是即可以提升其话务量，又不降低收入的。还有上面介绍的"自然增长率"的例子，曾经考虑叫做"模式归纳"，或是"探求因果"，原来是将它们考虑成两种类型，但后来发现其实它们是相似的。

 

这项工作还在进行当中，稍微成型一点，将会拿出来跟大家探讨。对了，我给这种需求分类起了个名字，叫做"分析域"。

 

之所以考虑这个问题，也就是因为有时候总是摸不透客户要的是什么。如果能够在需求书里面将客户需求归入到某个类别里面，也就是"分析域"，并且大家对这些分析域的含义有个共识的话，后面工作会轻松很多。比如用户提出的只是一个"分门别类"需求，你就别整出一堆复杂的预测模型来实现了。如果是"探求因果"，就得找出因果关系才行。

 

曾经有段时间非常困惑，划分"分析域"的标准是什么？为什么你将分门别类作为一类，而将模式归纳归成一类？其实，在分类的时候，不也是在将相同模式的事物归成一类吗？这不也成了模式归纳？

 

后来稍微清晰一点。划分分析域的标准在于他们得出的分析结论是不同形式的。比如分门别类是希望知道事物可以分成"几"种；数值预测是希望知道未来一个确切的值；探求因果的结论是用"如果-那么"表示。因此，当将分析域界定清楚以后，也就是确定了最后分析结论的表达形式。而检验你这个需求是否跟客户真实需求一致的标准，就是看这种形式的结论是否能够支持他下一步的决策（能不能这么说我还在怀疑中）。

 

这次谈了一些分析域的话题。能够将客户模糊的需求放在一个大概的框框里，以此来定位它的本质，让后续的分析工作有的放矢。当然，这项工作目前尚未完成，即使已经归纳完毕，还得验证呢。但业务需求书是需要的，下次就来谈谈在没有分析域的情况下，它由哪几部分构成吧。

[Qing]

关于如何描述分析应用的需求，前面已经介绍了《业务需求书》的必要，以及对这类需求本质的识别，并且用一个"分析域"的名词来称呼它。当然，这还是在思考并实践的过程中。接着来谈谈一份业务需求书究竟包含哪些内容。

 

很多人被告知要撰写一份需求书的时候，会首先去搜寻有没有现成的模板。这个模板也是起到一种告诉你应该在需求书里面编写哪些内容的作用。比如，功能性需求、非功能需求...已经给你列好标题，只需要往里面填数就可以。这大多是定义事务型系统的需求书模板，而且，模板虽多，能够给出一份能够准确定义未来系统的需求书，确实少之又少。原因在哪儿？在于对每个标题的理解差异。比如什么是功能，什么是接口，这得在概念上要分清的，可惜如果需求分析者分不清楚，恐怕只能给出一份标题都具备，内容却空泛的需求书。

 

描述分析应用的需求书模板不多。原因很多，首先能够将这种分析应用当作一个需求的不多，或者是另外一种形式存在，比如一些咨询公司给客户，可能就不是以需求书的形式出现。但总得有什么东西来描述客户到底需要什么，需要的不是什么。所以，这里谈的《业务需求书》就不必理解成为是一种必须叫这个名字的文档，重点是在内容。

 

为了要将客户所需的分析（主要是数据分析）定义清楚，可以从以下几个方面进行描述。

一、背景

二、业务目标

三、约束定义

四、交付件定义

五、分析角度

六、应用场景

七、术语定义

 

逐一讲解。

 

首先是背景。为什么要作这个分析，当然，这个背景最好是实实在在。如果这份文档是帮助客户和分析人员理解作用的，就不必提什么"WTO"，"竞争激烈"之类的词汇，大多是无用的废话。直接了当，是为了什么，是为了提高收入？这是大题目，有很多方法，你这个分析恐怕不是直接服务于此的。最好是描述为是支持某类收入的提升，这就明细一点。这里，限定的越明确，当然，分析的范围就越小，目标就越清晰。总之，客户之所以产生了这样一个需求，是因为存在一种困境，需要回答某个问题的。因此，在"背景"中，要将这个问题，以及涉及到这个问题的环境简要描述出来。

 

比如下面这段： 我公司KPI指标xx一直发展不力，其含义是xxxx，为了提升该KPI值，需要重点发展xx业务，初步考虑用xx、yy手段来针对目标客户群进行营销活动，需要分析哪些能够分成哪些目标客户群，并且各自具备什么样的特征。

 

上面这段背景已经是比较清晰了，但老实说，通常客户提出的需求并没有这么清楚。也许它不知道该用哪些手段作营销，或者根本就没有思路。此时，至少是要能够将分析的目标用简短的文字（比如不超过30个字）来描述出来。

 

第二部分，定义分析的目标。虽然在上面的背景中已经有所描述目的，但那还是比较泛泛地描述，此处要用尽可能简短，并且准确的词汇描述出实现此需要能够给客户什么帮助。如有可能，量化表示。建议采用条目形式，列出每个目标。比如

 1、辅助xxKPI在半年内从30％提升至40％；

 2、将现有客户群分成n群，并给出每群客户的特征项；

 3、给出目标客户群以及营销策略的建议；

 

第三部分，约束定义。定义这些分析是在哪些限定范围内完成，这一节是比较详细地描述，是细节。比如要分析的是xx地市，而不是全省。分析的是这种品牌，而不是那种品牌。为了实现上面的目标，也可以分条目，每个条目描述对某个目标的分析、约束。

 

第四部分，交付件定义。描述这份需求最后以什么形式交付客户（总不能只是口头告诉客户吧），一般来说，都是分析报告，用word或ppt形式提交。也许有的需求不止这些，除了得出分析结论，还要求给出客户名单之类的，当然也是在此描述。但一般，不要在此给出分析报告、名单的详细内容，因为这根本就不是在需求描述阶段能够确定的。

 

第五部分，描述分析角度。这份需求书一方面是准确描述客户的需求，一方面是帮助后续的数据分析、数据挖掘建模者准确理解客户需求。因此，在此设计了这个章节。因为在客户沟通过程中，针对分析目标，已经确定了一些思路，虽然这些思路可能是不成立的，但可以作为一种参考。在此节描述。比如如何识别目标客户群，可以从交往圈，从长途漫游比例来分析。

 

这一节不是准确的定义，是帮助读者理解的描述。

 

第六部分，描述应用场景。同样，也不是严谨地定义，而是描述未来出来分析结论之后，客户如何使用这些结论。如果能够用示意图的形式表示最好了，比如如何在一副图里面显示目标客户群的分布，基于这个图，可以判断优先针对哪些客户群采取行动。

 

第七部分，定义术语。要知道大家经常对同一个名词有不同的理解，比如说"价值"，是收入减成本呢？或是仅仅为收入？因此，为了让客户、需求分析者以及数据分析者在同一个语境里面沟通，请将所有大家可能发生理解差异的词汇准确定义出来。

 

术语定义本身就是一门学问，在定义中，尽量使用没有特别业务含义的词汇，否则，还得交叉定义。例如，定义"中高端客户"为"连续三个月平均价值大于等于120的客户"，当这里的"价值"一词没有被大家共同理解，建议使用大家有相同理解的词汇，比如"帐单金额"。

 

当将以上七点描述清楚，后面的分析者可以集中在对问题的求解，并且按照要求来表示自己的分析结论。

 

本来想在一篇里面将这个话题描述完毕，不过竟然花了三个。其实如何准确定义需求不是简单文字的工作，而是概念整理的工作，去挖掘客户语言背后的目的，去帮助他们准确定义业务问题。从模棱两可到准确定义，需要一个长期实践。

[Zen Zhang]

COGNOS 开发文献库现在可免费从IBM网站直接参阅：

http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp

---

Ask a question on any topic and get answers from real people. Go to Yahoo! Answers.

[阿易]

Very Good，Thanks

2009/1/23 Zen Zhang <zen...@yahoo.ca>