软件工程的需求分析_软件工程需求分析

• 什么是需求？ 什么是软件需求？
• 什么是需求分析？ 为什么要做需求分析？需求分析做什么？ 需求分析怎么做？
• 如何获取用户需求？ 常用的获取需求的方法有哪些？
• 结构化需求分析方法的步骤、方法和常用工具？各种工具的作用是什么？ 什么是数据规范化？
• 什么是需求规格说明？ 需求规格说明撰写什么内容？ 为什么描述需求规格说明比较困难？ 谁负责编写需求规格说明书？ 谁使用需求规格说明书？ 好的需求规格说明应满足什么条件？

团队成员的责任

• 分析人员：主要负责与客户交互和需求。
• 设计和编码人员：主要负责设计、实现和单元测试。
• 测试人员：主要负责功能、性能和系统测试。
• 项目经理：主要负责持续的项目团队的跟踪并关注关键的交付产物。
• 质量保证和方法专家：负责质量标准和最佳实践。
• 客户：负责澄清他们的业务需求。

一、需求分析概述

什么是需求？

• 简单的需求--买肉

卖肉的问：要啥？ 买肉的答：要点肉。 卖肉的问：啥肉？精肉还是五花肉？ 买肉的答：做饺子的。 卖肉的答：那来点五花肉吧。几斤？

• 购买汽车的需求：

要购买一辆汽车需要：能看光碟，带有导航系统，车价适中，节省燃油，良好的刹车系统等。

美国电气与电子工程师学会 (IEEE) 将需求定义为： 用户解决问题所需的条件或能力。

什么是软件需求？ 

软件需求是指用户对软件所提出的功能性和非功能性的要求。前者定义了系统做什么，后者定义了系统工作时的特性。

软件需求的定义： 

1. 用户解决问题或达到目标所需的条件或能力。
2. 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
3. 一种反映上面1和2所描述的条件或能力的文档说明。

如何去理解上面的软件需求定义呢？    

软件需求的定义包括了用户角度（系统的外部行为）和开发人员角度（系统的内部特性）两个方面，其中的关键在于需求一定要文档化。

二、需求分析任务

什么是需求分析？

• 需求分析是指开发人员要准确地理解用户的要求，进行细致的调查研究，将用户非形式化的需求描述转化为完整的需求定义，再由需求定义转化为相应的软件需求规格说明书（即需求分析的结果）的过程。
• 需求分析是理解、分析和表达“系统必须做什么”的过程。
• 需求分析是为用户所看到的系统建立一个概念模型，是对需求的抽象描述。

为什么要做需求分析？

1. 许多大型应用系统的失败，最后均归因于需求分析的失败。要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
2. 需求规格说明书是客户、软件开发人员、软件测试人员和项目管理人员四者共同工作的基线，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
3. 需求分析通常要占用整个软件开发时间或工作量的30%左右。
4. 需求分析阶段的错误，属于软件开发过程中的早期错误，将给项目带来极大风险，因为这些错误会在后续的设计和实现中进行发散式的传播。   基于以上四项原因，IT企业对需求分析特别重视，通常派经验最丰富的人员去做软件或项目的需求分析。

需求分析做什么？

• 准确回答“系统必须做什么?”这个问题；
• 通过分析和构建系统的“模型”，对系统提出完整、准确、清晰、具体的要求；
• 编写软件需求规格说明书；
• 用户要很好地参与到需求分析过程中来；(需求需要不断地迭代)
• 注意区别”可行性分析”和”需求分析”的异同；

需求分析怎么做？

从概念上讲，需求分析主要涉及以下三项活动或工作。

三、与用户沟通获取需求的方法

获取需求：通过与用户的沟通和交流，收集用户对新系统的各项要求。 

如何获取用户需求？

获取需求是否彻底与成功，直接关系到软件开发的成败。

获取需求为什么难?

