软件工程第3章需求分析

第3章需求分析第3章需求分析3.1需求分析的任务和原则3.2初步需求获取技术3.3需求建模3.4实体关联图3.5辅助图形工具3.6需求规格说明与评审——需求验证3.7一个实例分析需求分析的任务与原则3.1需求分析的任务与原则基本任务：准确定义系统的目标，回答“系统必须做什么？”任务的承担者：需求分析小组或系统分析员三种模型：数据模型：描述问题信息域——实体-联系图功能模型：定义软件功能——数据流图行为模型：描述软件行为——状态转换图三个阶段：1.

需求获取阶段（问题分析）2.需求规约/规格说明阶段（需求描述）3.需求验证阶段（需求评审）一.需求获取阶段——问题分析1.任务：通过多种方式（与用户交流、实践等）清晰地理解所要解决的问题，完整的获取用户的需求。2.原则：1).找出用户的不合理需求和潜在需求。2).对用户的需求进行建模。3.作用：准确地描述用户从多个不同视点、不同抽象层次上对原始问题及目标软件系统的认识；帮助需求分析人员分析发现用户需求中的不一致性，排除不合理部分，挖掘潜在用户需求；有助于形成需求规格说明书。3.1需求分析的任务与原则二.需求规约阶段——问题描述3.1需求分析的任务与原则1.任务：以需求模型为基础，考虑到问题的软件可解性，生成软件的需求规格说明书和初步的用户手册。2.原则：确保需求规格说明书对用户需求描述的完整性、一致性和准确性鼓励用户参与需求规格说明书以及用户手册的制定尽可能做到结构清晰，措辞准确和简洁三.需求验证阶段——需求评审3.1需求分析的任务与原则1.任务：让用户和设计人员对需求规格说明以及用户手册的理解达成一致。2.原则：确保需求规格说明书和用户手册是一致、完全和准确的；支持各方（用户，需求分析人员、设计人员）参与评审工作。需求分析的任务与原则3.1需求分析的任务与原则需求分析的任务：3.1.1确定对系统的综合要求：P56功能需求、性能需求、运行要求、未来可能的扩充要求等3.1.2分析系统的数据要求：P57建立概念模型(ER图)形象描绘数据结构(层次方框图、Warnier图、IPO图)数据结构规范化3.1.3导出系统的逻辑模型:P583.1.4修正系统开发计划：重估成本、进度3.1.5开发原型系统需求分析的任务与原则3.1需求分析的任务与原则3.2初步需求获取技术初步需求获取技术一.访谈和会议3.2初步需求获取技术采用访谈和小组会议的形式与用户进行沟通和交流，据此逐步理解用户对目标软件系统的期望和需求。原则：循序渐进、自由发挥、反映全貌常用方法：正式访谈（具体问题）；非正式访谈（开放式问题）大量人员意见：分发调查表，并针对性地回访一些人员通过实践和观察用户工作流程来理解问题和获取用户的需求情景分析技术P58一.访谈和会议3.2初步需求获取技术分析人员和用户共同组成的联合开发小组，有利于：激发各方的主动精神；建立良好的合作关系；便于交流和沟通；消除误解和遗漏。联合小组要有自己的工作制度和计划，不断进行交流一.访谈和会议——案例分析3.2初步需求获取技术开发目标——家庭保安系统家庭保安系统能够识别异常事件（非法进入、水灾、火灾）并采取相应的防范措施。一旦异常事件被相应的传感器识别出来，系统将自动地用电话线向监控中心汇报。系统允许用户对其行为进行可配置的控制。一.访谈和会议——案例分析3.2初步需求获取技术1.建立联合小组：参与者：用户、需求分析人员；工作制度：每次会议有议程、充分准备2.会议讨论，明确问题、范围、环境等等，逐步了解用户需求。会议应有纪录，整理形成文档3.分成二个小组：用户配置控制子系统和传感器监测子系统。目的：对子问题的软件需求进行更全面、细致、准确地工作4.各个小组组合在一起讨论子系统之间的整合以及整个系统的汇总5.形成结论性的需求分析文档二.基于数据流的分析方法3.2初步需求获取技术本质上是运用抽象和分解技术，自顶向下、逐步求精、在不同的抽象层次上理解用户需求的过程。数据流图是问题域中各个处理子功能以及它们之间数据流动的图形表示。数据流图的精化过程实际上是对各个处理子功能（变换）的细化过程，也是对这样一些处理子功能理解和认识上逐步提高的过程。随着精化过程的不断进行，用户需求逐步准确化、一致化和完全化。二.基于数据流的分析方法

