业务用例的继续学习

相对独立性：

可以把一个业务用例的工作隔离开来，因为它的处理与其他的业务用例基本上没有联系，BUC之间唯一的重叠时它们存储的数据。

每个业务用例的相对隔离，可以在利益相关者的帮助下详尽描述这部分工作。

可以确定一个或多个利益相关者，他们是某个业务事件的专家。

业务建模的流程

 

 

业务建模关注： 机构的核心价值 机构的边界 机构的参与者 机构中的工作流及如何优化

业务用例模型(Business Use-Case Model) 业务用户表示为业务参与者(Business Actor) 业务过程表示为业务用例(Business Use-Case)和业务用例实现 业务对象模型(Business Object Model) 人们在组织中扮演的角色表示为业务工人(Business Worker) 组织管理或制造的“东西”表示为业务实体(Business Entity)

一、需求分析任务

需求分析需要实现的是将软件用户对于软件的一系列意图、想法转变为软件开发人员所需要的有关软件的技术规格，并由此实现用户和开发人员之间的有效通信，它涉及面向用户的用 户需求和面向开发者的系统需求这两个方面的工作内容。

1.用户需求

用户需求是用户关于软件的一系列意图、想法的集中体现，涉及软件的操作方式、界面风格、报表格式，用户机构的业务范围、工作流程，以及用户对于软件应用的发展期望等。因此， 用户需求也就是用户关于软件的外界特征的规格表述。 实际上，用户需求提出了一个有关软件的基本需求框架，具有以下特点：

　　（1）用户需求直接来源于用户，可以由用户主动提出，也可以通过与用户交谈，或对用户 进行问卷调查等方式获取。由于用户对计算机系统认识上的不足，分析人员有义务帮助用户挖掘需求，例如，可以使用启发的方式激发用户的需求想法。如何更有效地获取用户需求，既是 一门技术，也是一门思维沟通艺术。

　　（2）用户需求需要以文档的形式提供给用户审查，因此需要使用流畅的自然语言或简洁清 晰的直观图表来进行表述，以方便用户的理解与确认。

　   （3）可以把用户需求理解为用户对软件的合理请求，这意味着，用户需求并不是开发者 用户的盲目顺从，而是建立在开发者和用户共同讨论、相互协商的基础上。

　   （4）用户需求主要是为用户方管理层撰写的，但用户方的技术代表，软件系统今后的操作 者，以及开发方的高层技术人员，也有必要认真阅读用户需求文档。

 

2.系统需求

系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅 读的，并将作为软件开发人员设计系统的起点与基本依据。 系统需求需要对系统在功能、性能、数据等方面进行规格定义，由于自然语言随意性较大， 在描述问题时容易发生歧义，因此系统需求往往要求用更加严格的形式化语言进行表述，例如 PDL 伪码，以保证系统需求表述具有一致性。 系统需求涉及有关软件的一系列技术规格，包括：功能、数据、性能、安全等诸多方面的 问题。

 

（1）功能需求

功能需求是有关软件系统的最基本的需求表述，用于说明系统应该做什么，涉及软件系统 的功能特征、功能边界、输入输出接口、异常处理方法等方面的问题。也就是说，功能需求需 要对软件系统的服务能力进行全面的详细的描述。 在结构化方法中，往往通过数据流图来说明系统对数据的加工过程，它能够在一定程度上 表现出系统的功能动态特征。也就是说，可以使用数据流图建立软件系统的功能动态模型。

（2） 数据需求

数据需求用于对系统中的数据，包括：输入数据、输出数据、加工中的数据、保存在存储 设备上的数据等，进行详细的用途说明与规格定义。 在结构化方法中，往往使用数据字典对数据进行全面准确的定义，例如，数据的名称、别 名、组成元素、出现的位置、出现的频率等。当所要开发的软件系统涉及到对数据库的操作时， 还可以使用数据关系模型图（ER图）对数据库中的数据实体、数据实体之 间的关系等进行描述。

（3） 其他需求

其他需求是指系统在性能、安全、界面等方面需要达到的要求。