1. 用户需求具有动态性，即需求的不稳定性。在整个软件生命周期中，应用软件的需求会随着时间的推移而有所变化。个别用户，甚至会朝三暮四地变化。
2. 用户需求具有模糊性。由于有些用户的业务素质不是很高，业务流程也不很规范，所以需求表达不很清楚也不够明确的情况时有发生。

 软件问题的幽默画：

常用的获取需求的方法有哪些？

通常采用以下方法去获取用户需求：

1、访谈：用户面谈、问卷调查、现场考察等

1）用户面谈

一种理解业务功能和业务规则的最有效方法。

面谈过程需要认真的计划和准备，在面谈之前需要：

• 明确面谈目的。
• 确定要包括的相关用户。
• 确定参加会议的项目小组成员。
• 建立要讨论的问题和要点列表。
• 复查有关文档和资料。
• 确立时间和地点。
• 通知所有参加者有关会议的目的、时间和地点。

信息收集中的主要问题：

2）问卷调查 

• 可用于确认假设和收集统计倾向数据。  
• 问卷需要快速回答，允许匿名方式反映存在的问题。  
• 相关的问题不能事先决定。  
• 问题背后的假设对答案造成偏颇，如这符合你的期望吗？  
• 难以探索一些新领域。  
• 难以继续用户的模糊响应。

在完成最初的面谈和分析后，可作为一项协作技术可以收到良好的效果。

3）现场观察商业过程和工作流程

掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法是亲自观察用户是如何完成实际工作的。    

一般方法：

• 对办公室进行快速浏览，了解布局、设备要求和使用，工作流总体情况。
• 安排几个小时观察用户是如何实际完成他们的工作，理解用户实际使用计算机系统和处理事务的细节。
• 像用户一样接受训练和做实际工作，发现关键问题和瓶颈。 

注意：现场考察可能造成用户紧张。

2、面向数据流自顶向下逐步求精（结构化分析：自顶向下，逐层细化的方法。）

• 决定信息系统本质的数据是需求分析的起点。
• 系统分析员一定要搞清楚数据的细节。
• 分析的对象：高层次数据流图（什么阶段得到的？）。
• 主要目标：把数据流和数据存储分解到元素级别（不可分解为止）。

从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出的关键因素。  

输出数据决定了系统必须具有的最基本的组成元素（包括功能和数据结构组成）。

3、简易的应用规格说明技术

前两种方法中，用户相对比较被动。 本技术是一种面向团队的需求获取方法，是一种主流技术。 它提倡用户与开发者密切合作、共同标识问题、提出解决方案，确定基本需求。

简易的应用规格说明技术流程：

它也不是万能药。但是它有以下优点：

• 要求开发者与用户不分彼此，齐心协力，密切合作。
• 即时讨论并求精。
• 有能够导出需求规格说明的具体步骤。 

4、快速原型法

快速建立起来的旨在演示目标系统主要功能的可运行的程序。 它是最准确、有效和强大的需求获取技术。

基本特性：

• 快速：快速的提供给用户一个可运行的软件。
• 容易修改：根据用户的要求可迅速构建新的原型。 

理解和分析需求：自己或者软件项目发起人，将获取的软件意图和要求，从模糊的状态逐步向明确的状态推进的过程。称为需求分析或问题分析。

目前常用的方法有： 结构化分析方法和面向对象分析方法。

表达需求 （编写需求规格说明书）

根据分析的结果，采用规定的规格描述模型或者规格描述语言编写需求规格说明书。

• 什么是需求规格说明？
• 需求规格说明写什么内容？
• 为什么描述需求规格说明比较困难？
• 谁负责编写需求规格说明书？
• 谁使用需求规格说明书？
• 好的需求规格说明应满足什么条件？

什么是需求规格说明？

将软件需求进行严密的定义，并将其文书化的东西就是需求规格说明。

需求规格说明写什么内容？

