需求平台介绍

需求平台的作用是帮助需求人员更快更好的完成需求工程。要了解什么是需求平台，我们首先应该理解需求工程的概念。

需求工程是面向业务全局、系统顶层的一种着眼于软件过程全过程的工程，是将客户业务作为内部研究对象、将软件工程实施作为外部研究对象的工程。需求工程是在总体遵循“正向可推导，反向可追溯”的思想下，由需求的规划活动、需求的业务建模过程、需求的系统建模过程所组成的，重视软件非功能特性和需求功能可量化、可验证的一套方法论的集合。

需求工程在我们公司的软件加工中心体系中处在第一个环节，它可以将用户的需求转化为业务模型,便于与客户进行交流确认需求，也能够直接将需求工程转化导出为设计工程，便于软件加工中心后续的软件设计。

  需求工程的模块包括：业务目标、涉众分析、业务对象、业务边界、业务角色、业务用例、业务场景、业务情景、概念实体、系统用户、系统用例、系统模块、系统情景、原型界面。

业务目标：业务目标又称为业务前景，是对要建设的系统的展望。客户立项准备开发一个软件系统，一定会对这个系统有明确的展望，即建设系统的目的是什么、准备用来做什么，而业务目标模块就是对这些信息的一个归纳。

涉众分析：涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分。本模块的作用就是归纳统计每个系统涉众的详细信息。

业务对象：业务对象是需求中收集到的所有单据的初步映射，主要展示出核心信息即可，是后续建模过程实体推导及最终数据库表的源头。本模块的作用是对从用户处采集需求收集到的原始表单、报表进行总结和归纳，为后续分析数据库概念实体做铺垫。

业务边界：业务边界是根据业务目标对系统的边界进行划分与界定。业务边界对于后续需求分析过程中发现业务主角、业务用例具有重要的推导作用。

业务角色：业务角色主要包括业务主角和业务工人，或者说是这两者的集合，主要来源于我们的涉众，涉众列表中的所有角色都是业务角色的候选，业务角色是涉众的子集或者是涉众的细化。业务角色作为业务分析的基础在后续分析中充当一个重要的角色。

业务用例：业务用例是针对业务目标所划定的业务边界的具体化，是结合业务角色和业务边界进行业务建模中的关键步骤。业务用例视图是表达客户业务执行的静态视图，是实现某关联业务目标的具体体现。

业务场景：业务场景是对客户总体业务过程的描述，使用活动图（泳道图）来表达业务的具体执行过程，等同于业务流程图。业务场景视图使用关于反映主要业务过程的业务用例视图的基本业务用例作为活动图中的活动来表达具体业务过程

业务情景：业务情景是由业务用例推导来的动态场景视图，业务情景用来描述一个业务用例在该业务的实际过程中是如何做的，使用活动图来强调参与该业务的各参与者的职责和活动。

概念实体：概念实体是借鉴数据库建模中的ER关系图，由业务对象推导而来，主要展示出核心信息即可，是后续建模过程实体推导及最终数据库表的源头。

系统用户：系统用户是系统最终的操作者，简单的说就是最终使用软件的人。在方法论中用户来源于业务角色，因为具体执行业务的人一般来讲是包括用户的，用户是业务角色的子集。系统用户最为系统分析阶段的基础，在后续系统用例、系统情景的分析中充当重要的角色。

系统用例：系统用例是从计算机系统执行业务的角度来描述业务场景的方式，平时使用UML绘制的用例图大多数情况下就是指这种类型的用例。在方法论中系统用例获取的来源主要在参考业务用例的基础上，以对应的业务情景为主体。

系统模块：系统模块从方法论角度来讲，类似业务建模阶段我们对业务场景汇总的形式，系统模块是对系统用例的按层次汇总。从使用角度来看，系统模块则是我们对系统功能按场景的初步划分，是系统最终进行模块展示和角色授权的依据之一。

系统情景：系统情景是对系统用例执行过程的动态描述，是用户与计算机交互的具体体现，是用户功能性需求的集中显现。

原型界面：原型界面就是系统界面的原型，并不代表是系统的最终实现，可以使用草图来表示。界面原型可以为设计工程中的页面设计提供重要的依据。

上图为需求平台中需求工程的工程树结构，后续我们将会另开帖子对需求平台的各个模块做详细的介绍。大家在使用的过程中遇到什么问题欢迎随时来提问。