标准软件需求分析简介

业务建模

无论是否存在计算机，客户的业务都是现实存在的，在业务建模中我们需要将客户的业务进行真实的展现，切不可自己想象，非常多的业务新人就是倒在了这里，导致了客户并不存在的需求出现在最终系统中。

业务建模的目的：

1、了解目标组织的结构及机制

2、了解目标组织中当前存在的问题已及问题的改进可能性

3、确保客户、最终用户以及开发人员就目标组织达成共识

4、导出支持目标组织所需要的系统需求

业务建模的作用：

1、业务建模是需求工作流程的重要起点，通过建模了几系统需求

2、业务实体是分析设计工作流程的重要起点，用例确定设计模型中的实体类。

业务建模是软件工作的最开端，在实际的工作中，以下场景的实际工作就是在进行业务建模。

1）、组织图：我们在进行需求调研的时候通常需要得到调研单位的组织及流程简图，便于更好的构建应用程序/系统的需求。

2）、领域建模：当我们要构建的应用程序/系统的目的是管理或提供信息时，我们需要针对其具体业务构件基于这些信息的的模型，在这个过程中不需要考虑业务的流程。这个工作被称为领域建模。

3）、多系统分析：当我们进行大的系统或多系统的构建时，业务建模的工作可能做为多个系统的共同开端，同时业务建模也是对多系统构架的体现。比如包含：企业信息管理、供应链管理、产品周期管理、决策分析系统等全方位构建。

4）、通用业务模型：通常在构建通用产品模型时我们会提出针对某种行业并提供给多个组织使用的系统。比如某行业销售系统、某行业库存管理系统。在这种场景下，通常会提取多个同行业组织的共同业务和有差异，提出建模工作优先级，通过咨询行业业务专家统一进行全面的业务建模。

5）、新业务：某一组织要开展一个全新业务，同时构建信息化系统对其进行管理时，其先启工作就是业务建模。

业务建模工作流程及步骤：

业务建模是软件过程中的起步阶段，在这个过程中会包括业务用例的建立、概念模型的建立以及领域模型的建立。在开始进行业务模型的建立之前，通常需要对当前客户的业务状态进行评估工作，这个评估工作的结果将对接下来的工作方式、资源投入起决定因素。

通常来说软件需求的客户会分为4种情况：

第一种：客户已有成熟的业务体系，并无需对其进行改进。在这种情况下只需对当前业务描述清晰即可完成。

第二种：客户已有成熟的业务体系，但需要针对业务进行改进和优化。在这种情况下，需要参与客户的业务改进讨论，并达成一致意见，同时需要得到客户的签字同意。

第三种：客户需要通过信息化过程来改善当前的业务模式。这种情况是最为复杂的，业务建模过程中需要考虑到业务的管理、业务流程的建立，需要同客户的管理层建立良好的默契，共同投入方可完成。

第四种：客户已有信息化系统，大部分业务已经清晰，这时只需要对不清晰的部分部分进行业务建模。在这种情况下，我们只需要建立需要分析清楚的业务对象之间的关系，提取出业务规则即可。

业务建模角色及工作产物：

统一软件过程的定义中，在业务建模中有三个角色分别承担不同的工作内容：业务流程分析员、业务设计员、业务模型审查员。

业务流程分析员：

工作内容：评估目标组织、获取业务词汇、查找业务主角和用例、建立业务模型、设定及调整目标、制定业务规则、定义业务架构。

产物：业务词汇表、业务规则、业务用例模型、业务对象模型、目标组织评估、业务前景、业务架构文档、补充业务用例规约。

业务设计员：

工作内容：业务用例详细说明、查找业务角色和业务实体、业务角色详细说明、业务实体详细说明、定义自动化需求。

产物：业务用例说明文档、业务用例实现文档、业务涉众说明文档、组织单元结构图、业务实体对象图、业务角色图。

业务模型审查员：审查业务用例模型、审查业务对象模型

在业务模型建立后，通常需要交付给客户一些业务建模的工作内容，这些内容将成为项目的正式文档，文档的组成部分就是业务设计员角色的所有产物，通过按一定格式对产物进行整合就可以形成可提交客户的正式文档。

系统建模

系统建模的工作是根据业务建模的结果，通过与客户讨论，决定对那些业务进行系统开发，并且规定这些业务如何进行实现。系统模型绝对是基于客户真实存在的业务模型构建，也就是系统模型是业务模型的映射。

系统建模的目的：

1、 与客户和其他涉众在工作内容方面达成并保持一致

2、 使系统开发人员能够清楚的了解系统需求

3、 定义系统边界

4、 为估算开发系统所需的成本和时间提供基础

5、 定义系统的用户界面

系统建模的工作流程及步骤：

系统建模的主要问题是了解我们使用该系统要解决问题的定义和范围。业务建模中提供的业务规则、业务用例模型、业务对象模型将增进我们的理解。如果没有进行过业务建模，那么系统建模将主要依赖于涉众请求。

1、 分析问题

问题分析的目的是理清什么是系统要解决的实际问题，那些是实际涉众。同时要出业务角度提出解决方案，同时对解决方案面临的问题提出制约因素，就这些问题与客户达成一致。

2、 涉众请求

需求是由不同的角色提出，客户、合作伙伴、最终用户、业务专家等。可以通过访谈、讨论、原型设计、问卷调查等方式进行获取。

3、 定义系统