功能规格说明 性能规格说明 可靠性规格说明 接口规格说明 等等。

仅限于功能规格说明，将其加以严密的定义就不是一件简单的事情。

撰写需求规格说明书：

以下是需求规格说明书需要撰写内容的例子

1. 系统目标

2. 新系统的业务需求

●适用业务的构成 ●DFD新逻辑模型 ●系统化的对象范围，新规需求列表等

3. 新系统的数据需求

●ER图和规范化数据项目表（规范化结果） ●数据项目定义书（数据字典）

4. 新系统的质量需求，以及其他设计上的前提条件和制约事项

●根据需要加以描述与其他系统和外部的接口需求、监察和保密的需求、容量/性能需求、备份和恢复需求、移植需求、系统的扩展需求等。 ●另外，描述系统再利用和部品化相关的方针，以及与质量特征（功能性、可靠性、可用性、效率性、可维护性、可移植性）相关的前提或者特殊事项。

5. 平台（硬件/软件/网络）需求

●有关运行环境的需求 ●有关开发环境和手段的需求

6. 费用对效果

附录

●业务术语集 ●DFD现物理模型/ DFD现逻辑模型 ●保留事项/未决事项

为什么描述需求规格说明比较困难？

• 描述对象的问题域没有像数学世界那样的具有显著的逻辑性。
• 用户本身想要什么的意图不明确，即使意图明确也不能清楚地加以表达。
• 用户的意图是变化的。或者，随着外部条件的变化意图也随之发生变化。
• 描述对象的问题域由于过大或过于复杂，不知如何去描述。

等等。。

谁负责编写需求规格说明书？

软件项目发起人。需要将需求传达给其他人，将软件开发委托给其他人。

开发软件的人。以确认发起人的意图为目的，或者，开发面向市场的软件产品的情况下，该产品的功能和动作需要去明确地表述。

谁使用需求规格说明书？

用户：检查开发人员是否真正理解了和正确表达了需求。

设计人员：根据需求规格说明书开展设计和实现（编写代码、测试）工作。

检查人员：检查做成的软件是否满足规格说明，用户本身也包含其中。

好的需求规格说明应满足什么条件？

• 正确性：说明内容没有自相矛盾。
• 完整性：说明内容必须完整，毫无遗漏。
• 严密性：没有模糊不清的地方，说明的内容无二义性。
• 可理解性：容易阅读和理解。
• 有效性：所定义需求确实能够解决用户所面临的问题。
• 可实现性：要求的东西具体可以实现。再正确再严密的需求规格说明如果实现不了没有任何意义。另外，依赖于特定的实现方法，束缚设计的需求规格说明也是尽量要避免的。

四、分析建模与规格说明

结构化开发方法 (structure developing method) 是现有的软件开发方法中最成熟，应用最广泛的方法，主要特点是快速、自然和方便。

结构化开发方法由： 结构化分析方法 (SA法)、 结构化设计方法(SD法)、 结构化程序设计方法(SP法)构成的。

结构化分析 (Structure Analysis，SA法) 方法是面向数据流的需求分析方法，是20 世纪70年代末由 Demarco 、Yourdon及Constaintine等人提出和发展，并得到广泛的应用。它适合于分析大型的数据处理系统，特别是企事业的业务管理系统。

结构化分析方法采用数据流图(DFD)，它是关注数据流构造方法的典型代表。

SA是面向对象方法之前的方法，尽管DFD没有被UML所采用，但是，由于它有以下特点，即使现在也是一种有效的方法。

• 没有采用麻烦的理论，直观、容易理解。
• 采用分层结构的方式对系统的功能进行自然的分解。
• 数据流图在关注数据流的同时，能够将输入、输出和功能整合起来加以理解。
• 目前流行的CASE(Computer Aided Software Engineering)，一般也都可绘制DFD。

SA法是一种“建模”的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。 

建模

