第3章 需求分析(NEW).pptVIP

教学目标: 了解需求分析的任务和步骤、评审标准和过程 掌握需求分析的基本技术,理解需求规格说明书的作用与组成 什么是软件需求？ 软件需求指用户对所开发的软件在功能、性能、运行环境、可靠性等各方面的要求。 需求分析的基本任务是什么？ 它的基本任务是准确地回答“系统必须做什么？”这个问题,也就是对目标系统提出完整、准确、清晰、具体的要求。 系统分析员的主要焦点是 “做什么（what）” ，不是 “怎样做（how）” 用《需求规格说明书》规范的形式准确地表达用户的需求。 3.1需求分析概述 3.1.1需求分析的任务 3.1.2需求分析的原则 3.1.3需求分析的过程 需求获取 需求描述 需求评审 3.1.4需求分析方法 3.1.1需求分析的任务 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统的开发计划 3.1.2需求分析的原则 理解表达问题的信息域，用数据模型描述 定义软件将完成的功能，用功能模型描述 表示描述作为外部事件结果的软件行为，用行为模型描述 必须对描述信息、功能和行为模型进行分解，用层次的方式展示细节 3.1.3 需求分析的过程 步骤1:需求获取 任务 清楚地理解所要解决的问题 完整地获取用户需求 需求获取面临的挑战 需求获取面临的三大挑战 (1)空间问题的理解 (2)人与人之间的交流 (3)需求易变性 需求获取的原则: 和用户进行交流和合作，获取并理解用户需求 将对原始问题理解与软件开发经验结合,清除用户需求的不一致性, 模糊性和歧义性，帮助用户发现潜在的需求 步骤2:需求描述阶段 任务 对用户需求进行建模，生成软件需求说明书和初步用户手册 软件需求说明书: 用户需求(功能, 行为, 性能等) 用户手册:如何操作和使用目标软件，界面描述和使用初步构想，目的… 原则 确保需求说明书的完整性、一致性和准确性 鼓励用户参与软件需求说明书以及用户手册的制定 尽可能做到软件需求说明书结构清晰，措辞准确和简洁 步骤3:需求分析评审 任务 多方人员一起对软件需求说明书进行复核和评审，以确保用户手册和软件需求说明书全面、准确、一致地反映用户需求 原则 支持各方（用户，需求分析人员、设计人员）共同参与评审工作 步骤3:需求分析评审 评审内容 系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述; 被开发项目的数据流与数据结构是否足够，确定; 所有图表是否清楚，在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内，是否都已充分说明; 需求分析评审 评审内容 设计的约束条件或限制条件是否符合实际; 开发的技术风险是什么; 是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认; 3.1.4 需求分析方法 常见的分析方法有： 1、访谈 2、面向数据流自顶向下求精 3、简易的应用规格说明技术 4、快速建立软件原型 §3.2.1 访谈 分正式和非正式访谈。 可采用调查表形式 可使用情景分析技术 某出版社系统调查表 某出版社系统调查表 §3.2 面向数据流自顶向下求精 结构化分析方法的实质 进一步细化可行性研究阶段获得到高层数据流图。包括建立： 详细的数据流图，描绘数据在软件系统内从输入移动到输出的过程中所经受到变换； 数据字典：定义数据流图中包含的元素； 实体关系（ ER ）图：从用户角度描述数据； IPO 图：描述数据流图中处理框的功能和算法。 面向数据流自顶向下求精过程 §3.2.3简易的应用规格说明技术 一种面向团队的需求收集法，提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。 具体过程见教材 P60 §3.2.4快速建立软件原型 快速原形就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。 要点： 实现用户看得见的功能，省略目标系统“隐含”功能。 3.3 分析建模与规格说明 3.3.1 分析建模 模型，是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。 构造模型的过程是一个抽象、分析的过程。 例：结构化分析方法建立的需求模型 实体关系图(Entity-Relationship Diagram,E-R图)来创建数据模型，描述系统中所有重要的数据对象； 数据流图（Data Flow Diagram,DFD） ：用来创建功能模型，描述了信息流和数据转换。 状态转换图 （State-Transition Diagram,STD）用来创建行为模型，描述系统状态如何响应外部事