1.建立顶级数据流图3.2初步需求获取技术根据问题域与外部环境之间的相互关系定义问题域的边界，即问题域与外界环境之间的输入和输出关系。家庭保安系统顶级数据流图二.基于数据流的分析方法

2.自顶向下，功能分解3.2初步需求获取技术数据流图的分层描述又称为结构化分析（StructuralAnalysis），简称SA法。方法：1.对用户的需求描述进行语法分析：名词或名词短语——潜在的数据流、数据源和外部实体动词——潜在的处理功能。2.结合对需求的理解，确定功能及功能间的数据流，构造出下一级数据流图。可能需要更新数据字典。二.基于数据流的分析方法

2.自顶向下，功能分解3.2初步需求获取技术二.基于数据流的分析方法

2.自顶向下，功能分解3.2初步需求获取技术家庭保安系统各级数据流图二.基于数据流的分析方法

2.自顶向下，功能分解3.2初步需求获取技术数据流图的分层原则：1.正确使用数据流图中的各个图形要素；如一个变换既有输入，又有输出；2.每个数据流、数据源、外部实体在数据字典中均有定义；3.数据流图中最底层的变换必须在变换说明中加以说明；4.父图和子图之间必须保持平衡，即：加细前后的I/O一致。二.基于数据流的分析方法

2.自顶向下，功能分解3.2初步需求获取技术例如：异常数据判断子功能1.参数：传感器有效信息；类别：传感器信息纪录2.处理步骤：(a）将传感器信息传送到用户处理子系统中；(b)根据配置信息，生成报警信息；(c)根据配置信息，获取相应的电话号码，传送给电话拨号子功能；

3.约束条件3.2初步需求获取技术例1：试判断下述分层数据流图是否平衡√√0ABA=a＋b1a2bB0B=a＋bABC1A2aaCC3.2初步需求获取技术例1：试判断下述分层数据流图是否平衡X√3.2初步需求获取技术例2：银行活期储蓄业务数据流图应用举例3.2初步需求获取技术例2：银行活期储蓄业务数据流图顶层图

（0层图）3.2初步需求获取技术例2：银行活期储蓄业务数据流图

——受理业务1层图3.2初步需求获取技术例2：银行活期储蓄业务数据流图

——存款业务1层图3.2初步需求获取技术例2：银行活期储蓄业务数据流图

——取款业务1层图3.2初步需求获取技术例2：银行活期储蓄业务数据流图若有时间请课后自行完成：a)基于上述数据流图试补上后续各层的数据流图b)为上述各图中出现的数据名写出数据字典注：精化过程适可而止如果某一处理子功能可以用简洁、准确的文字来描述清楚，就无需进一步的分解。精化应避免涉及涉及细节。二.基于数据流的分析方法