模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。 在软件系统的结构化分析建模过程中，软件系统分析员应该从不同角度（功能角度、数据角度、行为角度）抽象出目标系统的特性，使用精确的表达方法（DFD、 ER、 STD、 IPO、DD等）构造系统的模型。

结构化分析模型的组成：

 结构化分析方法创建的几个主要模型及关键元素如下：

• 功能模型：数据流图(DFD)＋IPO
• 数据模型：E-R图（E-RD）
• 行为模型：状态转换图（STD）
• 数据字典：模型中心（DD）

根据上述模型整理出软件需求规格说明书。

基本思想

分解：

对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。（各个击破！）

抽象：

分解可以分层进行，即先考虑问题最本质的属性，暂时把细节略去，然后再逐层添加细节，直至涉及最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。

结构化分析工具-数据流图

名称定义：数据流图（Data Flow Diagram，DFD）

• 是用来描述系统逻辑模型的一种图形工具。
• 数据流图从数据传递和处理的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。

 数据流图-符号

 数据流图-数据传递

 

数据流图-处理

数据流图的作用 

• 数据流图（DFD）是为了对分析对象的业务范围进行有效把握的一种图形工具。
• 通过使用它可以在需求分析阶段，对将要系统化的业务的问题域进行可视化。 

数据流图的特征

• 可以特定业务和处理的范围；
• 可以描述需要什么样的处理；
• 可以具体地描述数据的流向；
• 不能正确地描述谁做这些业务和处理；
• 不能描述处理的顺序和时间。

如何绘制数据流图

1.用自然语言描述业务场景

接单中心从〇〇公司接到了货物订单。

订单内容为4套N型配电盘。

接单中心在接到订货后，进行了库存调查，给〇〇公司回答了报价。

由于N型配电盘目前没有库存，所以系统自动向厂家发出了委托生产的请求。

在收到厂家交付的N型配电盘并入库后，系统自动发出出库指示，随后，由物流中心将4套N型配电盘配送到〇〇公司。

2.把握数据的产生和使用

DFD是通过数据流来把握业务全貌的，因此，

• 什么时候、在何处产生了数据？
• 这些数据在哪里被使用了？

是重点要掌握的。

从刚才的例子看，数据的产生在以下两个地方：

1. 接单中心接到顾客的订货请求并回答了价格。
2. 从厂家收到产品并将其入库。  

数据的使用是在在给物流中心发出送货指示业务完了的地方。

3.把握数据的存储

接下来，整理出像「接单数据」、「库存数据」等这些长期或暂时需要保存的数据存储。

4.列举出所需要的处理

最后，整理出和上述的1～3相关的处理，完成DFD。

绘制数据流图的注意事项 

• 注意数据流图和程序流程图的区别。DFD中的箭头线是数据的流向，而不是处理的执行顺序。
• 对每个处理一定有输入和输出。不存在只有输入或只有输出的处理。
• 处理的名称最后确定。对数据的源点/终点、数据流、数据存储先确定名称。理由是，从输入/输出容易推测处理的内容，而从处理内容来推测数据要困难些。
• 定义名称时禁止使用抽象的词汇。
• 除了与数据存储之间的数据流不用命名外，其他的数据流必须命名，名称应该用名词或名词短语命名。
• 每个处理也要有处理名称，通常用动词或动词短语来描述。

结构化分析的步骤

案例：

下面以任课教师收到课表后，根据课表安排的教学周次向实验室管理部门申请实验室的使用为例，说明结构化需求分析的步骤。

其手工操作的业务流程图如下：

构建DFD现物理模型 

通过对现实环境的调查研究，获取当前系统的物理模型。

前提：需要客户很好地协助，毫无遗漏地收集现有业务的工作流程和事务处理的手册，现有系统的报表/画面、文件和数据库格式等。

目的：整理出现有业务的内容、作用以及业务上存在的问题点。

