需求之界

[Qing]

如何写需求说明书，这个话题曾经探讨过。但这是个很模糊的问题，主要是需求和设计之间的界限问题。

 

去年年初曾经写过一篇，关于分析型应用的需求书写法：

http://groups.google.com/group/ttnn/browse_thread/thread/11de490b7de2983c/a5d2e538caccbd3c

 

这只是局限在分析型的需求表达上面，而且，其实你可以明确需求书应当包括那些内容，这是形式问题。而概念的区分是更加重要的。在与同事、朋友交流中，发现存在很多模糊的理解。因此，想再做一些抽象。

 

一、需求、设计的界限，其实可以抽象成为需求方-提供方的界限，在实现一个系统的过程里面（或其他的过程），存在多种这种的界限；

二、需求说明书是需求方跟提供方的合约；

三、需求的表达不是绝对的，也要视乎提供者的理解范畴；

四、为了简化这种个性化的合约，出现分类型的表达方式，即模板化的需求书。他假设提供方的理解范畴是一定的。

 

编写需求是表达需求的工作，一般来说，可能并非需求直接提供者来干。在编写需求书的时候，首先要站在需求方，看看写出来的东西，是否充分表达了自己的要求，而没有谈具体实现。接着，要站在提供方角度，去审视这份需求是否清晰到让人动手的地步，是否存在一些没有解释而模棱两可的字眼。这个过程，就像是在审查合同。

 

要区分这道界限，还是要认清楚需求方是谁，提供方是谁，他们各自该干嘛。

 

今天时间不多，先开个头。

[cui chang]

唉，这个是大家的难题啊，开发人员都为这个发愁。

2008/9/19 Qing <happ...@gmail.com>

[left...@gmail.com]

需求在软件开发过程太重要了，好的需求分析，太难了。
界定就更有难度了，不断的学习啊。。。。。。

[Qing]

之所以抛出这个话题啊，唉，说来话长。

 

话说，最近我遇到两个项目，这俩项目算一个项目还是两个，有点模糊，因为都是面对同一个客户的。只是，将需求这块的工作单独拿了出来，跟实施分开，立了个咨询项目。而实施则是另外项目的范畴。我们是同样的人干这两块项目。如果所有实施都是一伙人干，或者没有划分这两个项目，需求工作一般不会太严谨（虽然应该是严谨的），可这偏偏不是。我们这一伙人，只是负责实施中的分析建模的部分，还不是全部。所以，我们还是要将需求表示地清楚一些，才对得起那个咨询项目嘛。

 

将这两种不同类型的事情界定清楚不容易，有时候一个人得在两种角色之间切换。当然，这种切换不会太频繁，一般来说，前期都是站在需求方来考虑问题的。后期再去作为实施方实现。我们一位同事就陷入这种角色转换的困境中，以前可能主要是站在实施方多些，所以在前期沟通当中，更多是沟通一些细节的业务规则，比如如何计算一个综合评分，而这其实已经是在做实施的工作。可一旦精力放在这些问题上面，那些应当做的，比如是否需要这样的综合评分，如何评判其合格的标准，这些问题没有结果。

 

这个场景中就充分暴露出需求方清晰表达需求的困难——需求方有时候过于从实现者角度在前期考虑如何实现的问题，而忽略了更加重要的事情，就是确立工作范围和任务完成标准。

 

所以，上周又重提了这个话题，想将关于需求书的观点在加强一些。那就是将它看作是需求方跟实现方的协议合同。当然，需求书是最后形成的有形的东西，而无形的东西，可能更加重要，就是大家需要认同的那些条款。比如你要求速度快，这不是一个明确的条款，但要求速度<5秒，这就明确了。而要实现这些认同，并不是撰写出来的，而是沟通，甚至是谈判出来的。这种沟通是重头戏，是比文档更加重要的工作。

 

表达需求，是确立需求方对实现方要求的过程，落在纸面上，就是需求书的条款。

 

沟通过程要比需求书重要。

 

有一次我们内部开会说起需求书的问题，有领导抱怨我们的需求书太简单，页数太少，文字太少，恐怕被客户认为是不合格的，因此需要加点料，比如将一些分析的过程，会议纪要什么都作为附件放上去。我不赞同，当场进行辩论，我认为需求说明书应该只记录需求分析的结果，对实现者的要求，不要将体现这些结果的过程都放上去。后来，有人出来打圆场，说，其实说的并不矛盾。其实也是，人家要说的问题并非"什么是合格的需求书"，而是"什么是可以应付客户的需求书"，我们要辩论的问题并非同一个问题，所以，也不抬杠了。可大家如果深入想一想这个问题，其实这是一种对需求工作的一种错误的理解。

 

通常有这样的观点，做需求，写需求文档，如果看起来很简单就没法交付，客户会认为你没有下功夫。

 

我很无奈这种观点，但不知道应当如何纠正。

 

