第三讲需求分析与建模
第3章 软件需求分析与建模
就是要通过软件开发人员与用户的交流和讨论，准确地
获取用户对系统的具体要求,见图1.11。 需求分析阶段 理解需求 生成、提交 作为 设计阶段的依据 图3.2 结束 7
软件规格说明书
2015-6-1 返回
第1章 软件工程引论
1.3 软件生存期(software life cycle)
（1）软件定义时期 软件定义部分又可划分为问题定义、可行性研究和需 求分析三个阶段。 撰写 任务
2015-6-1 返回 结束 31
第3章 软件需求分析与建模
3.2 数据建摸
3.2.2 方框层次图 层次方框图非常适合描述自顶向下的需求分 析方法中数据的层次关系。 系统分析员可以从对顶层信息的分类开始， 沿着层次图中的每条路径逐步细化，直到确定 了数据结构的全部细节为止。
2015-6-1
返回
结束
需求分析员 软件设计人员
留下隐患 花时搞清需求 建好模型
用户
问题二 图3.3 2015-6-1 返回
系统模型 9
结束
第4章 软件需求分析与建模 功能需求 非功能需求 用户需求 业务需求
(3) 系统的需求分类 是从各个角度对系统的约束和限制，反映了应用对 定义了开发人员必须实现的软件功能，使得用户能完 反映了组织机构或客户对系统或产品高层次的目 描述了用户使用产品必须要完成的任务，可以在 软件系统质量和特性的额外要求。主要包括： 成他们的任务，从而满足了业务需求。 用例模型或方案脚本中予以说明。 标要求，它们在项目视图与范围文档中予以说明。 过程需求(如交付需求、实现方法需求等) 主要说明了待开发系统在功能上实际应做些什么，是 产品需求 (如可靠性需求、可移植性需求、安全保密性 需求 ) 用户最主要的需求。通常包括系统的输入、系统能完成 外部需求(如法规需求、费用需求等)等。 的功能、系统的输出及其他反应。
信息系统开发中的需求分析与建模
信息系统开发中的需求分析与建模需求分析是信息系统开发过程中的重要一环，它负责确定用户需求和系统功能的对应关系，为系统的设计与建模提供依据。
本文将探讨信息系统开发中的需求分析与建模的关键步骤和方法。
一、需求分析的定义和重要性需求分析是在信息系统开发的初期阶段，通过与用户的交流和沟通，明确用户的需求，并将这些需求转化为对应的系统功能和特性。
需求分析的目标是确保开发团队和用户对系统的期望达成一致，并为后续的设计和实施提供基础。
需求分析的重要性体现在以下几个方面：1. 利益相关者满意度：准确理解用户需求，可以提供满足用户期望的系统，提高用户满意度；2. 成本控制：需求分析可以避免后期需求变更带来的开发成本和时间的增加；3. 项目规模管控：通过需求分析，可以明确项目的边界和目标，有效控制项目规模；4. 风险控制：需求分析可以发现并规避项目中的潜在风险。
二、需求分析的关键步骤1. 沟通与交流：开展需求分析的首要任务是与用户进行深入的沟通与交流，了解用户的需求和期望。
可以通过面谈、问卷调查、焦点小组等方法获取用户需求信息。
2. 需求收集与整理：收集并整理用户需求，将其转化为可理解和可操作的形式，以便后续的分析与设计。
3. 需求分析与验证：对收集到的需求进行分析和验证，确保其具备可行性和合理性。
需要明确需求的优先级和重要性。
4. 需求规格说明：将分析和验证后的需求进行规范化和详细说明，以便于后续的设计与建模。
5. 需求确认与确认：与用户再次确认需求，确保双方对需求的理解一致，避免后期的纠纷和修正。
三、需求建模方法需求建模是将需求规格化和可视化的过程，通过建立不同层次和抽象级别的模型，明确描述系统的功能和特性。
以下是常用的需求建模方法：1. 数据流图（DFD）：DFD图是一种描述系统功能和数据流动的图形工具，通过表示系统中的数据流、数据处理和数据存储，清晰地展示了系统的输入、处理和输出过程。
2. 用例图（Use Case Diagram）：用例图是描述系统与外部实体之间交互的图形模型，通过定义参与者和系统之间的交互关系，具体描述了系统功能和特点。
系统需求分析与建模
系统需求分析与建模一、引言对于系统的设计与开发来说，需求分析与建模是至关重要的环节。
系统需求分析与建模可以帮助我们全面理解用户的需求，并将其转化为系统功能与特性的清晰描述。
本文将探讨系统需求分析与建模的基本概念、方法和工具，并介绍如何有效地进行需求分析与建模。
二、系统需求分析系统需求分析旨在识别和明确系统的功能、性能和约束条件。
以下是系统需求分析的几个主要步骤：1. 需求获取和理解需求获取是指通过与用户、业务分析师和相关利益相关者的沟通来收集和理解系统需求。
这可以通过面对面的会议、问卷调查、用户访谈等方式进行。
重要的是要确保获取到的需求能够准确反映用户的期望和业务的要求。
2. 需求分析和整理需求分析的目标是将收集到的需求进行分类、整理和整合。
可以使用流程图、数据流图、用例图等工具来分析和描述系统的功能和流程。
同时，需求分析还包括对需求的可行性和优先级进行评估。
3. 需求验证和确认在需求分析的最后阶段，需要与用户和相关利益相关者一起验证和确认需求的准确性和完整性。
这可以通过演示、原型展示或者文档审查等方式进行。
目的是确保需求可以满足用户和业务的期望，并且没有遗漏或冲突。
三、系统需求建模系统需求建模旨在将需求以图形化的方式进行描述和表达，以便于更好地理解和交流。
以下是系统需求建模的几个常用方法：1. 用例图用例图是描述系统与其用户之间交互的图形化表示。
用例图可以帮助我们理解系统的功能与角色，并识别各种场景及其对应的用例。
用例图可以用来指导后续的系统设计和开发工作。
2. 数据流图数据流图是描述系统内部数据流动和处理过程的图形化表示。
数据流图以数据流和处理器为中心，展示了系统的功能和数据流动的过程。
数据流图可以帮助我们识别系统的数据流向和处理逻辑。
3. 状态图状态图是描述系统各个对象的状态及其状态变化过程的图形化表示。
状态图可以帮助我们理解系统的行为和状态转换规则。
通过状态图，我们可以更好地描述系统的状态变化及其对应的操作和事件。
需求分析建模技术
项目需求分析1. 需求分析概述1.1 需求分析定义需求分析是指理解用户需求，就软件功能和性能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。
在这个过程中，用户处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。
需求分析阶段结束后，要求得到《用户需求说明书》和《需求规格说明书》两份文档。
广义上，需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上的需求分析是指需求的获取、分析及定义的过程。
需求分析的任务就是软件系统解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求的过程。
1.2 需求分析的根本任务从实践角度考虑，需求分析不是分析如何实现用户的需求。
实际上，需求分析是以业务分析为导向，将用户零散的需求串联起来，形成一个体系完成、组织合理、内容清晰的框架，为今后的设计开发工作打下良好的基础。
1、建立分析模型⏹将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征。
⏹和用户达成对信息内容的共同理解。
⏹分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息。
2、创建解决方案⏹将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找解决方案。
⏹创建解决方案的过程是创造性的。
⏹帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关系。
⏹这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案的正确性。
1.3 需求的层次1、业务需求反映组织机构或客户对系统、产品高层次的目标要求。
通常问题定义就是业务需求2、用户需求描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求3、系统需求从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束1.4 需求分析的重要性如果投入大量的人力、物力、财力和时间，而开发出的软件却没人要，那么所有的投入都是徒劳。
第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
软件需求分析和建模
易变问题：分清需求稳定部分和易变部分
收集活动： 识别真正的客户/用户 正确理解客户的需求
耐心听取客户意见和思考
尽量使用符合客户语言习惯的表达
25/150
2.3 分析和精化
开发一个精确的技术模型，用以说明软件的功能、 特征和约束。
精化是一个分析建模动作，由一系列建模和求精 任务构成
2.1.2 扩展流程：......
31/150
系统需求
系统需求是比用户需求更详细的需求描述，是系 统实现的基本依据
系统需求描述可能包括许多不同的模型，如对象 模型和数据流模型
32/150
软件需求各组成部分之间的关系
33/150
软件需求规格说明的原则
从现实中分离功能，即描述要“做什么”而不是 “怎样实现”
用户交流不够 需求规约质量差 低效的需求分析
有拓展性的系统设计，才会给 系统更大的扩展空间，从而在 需求发生变化的时候可以更从 容的修改。
13/150需求分析的Fra bibliotek要性需求的重要性： 需求是产品的根源，需求工作的优劣对产品影响最大。 是系统开发的基础，质量和成败的关键 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一 直忙碌不停地开发。
软件工程方法与实践
软件需求分析与建模
..
1
主要问题
什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 什么是面向数据的建模？ 什么是面向数据流的建模？ 什么是非形式化建模、半形式化建模和形式化建模？ 什么是统一建模语言（UML）？ 什么是用例建模？ 什么是领域模型？
2/150
软件需求分析过程
软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“产品”， 它是客户、管理者、分析工程师、测试工程师、 维护工程师交流的标准和依据。
软件需求分析与系统建模
软件需求分析与系统建模软件需求分析是软件开发过程中的关键步骤之一，它是在系统开发的初期，对用户需求进行深入分析和理解的过程。
通过软件需求分析，可以准确地确定系统的功能需求、性能需求、安全需求等，为后续的系统设计和开发工作提供指导和参考。
在需求分析的过程中，系统建模是一种有效的方法，它能够以图形化的方式表达系统的各种模块、组件、操作和数据之间的关系，帮助开发团队更好地理解和描述系统的结构和行为。
本文将介绍软件需求分析与系统建模的相关知识和方法。
一、软件需求分析软件需求分析是系统工程中的一项基础性工作，它主要包括以下几个方面：1.1 需求收集需求收集是软件需求分析的第一步，它通过与用户、管理人员、开发团队等进行沟通和交流，获取到系统的需求信息。
需求收集的过程中，可以采用面对面访谈、问卷调查、文档分析等方法，确保获取到全面、准确的需求信息。
1.2 需求分析需求分析是对需求进行分类、整理和分析的过程。
在需求分析的过程中，可以使用需求建模技术，将需求分解为不同的功能模块或子系统，以便更好地进行后续的设计和开发工作。
1.3 需求验证需求验证是验证需求的合理性和正确性的过程，它通常包括需求评审、原型验证、用户验收等环节。
通过需求验证，可以确保系统需求符合用户的期望和要求。
二、系统建模系统建模是通过图形化的方式描述系统的各种组成部分和它们之间的关系。
常用的系统建模方法有数据流图、用例图、类图等。
下面将分别介绍这些系统建模方法的基本原理和使用场景。
2.1 数据流图数据流图是一种图形化工具，用于描述系统中数据的流动和处理过程。
数据流图由数据流、处理、数据存储和外部实体等要素组成，通过连接和箭头来表示它们之间的关系和交互。
数据流图适用于描述系统的数据流程和功能。
2.2 用例图用例图是一种描述用户与系统之间交互的图形化工具。
用例图由参与者、用例和关系等要素组成，通过参与者和用例之间的连线来表示它们之间的交互关系。
用例图适用于描述系统的功能需求和用户需求。
第3章 需求分析及功能建模方法
第3章需求分析及功能建模方法3.1 需求分析概述3.1.1 需求分析概念1、所谓需求分折：就是对待开发的系统要做什么，完成什么功能的全面描述。
2、需求分析的工作：通过对需求的调查、了解、观察和分析，通过对原始数据的收集、分类和抽象，并采用有效的技术、工具，对原始资料进行加工整理，描述开发目标、实现的功能及其相互关系等活动的集合;3、需求的定义：客户对一个待开发的系统在实现目标、完成功能、应达到的性能、安全性、可靠性等方面的期望和要求的集合;4、需求获取的困难：(1) 软件功能复杂;(2) 需求的可变性;5、需求分析阶段的主要任务：分析当前的业务流程，包括体系结构，各职能部门完成的主要任务、关系及其交流的信息。
6、需求分析的结果通常以模型等建模工具和方法描述系统的信息流、功能结构及完成各功能需要的数据。
7、功能模型和软件需求规格说明书是软件开发的依据，将指导后续的开发工作。
8、需求分析工作是系统分析员与用户不断交互的过程中完成的。
3.1.2 系统分析员的职能1、系统分析员的主要要任务：是确定应用信息系统及软件产品应该达到的各项功能性要求和非功能性要求，即用户要做什么。
2、系统分析员应该具备的素质：(1) 获取需求的能力;(2) 管理及沟通能力;(3) 技术素养;3.1.3 需求获取的方法常用的几种获取需求的方法：(1)面谈;(2)实地观察;(3)问卷调查;(4)查阅资源;3.1.4 需求分析过程1、标识问题：(1) 需求分析的第一步，通过对问题的识别和标识获得所求解问题及其运行环境的理解;(2) 标识问题从现行系统的业务流程做起，理解现行系统的业务流程;(3) 在标识理解需求的同时，还要注意确定系统的人机界面;2、建立需求模型：(1) 模型是对现实原形所作的一种抽象，其本质是只关心与研究内容有关的因素，而忽略无关的因素，其目的是把复杂的事物变得简单，便于认识和分析;(2) 目前常用的模型方法主要有DFD数据流图和IDEFO，都属于结构化分析方法，其特征是抽象和分解;(3) 首先对应用领域进行全面的分析，发现并找出同类事物的本质，用抽象方法把这类事物的非主要方面剔除，把握住事物的内部规律或本质，就可以找到解决办法;然后采用自上而下逐步求精的方法对复杂的问题进行分解;(4) 结构化分析及建模方法的主要优点：(A) 不过早陷入具体的细节;(B) 从整体或宏观入手分析问题;(C) 通过图形化的模型对象直观地表示系统要做什么，完成什么功能;(D) 图形化建模方法方便系统分析员理解和描述系统;(E) 模型对象不涉及太多的技术术语，便于用户理解;3、描述需求：(1) 需求描述的目标：对软件项目功能性和非功能性的需求全面描述;(2) 功能性需求：指需要计算机实际解决的问题或实现的具体功能，明确描述系统必须做什么，实现什么功能以及输入输出等;(3) 非功能性需求：软件项目对实际运行环境的要求;(4) 需求描述主要由需求模型和需求说明书组成，说明书侧重文字说明，内容如下：需求概述;功能需求;信息需求;性能需求;环境需求;其他需求;(5) 在对需求进行分析过程中，系统分析员要经常考虑的问题：(A) 描述的需求是完全的吗?(B) 需求描述是正确的和一致的吗?(C) 描述的这些需求是可行的、实际可操作的吗?(D) 描述中的每一条需求都是客户需要的吗?4、确认需求：1、评审委员会审核下列内容：功能需求;数据需求;性能;数据管理;其他需求。
需求(用例)分析与建模
3、统一建模中的“统一”含义
（1）软件开发的整个生命周期都可以用可视化建模技术统一起 来，避免“分而治之”（业务流程图、ER图、DFD图等）。 （2）在传统的开发技术中，这些步骤是由不同的技术完成的， 如业务模型是由IDEF 语言来描述，分析设计由数据流图来表 示，数据库结构是用ER 来定义等等。 （3）通过统一建模语言UML，可以大大增强团队的沟通，提高 开发效率和软件质量
用例图 包图、类图、对象图 组件图和配置图
（2）动态建模---动态建模机制包括
时序图和协作图 状态图和活动图
8、何时需要建模 （1）在应用开发的任何阶段进入建模工作都是有意义的 （2）在设计最初阶段 无可否认的是，在设计最初阶段，应将精力主要用 于处理有关应用系统功能、为实现这些功能应采用何种 开发平台、编程环境等技术手段，而不是考虑程序的细 节---如在屏幕上的什么位置应该放置什么按钮等。 （3）在项目开发的中期引入建模也是非常有意义的 Ratioal Rose既支持正向建模，同时也支持反向建模。
需求（用例）分析与建模
在本讲您能了解如下知识点
需求分析？重点和内容？ 系统建模？为什么？如何？ 面向对象的统一建模 利用UML实现面向对象的建模 动、静态建模所涉及的UML图 体验UML中的基本建模过程
一、需求（对用例）分析
1、需求分析概述---系统概要设计的输入来自于需求工程 （1）什么是需求分析
类图----显示系统中类与类之间的交互 状态图（当然也包括其它的动态视图）---显示一个对象 从生成到删除的生命周期
希望您能够区分与分析阶段 中所出现的类图的不同！
（4）编程(构造)是一个相对独立的阶段
任务：是用面向对象编程语言将来自设计阶段的类转换成 实际的代码。 要点 在用UML建立分析和设计模型时，应尽量避免考虑把模型 转换成某种特定的编程语言。 因为在早期阶段，模型仅仅是理解和分析系统结构的工具， 过早考虑编码问题十分不利于建立简单正确的模型。 所用到的UML的图 包图----显示系统中类与类之间的集合关系 类图----显示系统中类与类之间的交互 组件图---表示系统中的组件及相互依赖性
软件设计师中的软件需求分析与建模
软件设计师中的软件需求分析与建模软件设计师在软件开发过程中扮演着重要角色，他们负责分析用户需求并将其转化为软件系统的详细规格。
软件需求分析是软件设计的关键环节，而软件建模又是软件需求分析的重要工具。
本文将探讨软件设计师在软件需求分析与建模中的作用与方法。
一、软件需求分析软件需求分析是软件设计师在开发软件之前必须进行的过程。
它的目的是理解用户需求，明确软件系统应该具备的功能和性能。
软件需求分析的核心是搜集和整理用户需求，并将其转化为明确的软件规格。
1. 需求搜集软件设计师需要与用户进行沟通，了解他们的需求。
这可以通过面对面的访谈、问卷调查、用户反馈等方式进行。
设计师需要倾听用户的意见和建议，并深入了解他们的业务流程和需求。
2. 需求整理在搜集用户需求之后，设计师需要对其进行整理和分类。
将用户需求整合为一个需求文档，明确每个需求的优先级和重要性。
这有助于后续的软件设计和开发过程。
3. 需求验证需求验证是确保软件规格准确无误的过程。
设计师需要与用户再次沟通，确保需求文档中的每一个需求都准确地反映了用户的期望。
在需求验证过程中，设计师还可以通过原型设计、模拟演示等方式，让用户更好地理解软件系统的功能。
二、软件建模软件建模是将用户需求转化为软件系统的具体设计。
它通过建立模型来描述软件系统的结构、行为和交互，为软件开发提供指导。
1. 功能模型功能模型是描述软件系统如何满足用户需求的模型。
常用的功能建模工具有数据流图、用例图等。
设计师可以通过这些工具，清晰地展现软件系统的功能和流程，帮助开发人员更好地理解和实现需求。
2. 结构模型结构模型是描述软件系统组成结构的模型。
常用的结构建模工具有类图、对象图等。
设计师可以使用这些工具，展示软件系统中对象之间的关系与属性，有助于编写高效且易于维护的代码。
3. 行为模型行为模型是描述软件系统动态行为的模型。
常用的行为建模工具有状态图、活动图等。
设计师可以通过这些工具，展示软件系统在不同状态下的行为和交互，帮助开发人员理解和实现系统的逻辑。
第3讲 需求分析阶段-过程建模
数据流图－外部实体
• 外部实体的图形表示：
– 在图形描述中，外部实体都需要一个名称来标识自己，它们通常会使用 能够代表其特征的名词为名称。
Lable Lable Lable Lable
DeMarco-Yourdon表示法
Gane-Sarson表示法
数据流图－外部实体
• 在实践中，常见的外部实体有：
DFD分层结构-N层图
• 0层图中的每个过程都可以进行分解，以展示更多的细节。被分解的 过程称为父过程，分解后产生的揭示更多细节的DFD图称为子图。对
– 对0层图的过程分解产生的子图称为1层图。 – 对子图中的过程还可以继续分解，即过程分解是可以持续进行的，直到 最终产生的子图都是基本DFD图。对N层图的过程分解后产生的子图称 为N+1层图（N>0）。 – 在低于0层图的子图上通常不显示外部实体。父过程的输入输出数据流称 为子图的接口流，在子图中从空白区域引出。如果父过程连接到某个数 据存储，则子图可以不包括该数据存储，也可以包括该数据存储。 – 子图中过程的编号需要以父过程的编号为前缀。
数据库系统设计
需求分析阶段－过程建模
概述
• 过程（处理）建模是结构化分析方法的典型技术。 • 过程建模将系统看做是过程的集合，其中一些由人来执行，另一些由 软件系统来执行。 • 过程的执行就是对数据的处理，它接收数据输入，进行数据转换，输 出数据结果。 • 过程执行时可能需要和软件系统外的实体尤其是人进行交互，会要求 外界提供数值输入或者将数据结果提供给外部实体。
• 其中
– 上下文图是DFD的一个特定层次，被用来说明系统的上下文环境，确定 系统的边界。 – DFD被用来建立过程的分解结构。
– 微规格说明被用来描述DFD过程分解结构中最底层过程的处理逻辑。
如何实现对软件系统进行需求分析与建模
序代码能够满足用户的需求 并且代码还能回溯需求的过程
（2）为什么要建模
通过建模可以更好地帮助开发人员理解正在开发的系统 同时也能够表达我们所渴望的系统结构和行为、展示和
控制系统体系结构，最终达到风险控制之目的。
通过建模可以实现把复杂的系统简单化
（3）面向对象的建模与结构化模型设计方法的不同 传统的结构化模型的设计所建立的模型不能反应源代 码，与程序设计脱节。 模型与代码几乎没什么关系。
二、域模型
1、什么是"问题域"和"域建模" （1）问题域
如金融、财务等
现实世界中系统所要解决问题的领域为“问题域”
（2）域建模---对问题域中的各个问题进行建模
我们设计一个系统，总是希望它能解决一些问题，这些问题总 是映射到现实问题和概念。 而对这些问题进行归纳、分析的过程就是域建模（这个域，指 的就是问题域）。
（1）ATM系统自动售票系统的功能性需求 （2）ATM系统自动售票系统的非功能性需求 （3）找出名词短语------域模型 （4）发现出类及类之间的关系
4、建模实例二：某一网站域模型的建立例
（1）用户所罗列出的一些需求 （2）需求分析 （3）找出名词短语------域模型 （4）发现出类及类之间的关系
5、建模实例三 下面给出"铁路呼叫中心"项目的功能性和非功能性 的需求，从而获得"问题域"中的相关的类；
（1）呼叫中心项目的功能性需求 （2）呼叫中心项目的非功能性的需求 （3）找出名词短语------域模型 （4）发现出类及类之间的关系
4、动态建模及设计要点 （1）UML的动态建模机制
主要的UML图
包括时序图、协作图、状态图和活动图等； 动态建模描述了系统随时间变化的行为，这些行为是用从静 态视图中抽取的瞬间值的变化来描述的。
软件需求分析与建模基础
软件需求分析与建模基础火龙果整理火龙果整理目录一什么是需求分析二系统建模三需求分析建模实例四经验总结目录一什么是需求分析1.软件生命周期2.需求分析的定义火龙果整理3.需求分析阶段的重要性4.需求分类5.需求捕获6.需求过程定义火龙果整理一、什么是需求分析？1、软件生命周期(SDLC-SoftwareDayLightCycle)同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期。
《软件工程国家标准—计算机软件开发规范》(GB8566—88)中将软件生命周期划分为8个阶段：可行性研究与计划需求分析概要设计详细设计实现(包括单元测试)组织测试(集成测试)确认测试使用和维护火龙果整理一、什么是需求分析？2、需求分析的定义是软件工程中的一个关键过程；是系统分析员进行软件功能和性能分析的依据；是指明软件和其他系统元素的接口、是建立软件必须满足的约束；是软件设计师进行软件分解的基础；是软件处理的数据模型、功能模型和行为模型；是软件设计师翻译成数据、体系结构、界面和过程设计的模型；是进行质量评估的依据。
火龙果整理一、什么是需求分析？3、需求分析阶段的重要性根据StandihGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。
而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。
也就是说，有近45%的项目最终因为需求的问题最终导致失败。
火龙果整理一、什么是需求分析？4、需求分类业务需求：反映组织机构或客户对系统、产品高层次的目标要求。
用户需求：描述用户使用产品必须要完成什么任务。
系统需求：从系统的角度来说明软件的需求，它包括用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束。
火龙果整理一、什么是需求分析？5、需求捕获明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是“项目的目标”理解业务流程：--若项目较大或者业务较陌生：应进行业务建模；--如果业务较陌生：聘请领域专家，领域培训；--如果术语较多，易于混淆：业务术语表；--无论如何，都应该建立跨部门职能流程图火龙果整理uml一、什么是需求分析？5、需求捕获明确用户需求：--What(收集什么信息)--Where(从哪收集)--How(如何收集)捕获技术用户访谈用户调查现场观摩文档考古联合开发优点直接有效、灵活、深入面广、可以获得更多反馈容易建立直接的认识能够详细、直观对数据流细节进行分析直接的头脑风暴，可以击破需求盲点缺点占用时间长，信息面窄、较片面不够深入，容易形式主义、失真消耗时间长易陷入文山书海，甚至产生误导成本高，需要较高的控制技巧火龙果整理一、什么是需求分析？6、需求过程定义组织机构原始手工作业流程图表格文档服务对象？现实业务？细化业务流程输入输出流设计原型逻辑关系图可行性研究业务之间的关系原型用例泳道图是否合法、是否能实现、设计限制、是否存在不合理需求、是否存在尚未提出的潜在要求逻辑关系数据关系需求阶段分析阶段火龙果整理目录二系统建模1.为什么要建模2.什么是UML3.UML的发展历程4.模型种类5.谁应该建模6.如何使用UML对需求建模火龙果整理二、系统建模1、为什么要建模从建筑方面的建模谈起…建造一个狗窝：只需备一些木料、钉子和基本工具。
4需求建模与分析
改进的目标G5：导航系统应允许驾驶员在不分散驾驶 员注意力的情况下输入所期望的目的地
20
3.1.2 目标描述的7个规则
• 规则6：为引入目标的原因提供简要而准确的描 述。了解引入目标的原理有助于对目标本身的 讨论，并支持对其他相关目标的识别
目标G6：系统应当提供直观的用户接口。 ？为什么要直观
改进的目标G6：因为80%的用户每月仅使用本系统12次，因此系统应当提供直观的用户接口。
目标G4：提高驾驶安全性。 ？可评测
改进的目标G4：通过AND分解 目标G4.1：在路面湿滑情况下降低20%的刹车距离 目标G4.2：在刹车过程中确保汽车的可操纵性
19
3.1.2 目标描述的7个规则
• 规则5：尽可能准确地描述目标为相关涉众创造 的价值或所期望创造的价值
目标G5：导航系统应当提供一种直观的输入旅行目的 地的方式。 ？什么是直观
2
3.1.1 目标建模基础
• 目标：是关于系统的目的、属性或者使用的 意图
̵ 可以在不同抽象层次上定义
• 高层目标：定义公司策略或产品策略相关的目标 • 具体目标：定义涉众关于系统使用和系统属性的期望 高层目标 精化 具体目标
3
3.1.1 目标建模基础
• 目标之间的关系
̵ 分解关系
• AND/OR分解关系
26
3.1.3 目标建模方法
定义：目标模型 目标模型是一种描述目标、目标向子目标的分解关系， 以及现有的目标依赖关系的概率模型
• 目标建模方法
̵ 目标建模语言
̵ 规则和指南：指导需求工程师有目的地使用目标建模语 言的建模元素来描述已知事实或建立有意义的目标模型
̵ 管理实践：为涉众规划、控制建模方法的使用
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
体系结构模型描述方式-方框图
系统体系结构“标准”模式
客户机-服务器
通用服务器提供共享的系统功能
分层系统
系统功能通过调用更低层次所提供的功能来实现
基于库的系统
子系统通过一个共享库进行通信
管道系统
系统中的每个部件都进行一定的计算，并将结果传 给其他部件以进行进一步的操作
体系结构建模举例
内容
需求分析概述 结构化需求分析方法 面向对象需求分析方法
需求分析的过程
分类筛选
合并
排序
需求分析成功的条件
甲方明确的 建设目标 乙方正确的 方法论
需求分析
分析什么？ 业务流程优化 关键问题
怎么分析？
结构化分析法 面向对象分析法
系统建模
系统模型描述了系统的某个特殊方面，在需求文 档中对自然语言描述的系统需求加入补充信息。 系统模型的界定 需求规格说明中应该包含的高层次的模型
分析1:定义系统的边界
评估原始需求，定义将要开发的计算机系 统的边界。
确定哪些是系统需求 哪些是和系统相关的操作过程的需求 哪些在系统范围之外的需求
原则
析2:系统环境建模
环境模型是系统将要使用的语境模型，应该是最 先开发的系统模型之一。 效益：记录必须说明接口的外部系统 模型包括：
和正在说明的系统直接交互的其他系统 其他有可能和本系统共存并发生交互的系统 系统所在的业务过程（定义涉及的行为、它们的输入 和输出、负责这些过程的人以及支持这些过程的软件）
系统环境建模-上下文图
作用：
上下文图能很好地概括产品的必要接口，初步确新 产品包含了哪些内容，产品之外又包含哪些内容。 即说明产品及其环境的图示 说明产品的范围
x
分解：对于一个复杂的系统，为 了将复杂性降低到可以掌握的程度， 可以把大问题分解成若干小问题， 然后分别解决（如右图）。
1.1 1.2 1.3 2.2
1 2
3
2.1
2.3
1.1 1.3
抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略 去 , 以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的 属性表示一个系统的方法就是“抽象”。
浏览器
HTML、 ActiveX、 Script
输入数据 请求按钮
业务处理请求和业 务处理所需的全部 输入数据
业务处理开始
HTTP请求
HTTP应答
表 示 层 输出数据
数据存取请求
WEB服务器
用户界面层
业务处理结束
全部处理结束 业务处理程序
应用服务器
ASP、 XML
数 据 层
SQL请求开始
数据登录/更新/读取 的请求
表示系统运行环境的模型 说明系统如何分解为子系统的体系结构模型
系统建模需要注意的事项
需求分析前的工作
需求（系统）分析与建模
理解真实世界中的问题和用户的需要并提出 满足这些需要的解决方案的过程。
分析前的准备
确认系统的参与者 确认系统的运行环境 确认系统的约束
内容
需求分析概述 结构化需求分析方法 面向对象需求分析方法
代末由 Yourdon,Constaintine 及 DeMarco 等人提出和发展，并得到广
泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理 系统。
SA法也是一种建模的活动，主要是根据软件内部的数据传递、
变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。
SA法的基本思想
结构化分析方法的基本思想是“分解”和“抽象”。
分析5:事件列表与功能列表
事件就是要求系统执行某项功能的请求 业务事件与产品事件 对复杂的业务任务采用任务说明、用例说 明或数据流图等方法进行解释。 对复杂的功能采用数据流图、算法描述、 活动图、数学说明等进行解释
事件列表与功能列表(续)
事件及功能列表的优点
主要作为核对清单，以说明应开发什么。而 其中对这些功能的详细说明构成了功能需求 的主要部分 开发人员可以方便的检查产品是否实现每一 个功能 用户能够在某种程度上确认业务事件和任务 列表
结构化开发方法（Structured Developing Method） 是现有的软 件开发方法中最成熟、应用最广泛的方法，主要特点是快速、自然 和方便。结构化开发方法由结构化分析方法（SA法）、结构化设计 方法（SD法）及结构化程序设计方法（SP法）构成的。 结构化分析方法是面向数据流的需求分析方法，是 20 世纪 70 年
DBMS执行SQL
业务处理开始
应用逻辑层 数据层
数据存取请求
SQL请求结束
数据库服务器
数据登录/更新/读取 的结果
业务处理结束
数据存取程序
分析4:开发互补的系统建模
互补的系统模型可以解释系统规格说明的不同方 面。系统模型用来表达系统规格说明的行为视图 或者结构视图。 系统模型的例子
数据处理模型 组合模型 分类模型 刺激-响应模型 过程模型
需求分析的方法
绘制系统关联图 创建用户接口原型 分析需求可行性 确定需求的优先级别 为需求建立模型 （模型包括数据流图、实体关系
图、状态变换图、对话框图、对象类及交互作用图 ）
创建数据字典 使用质量功能调配
需求分析方法（细节）
采用SRS模板 指明需求的来源 为每项需求注上标号 记录业务规范 创建需求跟踪能力矩阵 审查需求文档 以需求为依据编写测试用例 编写用户手册 确定合格的标准。
需求分析与建模—结构化方法
结构化方法是一种系统分析和设计的方 法，包括定义、开发和确认系统模型过 程中用到的表示法、指南和规则。 功能需求分析与建模方法
功能需求说明数据的用途，以及如何记录、 计算、转换、修改及传输数据等。
数据需求分析与建模方法
数据需求指定系统的存储数据
结构化分析方法
优点：
上下文图为开发人员概括了所有的接口，在开发中 或开发后，方便地验证是否已处理了所有接口 用户能不费力地理解上下文图，并发现遗漏的接口。
系统环境建模案例
邮件传阅系统环境建模
企业OA办公系统 图书管理系统 操作管理员 一般工作人员
分析3:系统体系结构建模
效益
体系结构模型有助于划分系统需求 体系结构模型说明了系统功能的概况 体系结构模型有助于需求工程师找出那些涉及多个 子系统的需求