在建立DFD现物理模型的同时，抽出现有业务所使用的全部数据项，将它们登录到数据字典中去。遇到没有用过的数据项，或者「同词异义」，或者「异词同义」的情况，此阶段不做整理，直接登录到数据字典中即可。 这些数据项都是从现有系统向新系统转换过程中的非常重要的信息。

何为数据字典（Data Dictionary  简称DD ）？

数据字典的作用是: 对于数据流图中出现的所有被命名的图形元素作为一个词条以字典的方式加以定义，使得每一个图形元素的名字都有一个确切的解释。

使用数据字典的一个重要目的是，解决在系统开发过程中出现的以下两个问题：

“同词异义”和“异词同义” 

数据字典的记述事项：

构建DFD现逻辑模型

从DFD现物理模型中将谁（个人或组织、现有系统）、何时、怎样（手段或媒介）实施业务的所谓“物理上的要素”以及“非本质成分”去掉，提炼出所谓的DFD现逻辑模型。

明确系统的范围

前提：做好需求调查与整理。

方法：用自然语言或条目列表的方式将需求整理出来。如果采用迭代过程模型（例如：敏捷开发）实施开发的话，还需要对功能需求排列优先顺序。

构建DFD新逻辑模型（这是重中之重！）

前提：确定好功能需求的范围。

方法：

1.用分层次逐步细化求精的方式绘制DFD。

实验教学申请系统的顶层DFD：

 实验教学申请系统的第二层DFD：

实验教学申请系统中的1.创建申请的第三层DFD：

2.对绘制好的最底层（最详细）的DFD的各个要素去进行必要的说明。

对数据存储进行说明

什么是IPO？

IPO是输入(Input)/处理或加工(Process)/输出(Output)图的简称，它是由美国IBM公司提出的一种图形工具。它的作用是能够方便地描绘输入数据、处理或加工数据、输出数据的关系。  

在需求分析阶段，它可以用来描绘数据流图中处理或加工的过程。    

在设计阶段，它可用来对模块结构图中的每个模块的输入、输出数据和数据加工进行说明。

IPO的形式： 

如何描述IPO：对处理进行说明

 采用IPO形式描述“1.1新建申请”的处理过程

3.将新产生的数据项追加到数据字典中。

将构建DFD新逻辑模型中产生的新的要素追加到下述数据字典中。

                                                        

实施数据规范化：第五节详细说明

绘制系统ER图：第六节详细说明

将规范化结果反映到DFD上

下图是还未实施数据规范化的DFD：

下图是实施数据规范化后的DFD：

撰写需求规格说明书 ：第三节最后面有详细说明

五、数据规范化

• 什么是数据规范化？为什么要实施数据规范化？
• 数据规范化的长处和短处是什么？
• 如何进行实施规范化？

什么是数据规范化？

• 数据规范化就是为了使数据结构没有重复的数据项，而对数据结构（或者表）进行适当分割的过程。
• 把规范化的数据结构（或表）称为「规范型」，把未实施规范化的数据结构（或表）称为「非规范型」。 
• 「非规范型」数据结构，由于存在数据项的重复，从而容易引起数据的矛盾或数据的不一致，不容易进行正确地数据管理。
• 「规范型」数据结构，由于没有了数据项的重复或矛盾，因此容易管理。从结果上看，也就降低了发生数据不一致性的风险。

数据规范化的长处和短处是什么？

长处： 数据易于维护和管理。 同一数据结构（或者表）可以在多种场合被利用。

短处： 伴随着表结构数量的增加，管理负担也随之有所增加。 为了获得一组关联信息，需要遍历多个表结构，获取的效率会有所影响。

如何实施数据规范化？

下面是目前使用的Word版实验教学申请表的模板。

通过这个模板我们可以得到实验教学申请的数据结构如下：（由于存在重复的数据项，所以是非规范型的。）

