第6章 软件需求分析与建模.ppt

软件需求概论 第6章 需求分析与建模最佳实践 6.1 需求分析与建模的要点 与误区分析 6.1.1 需求分析到底做什么 6.1.2 建模的目标与要点 6.1.3 选择建模工具的要点 6.1.1 需求分析到底做什么 需求分析是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。 概括为：分解、提炼、消除矛盾 需求分析到底做什么之一：分解 分解：自顶向下的方法 现代需求工程理论更建议采用业务导向的分解，而非传统的系统导向的分解。 分解结构类型 (1)业务流程为主线索的分解结构 联机事务处理系统、管理信息系统适用。 (2)程序结构为主线索的分解结构 适用于问题域不复杂或者系统与问题域关联性不强的情况。 6.1.1 需求分析到底做什么 (3)基于场景的分解结构 适用于决策支持系统、面向用户的嵌入式系统 (4)基于数据的分解结构 适用于诸如数据仓库之类的数据类项目 选择了一个合适的分解结构之后，就可以把需求规格说明书的大纲确定下来，知道应该捕获什么信息；因此当信息捕获回来后，需求分析的任务就是将其填充到相应的级别上，并不断验证是否已经填充完成。 需求分析到底做什么之二：提炼 提炼：自底向上的方法 分解是一种自顶向下的方法，当你按任何一种线索进行分解时，就会破坏其他线索的完整性。例如，如果以“事”为线索，那么会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。 当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此我们还需要采用自底向上的方法进行提炼。 需求分析到底做什么之三：消除矛盾 在分析过程中，显然会发现有些需求是相互矛盾、相互冲突的。由于你是在把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，你就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。 6.1.2 建模的目标与要点 建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识 1.建模的目的 帮助我们按照实际情况或按我们需要的样式对系统进行可视化； 提供一种详细说明系统的结构或行为的方法； 给出一个指导系统构造的模板； 对我们所做出的决策进行文档化。 6.1.2 建模的目标与要点 2．建模的要点与原则 要点： 设计要考虑到计划之外的变化； 设计要文档化； 用可视化的模型表达架构，有助于理解变化所代表的含义。 原则：模型是用来沟通的，需要时才构建。 6.1.3选择建模工具的要点 1．正确认识建模方法论 6.1.3选择建模工具的要点 2．正确认识UML UML是一种Language(语言) ！ UML是一种Modeling(建模)Language! UML是一种Unified(统一)Modeling Language！ 如何选择UML图 ？ 第6章 需求分析与建模最佳实践 6.2 周期一:理清框架与脉络 6.2.1 业务流程分析 6.2.2 业务实体分析 6.2.3 角色与使用场景分析 6.2.4 周期一的产物 6.2 周期一:理清框架与脉络 6.2.1 业务流程分析 这个阶段的任务是理清需求的结构框架(领域类图)和行为脉络(流程图和用例图) 该工作的输入是需求定义阶段产生的业务事件列表和报表列表，输出的是领域模型和用例模型 在整个过程中是针对每个业务事件进行业务流程分析、业务实体分析和用例分析；针对每类报表业务实体分析和用例分析。 6.2.1 业务流程分析 业务流程分析是针对每个业务事件来进行的，业务事件是业务流程的触发，沿着对业务事件的响应序列，找到所有相关的业务活动，表述出这些业务活动之间的关系就是该任务的关键目标。 在业务流程分析中，信息的主要来源是负责该业务流程的中层管理人员，因此访谈的对象就是这一类人员。具体来说，它就是针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接受哪些信息，将产生哪些数据(表单)，确定数据传送的路线；同时标识出业务活动是由哪些部门、岗位负责等信息。 在分析过程中，要注意抓住核心业务和主要活动点、部门内以及部门之间的衔接，工作中的烦琐及反复的环节，成本高、效率低、时间长的环节以及任务转手次数较多的环节。 1. 业务流程分析的要点与产物 关键的要点： 一是理解流程的层次性； 三大层次 ：组织级，部门级 ，岗位级 二是了解流程的类型； 生产性流程，管理性流程，支持性流程 三是掌握以业务事件识别、寻找流程的技巧。 流程分析产物，最常使用的模型有三种：跨职责流