简单与否，是一种形式上的判断。而清晰与否，是内容上的判断。简单的，不一定清晰。但清晰的，应该是比较简单的。长期以来，我对于需求书是否合格的判断，就是它是否准确无歧义地表达了需求方的要求了，是否可以让实现方理解了，是否有多余的废话。如果要严谨一点，一句废话都不应该出现的，比如在需求背景中的"形势危急"、"响应...号召"之类的语句。

 

也许这是观念问题吧，很难确立什么规范，去对需求者作出要求，即便有要求，也多是形式上，比如模板之类，而内容上，你说准确、无歧义的判断标准是什么？从这点看，却正是证明了，内容要简洁一点，不要啰啰嗦嗦说上几十页——因为你搞出那么多是不是就想糊弄过去，把人搞晕呢？按照这个逻辑，大家可以有个判断了。对于那种厚厚的一叠，除非你面临的是一个宏大的工程，否则，肯定是在充数，反倒证明这种需求书的垃圾程度。

 

咱们这里说的关于需求的事情，还仅仅是如何"表达"需求的事情，并没有说到如何挖掘客户真正需求的问题上。但就表达需求而言，已经存在很多误区。如果从观念上，不理解何谓需求，恐怕是无法表达好。

 

然后，我们将需求、实现当作一个流程，但其实呢，往往这个过程是螺旋迭代的。分析型需求恐怕更加如此，在客户面对一个业务问题的时候，恐怕只是初步的一种猜测，一种好奇。这时候，你需要表达他的需求，很难表达清楚，即便你已经充分沟通了。但随着对问题进一步调查和数据分析，会暴露出更清晰的需要。最后，也许落在一个很具体的数学模型上面。但很多项目的管理并不允许这种过程，一般都是提出一次需求书，然后实现需求书，完成需求。这种模式迟早要改变的。但在没有改变之前，清晰将需求表达出来是必要的。

[博文先生]

 

以我之见，需求分为以下几类：

 

1、状态需求，例如：目标、期望、我想要……；

2、规则需求，例如：如果……那么……；

3、过程需求，例如：HOW

4、权限需求，例如：允许……

其它需求都是上述需求元的组合。

 

需求分析看需求表达的对象，越是高层的越是偏向于结果（如目标的达成），越是基层的越是偏向过程的控制（如流程的表达）。

 

需求分析的难点在于：如何让分析成果的生命周期能符合客户所支付代价的期望值。

 

博文

2008/9/19 Qing <happ...@gmail.com>

[xi rong]

感觉这里面要分两个层次说，一个层次就是如何应付客户，证明需求咨询工作做完了；第二个层次则是软件的需求搞定了。第一个层次关键在于项目管理，第二个层次其实没有终点，或是当软件的生命周期结束以后才完成，是不可能通过瀑布模型定义完全的。
对于第一个层次，可以考虑实现同客户约定需求的范围，比如分为功能需求、安全性需求等等，然后搞一个检查表出来，最后是根据检查表让客户评审，评审通过项目就结束了。如果Qing希望咨询项目尽快收款的话，还是把两个项目分的清楚一些比较好：）

在 08-10-4，博文先生<rocher...@gmail.com> 写道：

--
Regards
Rongxi

[Qing]

这四类需求元也许还可以归纳一下，就是状态需求和规则需求，感觉过程需求和权限需求都属于规则需求，为什么要将这两者区分出来呢？

看到这四个需求元，不禁考虑分析类需求如何归入其中。一般来说，肯定要有状态需求的部分，比如规定找出一些因果关系。但分析的过程在刚开始面对那个题目的时候是很模糊的，所以，当初我提出了"假设论证"的需求表达方法，将需求表达变成一个迭代的过程。

但再想想，表达需求的真正目的是为什么？我觉得还是为了让实现者可以履行他的职责。而在这个话题里面，我将需求分析和需求表达是分开的。需求分析包括跟客户沟通，达成一致意见，搜集资料，分析、综合、抽象。需求表达，就是将这些成果表述成需求说明书。

对于假设论证的需求表达方法，发现如果变成一个迭代的过程，那么他就已经是属于需求分析的过程，而非表达的过程了。因此，现在已经有些疑虑，继续思考中。

对于博文的最后一句话，"需求分析的难点：如何让分析成果的生命周期能符合客户所支付代价的期望值。"有些不明白，还请展开。

2008/10/4 博文先生 <rocher...@gmail.com>

 

以我之见，需求分为以下几类：

 

1、状态需求，例如：目标、期望、我想要……；

2、规则需求，例如：如果……那么……；

3、过程需求，例如：HOW

4、权限需求，例如：允许……

其它需求都是上述需求元的组合。

 

需求分析看需求表达的对象，越是高层的越是偏向于结果（如目标的达成），越是基层的越是偏向过程的控制（如流程的表达）。

 

需求分析的难点在于：如何让分析成果的生命周期能符合客户所支付代价的期望值。

 

博文...