定义系统是指对涉众请求进行建设，并整理为需求说明。在定义系统的初期要明确一下内容：需求构成、文档格式、语言形式、需求的具体程度、需求优先级、工作量预估、风险管理及系统初期规模。

4、 详细系统定义

详细系统定义则是对涉众请求进行系统用例化，通过这种方式描述需求如何在系统中进行实现，用例将包括用例的说明、流程、活动，用例间的关系等。

同时在详细系统定义时要对系统测试提出计划及功能验证的方式，在其中要体现出要核实系统的那些功能。

5、 管理系统规模

为了控制系统的规模，需要针对深圳的需求定义优先级从而对项目规模进行控制。在实际工作中开发人员的注意力经常被他所感兴趣的系统特性所吸引，没有注意到系统整体架构的稳定性或降低系统风险方面，因此一定要引导开发人员避免因此原因造成系统的复杂化、需求扩大化。

6、 管理需求变更

不论我们在需求阶段如何认真工作，需求的变更总会是无可避免的。一个变更的需求会花费或多或少的时间来实现某一个新的系统特性，同时也可能对其他需求造成关联影响。因此我们必须使需求具有可追踪性，但编制需求是一定要注明其与其他需求时候具有关联或依赖关系。在变更是要对关联及依赖进行检查，以便控制需求的变更造成严重损失。

系统建模的角色及工作产物：

统一软件过程中，在系统建模中有5个角色分别承担了不同的工作内容：系统分析员、架构设计员、用例阐释者、用户界面设计员、需求评审员。

系统分析员：

工作内容：制定需求管理计划、确定前景、获取涉众请求、获取业务词汇、查找主角及用例、管理业务依赖关系、经理用例模型

产物：需求管理计划、涉众请求、词汇表、系统前景文档（商业计划书、产品白皮书、市场分析报告、可行性研究报告、产品功能说明书等类似文档，根据系统类型不同而提交产物不同）、用例模型图、补充规约、需求跟踪表

架构设计员：

工作内容：确定用例优先级

用例阐释者：

工作内容：详细说明用例、详细说明软件需求

产物：用例图、用例包、软件需求规约（需求规格说明书：内容包括用例模型、补充诡异、系统原型等产物的集合物）、用例界面映射说明（描述用例从开始到结束在系统中如何体现）

用户界面设计员：

工作内容：用户界面建模、设计用户界面原型

产物：系统人员（角色、岗位等系统定义相关）、边界类、用户界面原型

需求评审员：

工作内容：评审需求

分析设计建模

日常工作中的概要设计和详细设计即为分析设计建模。它主要使用分析模型和设计模型来完成分析设计的过程。分析设计依赖于系统建模，是对系统建模的映射。

分析设计的目标：

1、 将需求转化为未来的系统设计

2、 逐步开发强壮的系统架构

3、 使设计色和与实施环境，为提高性能而进行设计

分析设计建模的工作流程及步骤：

由于分析设计的复杂化，用简单的语言无法进行详尽的描述，因此在描述中将串差一些分析设计的流程图供大家了解。





分析设计流程图（网络图片）

1、 定义及改进架构





定义架构图（网络图片）





改进架构图（网络图片）





改进备选架构图（网络图片）

2、 分析行为

分析行为即为分析用例场景。使用分析类或设计类，同时结合架构和思想用例场景的过程。在分析过程中如果过于深入细节将会极大的增加工作量，因此要根据实际需要进行抽象，从而控制工作量。





分析行为图（网络图片）

3、 设计组件

在统一过程中，组件是实施单元，他代表可放置在架构中的某一位置然后由架构来驱动运行。如果项目中不存在可服用的基础需求，就没有必要进行组件的设计。在当前中国的开发环境中，绝大部分都是按需定制，因此就没有了组件设计的必要。

在软件中组件分为实时和非实时二种，对于我们的设计来说没有很大的区别，但是在实现时由于对系统的稳定性和时间性要求不同对于组件提出了不同的要求。





设计非实时组件图（网络图片）





设计实时组件（网络图片）

4、 设计数据库

数据库设计对于大多数从事软件开发的工作人员来说没有什么特殊的。但是由于我们引入了面线对象的概念，因此对象映射是我们在设计时需要关注的重点，在设计时需要注意不要让代码与数据库结构进行严格的绑定，这样对于以后系统的改进会造成严重的阻碍。可以考虑现有流行的OR-Mapping工具，这些工具可以方便的将归纳出的实体对象转换为数据库设计。处于对客户高层服务的角度，可以对高层关注的数据进行特别优化和保存。

分析设计建模的角色及工作产物：

统一软件过程中，在系统建模中有5个角色分别承担了不同的工作内容：架构设计师、设计员、架构审核员、数据库设计员、封装体设计员、设计审核员。

架构设计师：

工作内容：架构分析、去顶设计机制、确定设计元素、合并现有设计元素、说明运行时架构、说明分布

产物：部署模型、架构文档、分析模型、设计模型、参考架构、协议、接口、信号、事件

设计员：

工作内容：用例分析、用例设计、子系统设计、类设计

产物：用例实现图、子系统设计文档、设计包图、设计类图、分析类图

架构审核员：

工作内容：审核架构

数据库设计员

工作内容：数据库设计

产物：数据模型

封装体设计员

工作内容：封装体设计

产物：封装体

设计审核员

工作内容：审核设计