需求——对系统边界的描述

  关于产品和项目的需求分析差异问题，和西宁私下沟通了过，明晰了一些。其实，我的回答并没有多少集中在差异上，而是对需求应该包含什么提出看法。

主要观点是，需求应该包括对系统边界的描述，不论这个系统是产品还是项目。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交互。"这，是一个黑色的立方体，长45厘米，宽23厘米，高3厘米，盒子的每个角都不尖锐，上方平坦，并有柔软质感；下方在四角之处都有凹进去的螺丝口，可以接杆子，以作凳子用。"

这就是仅仅对其功用的描述，其目标是作凳子用。这可以看作是功能性需求，当然如果还有一些约束，例如"此立方体可以承受300斤胖人之重"，这就可以看作是非功能性需求。但同样还是在描述边界。而对于其内部构造如何，在需求中不要描述，例如盒子是空心的还是实心的，材质用钢板还是木头，这都不是需求，而是已经在设计了。

因此，在描述需求的时候，重要的就是界定系统的内外。看过很多的需求，自己也写过很多的需求，界定内外不是容易的事情。有几个原因，一是没有内外的概念，不知道需求描述的是什么；二是知道内外，然而对于边界的定义，没有足够的词语描述清楚，只能用对系统内部设计来代替。这样的结果是，一份需求书，你搞不清楚它是需求还是设计。

譬如有的需求书，它描述了系统内部模块划分，三层结构，数据存储、中间逻辑等等。比如专题分析的需求中，包含了对挖掘变量的描述，嗬，将上百个变量列在文档中确实能够让页数增加。然而这恐怕不是阅读对象关心的，也不符合分离变化与不变的原则。需求书的阅读对象关心的是系统是什么，而非如何实现。系统是什么是相对不变的，而实现方式却是相对变化的。例如上面盒子的例子，用它作凳子是不变的，而至于用木头或是钢材，是后面考虑，可能会反复变化的。对于专题分析也是如此，这个分析针对的业务问题，诸如哪些客户最有可能离网，这个目标是相对固定的。而你是考虑使用呼转次数或是话费突降的角度来考虑，这是变化的。因此，在需求中，绝对不要将设计的东西加入进去（除非你是想便于说明问题），因为那种东西不能够作为一种"规格"，用于验收、测试的标准。

当然，有时候根据客户在作要求的时候，并非完全从系统边界上考虑，而真的会从系统内部提要求。譬如说，这个凳子，你就得用钢板，不能用木板，至于为什么，可能这仅仅是他的喜好。软件系统也是如此，有时候他会提出要求，你就得用某种产品，你就得用分类模型或者是神经元算法来实现。面对这样的要求，我也不知道该如何在需求书中表述，难道写上一堆系统约束——必须用叉叉产品，不得在系统中出现任何英文字母…？

需求所描述的系统边界，用UML中的用例图来表示是比较简洁的，用例图中的"角色"既是外部与系统交互的人或物或其他系统，"用例"则是系统表现出来的功能，而上面还提到了一些"约束"，不知道在用例图中是否有对应，研究不够。

用例图是起到示意作用，在需求规格说明书中，需要对这些角色、用例、约束进行阐述。例如在描述事务型系统的时候，会涉及到业务流程中参与的各个角色，有必要对每种角色进行定义。而对于一个分析系统，总感觉其流程不似事务型系统般流程清晰，因此，在早期的经营分析系统需求书中，大量篇幅在定义分析主题的维度、度量构成，却忽视，这个分析主题真正的业务目标和流程（谁来用这个多维分析？产生什么输出？）