系统上下文分析
- 系统上下文分析： 理解现实世界中的问题和用户的需要，并对如何满足这些需要提出解决方案。
一，在问题定义上达成共识
-
做法：将问题用标准化格式记录下来。
问题要素 介绍 问题是… 面临的问题 影响到… 受问题影响的涉众 导致… 问题对涉众和商业活动的影响 方案优点… 新解决方案的优点 -
例子
问题要素 介绍 问题是… 销售订单不准确。 影响到… 销售下单人员，客户，制造者，运输以及客服。 导致… 增加废料，过高的处理成本，客户不满意，而且利润减少。 方案优点… 创建一个新系统解决处理以下问题，包括：- 在入口增加销售订单的准确性，- 改善给管理部门的销售数据报表，- 最后，更高的收益
-
二，理解根本原因——问题背后的问题
-
做法：采用鱼骨图和帕累托图
三，识别涉众和用户
- 动机：必须找出非用户类涉众的需要
- 做法： 问以下问题
- 谁是系统的使用者?
- 谁花钱购买此系统?
- 系统所产生的输出还会影响谁?
- 系统发布和部署时需要谁评估和批准?
- 是否还有其需要必须考虑的内部或外部用户?
- 谁维护这个新的系统?还有谁会在意这个系统?
四，定义解决方案系统边界
- 动机：把世界划分成**“我们的系统”和“与我们的系统交互的事物”**。
- 做法：识别我们系统的参与者（actor）。即通过接口或界面与我们的系统发生交互的人员或事物（装置、设备、系统等）
- 参与者（用户或者其他系统）在系统边界之外，通过I/O界面与系统交互。识别了参与者就明确了系统边界。
五、确定解决方案将受的约束
-
说明：约束限制了我们提供解决方案的自由度
-
动机：进一步理解系统上下文，以免错误地定义和设计系统。
-
做法：通过检查表启发思考。
来源 约束 理由 操作 销售订单数据的精确拷贝必须保存到旧数据库中长达一年。 丢失数据的风险太大，我们需要并行运行3个月。 系统 应用在服务器上运行所需存储空间必须小于20MB。 我们受限于服务器有限的可用存储空间。 设备预算 系统必须在现有服务器和主机上开发，用户所需的客户机硬件可以提供。 我们需要控制成本和维护现有系统。 人员预算 人力资源已固定，没有外包可能。 目前的预算要求固定运作成本。 技术要求 必须使用新的面向对象的技术。 我们相信此技术可以提高生产效率，增强软件的可靠性。
业务建模
- 业务建模： 给出组织机构的业务描述。
- **目的： **
- 理解现存机构的结构和运作机制
- 确保客户、最终用户和开发人员对机构有共同的理解
- 了解如何部署一个新系统以提高效率以及哪些现存系统会受新系统的影响
- 业务建模是针对复杂的信息管理系统，对问题分析5步法的充实、扩展。业务建模是可选过程
- 统一过程（UP）推荐的业务建模方法是使用UML语言，通过业务用例和业务对象表示业务模型。
- 业务用例=业务场景的描述
- 业务对象=业务活动涉及的人、具体物、抽象物、概念等项目
- 业务用例描述业务参与者与业务系统交互的情景。
- 业务参与者可以是业务的服务对象，机构内部工作人员，外部机构等。
业务建模举例
-
格式：用例名，业务参与者，前置条件，后置条件，主要流程。
-
举例：
用例名 用户登录 业务参与者 学生 前置条件 学生拥有有效的账户信息 后置条件 学生成功登录系统，可以访问个人资料和考试相关功能 主要流程 1. 在登录界面输入自己的用户名和密码（用户凭证）2. 点击登录按钮，提交自己的凭证信息。3. 考试系统后端处理登录请求4. 登陆成功跳传到主页面 -
UML的活动图描述业务过程
- 从业务用例或者业务流程图中，可以捕获业务对象模型。
