2011年软考系统架构设计师学习笔记第十四章3

 14.3.2 需求分析的任务

　　1、需求分析的目的

　　完整、准确地描述用户对系统的需求，跟踪用户需求的变化，准确地反映到系统架构和设计中，设计和用户的需求保持一致。

　　具有决策性、方向性、策略性的作用。

　　2、需求分析的特点

　　追求系统需求的完整性、一致性、验证性。

　　保持和用户要求同步，

　　保持需求分析各侧面之间的一致，

　　保持需求和系统设计间的同步。

　　14.3.3 需求文档与架构

　　每个用例都有一个相关需求的文字描述，定义用例应该和领域专家一起进行，如果没有领域专家的长期参与，只能是一种"伪分析"。

　　用例为定义架构提供了一个系统的领域行为模型。

　　界面的外观、功能、导航同用例紧密相连，有效定义屏幕的方法叫低保真度原型(Low-fidelity Prototyping)，领域专家也始终参与到屏幕定义中去。

　　需求分析的项目词汇表，也将在架构规划中被扩展。

　　14.4 系统架构设计

　　系统架构沟通了需求和软件之间巨大的语义上的鸿沟。

　　系统架构的第一个任务就是定义这两个极端之间的映射。

　　开放分布式处理(Open Distributed Processing，ODP)包括企业、逻辑信息、计算接口、分布式工程、技术选择。

　　对每个观点，确认架构需求的一致性是非常重要的。

　　14.4.1 企业业务架构

　　企业业务架构从IT角度，对企业的业务结构、企业机构、业务的关系、内部的关系、与外部机构的关系进行整理定义。

　　包含如下内容：

　　1、企业的业务和战略目标，近期、中期、长远 目标。

　　2、企业的组织结构。

　　3、业务的分类。

　　4、各类业务之间的关系。

　　5、组织机构与业务的关系。

　　6、企业与外部机构的关系。

　　这些业务对象模型标识出系统的关键性约束，包括系统目标和重要的系统策略。

　　策略包含如下三类明确的表达方式：

　　责任：业务对象必须做什么。

　　许可：业务对象可以做什么。

　　禁止：业务对象不可以做什么。

　　对业务问题进行分析时，要考虑企业业务的发展，如新的服务或产品推出、考虑组织机构的改变等。

　　所有这些可能的变化(易变场景)都应该提现在企业业务架构中。

　　通过对企业业务架构的定义，很清楚地知道由于企业业务特点、业务的流程特点、企业的组织机构等原因对IT系统所带来的自然分块和各个分块之间的边界关系。

　　企业业务架构的维护是一个长期而反复的工作。

　　测试结果报告系统(Test Results Reporting System，TRRS)。

　　对象约束语言(Object Constraint Language，OCL)来定义企业活动者的这些策略(如 许可、禁止、义务等)。