再谈需求

谈需求工程方面的文章前面写过很多，本文仅做最近思考的一些点滴记录。

首先我们谈下业务建模层面，对于从用户提出最初的业务需求到交付一个完整的系统，在建模层面涉及到两个层面的抽象，其一就是业务建模解决现实世界本身的抽象描述，其二就是软件架构设计，解决从业务模型到IT架构模型的第二次转换。

在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成，在岗位不断细分后我们看到反而会出现忽视了业务建模的问题。即原有的业务需求或用户需求往往转交给了各个业务部门的IT接口人来处理，这些人员往往重点是收集，描述和定义清楚需求，而不关心业务层面的抽象；而对于软件需求往往由IT人员来完成，但是IT的需求人员往往拿到用户需求后直接转化为软件需求层面的内容，同样也忽视了业务建模层面的内容。

流程，活动，数据，组织这些是我们最关心的内容，这些本身就体现从业务到IT的一个转换和承接关系。有业务流程和业务域，才谈得上后面系统层面的业务功能模块；有业务对象才有系统层面的数据对象和数据库表；有业务流程才会有后面的BPEL或流程引擎，有组织岗位和角色才会有系统实现层面的权限模型等。这些都说明了业务层面也需要通过模型进行抽象，业务模型最大的作用是对现实的抽象描述，而不是去考虑IT系统如何去设计和实现。在MDA思想里面也相当强调业务模型本身的重要性，即业务模型本身是和IT架构和实现无关的，仅仅是业务需求内容的抽象表达。

业务建模核心内容是什么? 其中最重要的仍然是把流程和流程中的每个活动搞清楚，把业务对象和数据搞清楚，把业务规则和逻辑搞清楚，把组织角色搞清楚。这些都清楚了基本业务也就清楚了。具体建模的时候是用EPC还是UML模型已经不再是最重要的了。

业务需求和用户需求，这两个相当来说是比较容易混淆的，对于不同的企业有些业务需求文档往往已经到用户需求层面，或者有些企业用户需求仅仅又是业务需求。业务需求简单来说是目标和范围，是把问题搞清楚，把期望的目标搞清楚，即业务需求层面往往并不一定有解决方案和思路，有具体实现业务需求的具体业务步骤。但是用户需求不同，用户需求重点是要详细说明业务方案，说明具体用户要操作的方法和步骤，对每一个用户需求点都要描述清楚。所以我们也常说首先是拿到业务需求，我们经过了需求调研后详细需求收集后，才能够准备形成条目化的用户需求；在经过需求分析和建模后才能够转化为软件需求。

做一个好的需求人员相当难，首先是你要能够对参与的业务有较为深入的理解，其次是要能够根据已有的知识和技能积累，将理解的内容进行业务建模和抽象，并最终形成架构设计阶段可以参考的需求文档。有时候我们拿到一份需求文档就会发现很多问题，其中最重要的就是需求本身对业务没有深入的理解就写出来了，那么需求实现后要解决的实际业务场景和问题是什么可能需求人员都不清楚；其次就是建模能力缺失后，导致整个需求文档本身的结构，分类，层级，关系不清晰；简单来说就是当面对一个复杂的业务场景或业务需求的时候，需求人员本身并没有通过建模的思路分而治之，或者说给出可行的业务解决方案。

为什么强调业务建模和架构设计要分离，还有一个重要的原因就是在业务阶段我们往往考虑了太多IT实现层面的内容而潜意识里面妨碍我们对业务的理解，对业务本身的抽象。这里面不仅仅是软件需求人员，包括已经长久使用了IT系统的用户，都会存在这个问题，即在需求阶段给出的不是业务需求或用户需求，而是直接给出了IT系统功能实现，这将直接导致我们在需求阶段深入的去理解业务背景和场景，无法对业务形成一个全局和端到端的认识就陷入了实现层面的细节。将业务建模和系统建模分离和解耦本身也体现了我常说的SOA松耦合思想。

前段时间在知乎看到一个问题，即在写软件需求的时候经常将需求文档写成了操作手册，怎么破解这个问题？其实这个问题的本质还是忽视了业务建模环节，这样就很容易在进行需求定义的时候直接跳入到了实现环节进行思考，但是这种实现方式是否最好往往并不应该是需求人员回答的问题。记得很早看过一本书，将需求建模进一步进行了延伸，即需求最基本的还是传统的用例建模的内容，这个清楚后可以进一步考虑界面建模和交互建模，但是后者本身并不是必须的，或者说我们更应该将其下移到设计和实现阶段再去考虑。

以业务场景下的业务流程分析入手，分解到具体的业务子流程和活动节点，再考虑业务活动和业务对象本身的耦合关系划分业务域和业务组件，同时根据业务活动识别出对应的业务用例，根据业务用例本身的实现来进一步分析业务组件间的接口和服务交互关系，对业务活动中使用到的业务对象单独出来进行业务对象模型分析和设计，即是我讲的有业务流程和建模贯彻到软件需求和用例分析的全过程。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密