有关需求规格说明书内容和形式的解释

2.0项目组的同事：
    你们好！
    我想可能需要解释一下需求规格说明书里的一些内容和形式：
    1、2.4.1章节的模块是怎么来的。
       我想我在考虑模块划分的时候有一个总体的指导思想：应用支撑平台是一个复杂的工作辅助系统，我们可能很难做到像EOS studio或者visual studio那些大型IDE的复杂和专业程度，但是终归来讲，解决一个问题总是包含两个部分的内容：原理和方法论。我会这样理解，原理是问题本身的描述，而方法论是针对问题本身而定制的解决方案。那么，在在模块划分时，会看到“构件库服务器”和“构建模型”这样可能让人觉得是重复的内容，但实际上，我们去建造应用支撑平台这样一个工具集的时候，包含了两个部分：工作的工具和工作方法，那么“构件库服务器”就是工作的工具，而“构建模型”则是工作方法。因此我想这并不重复，当然，我也很希望大家能够对任何这些想法提出自己的意见和建议。
    2、2.4.1章节的“用例分配负责”是什么东西。
       依照之前讲述的内容，一个模块会包含1..n个用例，一个用例会被1..n个模块使用。那么，在这张表格中，用例的划分就是一个软件系统拆解的过程。从软件系统，到功能模块、到功能单元（用例），这是一个层次化的过程。而这个“用例分配负责”就是在讲，从功能模块到用例划分这个拆解过程，是由谁来完成，而不是说，拆解出来的用例由谁来编写。那么这样理解，这是一个业务细化的过程，与软件设计与实现无关。
    3、第2、3、4章节的粒度怎么掌握，什么是需求，什么是设计。
       我不得不承认，辨别“需求”和“设计”这两个概念我花了很长时间，甚至可能现在我的认识也有可能是不准确或者是不确切的。那么我的理解是：需求是业务的描述，设计是业务的实现。而这样就又扯出来一个概念，什么是“业务”？我们很常见的业务比如电子政务的业务，公文传输、电子签章，这都是业务；那么当我们面对软件开发这个领域的时候，什么是“业务”？编写代码、提取构建就是业务；当我们面临中间件领域的时候，什么是业务？提供接口、提供服务环境，这就是业务。可能大家并没有参加过之前一次有关安全中间件需求、设计评审的工作，有机会我会将那次的文档转发给各位来了解一下，在当时的需求分析、概要设计和详细设计中，描述了完全一样的内容，而绝大多数人的理解（对于概要设计和详细设计）就是，详细设计就是把概要设计用10个字说明的事情改用100个字说明，而我相信这是个错误。需求分析了业务，概要设计描述了实现途径，详细设计描述了代码结构（这里是代码结构，而不是程序结构）。
      可能有些晦涩，那么举一个简单的例子，在后续章节中提到一个通讯接口的问题，里面提出了一个概念“通讯协议”。通讯协议只有在开发的过程中才会使用，那么为什么要在需求文档里提出呢？比如我们采用基于HTTP的web service，那么通讯协议是什么？两个层面：传输层面采用了HTTP，数据持久层面采用了SOAP，而HTTP和SOAP已经规定了详细的数据通讯方式，这是一个基础的业务需求，我们用什么做什么事。我们用HTTP和SOAP去做基于HTTP规则的web service通讯。回过头再来看我们的需求分析文档中的内容，我想我在尽量尝试用这个原则去知道需求分析的编写过程，我们面向的业务范畴不同，需求分析内容就不同，并不是出现了代码结构、出现了软件接口，这就变成了设计文档，比如中间产品，他的功能需求就是提供软件接口。
    4、为什么是用例。
       在这么多年来的软件工程发展过程中，用用例来衡量工作量，用用例来标识软件需求已经成为一个管理，我也承认很难严格区分需求与设计的概念，用例本身的规划已经包含了大量的设计思想，比如在需求规格说明书中要求包含对用户界面的详细描述，这本身就是UI设计，那么我们还要设计文档干什么，用例的划分到底是基于设计还是需求的？我会这样去解释这个问题：设计本身是面向功能的，我们为了实现一个功能（这可能、或者说这一定是个流程），要实现一组操作，包括计算机操作和人工操作，单独存在的计算机操作和人工操作是没有任何意义的，比如我去银行办理储蓄业务，那么储蓄是银行的一个功能，可能包括了填表、点钞、录入、回执这样四个过程，那么一个人去办理储蓄业务，填表，然后闪人回家，这个功能就完全没有被使用，虽然你执行一步操作。对于这样一个过程，我相信我会映射为一个功能的四个用例：填表、点钞、录入、回执。在软件开发过程中，我利用这四点去分配和衡量开发人员的工作量，但是软件设计本身，概要设计会标志出，储蓄这样一个4步的业务流程，怎么通过计算机来体现，没错，就是设计一样可以描述业务，只是把自然语言换成了计算机语言（伪代码也是计算机语言）。那么通过这个例子我想可以表达出，用例是面向业务和软件开发过程管理，而非软件设计的。
    5、粒度是用来区分需求与设计的标准吗？
       我们在质疑需求规格说明书是不是写得太多了，写到设计的内容了？粒度不是区分需求与设计的标准。设计本身也是一种业务描述。理论上，需求分析由业务专家完成，设计文档由软件设计师完成，软件开发由程序员完成，断层存在与业务专家和设计师身上。软件设计师和程序员的交流是无障碍的，但是业务专家和软件设计师的交流是存在障碍的，如果设计师完全不懂业务，或者业务专家没见过计算机，那么这个事情恐怕做不下去了。业务专家通过需求分析文档表明我想要什么、我要怎样的东西，“怎样的东西”已经包含了业务专家对软件系统工作方式的期望，软件系统的工作方式不是业务，是软件系统本身的特质，那么这就是需求分析文档侵入设计的表现；同理，设计师要表达功能的实现，用计算机逻辑去描述业务逻辑，如果只是单独的软件模块，它没有存在的价值，融入功能模块后，它发挥了价值，因为它满足了需求，perfectly meet the need！okay，设计一样侵入了需求。因此我想，需求和设计是两个层面对业务逻辑的描述：业务语言和计算机逻辑。这是描述的侧重点，和选用的语言工具没有直接关系，UML和ER diagram都可以描述业务和软件设计。
    6、交流。
       我希望大家能站出来推翻我的方案，我一样希望每个项目组成员都是项目经理杀手（or架构师杀手），我的理解中也一定存在很多误解甚至错误，所以也希望加强交流，任何形式都可以。虽然我很赞成申鸿伟的周会建议，但是未必是每个人的意愿，有一个人反对face to face的会议，这个会议就没有必要开展，那依据我自己的经历，我也很喜欢邮件会议：群发邮件，群体回复。有兴趣的话可以搭个mail list来做这个工作也没有问题，如果大家知道mail list是做啥的话。