3.支持数据流分析的CASE工具3.2初步需求获取技术建模(数据流图、数据字典、变换说明等)信息的存储、显示和检索其它工作如一致性检查等等三、简易的应用规格说明技术访谈/面向数据流自顶向下求精方法定义需求时：用户处于被动地位，有意无意地与开发者区分“彼此”。“面向团队的需求收集法”，又称“简易的应用规格说明技术”。用户与开发者形成团队，不分彼此：共同标识问题，指定基本需求。信息系统领域使用的主流技术。三、简易的应用规格说明技术过程：初步访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议，并在开会前预先把写好的产品需求分发给每位与会者。在开会前：每位与会者认真审查产品需求，并不期望每位与会者列出的内容都是毫无遗漏的，但是，希望能准确地表达出每个人对目标系统的认识。三、简易的应用规格说明技术会议：讨论的第一个问题是，是否需要这个新产品；一旦确定需要，每位与会者把各自会前准备好的列表展示出来供大家讨论。大家共同创建一张组合列表。在组合列表中消去冗余，加入了在展示过程中产生的新想法，但是并不删除任何实质性内容。把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。每个小组都展示各自的小型规格说明，供大家讨论。每个与会者都制定出产品的一整套确认标准，并把自己制定的标准提交会议讨论，以创建出意见一致的确认标准。最后，由一名或多名与会者根据会议成果起草完软件需求规格说明书。四.快速建立软件原型是最准确、最有效的需求分析技术实现用户看得见的功能(如，屏幕显示或打印报表)，省略目标系统的“隐含”功能(如，修改文件)。“原型”：演示目标系统主要功能的可运行程序；让用户评估并提出修改意见，从而准确地获取用户的需求。当原型最终被用户接受和确定后，再对目标软件系统进行开发3.2初步需求获取技术四.快速原型方法的需求分析步骤12343.2初步需求获取技术四.快速建立软件原型构建原型的方法：第四代技术：数据库查询和报表语言、程序生成器以及Python，Perl等语言。用于快速地生成可执行代码可重用的软件构件使用一组已有的软件构件来装配(而不是从头构造)原型。构件：数据结构(或数据库)，或软件体系结构构件(即程序)，或过程构件(即模块)。重用构件时，不知其内部工作细节。3.2初步需求获取技术四.快速建立软件原型构建原型的方法：形式化规格说明和原型环境人们已经研究出许多形式化规格说明语言和工具(参见第4章)，用于替代自然语言规格说明技术。今天，形式化语言的倡导者正在开发交互式环境，以便可以调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码，3.2初步需求获取技术一.模型模型：是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。包括一组图形符号和组织这些符号的规则。需求模型：详细、准确地描述了用户对目标软件系统的功能、行为、性能、设计约束等方面的要求。3.3需求建模二、建模是刻画、分析

和解决问题的一种好的方法3.3需求建模为什么需要建模？有助于分析人员全面、系统地了解和分析用户的需求有助于发现用户需求描述中的不一致性、错误和模糊性确保软件需求规格说明书一致化、全面化、准确化需求分析需要建立三种模型：数据模型：实体-联系图数据对象(即实体)之间的关系功能模型：数据流图系统对数据进行变换的功能行为模型：状态转换图系统的各种状态（行为模式）及状态之间的转换一、数据对象3.4实体关系图ER图：从用户角度看到的数据。反映客观现实，与软件的实现无关。数据对象：现实世界中省略了功能和行为的实体，由一组属性来定义。仅有单个值的事物(例如，宽度)不是数据对象。外部实体(例如，产生或使用信息的任何事物)、事物(例如，报表)、行为(例如，打电话)、事件(例如，响警报)、角色(例如，教师、学生)、单位(例如，会计科)、地点(例如，仓库)或结构(例如，文件)等。与面向对象范型中的“类”或“对象”的区别：只表示数据而不表示作用于数据上的操作。数据对象彼此间是有关联的例如，教师“教”课程，学生“学”课程二、属性3.4实体关系图应根据问题，来确定数据对象的一组合适的属性。命名性属性：唯一地表示数据对象，如汽车的车牌号描述性属性：对数据对象的性质进行刻画，如汽车的颜色和型号等等；引用性属性：将该数据对象与其他数据对象联系起来的属性如汽车的车主、制造商；例如：汽车数据对象的属性车牌号型号颜色制造商粤A-00001奔驰500黑色德国奔驰公司三、联系数据对象之间联系/关系分为3种类型：(1)一对一联系(1∶1)如：一个部门有一个经理，而每个经理只在一个部门任职(2)一对多联系(1∶N) 如：每位教师可以教多门课程，但是每门课程只能由一位教师来教。(3)多对多联系(M∶N) 如：一个学生可以学多门课程，而每门课程可以有多个学生来学。联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既依赖于某名特定的学生又依赖于某门特定的课程，既不是学生的属性也不是课程的属性；所以它是学生与课程之间的联系“学”的属性四、实体关系图简介

（Entity-RelationshipDiagrams）