对包含重复数据项的非规范化的数据结构（或者表）按照「第一范式」、「第二范式」、「第三范式」的顺序实施规范化。到「第三范式」的情况下，就可以做到数据结构（或者表）不存在重复数据项了。

对下面的数据结构（或者表），按照上述步骤实施规范化该如何去做呢？

第一范式化：将下表中导出的数据项「金额」和「订单合计金额」删除，再将重复数据项「商品No」、「商品名」、「单价」、「数量」分解到另外的表中去。

 

第二范式化：由于订单明细表中的主键「商品No」可以决定「商品名」和「单价」，因此将其分解到另外的表中去。

第三范式化：由于订单表中的主键以外的「客户名」和「客户地址」由「客户代码」决定 ，因此将其分解到另外的表中去。

 回到实验教学申请表的例子。

按照上面介绍的三个范式的要求可以把上述格式的一个数据结构分解为如下五个数据结构。

再次回到实验教学申请系统！  

实验教学申请系统的第二层DFD 

按照上面介绍的三个范式的要求我们把实验教学申请系统的数据存储进行规范化处理。 

 

 

六、实体-联系图

什么是ER图？

实体联系图又叫ERD（Entity Relationship Diagram）或实体-联系模型，它是在调查分析用户的需求之后，把用户对数据的要求用实体联系模型表达出来，明确描述应用系统的概念数据模型。

概念数据模型的实质，就是分析和梳理现实中的数据及其数据联系，为后续的数据库设计打好基础。

概念数据模型的构成： 实体 属性 联系

什么是实体？

实体（Entity）表示一个离散对象。它是具有一系列不同性质或属性的事务。实体通常使用名词表示，如计算机、雇员、歌曲、数学定理等。  在ER模型中实体用矩形框表示，矩形框内写上实体名。

什么是属性？

属性就是实体所拥有的特征。一个实体拥有多个属性。  在ER模型中属性用椭圆框表示，框内写上属性名，并用无向边与其实体相连。

什么是联系？ 

联系描述了两个或更多实体相互如何关联。联系可以被（粗略地）认为是动词。如：雇员和部门之间的管理关联。  在ER模型中实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1-1、1-N或M-N。

如何绘制ER图？

按照上面介绍ER图的符号和含义，绘制得到实验教学申请系统的整体ER图（ER模型）如下。

除了上面绘制的整体ER模型以外，通常还需绘制各个实体所拥有的属性。例如，实验教学申请实体的属性如下。

七、状态转换图

八、验证软件需求

小结

需求分析任务

1、确定对系统的综合要求 

 2、分析系统的数据要求（数据建模）

• 软件系统的本质是对数据进行处理。
• 通常要求建立完整的数据概念模型（E-R模型）
• 数据字典缺乏直观性（考虑图形化的描述复杂数据的组成）
• 必要时需要对数据模型进行规范化（范式）
• 阶段性成果： E-R（Entity Relationship）图、层次方框图或Warnier图

层次方框图 

层次方框图不仅可以反映系统的功能组成关系，还可以反映现实世界中的信息组成关系。因此，在数据建模中可以用来表示信息的组成关系。

Warnier图 

它也是用来表示信息层次结构的图形工具。

它可以指出信息是重复出现的或者是有条件出现的。

图形包括：

• 用来区分数据结构层次的花括号；
• 表明一类信息或一个数据元素在一定条件下出现的异或符号；
• 名字后面的数字表示信息类在数据结构中重复的次数。

3、在可行性分析的基础上分析系统的功能模型

确定系统综合要求和分析系统数据要求顺利完成之后即可导出详细的系统功能模型。

阶段性成果：

• 层次分解细化的并经过多次校验的数据流图(DFD)
• 与数据流图相辅相存的数据字典(DD)
• 概要性的描述主要加工的处理算法(IPO)

4、分析描述软件系统动态的行为模型 

确定系统的动态变化的方式，采用状态转换图来描述。

