第3章 需求分析

解业务、需求，理解软件及其架构如何构造的。
金陵科技学院 软件工程学院
3.1.3 选择建模工具的要点
• 2．正确认识UML
• 表3.2 需求阶段常用的图
使用频率 图名 用例图 主体 活动图 功能 说明角色和使用场景之间的关系 说明业务流程，以及业务活动的步骤 关注要点 人 事
顺序图 类图
描述对象之间的交互 说明业务实体之间的关系，体现结构规则
Constantine 及DE Marco 等人提出和发展，并得到广泛的应用。如同结构化编程一 样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模，建模主 要包括数据流模型（DFD）、数据字典（DD）、实体关系图（ERD）。 • 结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重 点放在对原有系统的建模，是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面，利用结
3.2.1 结构化分析（Structured Analysis）
• 4)在研讨班开设之后，学生可以根据主持教师（的姓名）和研讨班的方向来选择和参加某个研讨班； • 5)所有的学生必须且只能参加一个研讨班的学习；
• 6)研讨班时常会开展活动，由教师来决定活动的时间、地点、主题和做报告的学生（的姓名）；
• 7)每次活动时，由一位或多位同学围绕活动主题做学习报告，交流自己对新技术的学习心得； • 8)每个学生一次活动最多只能作一个报告，但每个学生至少会在一次活动中做一个报告；
• 9)教师对每份活动中的学生报告进行一次点评和指导，提出建议和意见。
金陵科技学院 软件工程学院
• 2．过程建模：数据流图Data Flow Diagram • 数据流图（DFD）就是组织中信息运动的抽象，是信息逻辑系统模型的主 要形式。这个模型不涉及硬件、软件、数据结构与文件组织，它与对系 统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻 辑功能，即所开发的系统在信息处理方面要做什么。 • 由于图形描述简明、清晰，不涉及到技术细节，所描述的内容是面向用 户的，所以即使完全不懂信息技术的用户单位的人员也容易理解。因此 数据流图是系统分析人员与用户之间进行交流的有效手段，也是系统设 计（即建立所开发的系统的物理模型）的主要依据之一。数据流图脱离 系统中的物理因素(如计算机等)，表达出系统对信息的加工情况，DFD可 以描述原系统/新系统/子系统。DFD是SA的主要工具，它简单、直观，用 图形、文字描述系统，它便于使用、便于交流、便于讨论、便于形成共 识，是计算机专业人员和用户单位业务人员的共同语言。
功能点1 子模块1 功能模块1 子系统1 功能模块n 目标系统 ...... 子模块n 功能点n
子系统n
金陵科技学院 软件工程学院
3.1.1 需求分析到底做什么
• (3)基于场景的分解结构 • 适用于决策支持系统、面向用户的嵌入式系统。 • 对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、使用场 景是主要的线索。向上可以总结成一类相似的集合，再总结成一系列的 关注点或者功能域，向下可以分解成具体的步骤或者操作任务。
UML是一种建模语言（Modeling Language），它不是编程语言，而是建模语言。
它不仅包含软件建模，而且可用于业务建模、流程建模等多种领域。UML是统一 建模语言（Unified Modeling Language ），它是一种标准化的、统一的建模语言， OMG认可的工业标准，也是如IBM、SUN等大型公司认可的事实标准。它为参与软 件设计和开发的各类人员提供统一的语言，使开发人员能够基于共同的模型来理
• 需求分析是业务分析，也就是选择一种业务导向的线索将零散的 需求串起来，形成一个体系完整、内容清晰的框架，以指导后续 的设计、开发工作，概括为分解、提炼、消除矛盾三个方面。
金陵科技学院 软件工程学院
3.1.1 需求分析到底做什么
• 1．分解采用自顶向下的方法：采用业务导向的分解
3.1.1 需求分析到底做什么
• 1．分解采用自顶向下的方法： • 采用业务导向的分解 • (1)业务流程为主线索的分解结构，该 分解策略是目前比较流行的方法，主 要按照“业务”的角度考虑分解方法。 此方法特别适合联机事务处理系统、 管理信息系统（MIS）。
系统级
职责区块
金陵科技学院 软件工程学院
岗位间
岗位级
的关联实体或者影响已有的实体特性；最后添加详细的描述信息，实体
的详细属性和关系的基数。
金陵科技学院 软件工程学院
• 1．数据建模：实体关系图Entity Relationship Diagram
• ERD建模的案例： • 1)研讨班在每个学年开始的时候开设，然后持续一个学年； • 2)每个研讨班针对一个或几个研究方向； • 3)每个研讨班由一位或几位教师主持；
3.2.1 结构化分析（Structured Analysis）
3.2.1 结构化分析（Structured Analysis）
• 1．数据建模：实体关系图Entity Relationship Diagram
• 简单情况下ERD建模分四步完成，首先从描述信息中辨识实体，可以重点
关注描述信息中的名词，看系统是否需要收集其相关的特征；然后确定
实体的标识符；进而建立实体间关系，判断各关系的建立是否会产生新
3.1 需求分析概述
• 1准确地回答“系统必须做什么？” • 2需求分析时，要遵循两个基本原则： • 原则一是分析结果需要能够表达和理解问题的信息域和功能域。 • 原则二是以层次化的方式对问题进行分解和不断细化，可以进行 横向分解，也可以进行纵向分解。
金陵科技学院 软件工程学院
3.1.1 需求分析到底做什么
决策步骤/任务1 决策场景/使用场景1 决策场景/使用场景集1 决策步骤/任务n 关注点/功能域1 决策场景/使用场景集n 目标系统 ...... 决策场景/使用场景n
关注点/功能域n
金陵科技学院 软件工程学院
3.1.1 需求分析到底做什么
• (4)基于数据的分解结构 • 适用于诸如数据仓库之类的数据类项目。 • 上述分解策略都是从“业务”角度来组织。但对于类似数据仓库之类的 数据类项目，业务线索并不是十分明显，或者并不重要，这时就需要以 数据为主的分解策略。其中主题域仍然与“业务流程为主的分解策略” 类似。而主题类是企业中的高层实体，主要由一组企业的逻辑数据类来 表示，而企业的逻辑数据类在实现时又会对应于多个物理数据类。
业务事件1 业务活动n 业务事件n 主题域1 报表类型1 报表n 报表类型n 报表1
业务报表n
功能点1
功能点n
目标系统
......
主题域n
3.1.1 需求分析到底做什么
金陵科技学院 软件工程学院
• (2)程序结构为主线索的分解结构：最常用的分解方法 • 适用于问题域不复杂或者系统与问题域关联性不强的情况。 • 当然，由于其过早进入程序结构，割裂了与问题域之间的联系，从而容 易导致对问题域研究的不足，降低了需求的质量。 • 目前认为此种方法仅适合于问题域比较清晰，问题不算复杂的情况，例 如工具软件、嵌入式系统等。
金陵科技学院 软件工程学院
3.1.2 建模的目标与要点
• 建模的目标是帮助需求分析员按照实际情况或按需要的样式对系统进行
可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系
统构造的模板；对需求分析所做出的决策进行文档化。
• 建模的要点是设计要考虑到计划之外的变化；设计要文档化；用可视化 的模型表达架构，有助于理解变化所代表的含义。
• 3.3 第一阶段：理清框架与脉络 • 介绍业务流程分析，业务实体分析，角色与使用场景分析，第一阶段的产物。 • 3.4 第二阶段：确定需求细节 • 介绍确定行为需求的细节，确定结构需求的细节，第二阶段的产物 • 3.5 其他需求分析 • 介绍接口需求，非功能需求的追踪，设计约束，其他需求示例。
金陵科技学院 软件工程学院
• 当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此还需要
采用自底向上的方法进行提炼。 提炼出系统的总体功能结构，更全面的
描述系统。
金陵科技学院 软件工程学院
3.1.1 需求分析到底做什么
• 3．及时发现分析中的矛盾并消除矛盾。
• 在分析过程中，显然会发现有些需求是相互矛盾、相互冲突的，由于分 析是把收集的信息放在一个预先定义的结构中来发现这些矛盾的，因此 对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面，这样， 就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。
去处理。
金陵科技学院 软件工程学院
3.1.3 选择建模工具的要点
• 1．正确认识建模方法论
方法论 时代背景 建模要点
出现于20世纪50～60年代,软件开发 选择适合的数据结构和算法显然是解决此类 程序=数据结构+算法 主要解决的是科学计算问题， 问题的关键 Fortran语言是代表 关键点有两个方法：一是确定有那些数据， 出现于20世纪60～70年代，将解决 格式是什么，如何存储，因此提供E/R模型； 一些与数据处理相关的问题，例如 而是确定数据的加工、处理过程，因此提供 计费等。COBOL、C语言是代表 了DFD(数据流图)
结构化分析与设计
数据并不再是唯一的视角，事（业务流程）、 出现于20世纪80～90年代，信息系 面向对象分析与设计 人的视角越来越重要，因此加入更多这方面 统覆盖了更多业务过程 的建模工具
金陵科技学院 软件工程学院
3.1.3 选择建模工具的要点
• 2．正确认识UML
• UML是一种语言（Language），实际上UML就是一种表示方法，它不是方法论。
金陵科技学院 软件工程学院
第三章 需求分析
制作人：李尤丰 cnlyf@
金陵科技学院 软件工程学院