第2章软件需求工程2.1软件需求的基本概念2.2可行性分析2.3需求工程的过程2.4需求获取技术2.5结构化需求分
析与建模2.6数据字典2.7案例分析2.8需求评审2.1软件需求的基本概念需求分析的任务确定系统将要实现的各项要
求数据分析定义逻辑模型适应需求变更2.1软件需求的基本概念需求分析的原则软件人员要从用户角度考虑软件需求以流程为主线尽量重用软部
件划分需求的优先级需求变更要及时反馈软件需求功能需求性能需求领域需求其它需求数据用户操作时间空间……安全性法律需求道德需求预期需
求2.1软件需求的基本概念需求分析的内容2.2可行性分析可行性分析的内容技术可行性研究：当前技术是否可行。经济可行性研究：
系统产生的效益是否超过成本。操作可行性研究：系统在用户中的可操作性。法律可行性研究：技术、经济、操作可行性符合法律规范。2.2
可行性分析在可行性研究阶段，对系统整体需求了解的同时，还需要用概括的形式对现有系统与将来系统的物理模型进行表示。系统流程图（S
ystemFlowchart）就是概括地描绘系统物理模型的传统工具。系统流程图主要用于表现：从用户角度上看，系统流程图在一个抽
象的层面描述用户的操作、应用场景与数据流动。这样，利于和用户交流，准确地获取用户需求。从系统分析员的角度上看，系统流程图使得系统
分析员全面了解系统业务流程，便于进行进一步的需求分析。从项目管理者的角度上看，系统流程图有利于系统分析员与用户的交流和沟通。2.
2可行性分析例如，某企业人力资源管理信息系统的系统流程图2.3需求工程的过程需求工程中的参与人员2.3需求工程的过程需求
工程过程中的活动可行性研究需求获取需求分析与建模需求评审基线可行性分析技术/成本分析需求获取需求分析需求验证需求变更需求管理2.3
需求工程的过程需求工程的迭代模型2.3需求工程的过程需求工程的管理——贯穿整个需求工程的全过程。在需求工程管理过程中存在两大难
题：一是需求确认困难；二是需求不断变更。需求确认的目的是为了：⑴软件需求规格说明书正确描述系统功能和特征；⑵通过可行性分析论
证、需求获取和需求分析过程，能正确得到用户需求；⑶需求内容满足一致性、完整性、正确性、可修改性和可验证性；⑷需求为后续系统设计
、实现、验收测试提供充分的准备。申请需求变更确认后的需求变更描述变更分析变更修改变更确认2.3需求工程的过程需求工程的管理——
贯穿整个需求工程的全过程。在需求工程管理过程中存在两大难题：一是需求确认困难；二是需求不断变更。需求变更管理过程2.4需求获取
技术需求获取是需求分析的前提，没有完整、正确的获取用户需求，就不能保证软件产品质量。因此，软件人员与用户交流需要好的方法，以便能达
成共识。个别会谈和小组会议问卷调查面向用例的场景分析快速原型法2.4需求获取技术个别会谈和小组会议Why:为什么该系统被
开发？What:系统将要开发的功能是什么？When:什么时候开发？Who:系统由谁负责？系统会有那些相关的人、事物或其他系
统？Where:所开发的业务处于整个系统的什么位置？How:在技术上采用何种方法？在管理上如何进行？Howmuch：开发系统需
要哪些资源？需要多少？2.4需求获取技术问卷调查2.4需求获取技术面向用例的场景分析(1)用户操作之前的场景状态(2)
一次用例的描述(3)与用户操作同步进行的其他用户的操作(4)操作中出现错误时的处理过程(5)操作中出现异常是的处理过程(6)
用户操作结束时的场景状态2.4需求获取技术快速原型法数据对象说明加工规格说明数据流图数据字典实体关系模型状态转换图控制规格说
明2.5结构化需求分析与建模结构化分析概述结构化分析的核心是数据。数据包括在分析、设计和实现中涉及的概念、术语、属性等所有内容
，并把这些内容定义在数据字典中。围绕数据字典，完成功能模型、数据模型和行为模型的结构化建模过程。2.5结构化需求分析与建模面向
数据的数据建模数据建模需要回答以下几个问题：系统中有哪些数据对象？数据对象具有哪些属性？数据对象间有什么关系？数据对象分别处于系统
的哪些功能或流程中？在面向对象建模中，从数据对象里能抽象出更高层次的对象吗？或者数据对象能组合吗？在面向对象建模中，从数据对象里能
细化出更具体的数据吗？或者数据对象能分解吗？2.5结构化需求分析与建模面向数据的数据建模数据对象（实体）属性关系和基数输入数据输
入数据输入数据输入数据输出数据输出数据输出数据输出数据外部系统外部系统外部系统外部系统外部系统外部系统外部系统外部系统目标系统目标
系统目标系统目标系统用户用户用户用户用户用户用户用户输入数据输入数据输入数据输入数据输出数据输出数据输出数据输出数据2.5结构化
需求分析与建模面向数据流的功能建模数据流图（DataFlowingDiagram，DFD）是结构化建模中最流行的功能建模工具
。DFD描述从数据输入、数据转换到数据输出的全过程。能对DFD图分层，分层的DFD更进一步刻画了系统的功能分解。或或或2.5结
构化需求分析与建模面向数据流的功能建模——DFD图基本图形符号数据加工，实现数据变换。其中要注明加工的名字。外部实体，即数据源或外
部系统。其中要注明数据源或外部系统的名字。数据存储。其中注明数据存储名字或编号。数据流，描述变换的加工数据及数据流方向。箭头上部要
注明数据流的名字。2.5结构化需求分析与建模面向数据流的功能建模——DFD图的分解过程DFD图可以用来表示任何抽象级别的系统
功能，随着系统功能和信息的逐渐增加，DFD图通过分解来逐层细化用户需求。分解步骤如下：确定系统的外部信息源、数据源或与外部系统的
接口。画出顶层（0层）DFD图。第一次精化：划分系统的子系统。逐层求精：对各子系统进一步精化。2.5结构化需求分析与建
模面向数据流的功能建模——DFD图的分解过程DFD图可以用来表示任何抽象级别的系统功能，随着系统功能和信息的逐渐增加，DFD图通
过分解来逐层细化用户需求。2.5结构化需求分析与建模面向数据流的功能建模——DFD图的分解过程例如：儿童自然语言理解系统。2
.5结构化需求分析与建模面向数据流的功能建模——DFD图的分解过程DFD图可以用来表示任何抽象级别的系统功能，随着系统功能和信
息的逐渐增加，DFD图通过分解来逐层细化用户需求。2.5结构化需求分析与建模面向数据流的功能建模——DFD图的分解过程2.5
结构化需求分析与建模面向数据流的功能建模——DFD图的分解过程DFD图可以用来表示任何抽象级别的系统功能，随着系统功能和信息的逐
渐增加，DFD图通过分解来逐层细化用户需求。2.5结构化需求分析与建模面向数据流的功能建模——DFD图命名对DFD图中各部分元素
的命名切忌用空洞的名词，这样不仅会给系统设计带来歧义，而且难以确定数据的结构和组织方式。命名时应遵循以下原则：用名词或名词短语，避
免使用空洞、无意义的词汇；尽量使用需求描述中的已有词和领域术语；命名出现困难时，考虑是否是数据流划分是否正确，并重获需求；顶层DF
D图中的加工名就是软件项目的名字；分层DFD图中，数据存储一般局限在某一层或少数几层中。2.5结构化需求分析与建模面向数据流的
功能建模——DFD图分层注意事项在逐层细化DFD图时，还要注意以下几点：父图和子图的平衡关系DFD图的编号平衡规则2.5结构化
需求分析与建模面向状态转换的行为建模状态转换图（StatusTransitionDiagram，STD）通过描述系统状态及引
起状态转换的事件来表示系统行为。STD图同时也反映了事件执行的行为。STD图主要由状态、转换和事件的图形符号构成。初态中间状态终
态名字状态变量活动2.5结构化需求分析与建模面向状态转换的行为建模状态是可观察到的行为，是同一数据对象在系统的不同运行时刻所具
有的行为属性值，是事件触发后一系列动作的结果。2.5结构化需求分析与建模面向状态转换的行为建模状态转换由一个状态转换到另一个
状态的关联就是状态转换，它表明状态变换是有序变换过程，用有向箭头表示。状态变换是由事件或条件触发的，因而箭头上应说明事件名称或触发
条件。如果状态间转换没有事件触发，则前一状态结束信息就是转换到下一状态的触发条件。2.5结构化需求分析与建模电梯运行状态的状态
转换图2.5结构化需求分析与建模面向状态转换的行为建模事件是指在某一时刻发生的事情，是触发状态转换的条件或一系列动作。在中间状
态的符号中，活动即是事件。STD图定义了3个标准事件，它们都没有参数：entry事件：用于说明转换到该状态的特定动作；exit事
件：用于说明触发该状态的特定动作；do事件：用于说明处于当前状态时执行的动作。2.6数据字典数据字典DD（DataDict
ionary）数据字典以结构化方式定义了在数据建模、功能建模和行为建模过程中涉及到的所有数据信息、控制信息。它是当前系统的软件词
典，提供用户和软件人员的概念解释，也提供在系统开发过程中各种有关数据和控制的描述信息，使得系统所有的相关人员对信息有共同的、一致的
理解。词条描述定义式Warnier图2.6数据字典数据字典DD（DataDictionary）——词条描述词条描述详细
说明了数据和控制信息在系统内的传播途径。它分为数据流词条、数据元素词条、加工词条和存储文件词条等内容的定义。数据元素名：词类型：
文字（char类型）长度：任意长度取值范围：1{名次|代词|动词|副词|形容词|数量词|介词|连词|助词}n相关的数据元素：
小词性相关数据元素的数据结构：字符型（不能为空）2.6数据字典数据字典DD（DataDictionary）——定义式“
存折”的定义表示：存折=户名+帐号+存取行户名=2{字母}24帐号=“00000001”..“99999999”存取行=
年+月+日年=“1900”..“9999”月=‘01“..“12”日=“01”..“31”存入=“0000000.01”.
.“9999999.99”支取=“0000000.01”..“9999999.99”2.6数据字典数据字典DD（Data
Dictionary）——定义式（BF范式）符号含义解释＝＋[.
..,...][...|...]{...}m{...}n(...)“...”..被定义为与或或重
复重复可选基本数据元素连结符例如，x=(a)，表示a可在x中出现,也可不出现。例如，x=“a”，表示x为取值为a的
数据元素。例如，x=1..9，表示x可取1到9之中的任一值。例如，x=a＋b，表示x由a和b组成。例如，x=[a,b]，x=[
a|b]，表示x由a或由b组成。例如，x={a}，表示x由0个或多个a组成。例如，x=3{a}8，表示x中至少出现3次a,至多出
现8次a，也可表示为2.7案例--简历自动获取和查询系统的需求建模1.数据建模----E-R图描述2.7案例--简历自动获取
和查询系统的需求建模2.功能建模----数据流图2.7案例--简历自动获取和查询系统的需求建模2.功能建模----数据流图2
.7案例--简历自动获取和查询系统的需求建模2.功能建模----数据流图2.7案例--简历自动获取和查询系统的需求建模2.功
能建模----数据流图2.7案例--简历自动获取和查询系统的需求建模3.行为建模----状态转换图2.7案例--简历自动获
取和查询系统的需求建模4.加工逻辑----PDL语言的描述2.7案例--简历自动获取和查询系统的需求建模5.数据字典2.8需求评审在需求工程完成之前，必须编写软件需求规格说明和数据规格说明，形成初步的用户手册，并按照评审标准对软件需求过程和规格说明进行评审，目的是发现并消除其中存在的遗漏、错误和不足，使得规格说明符合标注及规范的要求。通过了评审的软件需求规格说明和数据规格说明将成为基线配置项，并纳入需求管理过程。主要包括：软件需求规格说明和软件数据需求说明等文档。第2章小结一、软件需求分析的主要内容功能需求、性能需求、领域需求、其他需求二、结构化建模数据建模：实体关系图(E--R)功能建模:数据流图（DFD）行为建模:状态转换图（STD） |
|