3.4实体关系图实体关系图是一种表示数据对象及其之间相互关系的图形表示语言，它主要有以下几个部分组成：1.实体（数据对象）：2.联系：3.属性：111NMN3.4实体关系图例子：3.5数据规范化目的：数据存储在数据库或文件中，为减少冗余，避免插入异常或删除异常，简化修改数据的过程。通常用“范式(normalforms)”表示消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)冗余程度最小。范式级别越高的代价：存储就需要更多张表，“存储自身”的过程也就越复杂；在需求变化时数据的稳定性较差；性能将下降。从实用角度看来，在大多数场合选用第三范式较恰当P551NF属性不可再分2NF消除部分依赖3NF消除传递依赖一、状态与事件ST图，状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换/变迁的事件，来表示系统的行为。---行为模型状态：可被观察到的系统行为模式正在进行的操作属性集组成的状态空间初态(初始状态)、终态(最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有多个。事件是在某个特定时刻发生的事情，引起系统做动作或转换状态。3.6状态转换图二、符号初态：实心圆表示终态：同心圆(内圆为实心圆)。中间状态：圆角矩形可分成3个部分：状态的名称（必须有）；状态变量的名字和值（可选的）；活动表（可选的）。状态的活动表：事件名(参数表)/动作表达式“事件名”可以是任何事件的名称，经常使用3种标准事件：entry，exit和do。（entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。）需要时可以为事件指定参数表。动作表达式描述应做的具体动作。3.6状态转换图二、符号状态转换／状态变迁：两个状态之间带箭头的连线。通常是由事件触发的，在箭头线上标出触发转换的事件表达式；如果未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。事件表达式：事件说明［守卫条件］／动作表达式事件说明：事件名(参数表)。守卫条件：布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且守卫条件为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。动作表达式：是一个过程表达式，当状态转换开始时执行。3.6状态转换图图3.3状态图中使用的主要符号状态：名称（必选）；状态变量（可选）、活动表（可选）四、例子电话系统的状态图（见书57页图3.4）没有人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态；如果拿起听筒很长时间不拨号(超时)，则进入超时状态；……。一.层次方框图3.7其它图形工具层次方框图采用树型结构的一系列多层次的矩形框描绘数据的层次结构。树型结构的顶层代表完整的数据结构，最底层的各个框代表组成这个数据的实际数据元素。由矩形分层构成的可用于描述数据全集、子集和数据元素间相互关系的树状数据结构图。例：P58图3.5二.J.D.Warnier图3.5辅助图形工具由法国人J.D.Warnier首创，主要用于描述数据的组成结构。也是树形结构，由于只使用{符号、括号和符号，故图形十分简洁。二.J.D.Warnier图3.5辅助图形工具{：属于同一类的信息：其上下方的两个元素只能出现一个括号内的数字：其前方元素在这个数据结构中的出现次数三.IPO(InputProcessOutput)图3.5辅助图形工具由IBM公司首创例：P59图3.7、图3.8IPO图与数据流图中的处理一一对应并由系统管理人员定义编号的排列顺序。一.需求规格说明书的内容3.8验证需求规格说明书1.功能与行为需求描述说明系统的功能和行为，一般通过输入、输出及其相互关系来描述；需求模型是需求规格说明书的主体。2.非行为需求描述说明系统工作时应具备的各种属性：效率，可靠性，安全性，可维护性，可移植性等等。二.需求规格说明书的标准格式一. 引言1. 编写目的2. 项目背景：介绍整个项目的概况，与软件项目计划书衔接3. 术语定义：对本说明书的一些关键术语进行定义4. 参考文献：列出一些对获取用户需求有意义的参考文献二、 系统概述1. 系统目标简述：简要评述系统的主要目标2. 用户特点：例如用户对计算机熟悉程度等3. 假定和约束：总体评价实现系统的一些假定和约束三、系统功能需求规定1. 实体关联图：描述系统主要实体及其关联2. 数据流图：给出数据流图及其分解3.8验证需求规格说明书二.需求规格说明书的标准格式3. 数据字典 •数据存储和数据流描述：描述数据存储和数据流的主要属性及其他特性 •数据加工描述：输入、主要功能、输出、限制、性能要求、启动特性等4. 系统状态转换图：给出系统一些实体的主要状态、系统主要事件和状态转换四、系统性能需求规定1. 输入输出规模方面的特殊要求2. 响应时间方面的特殊要求3. 系统安全性和完整性方面的特殊要求4. 系统故障处理及备份要求5. 其他特殊考虑五、运行环境要求：软硬件环境，与其他软件接口等3.8验证需求规格说明书三.需求规格说明书的目的便于用户、分析人员和软件设计人员进行理解和交流目标软件系统最终的验收和确认的标准控制系统进化过程：判断追加的需求是否是新的需求统计表明：软件系统中15%的错误起源于错误的需求需求评审3.8验证需求规格说明书四.需求评审（验证）要求用户、需求分析人员和设计人员共同参与。评审的内容和标准：1.正确性：SRS中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。2.无歧义性：SRS中描述的每个需求都只有一种唯一的解释。3.完全性：不遗漏用户的任何需求包含希望未来系统所做的任何事；包含未来软件系统在所有可能情况下对所有可能输入的响应；没有任何内容被标为待定；3.8验证需求规格说明书四.需求评审（验证）3.6需求规格说明书与评审4.可验证性：对于任意用户需求，均存在技术和经济上可行的手段进行验证5.一致性：SRS中描述的需求与前面的文档不矛盾；指SRS中陈述的各个需求之间不冲突；6.可理解性：易于理解的7.可修改性：易于修改的8.可跟踪性：SRS必须将分析后获得的每一项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档应用这些需求提供便利。9.可被跟踪性10.设计无关性：SRS中不暗示特定的软件结构或算法；11.注释一.题目要求及分析

开发一个学生学习成绩管理系统，

管理一个系的各个学生的各种学习成绩。3.9实例分析1、主要功能：保存各个学生的成绩，能够随时查询某个学生的成绩，并打印成绩报表能够分班级对学生的成绩进行统计分析（这种功能可能开始是不确定的）2、潜在扩充：扩充到整个学校扩充到更多的分析，如不同班级学生对比，不同年级学生对比分析，并建立数学模型以确定学生成绩走向，并评价教学效果3、功能分析：输入学生成绩、查询学生成绩、打印报表学生成绩的统计分析一.题目要求及分析

开发一个学生学习成绩管理系统，

管理一个系的各个学生的各种学习成绩。3.9实例分析4、数据分析：学生档案，考虑学生档案的详细程度，是学生成绩管理而不是学生管理班级档案，学生与班级的关系，考虑学生是否能够被分在两个班？如参加副修的学生怎样处理？课程档案，考虑不同班级的学生可能开同样的课程，课程通常只是开到班级，不会考虑每个学生，考虑选修课可能有些学生不会选？公共选修课如何处理？学生成绩档案，与学生、班级、课程档案的关系如何处理？学生成绩报表的格式？统计分析结果是否应该保存？统计报表的类别与格式？一.题目要求及分析

开发一个学生学习成绩管理系统，

管理一个系的各个学生的各种学习成绩。3.9实例分析5、用户分析：教务员：负责输入，学生的成绩可以随便修改吗？学生：可以让学生自己查询吗，要经过什么手续？领导：领导需要作为用户吗？6、环境分析：支撑平台，单机或网络，需要上国际互连网吗？7、性能分析：查询的响应速度，特别是如果在国际互连网上运行？学生的人数，以及学生成绩数据的规模？统计分析的速度？8、其他分析：学生成绩的统计分析是否需要有数学模型支持？二.实体关联图3.9实例分析实体关联图中要描述以下成份：数据对象或实体：用来描述系统必需理解和处理的复合信息，所谓复合指它还有自己的属性和结构。通常实体是一个抽象的集合，它包含许多实体实例。属性(Attribute)：用来描述数据对象的性质。用以区分实体中不同实例的属性——关键字用来描述实体不同性质的属性——依赖于关键字引用其他实体实例的属性——外来关键字关联：描述实体之间相关关系。一对一关联、一对多关联、多对多关联二.实体关联图1.对实体及其属性的考虑：学生：学号(关键字)、姓名、性别、年龄、所属班级(学生属性的设置与对学生成绩的统计分析要求有关)班级：班级编号、班级名称、系别专业、年级课程：课程编号、课程名称、课程描述、教材（可要可不要）成绩：学生学号、课程编号、成绩思考：分析报告？教务员？用户？选课记录？2.实体之间的关联关系：学生属于一个班级学生要选课，每个学生选每一课都有一个成绩二.实体关联图3.实体关联图：学生班级属于选课课程成绩NM11M三.数据流图1、加工分解：