阶段性成果： 状态转换图(STD，State Transition Diagram) 

行为模型与状态转换图 

为了反映事物的变化规律，在需求分析中有时需要建立系统的行为模型（动态模型）。

状态转换图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

例如：上课铃响了，同学们应该进入教室准备上课。

状态转换图还指明了作为特定事件的结果，系统将做哪些动作(例如，处理数据)。

状态转换图-状态 

状态代表系统的行为模式。

它规定了系统对事件的3种响应方式。

• 改变状态（绝大多数的系统都如此响应）
• 做动作（完成一定的“操作”）
• 既改变状态，又做动作（比较复杂）

三种状态类型：初态、终态和中间态。

状态图可表示循环运行过程以及单程运行过程。

状态转换图-事件

某个特定时刻发生的“事情”。

它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。

它是控制信息，状态是受事件触发的。

状态转换图-状态转换图的符号

在状态转换图中，初态用实心圆表示，终态用一对同心圆（内圆为实心圆）表示。 中间状态用圆角矩形表示。可以用两条横线把它分成上，中，下3个部分。上部为状态的名称，是必填项。中部为状态变量的名字和值，是可选项。下部为活动表，也是可选项。 两个状态之间带箭头的连线称为状态转换。箭头指明了转换方向。 

举例 

5、编写软件需求规格说明书并根据需要修改开发计划 

将上述的阶段性成果汇总为“软件需求规格说明书”，以提交评审。

在可行性分析的基础上，较准确地估计系统的开发成本和进度。

修改开发计划。

通俗地说,需求分析的任务就是准确地定义未来系统的目标，确定为了满足用户需求的系统必须做什么。用 <需求规格说明书> 规范的形式准确地表达用户的需求。

需求分析阶段关键在于“理解”和“表达”。  

“理解”是开发人员对系统需求的理解     （1）挖掘用户需求     （2）修正需求。

“表达”是对理解用逻辑模型描述出来，一方面能让用户看懂，另一方面能让设计人员和程序员理解。

需求分析建模

需求分析过程 

需求分析所应具备的基本技能 

做好需求分析任务所必备的四项基本技能：

1. 确立需求分析的方法论 ：如何没有确立需求分析的顺序、工作内容和成果物，按照自己的方式进行需求分析的话，就会出现有的项目成功有的项目失败的情况。确立方法论就可以减少项目失败的风险。
2. 掌握图形表现工具 ：绘制业务流程图、DFD、ER图和UML图，可以减少文字描述造成的模糊性。用图和客户进行讨论和沟通，可以更好地共有思考过程，容易与客户达成一致。
3. 沟通的技能 ：用户不积极参与，不认真听取我们的解决方案等，是沟通过程中常常发生的问题。为了解决这些问题，需要掌握与人沟通的技能。
4. 了解行业・业务知识 ：了解客户的业务规则、行业用语、竞争对手的经营状况等，这些不用说也应该知道的东西。 如果没有行业・业务知识，就和客户没有共同语言，也就无法了解客户的真实需求。

DFD和用例图的比较

如果想了解可行性分析可以看这篇文章：

软件工程的可行性分析_软件可行性分析作用_不学无术BruceYoung的博客-CSDN博客什么是可行性分析？为什么要进行可行性分析？可行性分析的主要任务是什么？可行性分析有哪些主要过程？如何去评估提出的可行性方案？进行可行性分析时常用的工具有哪些？可行性分析报告的内容要求和写法说明1、什么是可行性分析？检查并确定是否值得为项目或产品投入时间、金钱和资源。这样的评估活动称为“可行性分析”。2、为什么要进行可行性分析？在软件项目开发过程中，只要资源和时间不受限制，几乎所有项目都是可行的。然而，由于受到资源和交付时间的限制，使得软件系统的开发变得越来越困难。因此，https://blog.csdn.net/qq_59125846/article/details/121367005